chore: tag dsv4 b300 benchmark scripts with inference engine

[cquil11]

Summary

• B300 single-node launcher now prefers a framework-tagged script (e.g. dsv4_fp4_b300_sglang.sh) and falls back to the legacy unsuffixed name (or the existing _trt suffix) when no tagged variant exists.
• Renamed benchmarks/single_node/dsv4_fp4_b300.sh → dsv4_fp4_b300_sglang.sh.
• Restored benchmarks/single_node/dsv4_fp4_b300_vllm.sh from the abandoned origin/claude/add-dsv4-fp4-b300-vllm branch (script only; no config wired up yet — separate PR can add dsv4-fp4-b300-vllm to nvidia-master.yaml when we want CI to run it).

Each model historically used one inference engine, so the launcher resolved ${model}_${precision}_b300.sh regardless of FRAMEWORK. dsv4 is the first b300 model where both sglang and vllm need to coexist; this PR adds the plumbing for that without forcing a rename of the other ~17 b300 scripts.

Test plan

• Trigger a dsv4-fp4-b300-sglang sweep — launcher should resolve to dsv4_fp4_b300_sglang.sh.
• Confirm an existing dsr1-fp4-b300-sglang sweep still resolves to the legacy dsr1_fp4_b300.sh via fallback.
• Spot-check that _mtp configs still find their script (*_b300_mtp.sh via fallback).

🤖 Generated with Claude Code

[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://cookbook.sglang.io/
• https://docs.vllm.ai/projects/recipes/en/latest/

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

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sgl-cookbook

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]

LGTM — mechanical launcher fallback plus script rename; the added vllm script is not yet wired into CI.

Extended reasoning...

Overview

The PR has three changes: (1) renames benchmarks/single_node/dsv4_fp4_b300.sh to dsv4_fp4_b300_sglang.sh, (2) adds a new dsv4_fp4_b300_vllm.sh script restored from an abandoned branch, and (3) updates runners/launch_b300-nv.sh to prefer a framework-tagged script (${model}_${precision}_b300_${FRAMEWORK}.sh) with a fallback to the legacy unsuffixed/_trt-suffixed name. The launcher change is small and localized to the non-multinode branch.

Security risks

None meaningful. The launcher change is a string-built file path with a fall-through, the new vLLM script does sed -i on a vendored vLLM source file but this is a benchmark recipe running inside the GPU container on a SLURM allocation, which is consistent with the pattern already used by the SGLang sibling. No auth, crypto, or permissions code is touched.

Level of scrutiny

Low. This is benchmark/runner plumbing, not production-critical code. The launcher fallback logic cleanly preserves backward compatibility for the ~17 existing b300 scripts that have not been retagged, and the new vLLM script is explicitly not wired into nvidia-master.yaml per the PR description, so it cannot accidentally get picked up by CI until a follow-up PR opts in.

Other factors

The bug hunter found only a single nit — a misleading comment at the top of dsv4_fp4_b300_vllm.sh that references dsv4_fp4_b200.sh (an SGLang script) as if it were a vLLM sibling. That is documentation-only and does not affect runtime behavior. The test plan in the PR description covers the three relevant fallback cases (new tagged script, legacy-name script, _mtp variant). Happy to let this merge without human review.

[claude]

🟡 The header comment claims this script "mirrors dsv4_fp4_b200.sh" since the vLLM blog lists 8xB200 and 8xB300 with identical flags, but dsv4_fp4_b200.sh is an SGLang script (uses sglang serve with SGLang-specific flags like --moe-runner-backend, --moe-a2a-backend deepep, CONC-based recipe dispatch). This new script uses vllm serve with an entirely different flag set and a vLLM-specific monkey-patch — they share no engine or flags. Consider dropping the mirrors dsv4_fp4_b200.sh reference (or pointing it at an actual vLLM companion) so future readers don't go looking for parity that doesn't exist.

Extended reasoning...

What's wrong

Lines 3-5 of benchmarks/single_node/dsv4_fp4_b300_vllm.sh read:

# Per https://vllm.ai/blog/deepseek-v4 the DeepSeek-V4-Pro recipe lists
# 8xB200 and 8xB300 with identical flags, so this script mirrors
# dsv4_fp4_b200.sh.

The "so this script mirrors dsv4_fp4_b200.sh" conclusion only follows if dsv4_fp4_b200.sh is itself a vLLM script — but it isn't. benchmarks/single_node/dsv4_fp4_b200.sh invokes PYTHONNOUSERSITE=1 sglang serve and uses SGLang-only flags (--moe-runner-backend flashinfer_mxfp4, --moe-a2a-backend deepep, --enable-dp-attention, --deepep-config, etc.) plus a CONC-based 3-recipe dispatch (low-latency / balanced / max-throughput).

The new script doesn't mirror it

dsv4_fp4_b300_vllm.sh invokes vllm serve with a totally disjoint flag set (--kv-cache-dtype fp8, --block-size 256, --enable-expert-parallel, --data-parallel-size, --compilation-config '{...}', --tokenizer-mode deepseek_v4, --reasoning-parser deepseek_v4, etc.), monkey-patches vLLM's sparse_attn_indexer.py, has no RECIPE_FLAGS array, and no CONC-based dispatch. The two scripts share nothing beyond trivial benchmark_lib.sh boilerplate.

Why the existing wording is misleading

The vLLM blog parity claim ("B200 and B300 with identical flags") is a vLLM-to-vLLM statement and would justify mirroring a hypothetical dsv4_fp4_b200_vllm.sh — but no such file exists in the repo. The PR description even notes that this script was "restored from the abandoned origin/claude/add-dsv4-fp4-b300-vllm branch," which is a plausible explanation for the stale reference: it may originally have pointed at a never-merged vLLM b200 sibling.

Step-by-step proof

1. Open benchmarks/single_node/dsv4_fp4_b200.sh and grep for the server invocation → line ~86 reads PYTHONNOUSERSITE=1 sglang serve \. So b200 is SGLang.
2. Open benchmarks/single_node/dsv4_fp4_b300_vllm.sh and grep for the server invocation → it reads vllm serve $MODEL .... So b300_vllm is vLLM.
3. Compare flag lists: b200 uses --moe-runner-backend, --moe-a2a-backend deepep, --mem-fraction-static, --disable-radix-cache, etc.; b300_vllm uses --kv-cache-dtype fp8, --block-size, --enable-expert-parallel, --data-parallel-size, --compilation-config, etc. → zero overlap.
4. ls benchmarks/single_node/dsv4_fp4_b200_vllm.sh → no such file. So no actual vLLM b200 sibling to mirror.
5. Conclusion: the comment is factually wrong; reading b200.sh expecting flag/structure parity will mislead.

Impact / fix

This is documentation only — no runtime behavior is affected. But the comment is the first thing a reader sees, and the PR is specifically about disambiguating engines (_sglang vs _vllm suffixes). Leaving a comment that points the vLLM script at the SGLang script undercuts that disambiguation. Suggested fix: either drop the so this script mirrors dsv4_fp4_b200.sh clause and keep just the recipe-source link, or replace it with something accurate like "flags follow the vLLM DeepSeek-V4-Pro recipe; B200 and B300 use identical flags per the blog."