[WIP][NV] dsv4-fp4-b200-sglang image to SGLang nightly 20260624

[hshrivastava-droid]

Update dsv4-fp4-b200-sglang to the latest SGLang mainline nightly container.

• Previous: lmsysorg/sglang:deepseek-v4-blackwell@sha256:df18bfc4... (DeepSeek-V4 Blackwell feature-branch tag, last updated 2026-04-29)
• New: lmsysorg/sglang:nightly-dev-cu13-20260624-b2c8f7a2

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

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

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

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 保持一致

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

如果不一致，请先创建一个 PR，之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准，使整个 ML 社区都能从你的辛勤工作中受益！谢谢

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

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 联系核心维护者。

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

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

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

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 保持一致

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

如果不一致，请先创建一个 PR，之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准，使整个 ML 社区都能从你的辛勤工作中受益！谢谢

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

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]

LGTM — simple image bump for a benchmark recipe with a matching changelog entry.

Extended reasoning...

Overview

This PR updates the SGLang container image for the dsv4-fp4-b200-sglang benchmark config in .github/configs/nvidia-master.yaml from a feature-branch tag (deepseek-v4-blackwell) to a mainline nightly (nightly-dev-cu13-20260624-b2c8f7a2), and adds a corresponding entry to perf-changelog.yaml. The diff is two lines plus a 5-line changelog block.

Security risks

None. This is a benchmark recipe image reference; it does not touch auth, crypto, or any production code path. The image is from the same upstream publisher (lmsysorg/sglang). Note that the new tag is not pinned by digest (unlike the previous @sha256:... pin), which slightly reduces reproducibility, but this is a common pattern for nightly bumps in this repo and matches the changelog convention.

Level of scrutiny

Very low. This is a routine config-only image bump for a single benchmark recipe, following the established *-changelog.yaml pattern visible in recent commits (e.g., 5873043). No logic changes, no shared infrastructure touched.

Other factors

The inline bug comment is explicitly tagged [Nit] and flags that this PR happens to retire the last *deepseek-v4-blackwell* consumer, which makes several TODO-tagged conditionals in B200 launcher scripts dead code. That cleanup is genuinely a follow-up and not a blocker — the dead branches fall through to the correct default. The author can choose to address it here or in a separate [skip-sweep] PR.

[claude]

🟡 This PR removes the last *deepseek-v4-blackwell* image consumer from .github/configs/, which makes several runner conditionals + TODOs dead code that their authors explicitly tagged for removal at this exact moment: runners/launch_b200-cw.sh:22-31, runners/launch_b200-dgxc.sh:416-425, runners/launch_b200-nb.sh:18-27 (each has a "drop the conditional once the image stops installing editable under /workspace" TODO), and benchmarks/single_node/fixed_seq_len/dsv4_fp4_b200.sh:31-35 (stale workaround comment). runners/launch_b300-nv.sh should stay — it also matches *deepseek-v4-bw-ultra*/*deepseek-v4-b300*/*sglang-b300* which are still live. Also worth calling out in the changelog entry: this image swap silently flips CONTAINER_MOUNT_DIR from /ix to /workspace for this config (almost certainly the intended outcome — the bench script uses $PWD-relative paths — but undocumented).

Extended reasoning...

What this PR enables

Line 1722 of .github/configs/nvidia-master.yaml was the last config entry that pinned the lmsysorg/sglang:deepseek-v4-blackwell image. A grep over .github/configs/ after this diff returns zero remaining matches for *deepseek-v4-blackwell*. The other four dsv4-*-b200-* recipes (lines 1763/1808/1829/1852) use unrelated vllm-openai:* and trtllm-deepseek-v4 images and never matched this glob.

What is now dead code

Three B200 launcher scripts share an identical guarded block, each with a TODO that explicitly nominates this moment for removal:

# runners/launch_b200-cw.sh:22-31  (and launch_b200-dgxc.sh:416-425, launch_b200-nb.sh:18-27)
# TODO(...): drop the conditional once the image stops installing editable under /workspace.
if [[ "$IMAGE" == *deepseek-v4-blackwell* ]]; then
  CONTAINER_MOUNT_DIR=/ix
else
  CONTAINER_MOUNT_DIR=/workspace
fi

With no remaining config matching *deepseek-v4-blackwell*, the true branch (/ix) is unreachable on the live workflow surface — the precondition the TODO authors named is now met. Similarly, benchmarks/single_node/fixed_seq_len/dsv4_fp4_b200.sh:31-35 carries a TODO describing the /workspace editable-install workaround that no longer applies to the new mainline nightly.

Why launch_b300-nv.sh should NOT be touched

runners/launch_b300-nv.sh:400-406 uses a broader pattern (*deepseek-v4-blackwell* || *deepseek-v4-bw-ultra* || *deepseek-v4-b300* || *sglang-b300*). The other branches still match live B300 / hopper-pinned configurations, so its conditional is not dead. The bug correctly scopes the cleanup to the three B200 launchers + the bench script.

Step-by-step proof the /ix branch is unreachable after this PR

1. Before this PR: dsv4-fp4-b200-sglang.image = lmsysorg/sglang:deepseek-v4-blackwell@sha256:df18bfc4... → at runtime IMAGE=lmsysorg/sglang:deepseek-v4-blackwell@... → glob *deepseek-v4-blackwell* matches → CONTAINER_MOUNT_DIR=/ix.
2. After this PR: image: lmsysorg/sglang:nightly-dev-cu13-20260624-b2c8f7a2 → glob does not match → falls through to CONTAINER_MOUNT_DIR=/workspace.
3. grep -r 'deepseek-v4-blackwell' .github/configs/ returns zero hits after the diff is applied. No other config can take the /ix branch.

Behavioral side-effect worth noting in the changelog

For dsv4-fp4-b200-sglang specifically, CONTAINER_MOUNT_DIR silently flips from /ix to /workspace. This is the intended outcome — the bench script's own comment notes that paths inside it are $PWD-relative for precisely this transition — but the perf-changelog entry only mentions the image bump, not the mount-dir side-effect. A line in the changelog ("Container mount dir now /workspace (was /ix); paths in the bench script are $PWD-relative so this is transparent.") would make the side-effect traceable for future bisects.

Impact and how to fix

None of this is a correctness defect — the dead conditional simply falls through to the correct default, and the mount-dir change is the intended behavior. But the TODOs themselves identify this PR as the natural cleanup moment, so bundling the four-file removal here keeps the cleanup atomic with the change that justifies it. Suggested follow-up (in this PR or [skip-sweep] follow-up): delete the three if [[ "$IMAGE" == *deepseek-v4-blackwell* ]] blocks in the B200 launchers, replacing them with a plain CONTAINER_MOUNT_DIR=/workspace; remove the stale TODO in dsv4_fp4_b200.sh:31-35; and add a one-line note about the mount-dir change to the changelog entry.

[github-actions]

see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28120029984
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=28120029984

[github-actions]

see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28120029984
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=28120029984