[Klaud Cold] Update minimaxm2.5-fp4-b300-vllm vLLM image to v0.21.0#1453
Conversation
|
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. |
1 similar comment
|
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. |
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=26006182198 |
There was a problem hiding this comment.
LGTM, straightforward vLLM image version bump with corresponding changelog entry.
Extended reasoning...
Overview
This PR bumps the minimaxm2.5-fp4-b300-vllm container image from vllm/vllm-openai:v0.19.0-cu130 to vllm/vllm-openai:v0.21.0 in .github/configs/nvidia-master.yaml and adds a corresponding entry to perf-changelog.yaml. The total diff is 7 lines added, 1 line changed — a single config key edit plus a new changelog block.
Security risks
None. This is a version-pin update for a published upstream image (vllm/vllm-openai) used for inference benchmarks; no auth, crypto, permissions, or input-handling code is touched.
Level of scrutiny
Low. The change follows the established pattern used throughout this repo for image bumps (e.g. recent PRs #1404, #1394, #1416 referenced in git log) — a single image: line update plus a changelog entry. The full-sweep-enabled label means CI will actually exercise the new image before merge, which provides the meaningful validation.
Other factors
The one bug surfaced by the bug hunting system is a cosmetic nit — the changelog description contains a (26d old) automation annotation that no other entry in the file uses. It does not affect parsing, runtime, or any tooling — purely a consistency issue worth addressing for future automation runs. Not a blocker for this PR.
| - config-keys: | ||
| - minimaxm2.5-fp4-b300-vllm | ||
| description: | ||
| - "Update vLLM image from v0.19.0-cu130 (26d old) to v0.21.0" | ||
| pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1453 |
There was a problem hiding this comment.
🟡 The new perf-changelog entry's description contains an automation-metadata annotation "(26d old)" that does not appear in any other entry in this file. All ~50+ other "Update image from to " entries follow the strict format without an age suffix; consider stripping the parenthetical so this line reads "Update vLLM image from v0.19.0-cu130 to v0.21.0" for consistency.
Extended reasoning...
What the bug is
The new entry added to perf-changelog.yaml (line 2636) reads:
- config-keys:
- minimaxm2.5-fp4-b300-vllm
description:
- "Update vLLM image from v0.19.0-cu130 (26d old) to v0.21.0"
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1453The parenthetical (26d old) is a freshness/age annotation produced by the automation that opened this PR — the same string appears verbatim in the PR description ("Bumps minimaxm2.5-fp4-b300-vllm from vllm/vllm-openai:v0.19.0-cu130 (26d old) to vllm/vllm-openai:v0.21.0"). It is automation metadata that escaped into the human-readable, version-controlled changelog.
Why this is inconsistent with the rest of the file
perf-changelog.yaml has a strong convention: every "Update …" description follows the shape Update <framework> image from <oldver> to <newver> with no annotations. A grep for \(\d+d old\) across the entire file returns exactly one match — this new entry. Concrete comparison with the immediately preceding analogous entries:
- Line 2605:
Update SGLang image from v0.5.11-cu130 to v0.5.12-cu130 - Line 2611:
Update SGLang image from v0.5.10-rocm720-mi30x to v0.5.12-rocm720-mi30x - Line 2618:
Update SGLang image from v0.5.11-cu130 to v0.5.12-cu130 - Line 2624:
Update vLLM image from v0.15.1 to v0.20.2 - Line 2630:
Update vLLM ROCm image from v0.18.0 to v0.21.0
None of these carry an age suffix.
Step-by-step proof
- Open
perf-changelog.yamland grep forUpdate vLLM image from— 19 matches across recent history. - Of those 19, 18 follow the form
Update vLLM image from <oldver> to <newver>with no parenthetical. - Exactly one — the new entry at line 2636, added by this PR — contains
(26d old). - Cross-reference the PR description: the same
(26d old)substring appears there, confirming it is automation freshness metadata copied verbatim rather than intentional changelog prose.
Impact
Purely cosmetic. The file is YAML and the field is a free-text description, so this does not affect parsing, runtime, CI, or any downstream tooling I'm aware of. The only cost is a small inconsistency in a changelog that is otherwise uniformly formatted.
Suggested fix
Strip the parenthetical so the description reads:
description:
- "Update vLLM image from v0.19.0-cu130 to v0.21.0"Going forward, the automation that generates these changelog entries should strip the (Nd old) suffix before emitting the description string.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=26006183154 |
|
/reuse-sweep-run |
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=26046003248 |
Summary
minimaxm2.5-fp4-b300-vllmfromvllm/vllm-openai:v0.19.0-cu130(26d old) tovllm/vllm-openai:v0.21.0.Test plan
full-sweep-enabledlabel.🤖 Generated with Claude Code