[codex] update MiniMax M3 FP8 MI355X vLLM image#1942
Conversation
ab9d3a0 to
abeb6ee
Compare
|
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 联系核心维护者。 |
|
Claude finished @functionstackx's task in 18s —— View job PR Review
LGTM — no blocking issues found.
|
There was a problem hiding this comment.
LGTM — straightforward image pin from a floating tag to the same immutable nightly already used by sibling MiniMax-M3 MI355X vLLM recipes, with the required perf-changelog entry.
Extended reasoning...
Overview
This PR makes two minimal changes:
.github/configs/amd-master.yaml: bumpsminimaxm3-fp8-mi355x-vllm.imagefrom the floatingvllm/vllm-openai-rocm:minimax-m3tag to the immutable digest-pinnedvllm/vllm-openai-rocm:nightly-3f5a1e1733200760169ff31ebe60a271072b199e.perf-changelog.yaml: appends the required changelog trigger entry for this config key.
All serving flags and the TP/EP/DP-attention search space for the recipe are untouched.
Security risks
None. Both files are CI sweep configuration consumed internally; no auth/crypto/permissions code is involved. The new image string is sourced from the official vllm/vllm-openai-rocm repository and is identical to the digest already pinned by the sister minimaxm3-fp4-mi355x-vllm and minimaxm3-fp4-mi355x-vllm-mtp recipes elsewhere in the same file — a coordinated pin, not a new untrusted artifact.
Level of scrutiny
Low. This is exactly the mechanical config-tweak shape that is safe to shadow-approve: two-file diff, one image-tag swap, one mandatory changelog append, no logic, no schema change. The author validated by regenerating filtered non-MTP entries and running pytest utils/matrix_logic/ (180 passed). The recipe-reminder comment is the standard auto-post and not a blocker.
Other factors
The bug-hunting system reported no findings. The PR is labelled full-sweep-fail-fast, meaning the sweep itself will surface any image-level regression before merge — appropriate gating for an image bump.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28212795766 |
2 similar comments
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28212795766 |
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28212795766 |
|
/reuse-sweep-run |
# Conflicts: # perf-changelog.yaml
|
/reuse-sweep-run |
What changed
minimaxm3-fp8-mi355x-vllmfromvllm/vllm-openai-rocm:minimax-m3to the immutablevllm/vllm-openai-rocm:nightly-3f5a1e1733200760169ff31ebe60a271072b199eimageWhy
This moves the non-MTP MiniMax-M3 MXFP8 MI355X sweep onto the current pinned ROCm nightly while leaving its serving flags and TP/EP/DP-attention search space unchanged.
Validation
python -m pytest utils/matrix_logic/ -q(180 passed)