Skip to content

feat(mori-v2): let the MoE dispatch wire be chosen, for the fp4 GEMM it feeds - #2018

Merged
junhaha666 merged 2 commits into
ROCm:mainfrom
jhchouuu:jhchouuu/mega-moe-dispatch-wire
Sep 1, 2026
Merged

junhaha666 merged 2 commits into
ROCm:mainfrom
jhchouuu:jhchouuu/mega-moe-dispatch-wire

Conversation

@jhchouuu

@jhchouuu jhchouuu commented Aug 25, 2026 •

Copy link
Copy Markdown
Contributor

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:

MEGA_DISPATCH_WIRE=bf16 | fp8 | fp4      default bf16 -- unchanged behaviour

Why

Dispatch ships bf16 today and every receiver quantizes the copy it got, so a token routed to topk peers is quantized topk times 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, so wire= and force_a8w4= are logged on the same line: a failed start is then readable instead of a width assert with no context.

A quantizing wire also runs only on mori's dispatch, which is the only one that carries the scale row, so this layer names that backend rather than leaving it to $MEGA_DISPATCH (whose default is flydsl).

Measured

DSV4-Pro on 4x gfx1250, DP4 + EP4 + fake-eplb, ISL/OSL 1024/1024, concurrency 2048, 8192 requests:

bf16 wire fp4 wire
total token throughput 57851.6 tok/s 60226.5 tok/s +4.1%
mean TTFT 11967.9 ms 11248.0 ms −6.0%
mean TPOT 58.93 ms 56.79 ms −3.6%
benchmark duration 290.0 s 278.6 s −3.9%

Two 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.py scores 0.042041 against an fp32 reference on both wires).

Usage

The DSV4 serve scripts under /app/scripts are not part of this repo, so turning the wire on is a launch-time change:

MEGA_DISPATCH_WIRE=fp4 python -m atom.entrypoints.openai_server -tp 4 --model ... \
  --enable-expert-parallel --enable-dp-attention ...

Confirm it took effect from the startup log:

[MORI-V2] Created MegaMoE: ... dispatch=mori wire=fp4 force_a8w4=0

MEGA_WIRE was the name during development. It now raises rather than falling back, because an env var that is silently ignored would serve bf16 while the operator believed they were on fp4. Setting both names to the same value is allowed, so a fleet can be rolled over one script at a time.

Depends on

ROCm/aiter#4984, which adds MegaMoEGfx1250(dispatch_wire=...) and the quantizing wire behind it. Without it the dispatch_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, merged); aiter raises a message naming it if you ask for fp8/fp4 without one. The bf16 default needs neither.

🤖 Generated with Claude Code

…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.
@github-actions

Copy link
Copy Markdown
Contributor

🏷️ CI Guide

Runs automatically on every eligible PR before approval:

  • ✅ Pre Checkin: Black, Ruff, catalog schema validation, non-GPU unit tests

Heavy model tests:

  • ✅ Run after the PR is approved and Pre Checkin passes
  • ✅ Run immediately when an approval review is submitted
  • ✅ Can be requested before approval with labels
Label Tests
ci:full Run all heavy PR model tests: native ATOM, vLLM, and SGLang
ci:atom Run native ATOM model accuracy tests
ci:vllm Run ATOM vLLM OOT model accuracy tests
ci:sglang Run ATOM SGLang model accuracy tests

Heavy jobs are skipped when the PR is not approved and no matching ci:* label is present.
Add labels via the sidebar or gh pr edit 2018 --add-label <label>

@zufayu
zufayu requested a review from JiaoliangYu August 26, 2026 00:58
Combine will want a wire of its own, so the unqualified name goes while it is
still unreleased. The stale name raises here too: this module passes
dispatch_wire= down explicitly, so aiter's own env read -- and its guard --
never runs for us, and a silently ignored MEGA_WIRE would serve bf16 while
the operator believed they were on fp4.
@junhaha666
junhaha666 merged commit 761b148 into ROCm:main Sep 1, 2026
49 of 51 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants