Update dsr1-fp8-b200-sglang and -mtp SGLang image to v0.5.12-cu130#1416
Conversation
… to v0.5.12-cu130 Ref #1154 Co-authored-by: Klaud Cold <Klaud-Cold@users.noreply.github.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 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=25980011920 |
| - dsr1-fp8-b200-sglang-mtp | ||
| description: | ||
| - "Update SGLang image from v0.5.11-cu130 to v0.5.12-cu130" | ||
| pr-link: XXX |
There was a problem hiding this comment.
🟡 The new entry added to perf-changelog.yaml uses pr-link: XXX as an unfilled placeholder instead of the actual PR URL. Every other entry in this file uses a proper GitHub PR URL (e.g., https://github.com/SemiAnalysisAI/InferenceX/pull/1402 on line 2550); this should be https://github.com/SemiAnalysisAI/InferenceX/pull/1416 so the changelog entry remains traceable to its source PR.
Extended reasoning...
What the bug is
The diff appends a new entry to perf-changelog.yaml documenting the SGLang image bump for dsr1-fp8-b200-sglang and dsr1-fp8-b200-sglang-mtp. The last line of that new entry reads:
pr-link: XXXXXX is a placeholder string, not a valid URL. It is the literal token typically left behind when a template-driven changelog entry is generated and the author/automation forgets to substitute in the real PR number.
Why this matters
Every other entry in perf-changelog.yaml follows a clear convention: pr-link is a full GitHub URL pointing at the PR that introduced the change. For example, the four entries immediately preceding this one are:
- line 2532:
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1407 - line 2538:
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1408 - line 2544:
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1409 - line 2550:
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1402
The new entry breaks this convention. The changelog is the authoritative record connecting an image/config change to the PR that motivated it; leaving XXX in place severs that link and makes future debugging harder when someone wants to understand why SGLang was bumped from v0.5.11-cu130 to v0.5.12-cu130.
Step-by-step proof
- View
perf-changelog.yamllines 2548–2557 — the diff appends a new list element under the top-level list. - The element has three keys:
config-keys(a list with two recipes),description(a one-line summary), andpr-link. - The value of
pr-linkis the literal stringXXX— not a URL, not a number, not a reference. - Compare to any other
pr-linkvalue in the file: they are all of the formhttps://github.com/SemiAnalysisAI/InferenceX/pull/<N>. - The current PR is Update dsr1-fp8-b200-sglang and -mtp SGLang image to v0.5.12-cu130 #1416, so the expected value is
https://github.com/SemiAnalysisAI/InferenceX/pull/1416.
How to fix
Replace line 2557 with:
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1416Severity rationale
This is a data-quality / metadata issue in a changelog file — it does not affect runtime behavior of any recipe or benchmark. However, it is also the only non-trivial content change in this PR's perf-changelog.yaml diff, so fixing it before merge is cheap and keeps the changelog convention intact. Flagging as a nit.
# Conflicts: # perf-changelog.yaml
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=25980012131 |
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=25984496981 |
|
/reuse-sweep-run |
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=25998506468 |
Updates SGLang image for
dsr1-fp8-b200-sglanganddsr1-fp8-b200-sglang-mtpfrom v0.5.11-cu130 to v0.5.12-cu130.\nRef #1154
Generated with Claude Code