config(kimik3): refresh MI355X vLLM image to the 2026-09-24 ROCm 10.0 nightly / 将 Kimi-K3 MI355X vLLM 镜像刷新至 2026-09-24 的 ROCm 10.0 nightly - #3419
Conversation
… nightly Repin kimik3-fp4-mi355x-vllm-agentic-mtp from nightly-rocm100-af1c0149 to nightly-rocm100-7f1a5398 and re-measure all 9 points. Only the image changes; the search space and kimik3_fp4_mi355x_mtp.sh are untouched. The old pin is from 2026-09-16 and the new one is 441 commits ahead, carrying Kimi-K3 fixes vllm-project/vllm#51483, #57098 and #57430 plus ROCm CPU KV-offload work this arm exercises above concurrency 4. 将 kimik3-fp4-mi355x-vllm-agentic-mtp 的镜像由 nightly-rocm100-af1c0149 更新为 nightly-rocm100-7f1a5398，并重新测量全部 9 个数据点。本次仅更换镜像， 搜索空间与 kimik3_fp4_mi355x_mtp.sh 均未改动。 旧镜像切出于 2026-09-16，新镜像领先 441 个提交，包含 Kimi-K3 修复 vllm-project/vllm#51483、#57098 与 #57430，以及本臂在并发大于 4 时会使用的 ROCm CPU KV 卸载改动。 Co-authored-by: Cursor <cursoragent@cursor.com>
Replace the XXX placeholder now that the PR exists. 在 PR 建立后，将 changelog 条目中的 XXX 占位符替换为实际链接。 Co-authored-by: Cursor <cursoragent@cursor.com>
|
Thanks for the contribution!
中文感谢你的贡献！
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Looks good, straightforward config change.
What was reviewed: the configs/amd-master.yaml image-tag bump for kimik3-fp4-mi355x-vllm-agentic-mtp (only the image: line changes) and the appended perf-changelog.yaml entry. Checked that the changelog entry is appended only at the tail with no historical bytes altered. Checked the pull/XXX pr-link placeholder against infx/workflows/validate_perf_changelog.py — it's an explicitly allowed placeholder on PR runs, not a bug.
Extended reasoning...
Two-file diff: a one-line Docker image tag bump in configs/amd-master.yaml and a purely-appended bilingual perf-changelog.yaml entry documenting the rationale; no security-sensitive surface (auth, crypto, permissions) is touched. Verified the changelog append preserves all prior bytes and only adds new lines at the end, and confirmed via validate_perf_changelog.py that the pull/XXX placeholder pr-link is a sanctioned convention for in-flight PRs rather than an oversight, so there's nothing here needing a human's extra scrutiny.
This review covers commit a3835ec, which is no longer the latest commit on this pull request; later commits are not covered by it.
|
View unofficial run (performance): https://inferencex.semianalysis.com/inference?unofficialRun=36082123873 View unofficial run (accuracy): https://inferencex.semianalysis.com/evaluation?unofficialRun=36082123873 |
|
/reuse-sweep-run 36082123873 |
… nightly Refresh the image on kimik3-fp4-mi355x-vllm-agentic-mtp and re-sweep it. The image: line is the only change; the search space and benchmarks/single_node/agentic/kimik3_fp4_mi355x_mtp.sh are untouched (nine points, same curve shape: TP8 conc 1/4 GPU-resident KV, conc 8/10/12/14 on vllm-simple DRAM offload, conc 44/48/70 on TP8/DCP8 vllm-simple). Old pin nightly-rocm100-af1c0149 (vLLM main 2026-09-16), new pin nightly-rocm100-7f1a5398 (vLLM main 2026-09-24), 441 commits apart. The jump carries three Kimi-K3 correctness fixes (vllm#51483, #57098, #57430) plus ROCm CPU KV-offload work (vllm#57160) exercised by the seven SimpleCPUOffloadConnector points above conc 4. This sweep is the qualification for the new image. Data type preserved: this image bump does not change the DSpark draft model data type. The script is unchanged; the draft loads unmodified from the published Inferact/Kimi-K3-DSpark checkpoint via --speculative-config (model=Inferact/Kimi-K3-DSpark, method=dspark). The only dtype in that speculative-config is kv_cache_dtype=fp8, which sets the draft KV-cache storage precision, not the draft weights. No flag overrides or re-quantizes the draft-model weights, so the draft dtype is preserved from its checkpoint across this re-sweep. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
As a PR reviewer and CODEOWNER, I have reviewed this and have:
- 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.
- Verified that this PR passes evals. Please link to GitHub Action workflow that shows this.
- 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_MOEis 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 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
- 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
- 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 single-node vLLM/SGLang recipe in this PR is documented in the official vLLM recipes and/or the SGLang cookbook:
- I linked the corresponding upstream PR in the vLLM recipe repo or SGLang 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:
- insert any additional info here
- recipe at https://recipes.vllm.ai/moonshotai/Kimi-K3?hardware=mi355x&features=text_only%2Cspec_decoding%2Ctool_calling%2Creasoning
- "This image bump does not change the DSpark draft model data type. Only the image: line changes and kimik3_fp4_mi355x_mtp.sh is unchanged; the draft loads unmodified from the published Inferact/Kimi-K3-DSpark checkpoint via --speculative-config (model=Inferact/Kimi-K3-DSpark, method=dspark). The only dtype in that speculative-config is kv_cache_dtype=fp8, which sets the draft KV-cache storage precision, not the draft weights. No flag overrides or re-quantizes the draft-model weights, so the draft dtype is preserved from its checkpoint across this re-sweep."
Signed: seungrokj
❌❌❌ REJECTED ❌❌❌@seungrokj Two checks block this sign-off. First, the effective MI355X launch command does not match the linked vLLM Kimi-K3 recipe on major server args. Second, the sign-off does not record the DSpark draft's stored and effective precision. ❌ Check 3 (Recipe linked, merged, complete): FAIL — The published Kimi-K3 recipe linked in the sign-off does not match the major args of
❌ Check 13 (Draft runs as shipped): FAIL — Draft precision could not be verified from the sign-off. The additional detail section names
Passed and not applicable checks✅ Check 0 (CODEOWNER): PASS — ✅ Check 1 (Passing sweep on in-PR commit): PASS — Run 36082123873 (attempt 2) ran on in-PR commit ✅ Check 2 (Evals pass): PASS — ✅ Check 4 (Reuse command): PASS — ✅ Check 5 (Latest checklist template): PASS — All 17 current template items, including the recipe sub-item, are present and checked. ✅ Check 6 (Upstream images / engine-first): PASS — ✅ Check 7 (No deprecated models/scenarios): PASS — ✅ Check 8 (No architecture hacks): PASS — No ✅ Check 9 (Spec-decode via chat template): PASS — The agentic replay drives ✅ Check 10 (No engine patches): PASS — Only the image tag changes. The unchanged script has no patches, site-packages edits, or engine wheel installs. ✅ Check 11 (Golden simulated AL): PASS — vLLM ➖ Check 12 (Append-only): N/A — The new changelog entry has no ✅ Check 14 (Pareto coverage): PASS — Computed from the Assessed commit: |
|
@edwingao28 regarding check 3 & 13, we still stick to Inferact/Kimi-K3-DSpark |
|
just to add up evidence The image bump looks fine technically, and the new-image sweep/evals are complete. Keeping Inferact is expected per For Check 13, the existing public evidence supports BF16 draft weights:
The draft's |
3 participants
Description
Refreshes the image on
kimik3-fp4-mi355x-vllm-agentic-mtpand re-sweeps it.image:is the only line that changes.nightly-rocm100-af1c01499b289be555c475669ba50a88e96d846e(vLLMmainat 2026-09-16T04:37Z)nightly-rocm100-7f1a5398e9610d96c473931a26c0e12bbe0d0423(vLLMmainat 2026-09-24T04:46Z)The search space is untouched, and so is
benchmarks/single_node/agentic/kimik3_fp4_mi355x_mtp.sh: TP=8 at concurrency 1 and 4 with GPU-resident KV, concurrency 8, 10, 12 and 14 onvllm-simpleDRAM offload, and concurrency 44, 48 and 70 on TP8/DCP8 withvllm-simple. Nine points, the same shape as the current curve.Baseline being replaced
The curve in production was measured by run 35157825655 on 2026-09-16, and every one of its 9 throughput and 9 eval cells ran on
nightly-rocm100-af1c0149. That pin is now eight days old. This sweep is the qualification for the new image; the green run on the old pin is not evidence for it.What the jump carries
Three Kimi-K3 correctness fixes the current curve predates:
Plus ROCm CPU KV-offload work that this arm exercises at every concurrency above 4, since seven of its nine points run
SimpleCPUOffloadConnector. Most directly vllm-project/vllm#57160 (private pinned tensors for ROCm CPU KV offload) and vllm-project/vllm#50045 (offload back-pressure detection and remediation).Image verification
The tag published 2026-09-24T05:45:09Z. Docker Hub reports it
activeandlinux/amd64at digestsha256:5df261803a5b4e8c4d6bbe58a32c9cd597140b6fdfa7358c0ef0d0211c33ab32, 17.14 GB, and a manifest request toregistry-1.docker.ioreturns that same digest for the tag.compare/af1c0149...7f1a5398reportsahead, so the new pin is a descendant of the old one and this is a pure forward move. It is the same image #3404 pins for the MI355X DSv4.1-Flash vLLM arm, on the ROCm 10.0 nightly channel these two arms share.Validation
configs/amd-master.yaml,configs/runners.yamlandperf-changelog.yamlall parse,git diff --checkis clean, andinfx.workflows.validate_perf_changelog --base-ref origin/main --head-ref HEADpasses. Targeted generation emits exactly 9 points, all carrying the new tag:Each resolves
runner: cluster:mi355x-amds,precision: fp4,spec-decoding: mtp,dram-utilization: 0.60andduration: 3600. GPU sweep and eval results are pending.AI model disclosure
claude-opus-5-thinking-high), via the Cursor agent.Related Issue
N/A
Type of Change
Checklist
perf-changelog.yamland have not edited historical entriesOWNER/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 sweep label will no longer automatically kick off new sweeps. Remove and re-add the label to force one.中文
说明
刷新
kimik3-fp4-mi355x-vllm-agentic-mtp的镜像并重新扫描。改动仅限image:一行。nightly-rocm100-af1c01499b289be555c475669ba50a88e96d846e（vLLMmain于 2026-09-16T04:37Z）nightly-rocm100-7f1a5398e9610d96c473931a26c0e12bbe0d0423（vLLMmain于 2026-09-24T04:46Z）搜索空间未改动，
benchmarks/single_node/agentic/kimik3_fp4_mi355x_mtp.sh同样未改动：TP=8 在并发 1 与 4 使用 GPU 常驻 KV，并发 8、10、12、14 使用vllm-simpleDRAM 卸载，并发 44、48、70 使用 TP8/DCP8 加vllm-simple。共 9 个数据点，与当前曲线形状一致。被替换的基线
生产曲线由 run 35157825655 于 2026-09-16 测得，其 9 个吞吐单元与 9 个评测单元全部运行在
nightly-rocm100-af1c0149上。该镜像至今已有八天。本次 sweep 即为新镜像的资格验证；旧镜像上的绿色运行不能作为新镜像的证据。此次跨度带来的改动
当前曲线所不含的三项 Kimi-K3 正确性修复：
以及本臂在并发大于 4 时均会使用的 ROCm CPU KV 卸载改动（9 个点中有 7 个使用
SimpleCPUOffloadConnector），其中最直接的是 vllm-project/vllm#57160（ROCm CPU KV 卸载改用私有 pinned 张量）与 vllm-project/vllm#50045（卸载背压检测与缓解）。镜像验证
该标签发布于 2026-09-24T05:45:09Z。Docker Hub 显示其状态为
active、平台为linux/amd64，摘要为sha256:5df261803a5b4e8c4d6bbe58a32c9cd597140b6fdfa7358c0ef0d0211c33ab32，大小 17.14 GB；向registry-1.docker.io请求该标签的 manifest 返回相同摘要。compare/af1c0149...7f1a5398返回ahead，说明新镜像是旧镜像的后代，本次为纯向前移动。该镜像与 #3404 为 MI355X DSv4.1-Flash vLLM 臂所固定的镜像相同，两个臂共用同一 ROCm 10.0 nightly 通道。验证
configs/amd-master.yaml、configs/runners.yaml与perf-changelog.yaml均可解析，git diff --check无告警，infx.workflows.validate_perf_changelog --base-ref origin/main --head-ref HEAD通过。定向生成恰好产出 9 个数据点且全部携带新标签，命令与结果见上方英文部分。各点均解析为
runner: cluster:mi355x-amds、precision: fp4、spec-decoding: mtp、dram-utilization: 0.60与duration: 3600。GPU sweep 与评测结果尚待完成。AI 模型使用说明、关联 issue、改动类型与检查清单见上方英文部分。