[DSv4][bring-up] FP8 MI300X SGLang benchmark / DSv4 FP8 MI300X SGLang 基准（bring-up）#2194
[DSv4][bring-up] FP8 MI300X SGLang benchmark / DSv4 FP8 MI300X SGLang 基准（bring-up）#2194Oseltamivir wants to merge 13 commits into
Conversation
Oseltamivir
requested review from
1am9trash,
billishyahao,
chunfangamd,
seungrokj and
yctseng0211
as code owners
|
Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase For PR verification, add the PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs 感谢你的贡献！请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md，然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人，你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板，包括保留英文语句 如需进行 PR 验证，请为此 PR 添加 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档 |
2 similar comments
|
Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase For PR verification, add the PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs 感谢你的贡献！请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md，然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人，你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板，包括保留英文语句 如需进行 PR 验证，请为此 PR 添加 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档 |
|
Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase For PR verification, add the PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs 感谢你的贡献！请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md，然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人，你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板，包括保留英文语句 如需进行 PR 验证，请为此 PR 添加 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档 |
New SKU — no prior DeepSeek-V4-Pro data on gfx942. Extrapolated per recipes.vllm.ai/deepseek-ai/DeepSeek-V4-Pro from the same-model MI355X entry (search-space shape, deepseek_v4 flags), the same-SKU dsr1-fp8-mi300x-sglang (gfx942 AITER infra), and the H200 dsv4 FP8 path (--quantization deepseek_v4_fp8). gfx942 has no native FP4, so the ~960GB mixed checkpoint runs in FP8 (~1.05TB), which only fits TP8 on 8x192GB — MI355X TP4 bands dropped. Sweep: TP-only low-latency (conc 1-32) + DP-attn/ EP8 throughput (conc 64-2048), 1k1k + 8k1k. Unvalidated on-cluster: needs debug-runs to confirm the mi30x image has the DeepseekV4 class + --attention-backend dsv4 / --quantization deepseek_v4_fp8 on gfx942. 中文：搭建 MI300X 上 DeepSeek-V4-Pro FP8 单节点 SGLang 脚手架（依据 recipes.vllm.ai 及同型号 MI355X、同 SKU dsr1-mi300x 外推；FP8 仅 TP8 可 放下故去掉 TP4）。尚未集群验证。
Oseltamivir
force-pushed
the
dsv4-mi300x-fp8-bringup
branch
from
8b57f42 to
8d17594
Compare
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| --host=0.0.0.0 --port $PORT \ | ||
| "${PARALLEL_ARGS[@]}" \ | ||
| --trust-remote-code \ | ||
| --quantization deepseek_v4_fp8 \ | ||
| --kv-cache-dtype fp8_e4m3 \ | ||
| --attention-backend dsv4 \ |
There was a problem hiding this comment.
🔴 This script passes --quantization deepseek_v4_fp8 to sglang serve, but that value is a vLLM-only QuantizationMethods enum (used in dsv4_fp8_h200.sh, a vLLM script) — SGLang's --quantization is an argparse choices flag that will reject it and fail server startup for all 24 configs in the sweep. Every existing SGLang recipe for this model (dsv4_fp8_h200_sglang.sh, dsv4_fp4_mi355x_sglang.sh) omits --quantization entirely and relies on the checkpoint config / AITER FP8 MoE path instead — this script should do the same.
Extended reasoning...
The bug: dsv4_fp8_mi300x.sh line 99 passes --quantization deepseek_v4_fp8 to sglang serve. That string, deepseek_v4_fp8, is a value from vLLM's QuantizationMethods enum — it is used correctly in dsv4_fp8_h200.sh:65, which is a vllm serve script for the same model. SGLang has its own, separate --quantization flag defined as an argparse choices-constrained enum (fp8, awq, gptq, w8a8_fp8, modelopt, etc.), and deepseek_v4_fp8 is not one of its members.
Why this triggers a hard failure, not a soft fallback: argparse choices validation happens at CLI-parse time, before the server process does any model loading. An unrecognized value causes SGLang to exit immediately with a parse error — there is no fallback path, no warning-and-continue. Since every one of the 24 generated sweep configs (both the TP-only low-latency band and the DP-attn/EP8 throughput band, across 1k1k and 8k1k) routes through this single sglang serve invocation, all 24 jobs in the sweep would fail identically at server startup.
Why existing code doesn't already guard against this: this is a copy-paste/analogy error introduced by this PR's extrapolation process, not a pre-existing gap. The PR description explicitly says the FP8 quantization flag was derived 'from the H200 dsv4 recipe' — but that recipe is a vLLM script, and the flag doesn't carry over to SGLang. The two SGLang precedents that actually exist for this model both omit --quantization: dsv4_fp8_h200_sglang.sh uses --moe-runner-backend marlin with no --quantization, and dsv4_fp4_mi355x_sglang.sh (this script's own stated template for search-space shape and deepseek_v4 model flags) also has no --quantization. Both rely on the checkpoint's own config plus the AITER/marlin MoE runner path to select precision.
Step-by-step proof:
- PR adds
dsv4_fp8_mi300x.sh, which is wired intoconfigs/amd-master.yamlas `dsv4-fp8-mi300x-sglang", generating 24 sweep configs (2 seq-len scenarios × 2 search-space bands × conc points). - Every config invokes the same script, which at line 99 runs
sglang serve ... --quantization deepseek_v4_fp8 .... - SGLang's serve argument parser validates
--quantizationagainst its fixedchoiceslist;deepseek_v4_fp8is absent from that list (it is a vLLM-only enum value, confirmed by grepping the repo: the string appears only indsv4_fp8_h200.shanddsv4_fp8_h200_mtp.sh, bothvllm servescripts). - Argparse raises an error and the process exits before the model or GPU is even touched — the server never reaches
wait_for_server_ready. - Since all 24 configs share this one launch path, every job in the sweep fails identically at this step.
The fix: drop --quantization deepseek_v4_fp8 from the sglang serve invocation (line 99) and let SGLang infer precision from the checkpoint config, following the pattern in dsv4_fp8_h200_sglang.sh (no --quantization, relies on --moe-runner-backend marlin) or dsv4_fp4_mi355x_sglang.sh (no --quantization at all, relies on AITER). The PR description itself already flags this exact flag as needing on-cluster confirmation with a documented fallback ('use the AITER FP8 MoE path without an explicit quant flag'), so this is a known risk the author anticipated — but as committed, it's a concrete correctness bug that will break server startup for the entire sweep, not just a hypothetical edge case.
| description: | ||
| - "Add DeepSeek-V4-Pro FP8 single-node MI300X SGLang benchmark (new SKU, previously no dsv4 data on gfx942)" | ||
| - "Extrapolated from the same-model MI355X entry (dsv4-fp4-mi355x-sglang) for search-space shape + deepseek_v4 model flags, and from the same-SKU dsr1-fp8-mi300x-sglang for gfx942 AITER infra; FP8 path (--quantization deepseek_v4_fp8) follows the H200 dsv4 recipe since gfx942 has no native FP4" | ||
| - "Search space mirrors MI355X (TP-only low-latency conc 1-32 + DP-attn/EP8 throughput conc 64-2048) but drops the MI355X TP4 bands: the ~960GB mixed checkpoint is ~1.05TB in FP8 and only fits TP8 on 8x192GB" | ||
| - "Image lmsysorg/sglang-rocm:v0.5.15-rocm720-mi30x-20260713 (mi30x variant of the MI355X sglang-rocm dated-tag family)" | ||
| pr-link: PLACEHOLDER |
There was a problem hiding this comment.
🔴 The new dsv4-fp8-mi300x-sglang changelog entry sets pr-link: PLACEHOLDER (perf-changelog.yaml:4761), which is not a value utils/validate_perf_changelog.py recognizes (PR_LINK_PLACEHOLDERS only accepts XXX or the literal pull/XXX URL). PR-time CI never checks this, but the automated /reuse-sweep-run merge path (utils/prepare_perf_changelog_merge.py → compare_entries → validate_added_pr_link) does, and will raise ChangelogValidationError, aborting the merge. Please change it to XXX or the actual URL (#2194).
Extended reasoning...
The bug: perf-changelog.yaml:4761 sets pr-link: PLACEHOLDER for the newly appended dsv4-fp8-mi300x-sglang entry. This is a one-off, non-standard value — every other unmerged entry in the file either carries a real PR URL or the documented convention of literal XXX (see AGENTS.md:160). utils/validate_perf_changelog.py defines PR_LINK_PLACEHOLDERS = {\"XXX\", \"https://github.com/SemiAnalysisAI/InferenceX/pull/XXX\"} — PLACEHOLDER is not a member of that set, and is not the entry'''s eventual real URL either.\n\nWhy PR-time CI misses it: The run-sweep.yml CI check invokes validate_perf_changelog.py'''s main(), which only calls validate_matrix_compatible_change → validate_generated_config (i.e. process_changelog.py). That path never calls compare_entries/validate_added_pr_link, so the placeholder sails through PR-time validation — consistent with the PR description'''s claim that validate_perf_changelog.py --base-ref main passes.\n\nWhere it actually breaks: The documented reuse-merge path (CONTRIBUTING.md, the /reuse-sweep-run skill / merge-prs skill) runs utils/merge_with_reuse.sh, which — under set -euo pipefail — unconditionally invokes utils/prepare_perf_changelog_merge.py. That script'''s canonicalize_appended_links calls compare_entries(base, head, pr_number) with the real PR number (2194) now known. compare_entries calls validate_added_pr_link for each newly-added entry; since the link is neither in PR_LINK_PLACEHOLDERS nor equal to the expected https://github.com/SemiAnalysisAI/InferenceX/pull/2194, it raises ChangelogValidationError. Because the merge script has no error handling around this call, the whole automated reuse-merge aborts.\n\nStep-by-step proof:\n1. PR #2194 is opened; perf-changelog.yaml gains the entry with pr-link: PLACEHOLDER.\n2. run-sweep.yml CI runs validate_perf_changelog.py --base-ref main at PR time — passes, because that path never touches pr-link values.\n3. PR is approved and someone runs the /reuse-sweep-run merge flow (or the merge-prs skill), which shells out to utils/merge_with_reuse.sh with PR number 2194.\n4. The script calls prepare_perf_changelog_merge.py, which calls canonicalize_appended_links(..., pr_number=2194).\n5. That function calls compare_entries(base_content, head_content, 2194), which iterates newly-added changelog entries and calls validate_added_pr_link(entry, 2194) on each.\n6. For the new entry, link = \"PLACEHOLDER\"; the function checks link in PR_LINK_PLACEHOLDERS (false) and link == expected_url (false, expected is .../pull/2194) → raises ChangelogValidationError(\"pr-link ... is not a valid placeholder or URL\").\n7. merge_with_reuse.sh runs under set -euo pipefail, so this uncaught exception aborts the entire merge script — the PR cannot be merged via the standard automated path until the value is fixed.\n\nThe fix: Change pr-link: PLACEHOLDER to either the literal pr-link: XXX (the documented convention for unmerged entries) or the real URL https://github.com/SemiAnalysisAI/InferenceX/pull/2194. Either value is recognized by validate_added_pr_link and will let the canonicalization/merge step complete normally.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29326787628 |
sglang argparse rejected --quantization deepseek_v4_fp8 (a vLLM-only method), crashing the canary before server start (run 29326787628). Remove the flag: sglang reads the modelopt quant config from the checkpoint and runs it via the AITER MoE path, matching the H200 and MI355X dsv4 sglang recipes (which pass no --quantization). 中文：删除 MI300X sglang 脚本中无效的 --quantization deepseek_v4_fp8 （该方法仅 vLLM 支持，sglang argparse 直接报错）。改为不传 --quantization， 由 sglang 从 checkpoint 读取 modelopt 量化配置并经 AITER MoE 执行，与 H200、 MI355X 的 dsv4 sglang 配方一致。
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29328162558 |
The prior fix cleared argparse but the server was then killed at CUDA-graph
capture (run 29328162558): --attention-backend dsv4 compiles its FP8 MLA
kernel via TileLang, whose InjectSoftwarePipeline pass fails on gfx942
("buffer access dependency ... cannot be reordered").
Set SGLANG_HACK_FLASHMLA_BACKEND=unified_kv_triton (+ SGLANG_USE_ROCM700A=0),
matching the same-model dsv4-fp4-mi355x-sglang recipe, so MLA runs through the
unified-KV triton path and avoids the failing TileLang kernel. Drop
SGLANG_AITER_MLA_PERSIST (MLA no longer via aiter); keep SGLANG_USE_AITER for
the MoE GEMMs, which were already running fine.
中文：MI300X 上 --attention-backend dsv4 的 FP8 MLA 内核经 TileLang 编译在
gfx942 上失败（软件流水线重排检查），导致 CUDA graph 捕获阶段服务被 kill。
参照同型号 mi355x 配方，设置 SGLANG_HACK_FLASHMLA_BACKEND=unified_kv_triton
改走统一 KV triton FlashMLA 路径以绕开该内核。
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29329188550 |
Third bring-up layer: unified_kv_triton cleared the MLA kernel, but the server was then killed at CUDA-graph capture (run 29329188550) in the AITER Composable-Kernel fused-MoE (ck_moe_stage1) with "Unsupported kernel config for moe heuristic dispatch" — CK has no tuned config for dsv4's FP8 MoE shapes on gfx942. Add --moe-runner-backend triton, which JIT-generates per-shape and needs no pretuned table. MI355X/gfx950 keeps the CK default (which has gfx950 configs). 中文：第三层 bring-up 问题——AITER Composable-Kernel 的 fused-MoE 在 gfx942 上没有 dsv4 FP8 MoE 形状的调优配置，CUDA graph 捕获阶段报 "Unsupported kernel config for moe heuristic dispatch"。改用 --moe-runner-backend triton（按形状 JIT 生成，无需预调优表）。
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29330031252 |
The sglang path hit successive gfx942 kernel gaps (nvfp4 MoE, TileLang MLA) that only have gfx950/MI355X builds. Pivot to vLLM, which runs the checkpoint in FP8 via --quantization deepseek_v4_fp8 (dequant FP4 MoE -> FP8) — the same path the no-FP4 H200 dsv4 vLLM recipe uses. Config/script mirror the same-model dsv4-fp4-mi355x-vllm (AITER MoE, deepseek_v4 tokenizer/parser, mp executor, FULL_AND_PIECEWISE compile) + gfx942 AITER infra; TP8 conc 4-512. Config key renamed dsv4-fp8-mi300x-sglang -> dsv4-fp8-mi300x-vllm. 中文：MI300X dsv4 由 sglang 改为 vLLM。sglang 在 gfx942 上接连遇到只有 gfx950/MI355X 才有的内核缺口（nvfp4 MoE、TileLang MLA）。vLLM 通过 --quantization deepseek_v4_fp8 将 FP4 MoE 反量化为 FP8 运行，与无 FP4 的 H200 dsv4 vLLM 配方一致。配方参照同型号 dsv4-fp4-mi355x-vllm。
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29333449416 |
…fx942 CI canary root cause (worker traceback): "Mxfp4 MoE backend 'AITER_MXFP4_MXFP4' does not support the deployment configuration ... QuantKey(u8 ... col=32)". --quantization deepseek_v4_fp8 only dequantizes the dense/attention weights; the MoE experts stay mxfp4 and go through vLLM's mxfp4 MoE selector. --moe-backend aiter forced AITER_MXFP4_MXFP4 (W4A4, native mxfp4) which gfx942 has no kernel for. Drop --moe-backend (default auto): vLLM's select_deepseek_v4_mxfp4_moe_backend takes its ROCm+DeepseekV4 branch and prefers AITER_MXFP4_BF16 (W4A16 CK, dequantizes weights — no native FP4) with a TRITON_UNFUSED fallback. MI355X keeps aiter because gfx950 supports the W4A4 kernel. 中文：MI300X vLLM 去掉 --moe-backend aiter（改用 auto）。deepseek_v4_fp8 仅反 量化稠密/注意力权重，MoE 专家仍为 mxfp4；在 gfx942 上强制 aiter 会选到 AITER_MXFP4_MXFP4（W4A4 原生 mxfp4）而无对应内核。auto 在 ROCm+DeepseekV4 分支优先选 AITER_MXFP4_BF16（W4A16 反量化），并回退 TRITON_UNFUSED。
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29335748715 |
Throughput sweep is green, but the eval job OOM-killed the server mid-gsm8k:
FP8 weights (~131GB/GPU) leave only ~71k tokens of KV on the 192GB MI300X
("Maximum concurrency ... 7.52x" for a 9472-token request), and the eval
drives CONC (128) concurrent requests. Set EVAL_CONCURRENT_REQUESTS=8 to fit
the KV budget. Eval-only (run_eval reads it); throughput jobs use CONC and are
unaffected. MI325X (256GB) has the headroom — its eval already passed — so it
keeps the default.
中文：MI300X 吞吐扫描已通过，但 eval 因 gfx942 KV 太小（FP8 权重占满，仅
~71k tokens KV，9472-token 请求最大并发 7.52x）在 conc 128 下把服务 OOM 杀死。
设置 EVAL_CONCURRENT_REQUESTS=8 匹配 KV 预算（仅影响 eval，不影响吞吐）。
MI325X 显存充足、eval 已通过，保持默认。
dsv4-fp8-mi300x-vllm-mtp mirrors the working normal recipe (auto MoE ->
AITER_MXFP4_BF16, deepseek_v4_fp8, EVAL_CONCURRENT_REQUESTS=8) and adds
DeepSeek-V4 built-in MTP via --speculative-config
{"method":"mtp","num_speculative_tokens":2}, with --dsv4 chat-template
encoding for run_benchmark_serving (required for meaningful MTP acceptance).
Routes to dsv4_fp8_mi300x_mtp.sh via the launcher's spec-decoding=mtp suffix.
中文：新增 MI300X vLLM MTP（投机解码）变体，在正常配方基础上加入
--speculative-config mtp 与 --dsv4 chat-template 编码。
origin/main advanced (H200 refresh #2191 merged); reset perf-changelog.yaml to origin/main and re-append the dsv4-fp8-mi300x-vllm and dsv4-fp8-mi300x-vllm-mtp entries so check-changelog's append-only rule passes. 中文：将 MI300X 分支 perf-changelog 重置到 origin/main 并重新追加其条目。
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29349001903 |
8k1k KV fits only ~20x concurrency; conc512 oversubscribed -> request timeouts (MTP c512 8k1k: 55.8% failures on both AMD SKUs). conc256 passed for normal and MTP; cap 8k1k conc-end at 256 (1k1k holds at 512). Eval clamp already present.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29353663375 |
MTP 8k1k conc256 failed (19.2% request failures) -- the MTP draft model shrinks KV below normal's, so 256 oversubscribes the ~20x ceiling. conc128 passed cleanly. Normal 8k1k holds 256 (passed), 1k1k holds 512.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=29365693328 |
1 participant
Summary
Bring-up scaffold — extrapolated config, not yet validated on-cluster. One of three per-SKU PRs adding DeepSeek-V4-Pro to the missing SKUs (MI300X here, MI325X and H100 separately). No prior dsv4 data exists on gfx942.
Extrapolated per https://recipes.vllm.ai/deepseek-ai/DeepSeek-V4-Pro plus:
dsv4-fp4-mi355x-sglang: search-space shape (TP-only low-latency + DP-attn/EP throughput),deepseek_v4model flags, SWA/page-size.dsr1-fp8-mi300x-sglang: gfx942 AITER infra (MEC-firmware scratch-reclaim guard,SGLANG_USE_AITER).--quantization deepseek_v4_fp8. gfx942 has no native FP4, so the ~960 GB mixed checkpoint runs in FP8.Sizing: ~960 GB mixed → ~1.05 TB in FP8, which only fits TP8 on 8×192 GB (TP4 = 768 GB does not) — so the MI355X TP4 bands are dropped. Sweep: TP-only low-latency (conc 1–32) + DP-attn/EP8 throughput (conc 64–2048), for 1k1k and 8k1k (24 configs).
Image:
lmsysorg/sglang-rocm:v0.5.15-rocm720-mi30x-20260713(mi30x sibling of the MI355X sglang-rocm dated-tag family).DeepseekV4model class, and that--attention-backend dsv4(else fall back toaiter) and--quantization deepseek_v4_fp8work on gfx942.Local checks:
generate_sweep_configs.py --runner-type mi300x→ 24 configs;validate_perf_changelog.py --base-ref mainpasses; script passesbash -n.中文说明
Bring-up 脚手架——外推配置，尚未在集群验证。 为缺失 SKU 补充 DeepSeek-V4-Pro 的三个按 SKU 拆分 PR 之一（此为 MI300X，MI325X 与 H100 另开）。gfx942 此前无 dsv4 数据。
外推依据 https://recipes.vllm.ai/deepseek-ai/DeepSeek-V4-Pro 及：
dsv4-fp4-mi355x-sglang：扫描空间形态（TP-only 低延迟 + DP-attn/EP 吞吐）、deepseek_v4模型参数、SWA/page-size。dsr1-fp8-mi300x-sglang：gfx942 AITER 基础设施（MEC 固件 scratch-reclaim 保护、SGLANG_USE_AITER）。--quantization deepseek_v4_fp8。gfx942 无原生 FP4，故 ~960 GB 混合精度权重以 FP8 运行。显存测算： ~960 GB 混合 → FP8 约 1.05 TB，仅 TP8 可放入 8×192 GB（TP4 = 768 GB 放不下），故去掉 MI355X 的 TP4 频段。扫描：TP-only 低延迟（conc 1–32）+ DP-attn/EP8 吞吐（conc 64–2048），覆盖 1k1k 与 8k1k（24 个配置）。
镜像：
lmsysorg/sglang-rocm:v0.5.15-rocm720-mi30x-20260713。DeepseekV4模型类，且--attention-backend dsv4（否则回退aiter）与--quantization deepseek_v4_fp8在 gfx942 上可用。本地检查：
generate_sweep_configs.py --runner-type mi300x→ 24 个配置；validate_perf_changelog.py --base-ref main通过；脚本通过bash -n。