Add B300 config: dsv4-fp4-sglang-mtp

[cquil11]

Summary

MTP variant of #1132's `dsv4-fp4-b300-sglang`. Mirrors the same recipe-per-CONC structure with EAGLE / MTP enabled where the cookbook prescribes it, per https://docs.sglang.io/cookbook/autoregressive/DeepSeek/DeepSeek-V4.

Recipe	CONC	EAGLE flags
low-latency	≤ 32	`--speculative-num-steps 3 --speculative-num-draft-tokens 4`
balanced	33–128	`--speculative-num-steps 1 --speculative-num-draft-tokens 2`
max-throughput	> 128	none — cookbook says verify step costs more than it saves at saturation

`SGLANG_ENABLE_SPEC_V2=1` set per the cookbook MTP requirement; `--use-chat-template` passed to `bench_serving` so EAGLE acceptance rate isn't depressed by raw prompts (per AGENTS.md).

Files

• `.github/configs/nvidia-master.yaml` — new `dsv4-fp4-b300-sglang-mtp` config; same TP/EP/dp-attn split as the non-MTP version, all rows tagged `spec-decoding: mtp`.
• `benchmarks/single_node/dsv4_fp4_b300_mtp.sh` — adds EAGLE flags to low-latency and balanced `RECIPE_FLAGS` arrays (max-throughput unchanged).
• `perf-changelog.yaml` — additive entry to trigger the sweep.

Test plan

• `generate_sweep_configs.py --runner-type b300 --model-prefix dsv4` → 17 `spec=mtp` matrix rows for the new config (4+2+3 per 1k1k, 4+2+2 per 8k1k).
• `pytest utils/matrix_logic/` → 149 passed.
• Sweep run completes; result filenames carry `spec-mtp` and EAGLE acceptance is logged on low-latency / balanced.

Notes

Depends on the same lmsysorg/sglang:deepseek-v4-b300 image as #1132. The DeepEP FP8 weight-postprocess bug that #1132 hit on dpa=true rows is currently being tracked separately; this PR will hit the same failure on balanced + max-throughput until that's resolved upstream.

[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.

[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]

🔴 The new benchmarks/single_node/dsv4_fp4_b300.sh is dead code for the dsv4-fp4-b300-sglang config: benchmarks/single_node/dsv4_fp4_b300_sglang.sh (added by PR #1146) still exists with the hardcoded low-latency recipe, and runners/launch_b300-nv.sh:267-272 picks the framework-tagged file first and only falls back to the bare name when missing. The newly added balanced and max-throughput rows (tp=8 ep=8 dp-attn=true, conc 64-1024 / 64-512) will execute the stale low-latency recipe but produce result filenames tagged ep=8/dpa=true, mislabelling the data. Fix: rename dsv4_fp4_b300.sh → dsv4_fp4_b300_sglang.sh (overwriting), or delete the stale dsv4_fp4_b300_sglang.sh. The MTP variant is unaffected because dsv4_fp4_b300_sglang_mtp.sh does not exist.

Extended reasoning...

What goes wrong

This PR adds two new benchmark scripts:

• benchmarks/single_node/dsv4_fp4_b300.sh — recipe-per-CONC dispatch (low-latency / balanced / max-throughput)
• benchmarks/single_node/dsv4_fp4_b300_mtp.sh — MTP variant of the same dispatch

It also expands the dsv4-fp4-b300-sglang YAML from a single TP-only (tp:8, ep:1, conc 4-1024/4-512) row into three recipes per seq-len, with the inline comment "are selected inside benchmarks/single_node/dsv4_fp4_b300.sh by CONC".

The problem: benchmarks/single_node/dsv4_fp4_b300_sglang.sh already exists on main. It was created by PR #1146 (rename of the old dsv4_fp4_b300.sh to add the framework suffix), and was later edited to hardcode the low-latency recipe at every CONC (with a TODO(Cam) comment explicitly pointing at this branch chore/dsv4-sgl-b300 as the place to restore CONC dispatch). The branch's revert commit 90e8f3d recreated dsv4_fp4_b300.sh (the old, pre-rename path) but did not touch the framework-suffixed file — so after this PR merges, both files coexist on disk with different contents.

Why the new script never runs

runners/launch_b300-nv.sh:267-272:

BENCH_BASE="benchmarks/single_node/${EXP_NAME%%_*}_${PRECISION}_b300"
BENCH_SCRIPT="${BENCH_BASE}_${FRAMEWORK}${SPEC_SUFFIX}.sh"
if [[ ! -f "$BENCH_SCRIPT" ]]; then
    LEGACY_FW_SUFFIX=$([[ "$FRAMEWORK" == "trt" ]] && printf '_trt' || printf '')
    BENCH_SCRIPT="${BENCH_BASE}${LEGACY_FW_SUFFIX}${SPEC_SUFFIX}.sh"
fi

The framework-tagged path is preferred; the bare-name fallback only fires when the tagged file is missing.

Step-by-step proof for one row

Take the new balanced row { tp: 8, ep: 8, dp-attn: true, conc-start: 64, conc-end: 128 } from the dsv4-fp4-b300-sglang 1k1k search-space:

1. The runner is invoked with EXP_NAME=dsv4_1k1k (model-prefix dsv4, seq tag 1k1k), PRECISION=fp4, FRAMEWORK=sglang, no spec → SPEC_SUFFIX="".
2. BENCH_BASE = "benchmarks/single_node/dsv4_fp4_b300".
3. BENCH_SCRIPT = "benchmarks/single_node/dsv4_fp4_b300_sglang.sh" — and that file exists (verified on disk: 3008 bytes, blob c9fb238).
4. The fallback to dsv4_fp4_b300.sh is not taken.
5. The hardcoded RECIPE=low-latency block runs with --tp 8 (no --dp-size, no --enable-dp-attention, no --moe-a2a-backend deepep), regardless of CONC.
6. But the result filename is composed from the YAML row's ep=8/dpa=true tags, so the output is mislabelled: low-latency numbers presented as balanced numbers.

The same logic applies to the max-throughput rows (CONC 256-1024 / 256-512). Effectively the entire YAML expansion in this PR is a no-op for the non-MTP config — the low-latency-only recipe runs at all concurrency points, and three out of four search-space rows produce misleading data.

Why MTP is unaffected

For the new dsv4-fp4-b300-sglang-mtp config, SPEC_SUFFIX=_mtp, so the runner first checks for dsv4_fp4_b300_sglang_mtp.sh — which does not exist — then falls back to dsv4_fp4_b300_mtp.sh, which is the new MTP script added in this PR. So MTP works correctly; only the non-MTP config is broken.

Fix

Either:

• Rename benchmarks/single_node/dsv4_fp4_b300.sh → benchmarks/single_node/dsv4_fp4_b300_sglang.sh (overwriting the stale file), or
• Delete the existing benchmarks/single_node/dsv4_fp4_b300_sglang.sh so the new bare-name file is found via fallback.

The first option is the more direct fix since it leaves the framework-tagged convention intact (matching what PR #1146 standardised).

[cquil11]

closing in favor of #1166