[AMD] MiniMax-M3 FP4/FP8 MI355X ATOM: refactor config & add MTP recipes#2001
Conversation
- Bump image from rocm/atom-dev:MiniMax-M3-20260623 to nightly_202607011530 - Add --online_quant_config (ptpc_fp8 with MoE exclusions) to all 4 scripts - Replace AITER_QUICK_REDUCE_CAST_BF16_TO_FP16 + ATOM_M3_SPARSE_USE_ASM_PA with ATOM_FORCE_ATTN_TRITON=1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
seungrokj
requested review from
1am9trash,
billishyahao,
chunfangamd and
yctseng0211
as code owners
|
Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you 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. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers. If additional help is needed, PR authors can reach out to core maintainers over Slack. 感谢你的贡献！对于 vLLM 与 SGLang，请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致 如果不一致，请先创建一个 PR，之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准，使整个 ML 社区都能从你的辛勤工作中受益！谢谢 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。如果选择重新运行失败的任务，PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档：https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow 一般而言，PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准，然后再请求核心维护者审阅。 如需更多帮助，PR 作者可通过 Slack 联系核心维护者。 |
2 similar comments
|
Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you 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. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers. If additional help is needed, PR authors can reach out to core maintainers over Slack. 感谢你的贡献！对于 vLLM 与 SGLang，请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致 如果不一致，请先创建一个 PR，之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准，使整个 ML 社区都能从你的辛勤工作中受益！谢谢 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。如果选择重新运行失败的任务，PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档：https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow 一般而言，PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准，然后再请求核心维护者审阅。 如需更多帮助，PR 作者可通过 Slack 联系核心维护者。 |
|
Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you 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. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers. If additional help is needed, PR authors can reach out to core maintainers over Slack. 感谢你的贡献！对于 vLLM 与 SGLang，请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致 如果不一致，请先创建一个 PR，之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准，使整个 ML 社区都能从你的辛勤工作中受益！谢谢 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。如果选择重新运行失败的任务，PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档：https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow 一般而言，PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准，然后再请求核心维护者审阅。 如需更多帮助，PR 作者可通过 Slack 联系核心维护者。 |
seungrokj
changed the title
|
@Oseltamivir @functionstackx This is reincarnation of #1967, #1968 without indexcaching |
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28646615329 |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| # block size 128 is mandatory for MSA. TP4 on a single gfx950 node, per the recipe. | ||
| minimaxm3-fp4-mi355x-atom: | ||
| image: rocm/atom-dev:MiniMax-M3-20260623 | ||
| image: rocm/atom-dev:nightly_202607011530 |
There was a problem hiding this comment.
🔴 This PR bumps the ATOM image, swaps env vars, and adds a new --online_quant_config flag across all four minimaxm3-*-mi355x-atom recipes, but does not append a perf-changelog.yaml entry. AGENTS.md's "Updating Docker images" section (line 126) explicitly states an entry is required — triggers benchmarks, and without it the four sweeps listed in this PR's own test-plan checklist will not run automatically in CI. Please append a changelog block listing the four affected config-keys (minimaxm3-fp4-mi355x-atom, minimaxm3-fp4-mi355x-atom-mtp, minimaxm3-fp8-mi355x-atom, minimaxm3-fp8-mi355x-atom-mtp), mirroring the pattern used in PRs #1978 and #1990 at the tail of the file.
Extended reasoning...
What is missing. The PR touches five files (configs/amd-master.yaml and the four benchmarks/single_node/fixed_seq_len/minimaxm3_*_mi355x_atom*.sh scripts) but does not modify perf-changelog.yaml. The changes made across those five files are exactly the kind that AGENTS.md flags as changelog-triggering:
- Image tag bump on all four ATOM recipes:
rocm/atom-dev:MiniMax-M3-20260623→rocm/atom-dev:nightly_202607011530(configs/amd-master.yaml:2648, 2667, 2686, 2705). - Env var swap in all four
.shscripts: removesAITER_QUICK_REDUCE_CAST_BF16_TO_FP16=0andATOM_M3_SPARSE_USE_ASM_PA=1, addsATOM_FORCE_ATTN_TRITON=1. - New serving flag in all four
.shscripts: adds--online_quant_config(ptpc_fp8 with MoE exclusion list) via the newOPT_ARGSarray.
Why this is required, not optional. AGENTS.md is unambiguous. Line 15: perf-changelog.yaml - benchmark trigger log; append-only. Line 58: Changes to perf-changelog.yaml trigger benchmark runs. And lines 124–126 (§ Updating Docker images): Update the image tag in the relevant configs/*-master.yaml and/or benchmarks/*.sh, update any related env vars / config params, and append a perf-changelog.yaml entry (required - triggers benchmarks).
Concrete consequence for this PR. The PR test-plan lists four sweeps that must be validated before merge: minimaxm3-fp4-mi355x-atom, minimaxm3-fp4-mi355x-atom-mtp, minimaxm3-fp8-mi355x-atom, minimaxm3-fp8-mi355x-atom-mtp. Because perf-changelog.yaml is the mechanism that tells the sweep runner which configs to benchmark for this PR, and no entry was added, none of those four sweeps will fire automatically. The PR ships an image + env/flag change that has never been validated in this repo's CI.
Step-by-step proof.
- Look at PR [AMD] MiniMax-M3 FP4/FP8 MI355X ATOM: refactor config & add MTP recipes #2001's changed-file list (in the PR metadata): 5 files, none of which is
perf-changelog.yaml. - Look at AGENTS.md:124–126 — the exact scenario in this PR (image tag bump + env var swap + new server flag on ATOM recipes in
configs/amd-master.yamlandbenchmarks/single_node/fixed_seq_len/*.sh) is what that section describes. - Look at the tail of
perf-changelog.yamlat HEAD: PR Update Minimax M3 FP4 vllm #1978 (minimaxm3-fp4-b200-vllmimage bump) and [NV] perf: update MiniMax-M3 FP4 B300 vLLM #1990 (minimaxm3-fp4-b300-vllmimage bump) each appended a block withconfig-keys, adescription, and apr-link. This is the pattern to follow. - Because no entry was appended for PR [AMD] MiniMax-M3 FP4/FP8 MI355X ATOM: refactor config & add MTP recipes #2001, the sweep-selection filter (which reads
perf-changelog.yamlchronologically to determine whichconfig-keysthis PR modified) sees zero new keys and skips all four MiniMax-M3 ATOM sweeps.
How to fix. Append a block to the end of perf-changelog.yaml (preserving its append-only whitespace convention — see AGENTS.md:150) along the lines of:
- config-keys:
- minimaxm3-fp4-mi355x-atom
- minimaxm3-fp4-mi355x-atom-mtp
- minimaxm3-fp8-mi355x-atom
- minimaxm3-fp8-mi355x-atom-mtp
description:
- "Bump ATOM image to rocm/atom-dev:nightly_202607011530 for all four MiniMax-M3 single-node MI355X ATOM recipes."
- "Replace AITER_QUICK_REDUCE_CAST_BF16_TO_FP16=0 and ATOM_M3_SPARSE_USE_ASM_PA=1 env vars with ATOM_FORCE_ATTN_TRITON=1."
- "Add --online_quant_config (ptpc_fp8, with MoE layer exclusions) to all four serving scripts."
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/2001That single append unblocks the four sweeps in the PR's own test plan.
seungrokj
changed the title
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28646817197 |
|
/reuse-sweep-run |
chunfangamd
left a comment
chunfangamd
left a comment
There was a problem hiding this comment.
- [ x] Verified that as of the moment of typing this, this is the latest version of PR_REVIEW_CHECKLIST.md
- [x ] Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
- [x ] Verified that this PR has passed PR validation: https://github.com/SemiAnalysisAI/InferenceX/actions/runs/28646817197
- [x ] Verified that this PR passes evals: https://github.com/SemiAnalysisAI/InferenceX/actions/runs/28646817197
- [ x] Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
- [ x] If an company claims that they support vLLM/SGLang as first class 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.
Signed: @chunfangamd
|
@Oseltamivir can you plz merge this ? |
|
/reuse-sweep-run |
3 participants
Summary
rocm/atom-dev:MiniMax-M3-20260623torocm/atom-dev:nightly_202607011530for all 4 single-node MiniMax-M3 ATOM recipes (FP4, FP4-MTP, FP8, FP8-MTP)--online_quant_configwith ptpc_fp8 and MoE layer exclusions to all scriptsAITER_QUICK_REDUCE_CAST_BF16_TO_FP16=0+ATOM_M3_SPARSE_USE_ASM_PA=1withATOM_FORCE_ATTN_TRITON=1PR Review Checklist
🤖 Generated with Claude Code