[michaelzhang-ai]

What

Adds a MI35x nightly accuracy gate for MiniMax-M3.1-Flash that runs the cookbook's MI355X / Flash / MXFP4 / Low-Latency / single-node / DSpark cell:

• Test: test/registered/amd/accuracy/mi35x/test_minimax_m31_flash_mxfp4_eval_mi35x.py
• Suite: nightly-amd-4-gpu-mi35x-minimax-m31-flash-mxfp4
• Job: nightly-4-gpu-mi35x-minimax-m31-flash-mxfp4 on linux-mi35x-gpu-8 (TP4), 5400 s per-file cap

The server uses the cookbook command unchanged: amd/MiniMax-M3.1-Flash-Quark-MXFP4, SGLANG_USE_AITER=1, TP4, DSpark with block verification and the draft bundled in the checkpoint, breakable prefill graphs, the aiter FP8 GEMM backend, and the minimax-m3 parsers. GSM8K runs through sgl-eval on the full split (1319 questions, 8192 max tokens, temperature 1.0, top_p 0.95) with a 0.93 threshold. These match the H200 and B300 M3.1 nightlies in #46627, so all three gates read the same way.

Depends on

• [Feat] [AMD] minimax: Support MiniMax-M3.1-Flash on MI350X / MI355X (gfx950) #46693 (with the kernel PRs [Feat] [AMD] minimax: gfx950 sparse attention, NVFP4 KV and DSpark verify kernels #46690, [Feat] [AMD] minimax: gfx950 MoE, router GEMV, block-fp8 GEMM and fp8 producer kernels #46691, [Feat] [AMD] distributed: JIT quick all-reduce for TP4 on gfx950 #46692), which adds the gfx950 M3.1 path. On main today the Quark checkpoint has no ROCm path for DSpark or the MXFP4 experts.
• [Fix] [AMD] MiniMax-M3.1-Flash-Quark-Mxfp4: requantize the FP8 shared expert so fusion can load #46587, which lets amd/MiniMax-M3.1-Flash-Quark-MXFP4 start with shared-experts fusion left on, as in the cookbook command. Without it the server fails at weight load.

This PR stays in draft until those land.

Notes for the reviewer

• Threshold: 0.93, as in the NVIDIA M3.1 nightlies. This checkpoint measured 0.9575 on rocm720 (below).
• DSpark accept length is gated at 3.8, also as on B300. It measured 4.21 on rocm720.
• rocm10: at [Feat] [AMD] minimax: Support MiniMax-M3.1-Flash on MI350X / MI355X (gfx950) #46693's 9ed330c the server hung after 71 of 1319 questions. At 6719205 rocm10 passes (below). That head drops the ROCm 7.2-tuned hipBLASLt rows on other ROCm versions, among other changes; I haven't isolated which commit fixed the hang.
• Only the MXFP4 cell is covered. The NVFP4 checkpoint on MI355X runs the same command and could be added as a second class on the same job later.

Test plan

Run on a branch with main at ec3365d plus #46693 and #46587 merged in, and this test (michael/minimax-m31-mxfp4-validate). #46587 conflicts with #46693 in quark.py; the branch keeps both changes and enables #46587's E8M0 scale decode only when #46693's MXFP8 path is off.

ROCm	Result	GSM8K	Accept length	Test time	Run
rocm720, #46693 at 9ed330c	pass	0.9575	4.21	765 s	job
rocm10, #46693 at 9ed330c	hang after 71/1319	-	-	5400 s (cap)	job
rocm10, #46693 at 6719205	pass	0.9553	4.14	705 s	job

The first rocm10 attempt failed while downloading the checkpoint: the rocm720 job, on another runner sharing the model cache, deleted the in-progress download. That is a CI cache race, not this test.

• The workflow parses with PyYAML, and the new job is in the job_select options and in check-all-jobs.needs.
• The CI registry parser picks up the file under the new suite. The file compiles and passes black and isort.

---

CI States

Latest PR Test (Base): ❌ Run #40735456071
Latest PR Test (Extra): ❌ Run #40735455771
Latest PR Test (AMD ROCm 10): ❌ Run #40735456069