feat(mori-v2): let the MoE dispatch wire be chosen, for the fp4 GEMM it feeds - #2018
Open
jhchouuu wants to merge 1 commit into
Open
feat(mori-v2): let the MoE dispatch wire be chosen, for the fp4 GEMM it feeds#2018jhchouuu wants to merge 1 commit into
jhchouuu wants to merge 1 commit into
Conversation
…it feeds Dispatch ships bf16 and every receiver quantizes the copy it got, so a token routed to topk peers is quantized topk times on the same values. MegaMoE can quantize once on the sender instead and forward the e8m0 row with the token, which is what MEGA_WIRE=fp8|fp4 selects. The wire is not a free choice: the receiver hands the payload to the expert GEMM as its A operand, so it has to be the format that GEMM wants. The EP4 serve script already runs a4w4 (AITER_FORCE_A8W4=0), so fp4 is the matching wire and fp8 would be a row-WIDTH error rather than a slower path. Both values are logged on one line for exactly that reason. Read once at import (this runs per MoE layer, 61x for DSV4-Pro) and passed to MegaMoE explicitly rather than left to aiter's own read of the env: this is the layer that owns the cco arena and the transport cache, so the value it keyed on and the value the transport was built with cannot drift. It is in the cache key because it changes the arena layout -- payload width, and whether an out_scales region exists at all -- so a transport built for another wire is not substitutable. Default is bf16: unchanged behaviour unless WIRE=fp4 is passed to scripts/dsv4/serve_dsv4_ep4.sh. That script lives outside any git repo, so the knob there ships in the image but is not tracked here.
Contributor
🏷️ CI GuideRuns automatically on every eligible PR before approval:
Heavy model tests:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Lets the MoE dispatch wire be chosen for the mori-v2 (MegaMoE) path, so it can ship an already-quantized payload instead of bf16:
Why
Dispatch ships bf16 today and every receiver quantizes the copy it got, so a token routed to
topkpeers is quantizedtopktimes on the same values. Quantizing on the sender does it once per local token and shrinks the wire; at hidden 7168 a token crosses as 14336 B on bf16, 7424 on fp8, 3840 on fp4.The wire has to match the expert GEMM's A operand — on gfx1250 that is fp4 unless
AITER_FORCE_A8W4=1. A mismatch is a row-width error, not a slow path, sowire=andforce_a8w4=are logged on the same line: a failed start is then readable instead of a width assert with no context.Measured
DSV4-Pro on 4x gfx1250, DP4 + EP4 + fake-eplb, ISL/OSL 1024/1024, concurrency 2048, 8192 requests:
MEGA_WIRE=fp4Two containers off the same image on the same box, only the env var differing. At the MoE-layer level the same change is −6.4% per layer at 16384 tokens/rank, all of it in dispatch.
Output is bit-identical either way — MX quant is destination-independent, so moving it to the sender changes no bytes (
test_mega_moe_gfx1250.pyscores 0.042041 against an fp32 reference on both wires).Depends on
ROCm/aiter#4984, which adds
MegaMoEGfx1250(dispatch_wire=...)and the quantizing wire behind it. Without it thedispatch_wire=keyword is unknown and construction raises — including on the bf16 default — so this should land after it.The quantizing wire additionally needs a mori that forwards a per-token scale row (ROCm/mori#593); aiter raises a message naming it if you ask for fp8/fp4 without one. The bf16 default needs neither.
Note on the launch script
MEGA_WIREis read from the environment, and the DSV4 serve scripts under/app/scriptsare not part of this repo, so turning the wire on is a launch-time change:Confirm it took effect from the startup log:
🤖 Generated with Claude Code