[AMD][CI] Add DeepSeek-V4-Flash FP8 accuracy coverage on MI30x

[michaelzhang-ai]

MI30x only. The V3.x drop was split out of #36388, which now carries only its MI35x half.

Motivation

DeepSeek-V4 has no gfx942 coverage: every DSV4 job in the repo runs on linux-mi35x-gpu-8, and this workflow's V4 section was literally commented MI35x only. Meanwhile the cookbook publishes three verified: true MI300X Flash FP8 cells, so the docs call MI300X a supported DSV4 target while CI has never once run DSV4 there.

Separately, nightly-8-gpu-deepseek-v31 and nightly-8-gpu-deepseek-v3-kv-fp8 do not test what their names say — both serve deepseek-ai/DeepSeek-V3-0324 for accuracy, and only the v31 perf step serves V3.1. Every MI30x path they exercise (aiter MLA, EAGLE MTP, enable_multithread_load, bs=1 send_one) is covered by the retained V3.2 jobs on a current checkpoint.

Together this is one trade: stop paying 32 GPU-h/night for two jobs on a superseded checkpoint, and spend a fraction of it on the model with no gfx942 signal at all.

Modifications

1. New job nightly-8-gpu-deepseek-v4-flash on linux-mi300-8gpu-sglang, running the new test/registered/amd/test_deepseek_v4_flash_fp8_mi30x.py via the new nightly-amd-accuracy-8-gpu-deepseek-v4-flash suite.

The launch config is the cookbook's mi300x | flash | fp8 | low-latency | single cell verbatim — the only TP-only MI300X strategy published, so the narrowest cell that still covers the gfx942 serving path. Accuracy only: gfx942 has no DSV4 perf baseline to regress against, and the MI35x jobs carry the throughput numbers. GSM8K uses the same 8-shot / 1319-question eval as the MI35x FP8 test, with a > 0.90 floor. Blocking in check-all-jobs.

Depends on #36405: the cell as published omits SGLANG_DSV4_FP4_EXPERTS=0 and cannot load its own checkpoint on a cold cache. The test sets it, and the set-equality check below is stated against the cell as fixed there.

2. Dropped nightly-8-gpu-deepseek-v31-rocm720 and nightly-8-gpu-deepseek-v3-kv-fp8-rocm720, with their job_select options and check-all-jobs needs. All four test files stay registered, so the three suites remain reachable from workflow_dispatch — the same outcome #34761 documented for nightly-amd-accuracy-8-gpu-grok1-fp8.

MLA + KV-FP8 on gfx942 stays gated rather than lost: the cookbook recipe runs --kv-cache-dtype fp8_e4m3 and the new job blocks, so dropping the V3 KV-FP8 job leaves no gap, on a current model instead of V3-0324. The ROCm 7.0 nightly still schedules both dropped jobs and is untouched here.

On #36390. That issue reports DSV4-Flash FP8 degrading with context length on MI300X. It runs --attention-backend aiter with --dsa-{prefill,decode}-backend aiter; this recipe runs --attention-backend dsv4. The pass below does not contradict the report — it localizes it to the aiter path, which no CI job covers on any architecture. A follow-up job for that path is a reasonable next step and is not attempted here.

Accuracy Tests

Two runs on 8x MI300X, both dispatched with rocm_version=rocm720 and continue_on_error=false so a failure is loud, both green:

Run	GSM8K	invalid
32918680921	0.9174	0.000
33023346555	0.9257	0.000

For reference, the MI35x DSV4-Flash suite spans 0.9189–0.9310 (mean 0.9251) over its last three nightlies, so MI300X sits inside the same band.

On the 0.90 floor. The first revision used 0.91, inherited from the MI35x FP8 test for comparability, on one observation. The second run showed the two MI300X values span 0.83 points — wider than the MI35x per-test run-to-run sd of ~0.0019, which is expected given this recipe adds KV-FP8 and EAGLE. At that spread 0.91 sits ~2 sd below the mean, about one spurious failure per forty nights on a job that blocks check-all-jobs; 0.90 is >3.5 sd out under either sd estimate. It does not weaken the gate in any way that matters — the failure modes this exists to catch (see #36390) collapse output entirely rather than costing a point of GSM8K. Comparability with MI35x is preserved in the measured numbers rather than in a shared threshold.

Static validation:

• pre-commit passes, including check for duplicate workflow job names, validate registered test CI registries and check yaml
• the test's env and flags are set-equal to the cookbook cell as fixed by [Docs][Cookbook] AMD DeepSeek-V4 FP8 cells are missing SGLANG_DSV4_FP4_EXPERTS=0 and cannot load on a cold cache #36405 (checked by parsing both files)
• job set delta against main is exactly -nightly-8-gpu-deepseek-v31-rocm720, -nightly-8-gpu-deepseek-v3-kv-fp8-rocm720, +nightly-8-gpu-deepseek-v4-flash-rocm720 (46 jobs to 45); no dangling job_select option or check-all-jobs need, and no removed job referenced anywhere in the repo
• the new suite resolves to exactly the one new file, and the dropped jobs' three suites still resolve to their test files
• trial-merged with [AMD][CI] Move the MI35x DeepSeek-V4-Flash nightly to the official 0731 checkpoint (blocked: triton FlashMLA accuracy regression) #36388: no conflict
• the diff is MI30x-only; every MI35x job is byte-identical to main

Speed Tests and Profiling

Measured from run 32757901075, summed over both image flavors: dropping nightly-8-gpu-deepseek-v31 frees 17.4 GPU-h/night and nightly-8-gpu-deepseek-v3-kv-fp8 frees 14.7. The new job is a single 8-GPU accuracy step that took 42 min on its first run. Net reduction, and 2 fewer 8-GPU MI30x job slots.

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
• Provide accuracy and speed benchmark results according to Test the accuracy and Benchmark the speed.
• Follow the SGLang code style guidance.

---

CI States

Latest PR Test (Base): ❌ Run #33026136250
Latest PR Test (Extra): ❌ Run #33026136082
Latest PR Test (AMD ROCm 7.2): ❌ Run #33026135973

[RolaoDenthu]

LGTM