Re-append perf-changelog entry for minimaxm2.5-fp8-mi355x-vllm (#1276)#1293
Re-append perf-changelog entry for minimaxm2.5-fp8-mi355x-vllm (#1276)#1293chunfangamd merged 1 commit intomainfrom
Conversation
PR #1276 ("Tune MiniMax MI355X vLLM scheduling thresholds") landed without a perf-changelog entry — the prepared entry was dropped in commit 8d8b1e0 ("Remove MiniMax perf changelog entry") before merge, so the tuned recipe never re-ran on push-to-main and the dashboard still reflects the old launch policy. Re-add the entry so a sweep is triggered for the new policy and the change is documented chronologically. The entry references the original PR #1276, matching the convention used for prior changelog re-appends (e.g. #1269). Co-authored-by: Cursor <cursoragent@cursor.com>
|
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 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. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — straightforward re-append of a perf-changelog entry that was accidentally dropped before #1276 merged.
Extended reasoning...
Overview
Single-file change to perf-changelog.yaml that appends one new entry referencing PR #1276 (minimaxm2.5-fp8-mi355x-vllm scheduling tuning). The entry was prepared in #1276 but dropped in commit 8d8b1e0 before merge, so the tuned recipe never re-swept on push-to-main. This PR restores it to trigger the sweep and chronologically document the change.
Security risks
None. The change is purely declarative YAML metadata (config-keys, description text, pr-link). No code paths, secrets, or permissions touched.
Level of scrutiny
Low. This is a documentation/sweep-trigger entry following an established repo convention for changelog re-appends (the description cites #1269 as a prior example). The config-keys value matches the recipe name from #1276, and the pr-link points to the correct upstream PR. The diff is purely additive at the bottom of the file.
Other factors
No bugs were flagged by the bug hunting system. Only timeline activity is the standard recipe-reminder bot comment. Nothing here warrants human review.
2 participants
PR #1276 ("Tune MiniMax MI355X vLLM scheduling thresholds") landed without a perf-changelog entry — the prepared entry was dropped in commit 8d8b1e0 ("Remove MiniMax perf changelog entry") before merge, so the tuned recipe never re-ran on push-to-main and the dashboard still reflects the old launch policy.
Re-add the entry so a sweep is triggered for the new policy and the change is documented chronologically. The entry references the original PR #1276, matching the convention used for prior changelog re-appends (e.g. #1269).