[ZhengGong-amd]

Motivation

amd/MiniMax-M3.1-Flash-Quark-MXFP4 crashes at load because its MXFP8 shared experts are fused into the packed MXFP4 routed-expert slot, so this PR makes the Quark fusion gate probe every named MoE layer and has the MiniMax-M3 hooks ask that gate.

RuntimeError: The size of tensor a (384) must match the size of tensor b (768) at non-singleton dimension 1

QuarkConfig.can_fuse_shared_expert() compares routed and shared specs only at layer 0 and the NextN block. When layer 0 is a dense MLP (MiniMax-M3, DeepSeek-V3, GLM-5.x, Kimi-K2.x), both lookups fall back to the global spec and agree, whatever the MoE layers hold. The MiniMax-M3 hooks never ask the gate anyway: they refuse only modelopt_mixed and minimax_m3_nvfp4.

Modifications

• quark: can_fuse_shared_expert() also probes every target decoder layer whose routed or shared experts are named in layer_quant_config, so one mismatched layer refuses fusion in any entry order. Draft entries (mtp.*, NextN layers past num_hidden_layers, non-layers.<N> bases such as model.mtp.0) are skipped, so an FP8 MTP block still vetoes fusion only for the draft.
• minimax: both MiniMax-M3 hooks call quant_blocks_shared_experts_fusion(quant_config), as DeepSeek-V2/V3/V4 do. The name list stays because MiniMaxM3Nvfp4Config does not implement the gate.

The checkpoint now loads unfused and logs why, the path --disable-shared-experts-fusion selects today. Across 13 local Quark checkpoints only this one changes (fused → unfused); MiniMax-M3, GLM-5.x, DeepSeek-R1-0528, Kimi-K2.6, Muse-Spark and Qwen3.5 MXFP4 exports keep their decision.

Correct output also needs the MXFP8 scale handling from #46693, #46587 and #44080 (on main 2160 weight_scale not found in params_dict). #46587 instead requantizes the shared expert to MXFP4 to keep fusion; Quark leaves lossy conversion opt-in via --enforce-shared-experts-fusion.

Accuracy Tests

4×MI355X, TP4, SGLANG_USE_AITER=1, main@6393e66b86 plus the same scale handling in every arm. GSM8K via sglang.test.run_eval, 5-shot chat, temperature 0, 1314 items.

Arm	Load	GSM8K
default	crash (fusion enabled)	—
--disable-shared-experts-fusion	ok	0.9665, 0.9673
this PR, default	ok, fusion disabled	0.9627, 0.9665

Both loading arms run the same unfused path; differences are within noise (stderr ±0.005).

New tests in test_quark_config.py and test_shared_experts_fusion_gates.py cover dense leading layers, both entry orders, named routed experts, NextN drafts and a real QuarkConfig in M3.1's layout; 106 pass.

Speed Tests and Profiling

Not a speed change: the fused path does not load on main.

Checklist

• Format your code according to the Format code with pre-commit.
• Add unit tests according to the Run and add unit tests.
• Update documentation according to Write documentations. Not needed.
• Provide accuracy and speed benchmark results according to Test the accuracy and Benchmark the speed.
• Follow the SGLang code style guidance.

---

Found by Hyperloom.

---

CI States

Latest PR Test (Base): ❌ Run #40823923906
Latest PR Test (Extra): ❌ Run #40823923805
Latest PR Test (AMD ROCm 10): ⏳ Run #40823923811

[BBuf]

@ZhengGong-amd _first_named_shared_expert_layer() makes this global fusion decision depend on quant-config insertion order. I reproduced this with the actual config helpers: routed experts use FP4, layer 3 shared experts use FP4, and layer 4 shared experts use FP8. Listing layer 3 first returns True; reversing the same entries returns False. The True case still enables fusion for the incompatible later layer. Could you check every distinct matching target-model MoE layer, or conservatively disable fusion when their schemes differ? One compact regression covering both entry orders should be enough.

[chaojhou]

/tag-and-rerun-ci

[BBuf]

Thanks, checking all named target MoE layers resolves the ordering and later-layer mixed-precision issues. The regression covers both entry orders and excludes draft layers. LGTM; please wait for the relevant quantization CI before merging.