[ChangLiu0709]

Summary

Updates the merged round 03 recipe (#4680) onto the upstream lmsysorg/sglang-rocm:v0.5.23-rocm10-mi35x-20261031 image, pinned by digest sha256:3867dc07ba2530f914e1f210ed829f7a572a75286c8c362dbc22cbecf9b5a7e6. There is no custom image, no patch, and no setup script. The nightly was built from SGLang e9c18259c. AITER stays 285579b6. SGLang pins sgl-amd-mono at b10f3b71 (sglang#47483, the merge of sgl-amd-mono#29), so qwen3.8next-rocm10-setup.sh is removed.

Against #4680, concurrency 12 and 16 are unchanged. Concurrency 1, 2, 4 and 8 switch to the FlyDSL monokernel:

• Existing config key qwen3.8next-fp4-mi355x-sglang-agentic-mtp: same model, TP1/EP1, conc 1/2/4/8/12/16, kv-offloading: none. Only the image digest changes.
• c1, c2, c4, c8: --enable-amd-monokernel for MTP target verify and each draft step. The kernel needs the per-draft SSM states and the PLE table on the GPU, so these points drop ReplaySSM and PLE offload, and admit max-running-requests = cuda-graph-max-bs-decode = conc (1, 2, 4, 8).
• c12, c16: the round 03 default path. ReplaySSM, PLE offload, max-running-requests = 2x conc (24 and 32).
• ROCM_QUICK_REDUCE_QUANTIZATION=NONE. SGLANG_USE_AITER, SGLANG_USE_AITER_UNIFIED_ATTN and AITER_FLYDSL_FORCE are not set.

Upstream pieces

Repo	PR	What it is	How it gets in
sgl-amd-mono	#29	FlyDSL monokernel for MTP verify and draft (--enable-amd-monokernel)	Pinned in the image at b10f3b71 via sglang#47483
SGLang	#46036, #46979, #46980, #46990	Monokernel spec registration by model type and the KV layer router that #29 reads	In the image (SGLang e9c18259c)
SGLang	#41880	FlyDSL hc_mix dispatch	In the image
AITER	#6201, #5804, #6467, #6165, #6225, #6050	BF16 GEMM configs, FlyDSL EP MoE, MoE sort and quant, and others	In the image (AITER 285579b6, unchanged)

Not included:

• still open: sglang#41879 (AITER GDN conv/decode hooks), sglang#45196 (QSA FlyDSL sparse decode), and sglang#47485 (BF16 lm_head through AITER tgemm; kept on [AMD][MI35X] Add Qwen3.8-Flash-Next FP4 SGLang agentic MTP on upstream v0.5.21-rocm724 image / 基于上游 v0.5.21-rocm724 镜像新增 MI355X Qwen3.8-Flash-Next FP4 SGLang agentic MTP #3974);
• merged in AITER after the image's AITER 285579b6 (2026-10-17): aiter#5993, aiter#6769, aiter#5992 and aiter#6670.

c12 and c16 stay on the default GDN and QSA paths, so they remain the slower points. #3974 carries those pieces.

Validation

• This head, PR sweep: Run Sweep 41226389969 (head 90fc8ffbb, the 20261031 image, no setup script, monokernel at c1–c8, full-sweep-enabled) passed at all six points and the c16 eval. c4, c8 and c12 failed in their first attempt in host setup (GPU memory left by a previous job on the node, not the recipe) and passed on rerun. The branch was then updated with main (bdf93a7f1, workflow and test files only). A new sweep on that head, 41248881067, was queued when this was written.

Conc	Total tok/s/GPU	vs round 03 (#4680)	Interactivity p50 / p90 (tok/s/user)	TTFT p50 (s)	Error drops
1	16,716	+42.2%	399.6 / 390.5	0.29	0
2	20,583	+70.0%	393.6 / 304.2	0.28	0
4	25,405	+48.6%	317.8 / 208.7	0.28	0
8	42,789	+22.0%	262.3 / 149.1	0.29	1
12	54,013	+0.3%	119.2 / 89.8	0.38	0
16	72,358	+0.2%	103.9 / 65.9	0.41	1

Round 03 is the merged #4680 sweep (run 41114439370). The c16 eval scored GSM8K 0.9674 strict (1319 questions, threshold 0.9).

• Previous image, CI: e2e run 41057516117 (qwen3.8-mi355x-init-01, head a5c969f6a) passed at all six points and the c16 eval on the 20261030 image. That head checked sgl-amd-mono out to the same b10f3b71 with a setup script. It is not a result for this image.
• Local c1 runs on MI355X, monokernel active (qwen38_flash_next_hip and qwen38_flash_next_mtp_draft_hip on gfx950), 0 error-dropped requests:
  • 20261030 image, checkout script moved sgl-amd-mono from 90c23551 to b10f3b71 (that revision also applied aiter#5993 and #6769), 600 s: interactivity p50 / p90 401.0 / 390.0 tok/s/user, TTFT p50 / p90 0.30 / 1.57 s, TPOT p50 2.49 ms, 119 requests.
  • 20261029 image with [NVIDIA] Fix Docker Networking and Image Name Issues for B200 Launch Scripts #29 as a patch, 3600 s: 16,750 total tok/s/GPU, interactivity p50 / p90 401.8 / 393.5, TTFT p50 / p90 0.30 / 1.39 s, TPOT p50 2.49 ms, 654 requests, accept length 2.32.

Known gaps:

• GSM8K runs only at c16, on the default path. The monokernel points (c1–c8) have no accuracy eval in the sweep, because eval groups split on engine env and the monokernel is selected by a CLI flag only.
• c8 and c16 each dropped one request with InvalidInferenceResultError (not yet investigated; c16 does not use the monokernel).

AI model disclosure

• Model/version: Claude Opus 5.5 (Cursor agent)
• Role: wrote the config, recipe, setup script, patch selection and changelog edits, the local smoke-test scripts, and the earlier description. Delegated agents ran the local smoke tests and branch checks.
• 2026-10-29 description update and patch regeneration: Claude Sonnet 5.5 (Cursor agent).
• 2026-10-30 move to the 20261030 image and the sgl-amd-mono checkout: Claude Opus 5.5 (Cursor agent).
• 2026-10-31 move to the 20261031 image, removal of qwen3.8next-rocm10-setup.sh, and this description: Claude Sonnet 5.5 (Cursor agent).

PR checklist and change type

Type of Change

• Bug fix
• New feature
• Configuration change
• Documentation update
• Other (please describe)

Checklist

• I have completed the AI model disclosure and kept it current
• I have tested my changes locally
• I have updated documentation if necessary
• For every change that can affect benchmark performance and every recipe addition or modification, I have appended a new entry to the physical end of inferencex-e2e/perf-changelog.yaml and have not edited historical entries
• If this PR can affect benchmark performance or adds or modifies a recipe, it carries exactly one primary sweep label (a maintainer applies it on fork PRs): full-sweep-fail-fast (recommended), full-sweep-enabled, or non-canary-full-sweep-enabled. Optional modifiers all-evals, evals-only, and agentx-fast require a primary label; the last two block reuse while applied.
• Before merging via reuse, an authorized maintainer (OWNER/MEMBER/COLLABORATOR) has commented /use <run_id> (or the legacy /reuse-sweep-run) on this PR. Do this only once there is a final full sweep that is all green with evals passing, since after this comment the primary sweep label will no longer automatically kick off new sweeps. Remove and re-add the primary sweep label to force a new sweep.

中文

概要

在已合入的第 03 轮配方（#4680）上，将镜像更新为上游 lmsysorg/sglang-rocm:v0.5.23-rocm10-mi35x-20261031（digest sha256:3867dc07ba2530f914e1f210ed829f7a572a75286c8c362dbc22cbecf9b5a7e6）。无自定义镜像、无补丁、无 setup 脚本。该 nightly 由 SGLang e9c18259c 构建，AITER 仍为 285579b6。SGLang 将 sgl-amd-mono 固定在 b10f3b71（sglang#47483，即 sgl-amd-mono#29 的合入提交），因此删除 qwen3.8next-rocm10-setup.sh。

相对 #4680，c12 与 c16 不变。c1、c2、c4、c8 改为 FlyDSL monokernel（--enable-amd-monokernel）：不使用 ReplaySSM，PLE 表留在 GPU 上，max-running-requests = cuda-graph-max-bs-decode = conc（1、2、4、8）。ROCM_QUICK_REDUCE_QUANTIZATION=NONE。

验证： 当前 head 的 PR sweep 41226389969（head 90fc8ffbb，20261031 镜像，c1–c8 启用 monokernel）6 个并发点及 c16 eval 全部通过。c4、c8、c12 首次运行因节点上一个任务遗留的 GPU 显存在 host setup 阶段失败（非配方问题），重跑后通过。相对已合入的第 03 轮（#4680）总吞吐 tok/s/GPU：c1 +42.2%（16,716）、c2 +70.0%（20,583）、c4 +48.6%（25,405）、c8 +22.0%（42,789）、c12 +0.3%（54,013）、c16 +0.2%（72,358）；c16 eval GSM8K strict 0.9674。随后分支已合入 main（bdf93a7f1，仅涉及 workflow 与测试文件），该 head 上的新 sweep 41248881067 撰写时仍在排队。上一轮 CI 41057516117 跑在 20261030 镜像上，不是本镜像的结果。

已知缺口： GSM8K 只在 c16（默认路径）运行，c1–c8 的 monokernel 点在 sweep 中没有精度 eval；c8、c16 各有 1 个 InvalidInferenceResultError 尚未排查。

AI 模型使用说明： 2026-10-31 镜像更新、删除 setup 脚本和本说明由 Claude Sonnet 5.5（Cursor agent）完成。更早的配方与说明由 Claude Opus 5.5 与 Claude Sonnet 5.5（Cursor agent）完成。

[github-actions]

Thanks for the contribution!

• Review: If this PR changes files owned by someone other than a repository admin or @SemiAnalysisAI/core, ask one eligible CODEOWNER to complete the latest PR_REVIEW_CHECKLIST.md before contacting a core maintainer on Slack. Follow the template exactly, including As a PR reviewer and CODEOWNER, I have reviewed this and have, so sign-off verification triggers.
• PR verification: Sweeps run only when the PR appends an inferencex-e2e/perf-changelog.yaml entry and carries exactly one primary label: full-sweep-fail-fast (strongly recommended; canary plus per-matrix fail-fast), full-sweep-enabled (canary; matrix jobs continue after a failure), or non-canary-full-sweep-enabled (no canary or fail-fast). The modifiers all-evals, evals-only, and agentx-fast require a primary label. On fork PRs, a maintainer applies the label. See sweep labels and reuse.
• After merging: PR authors must ensure all GitHub Actions jobs pass. Transient failures often pass on rerun; see how to rerun failed jobs.

中文

感谢你的贡献！

• **审阅：**如果 PR 修改的文件归属于仓库管理员及 @SemiAnalysisAI/core 之外的 CODEOWNER，请先联系一位有资格的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md，再通过 Slack 联系核心维护者。必须严格遵循模板，并保留 As a PR reviewer and CODEOWNER, I have reviewed this and have，才能触发签核验证。
• **PR 验证：**只有当 PR 在 inferencex-e2e/perf-changelog.yaml 末尾追加了条目，并且恰好带有一个主标签时，才会运行扫描：full-sweep-fail-fast（强烈推荐；canary 加逐矩阵 fail-fast）、full-sweep-enabled（有 canary；矩阵任务在失败后继续运行）或 non-canary-full-sweep-enabled（无 canary，也无 fail-fast）。修饰标签 all-evals、evals-only 和 agentx-fast 必须与主标签一起使用。fork PR 的标签由维护者添加。参见扫描标签与复用。
• **合并后：**PR 作者必须确保所有 GitHub Actions 任务通过。临时性失败通常可以通过重新运行恢复；参见重新运行失败任务的说明。

[claude]

Claude finished @ChangLiu0709's task in 43s —— View job

---

Review: PR #4542

• Checked for earlier reviews (none)
• Reviewed the diff: amd-master.yaml entry, srt-slurm recipe, setup script and perf-changelog.yaml
• Posted findings

LGTM - no blocking issues found.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

[claude]

🔴 MI355X Qwen3.8-Flash-Next AgentX numbers would be measured with thinking turned off. They are still scored against the thinking-on golden AL and compared with NVIDIA siblings that run thinking on. default-chat-template-kwargs: '{"enable_thinking": false}' at agentic.yaml:52 changes the server-side chat template for every point. Neither the PR description nor the changelog mentions this. Fix: drop this arg so the server keeps the model's default thinking-on template, like the b200/b300/gb300/h200 qwen3.8next recipes, and so the injected thinking_on AL matches the mode actually served.

Why this was flagged

Every agentic point (c1-c16) launches SGLang with default-chat-template-kwargs set to {"enable_thinking": false} (agentic.yaml:52). AgentX chat requests are therefore rendered in non-thinking mode. The workflow hard-codes THINKING_MODE: thinking_on (.github/workflows/benchmark-tmpl.yml:108). synthetic_acceptance.py:166 then injects the thinking_on golden AL. qwen3.8next_mtp.yaml has no thinking_off curve at all, and its thinking_on value for 3 steps is 2.32. infx/golden_al_distribution/README.md says each model and thinking mode has one curve, and all submissions for the same model and mode use the same curve. No other qwen3.8next recipe sets this kwarg; b200, b300, gb300 and h200 all run with reasoning-parser: auto and the default thinking-on template. So the MI355X rows published under model-prefix qwen3.8next use a different workload mode from every sibling, and output and reasoning token mix can differ. Nothing in check_fragment or validate_recipe catches this, because they never inspect chat-template kwargs.

Verification: Trigger: any AgentX or eval request that reaches SGLang's chat endpoint without its own chat_template_kwargs, since the recipe sets no AIPERF_EXTRA_INPUTS. agentic.yaml:52 sets default-chat-template-kwargs: '{"enable_thinking": false}' for c1-c16. synthetic_acceptance.py:166 still injects the thinking_on golden AL of 2.32 from qwen3.8next_mtp.yaml.

[claude]

🟡 nit (optional): New header and history comments break AGENTS.md's mandatory comment rules (no headers describing a file, config or override; no history). sweep:^# Qwen3.8-Flash-Next|^# One variant per point|^# Qwen3.8-Flash-Next baseline Example sites: agentic.yaml:1-5 and amd-master.yaml:488-490 describe the config, and the script's lines 2-23 list PR/commit provenance. Fix: delete them and keep only short notes on why a specific line is set. [also at: inferencex-e2e/benchmarks/multi_node/srt-slurm-recipes/configs/qwen3.8next-rocm10-merged-patches.sh:23 - Maintainers get new file, recipe and section header comments full of PR history, which AGENTS.md:56-57 bans in every file.]

Why this was flagged

AGENTS.md "Comments (mandatory, every file)" bans header comments that describe a file, config, recipe, override or section. It also bans history: where code came from, what it replaced, or past results. The diff adds a 5-line header at agentic.yaml:1-5. It adds a block before override_c1 (agentic.yaml:80-91) that describes the overrides. It adds a 3-line header above the new key in amd-master.yaml:488-490. qwen3.8next-rocm10-merged-patches.sh:2-23 lists upstream PR numbers, image commits and what the image already has. The rule says that information belongs in git and perf-changelog.yaml. Each block restates the recipe or carries provenance that goes stale on the next image bump.

Verification: AGENTS.md:54-58 says: "No header comments describing a file, topology, config, recipe, override, or section." and bans history. agentic.yaml:1-5 and amd-master.yaml:488-490 are headers describing the config, and qwen3.8next-rocm10-merged-patches.sh:2-23 is a file header full of provenance. Nothing breaks at runtime.

[github-actions]

View unofficial run (performance): https://inferencex.semianalysis.com/inference?unofficialRun=41526799231

View unofficial run (accuracy): https://inferencex.semianalysis.com/evaluation?unofficialRun=41526799231

[chunfangamd]

Pushed e7a7306 to address two review findings:

• Monokernel eval coverage. c1, c2, c4 and c8 now set SGLANG_USE_AITER=1. sgl-amd-mono's spec requires it, and the image already sets it in config.Env. Their engine env now differs from c12 and c16, so the agentic GSM8K selection also runs an eval at c8 on the monokernel path, not only at c16 on the default path. infx.matrix.generate marks run-eval at c8 and c16.
• Thinking mode. Dropped --default-chat-template-kwargs '{"enable_thinking": false}'. AgentX requests use the chat endpoint with no per-request override, so every point was served thinking-off. The injected AL (2.32) comes from the thinking_on curve, and the b200/b300/gb300/h200 qwen3.8next recipes run thinking on.
• Merged main, resolving the changelog conflict with the helper. The changelog entry now also notes that the monokernel runs the MoE on BF16 activations (a16w4), where the default path quantizes them to MXFP4.

Full sweep: Run Sweep 41511531988. The earlier /reuse-sweep-run 41413394159 no longer matches the head; /use follows once this sweep is green. sgl-project/sglang#47951 needs the same thinking change, since its MI355X commands still pass enable_thinking: false.

中文

已推送 e7a7306，处理两项 review 问题：

• monokernel 的 eval 覆盖。 c1、c2、c4、c8 设置 SGLANG_USE_AITER=1。sgl-amd-mono 的 spec 要求该设置，镜像的 config.Env 中也已默认设置。这样它们的 engine env 与 c12、c16 不同，agentic GSM8K 除了在默认路径的 c16 跑一次，也会在 monokernel 路径的 c8 跑一次。infx.matrix.generate 在 c8 和 c16 标记了 run-eval。
• Thinking 模式。 删除 --default-chat-template-kwargs '{"enable_thinking": false}'。AgentX 请求走 chat 接口，且不带单独的覆盖参数，因此之前所有点都在关闭 thinking 的状态下运行。而注入的 AL（2.32）来自 thinking_on 曲线，b200/b300/gb300/h200 的 qwen3.8next recipe 也都开启 thinking。
• 已合并 main，changelog 冲突用 helper 解决。changelog 条目补充说明：monokernel 的 MoE 使用 BF16 激活（a16w4），而默认路径会把激活量化为 MXFP4。

Full sweep：Run Sweep 41511531988。原先的 /reuse-sweep-run 41413394159 已不对应当前 head，本次 sweep 通过后再发 /use。sgl-project/sglang#47951 需要做同样的 thinking 修改，它的 MI355X 命令目前仍带 enable_thinking: false。

[chunfangamd]

Restarted the sweep on the current head with all-evals: Run Sweep 41526799231 on 64527ed, with ALL_EVALS: true and an eval for each of the six points.

• I cancelled the re-run of 41511531988. A re-run keeps the original run's commit (e7a7306) and labels, so its setup ran with ALL_EVALS: false and would have evaluated only c8 and c16.
• The all-evals run 41512481731 was cancelled by the later push and re-run. Before that, it finished two evals with thinking on: c1 on the monokernel at GSM8K strict 0.980, and c12 on the default path at 0.977. Its c1 server log shows the monokernel's target-verify and draft launches, with default_chat_template_kwargs: None.
• Please avoid pushing or re-running while this sweep runs, since either cancels it.

中文

已在当前 head 上带 all-evals 重新开始 sweep：Run Sweep 41526799231，head 为 64527ed，ALL_EVALS: true，6 个点各有一个 eval。

• 我取消了 41511531988 的重跑。重跑沿用原 run 的 commit（e7a7306）和 label，setup 是 ALL_EVALS: false，只会评测 c8 和 c16。
• all-evals 的 run 41512481731 被之后的 push 和重跑取消了。在此之前，它在开启 thinking 的情况下完成了两个 eval：monokernel 路径的 c1 GSM8K strict 0.980，默认路径的 c12 0.977。它的 c1 服务器日志里有 monokernel 的 target verify 和 draft launch，default_chat_template_kwargs: None。
• 这次 sweep 运行期间请不要 push 或重跑，两者都会取消它。

[chunfangamd]

/use 41526799231

[github-actions]

@chunfangamd staged run 41526799231.

• Qwen3.8-Flash-Next · agentic-traces · FP4 · mi355x_sglang · 2026-11-02

This run remains available across future /stage-results requests. Staging the same run ID again updates its staged data. Staging workflow

[chunfangamd]

As a PR reviewer and CODEOWNER, I have reviewed this and have:

Checklist items

• Verified that as of the moment of typing this, this is the latest version of PR_REVIEW_CHECKLIST.md
• Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
• Verified that this PR has passed PR validation. Please link to GitHub Action workflow that shows this. https://github.com/SemiAnalysisAI/InferenceX/actions/runs/41526799231
• Verified that this PR passes evals. Please link to GitHub Action workflow that shows this. https://github.com/SemiAnalysisAI/InferenceX/actions/runs/41526799231
• Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
• Verified that every draft model and draft head is served as it ships: the draft that ships with the served checkpoint, at its stored precision, through the pinned upstream image's default handling, with the shipped and effective draft precision recorded in the additional detail section. No submission-side quantization, dtype override, checkpoint substitution, or patch may lower draft precision below that default, regardless of eval results or AL. Explicitly verified that SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE is not enabled in the effective recipe, including inherited settings; enabling it is prohibited going forward, and historical runs do not grant an exception. See Draft-model precision for what counts as the default and the MLPerf comparison.
• For agentic workloads: verified that speculative-decoding configs (EAGLE / MTP / draft models) run with simulated synthetic acceptance, with the acceptance-length value taken from the committed golden AL curve in infx/golden_al_distribution/ for that model, thinking mode, and draft length. A submission may choose any supported draft length, but it may not substitute a different acceptance target.
• Verified against the current MODELS.md that this PR does not submit a deprecated model, scenario, or model-scenario combination.
• Verified that the model architecture isn't changed with benchmark hacks like using --hf-overrides to skipping indexer for every x layers on models that don't natively support this. As a general rule, we won't accept optimizations that reduces the number of model architecture FLOPs. Anything that makes that same computation run faster is fair game; target/verifier FLOPs at lower precisions is fine, given that the config passes private evals, but this does not permit lowering draft-model or draft-head precision below what ships. As an general north star princple, we should only use optimizations which is used in production by customers that care about accuracy
• Verified that new models disable integer all-reduce, with SGLang ROCm explicitly setting ROCM_QUICK_REDUCE_QUANTIZATION=NONE. Existing models are grandfathered per MODELS.md.
• For affected Dynamo TRT-LLM benchmarks, verified that iteration/KV-cache metrics are collected and published under the pinned Dynamo implementation and effective engine settings. Resolve the installed Dynamo version separately from the container tag; use supported metrics controls without requiring KV events. Record the version and configuration evidence in the additional detail section. See verifier Check 17. N/A for unaffected serving paths or frameworks without these Dynamo settings.
• If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have verified that the respective vLLM submission made using upstream https://hub.docker.com/u/vllm docker repo, upstream SGLang https://hub.docker.com/u/lmsysorg docker repo. The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet as supported by vLLM/SGLang community maintainers
• For official InferenceX (non-preview), verified that established models use upstream engine images built from master (or the equivalent default development branch), with new models transitioning within a reasonable time after release. See MODELS.md.
• If an company claims that they support vLLM/SGLang as first class upstream in-tree LLM inference engines on their hardware, I have have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
• Verified that every affected vLLM/SGLang production serving configuration in this PR, including Dynamo deployments, is documented in the official vLLM recipes and/or the SGLang cookbook, for both single-node and multi-node aggregated and disaggregated serving. The documentation covers production-useful flags, environment variables, and launch commands (including prefill, decode, and router/frontend commands for disaggregation); InferenceX-only benchmark/harness settings are excluded with reasoning in the additional detail section:
  • I linked the corresponding upstream PR in the vLLM recipe repo or SGLang cookbook source repo and verified that it is MERGED before this InferenceX PR merges. An opened, draft, or closed-without-merge upstream PR does not satisfy this requirement. If the matching recipe was already published, I linked the published recipe/cookbook page in the additional detail section below.
• Verified that this PR does not patch the inference engine or serving stack — the pinned image must run as shipped. This covers .patch files / git apply / patch, inline patches embedded in benchmark scripts (e.g. a python3/sed heredoc that rewrites installed engine sources before serving), in-place edits of site-packages, monkey-patching, overwriting container files, and installing forked/rebuilt engine wheels on top of the pinned image. The only exception is a patch covered by a filled-out waiver at docs/waiver/<PR_NUMBER>.md — named after the PR that introduces the patch and filed in that same PR, stating what is patched, why the unmodified upstream image cannot run this benchmark, the upstream PR/issue link, and the removal plan — which I have linked below in the additional detail section.
• If this PR uses append-only: true, verified that it only adds generated points or recipe variants inside a selected existing config/scenario and existing same-image visual curve: every previously generated point remains present with the same recipe, no prior point is removed or rerun, and every benchmark-affecting change in the complete diff can affect only the corresponding newly appended points (never an existing point), regardless of which file contains it.
• If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.
• Reported measured throughput/E2EL Pareto counts and evidence per affected curve (≥5 points strongly recommended). Below 5 or unverifiable: tag a core maintainer for review; recorded admin bypass required before merge. N/A if no curves are affected. Details.

Additional detail section:

• Evals: run 41526799231 ran GSM8K at all six points (all-evals) on the PR image: strict 0.9788 (c1), 0.9780 (c2), 0.9773 (c4), 0.9795 (c8), 0.9788 (c12) and 0.9795 (c16), n = 1319, SE about 0.004. No row trails another by more than 2σ. The c1, c2, c4 and c8 eval servers ran enable_amd_monokernel: True and logged the monokernel's runs target_verify steps and MTP draft runs lines; c12 and c16 ran the default path. Default sweeps also evaluate the monokernel: c1–c8 set SGLANG_USE_AITER=1 (its requirement and the image default), which gives them their own eval group.
• Cookbook: sgl-project/sglang#47951 merged.
• Golden AL: all six points inject SGLANG_SIMULATE_ACC_LEN=2.32, the qwen3.8next_mtp.yaml thinking_on value for 3 draft tokens; signoff_facts golden-al matches it. Every server now runs the model's default thinking-on template (default_chat_template_kwargs: None), matching that curve and the other qwen3.8next recipes.
• Draft precision: the MTP head (mtp.* of amd/Qwen3.8-Flash-Next-Quark-MXFP4-AttnFP8-PLEFP8 @ bd6e49d9) runs as shipped.
  • Shipped: W8A8 FP8 attention and indexer projections (F8_E4M3 with F32 scales, per-token dynamic activations), W4A4 MXFP4 routed and shared experts, and BF16 router, HC mixers, fc_embedding/fc_hidden and norms. The draft loads with the checkpoint's own Quark config (speculative_draft_model_quantization: quark) and a BF16 KV cache.
  • c12/c16 default path: as shipped; the aiter MoE key is ..., 513, 11, ..., float4_e2m1fn_x2, float4_e2m1fn_x2, per_1x32.
  • c1–c8: sgl-amd-mono b10f3b71, pinned by SGLang e9c18259, reads the FP8 and MXFP4 weights in place and copies only BF16 tensors into its tile order. It keeps per-token FP8 activations for the W8A8 projections and runs the MoE on BF16 activations (a16w4), so no draft weight or activation is lowered. It also turns off SGLang's QSA MTP index sharing, so each draft decode selects its own blocks.
  • SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE is unset, and integer all-reduce is off (ROCM_QUICK_REDUCE_QUANTIZATION=NONE, TP1).
• Changelog: the entry covers the image, the monokernel and its BF16-activation (a16w4) MoE, SGLANG_USE_AITER at c1–c8 and the thinking-on template.
• Validation / reuse: run 41526799231 (attempt 1) on the current head 64527ed: all six agentic points and six evals are green, and /use 41526799231 is posted. Requests dropped with errors: 2 at c2, 2 at c8, 1 at c12 and 5 at c16. The branch conflicts with main only in perf-changelog.yaml; leave the sync to merge_with_reuse, because main now carries srt-slurm v2.66.1 and the AgentX AL gate, both on this config's launch path.
• Images: lmsysorg/sglang-rocm:v0.5.23-rocm10-mi35x-20261031@sha256:3867dc07… resolves. It is built from SGLang main at e9c18259, with aiter 285579b6, sgl-amd-mono b10f3b71 and mori f39fa765, each on its default branch. qwen3.8next is grandfathered under the all-reduce policy and still sets ROCM_QUICK_REDUCE_QUANTIZATION=NONE.
• Other: no patches or setup scripts. json-model-override-args only declares the FP8 PLE storage the checkpoint ships. No append-only; Checks 16 and 17 are N/A.
• Pareto (p90 throughput per GPU vs E2EL, one curve, the six bmk_agentic_* artifacts of run 41526799231, via pareto_coverage): 6 measured, 0 invalid, 3 on the frontier (c8, c12, c16). c1, c2 and c4 are dominated by c8. With fewer than 5, core maintainer review and an admin bypass are needed before merge. cc @functionstackx

Signed: @chunfangamd

[github-actions]

Ingest report — ✅ Results ingested into the production database.

Ingest workflow · Merge Ingest run · Benchmark source run

Category	new	duplicate	skipped	unmapped	failed
benchmark	6	0	0	0	0
eval	6	6	6	0	0
trace	6	0	0	0	0
power	6	0	0	0	0

_{benchmarkFiles 6, rawBenchmarkRows 6, coveredByPerJobFiles 0, purgedPoints 0, failedRunRows 0, runStatsNew 0, runStatsDuplicate 0, evalSamplesNew 7914, gpuMetricSamplesNew 29224, powerPublicationPoints 6, changelogEntriesWritten 1}

Counts cover only this run. Rows: benchmark_results, eval_results, agentic rows linked to a trace, gpu_metrics series. This comment updates if the ingest is rerun.

中文

Ingest 报告 — ✅ 结果已写入 production 数据库。

上表仅统计本次运行写入的数据，各行单位依次为 benchmark_results 行、eval_results 行、已关联 trace 的 agentic 行和 gpu_metrics 序列。重新运行 ingest 时本评论会原地更新。