Add B300 config: dsv4-fp4fp8-vllm (DeepSeek-V4-Pro)

[functionstackx]

Summary

• Add new B300 vLLM config dsv4-fp4-b300-vllm for DeepSeek-V4-Pro, per the recipe at https://vllm.ai/blog/deepseek-v4 (which lists 8xB200 and 8xB300 with identical flags).
• Uses vllm/vllm-openai:deepseekv4-cu130 against deepseek-ai/DeepSeek-V4-Pro. EP + DP=8 (no --tensor-parallel-size flag), FP8 KV cache, block size 256, FP4 indexer cache, prefix caching disabled.
• New launch script benchmarks/single_node/dsv4_fp4_b300.sh is a direct port of dsv4_fp4_b200.sh with a header note.

Companion PR

• B200 version: Add B200 config: dsv4-fp4-vllm (DeepSeek-V4-Pro) 🐋 🐋 #1127

Recipe flags

--trust-remote-code
--kv-cache-dtype fp8
--block-size 256
--no-enable-prefix-caching
--enable-expert-parallel
--data-parallel-size $TP    # $TP = 8 from search space
--compilation-config '{"cudagraph_mode":"FULL_AND_PIECEWISE","custom_ops":["all"]}'
--attention_config.use_fp4_indexer_cache=True
--tokenizer-mode deepseek_v4
--tool-call-parser deepseek_v4
--enable-auto-tool-choice
--reasoning-parser deepseek_v4

Search space

• 1k1k: { tp: 8, ep: 8, dp-attn: true, conc: 4..1024 }
• 8k1k: { tp: 8, ep: 8, dp-attn: true, conc: 4..512 }

Test plan

• generate_sweep_configs.py test-config --config-keys dsv4-fp4-b300-vllm expands to 17 entries (exp-name dsv4_1k1k/dsv4_8k1k, runner b300, tp=8, ep=8, dp-attn=true, max-model-len 2304/9472).
• bash -n benchmarks/single_node/dsv4_fp4_b300.sh passes.
• YAML files parse; perf-changelog.yaml diff vs main is pure additions (additions-only gate in process_changelog.py).
• Run the triggered sweep on a B300 runner — verify the server launches and benchmark + eval produce results.

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

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

LGTM — straightforward B300 port mirroring the companion B200 recipe; the inline EP-flag nit is non-blocking since the search space only emits ep: 8.

Extended reasoning...

Overview

This PR adds a new B300 vLLM config dsv4-fp4-b300-vllm for DeepSeek-V4-Pro per the official vLLM recipe (which lists 8xB200 and 8xB300 with identical flags). It touches three files: a new search-space entry in .github/configs/nvidia-master.yaml, a new launch script benchmarks/single_node/dsv4_fp4_b300.sh that's a direct port of the B200 script, and an additions-only entry in perf-changelog.yaml.

Security risks

None. This is a benchmarking config + launch script — no auth, crypto, permissions, or input-handling changes. The script runs in an isolated benchmark container.

Level of scrutiny

Low. This is a routine benchmark recipe addition following an established pattern (≈10 similar B200→B300 ports already in this changelog). The script mirrors dsv4_fp4_b200.sh from the companion PR #1127, the YAML entry is structurally identical to neighboring vLLM configs, and the PR description shows test-config expansion was verified.

Other factors

A nit was filed inline about the hardcoded --enable-expert-parallel flag not following the conditional-EP convention. The bug report itself classifies it as WARNING-level and notes runtime behavior is unaffected today (search space only emits ep: 8). The same pattern exists in the B200 source script being ported, so it's a pre-existing convention drift rather than a regression introduced here. The PR's only outstanding test-plan item is the actual B300 runner sweep, which can only be validated post-merge.

[claude]

🟡 The new dsv4_fp4_b300.sh hardcodes --enable-expert-parallel at line 47, violating the project's PR-review rule (.github/workflows/claude-pr-review.yml lines 141-159) that scripts must conditionally enable EP based on EP_SIZE. Every other vLLM/ATOM script in benchmarks/single_node/ uses the if [ "$EP_SIZE" -gt 1 ] pattern; please wrap the flag the same way (and add EP_SIZE to check_env_vars) so a future search-space entry with ep: 1 doesn't silently still apply expert parallelism.

Extended reasoning...

What the bug is

In benchmarks/single_node/dsv4_fp4_b300.sh line 47, the vllm serve invocation hardcodes --enable-expert-parallel unconditionally. The repo's own PR-review rules (.github/workflows/claude-pr-review.yml lines 141-159) explicitly forbid this and prescribe the canonical pattern:

if [ "$EP_SIZE" -gt 1 ]; then
  EP=" --enable-expert-parallel"
else
  EP=" "
fi

The rule is documented as a 🟡 WARNING-level review issue. Today the script also doesn't list EP_SIZE in its check_env_vars call (lines 8-16), so even if a caller exported EP_SIZE=1, the script would ignore it.

Why existing code doesn't prevent it

The sole reason runtime behavior is currently fine is that the new YAML search space (.github/configs/nvidia-master.yaml) only emits ep: 8 entries, so the runner always intends EP. There is nothing structural preventing a future ep: 1 entry — and once one is added, this script will silently still pass --enable-expert-parallel, contradicting the YAML's declared intent.

Code-path proof

1. A future contributor adds { tp: 8, ep: 1, ... } to dsv4-fp4-b300-vllm.search-space in nvidia-master.yaml to compare TP-only vs EP performance.
2. The runner expands the entry and exports EP_SIZE=1 into the script's environment (this is the standard contract used by every other ATOM/vLLM script in benchmarks/single_node/).
3. The script ignores EP_SIZE — check_env_vars doesn't list it, and the vllm serve command unconditionally has --enable-expert-parallel baked in.
4. vLLM launches with expert parallelism on, producing perf numbers that don't match the search-space's declared ep: 1 configuration. The run is silently mislabeled in the result store.

Convention evidence

Grep over benchmarks/single_node/ shows ~24 sibling vLLM/ATOM scripts that use the conditional pattern (minimaxm2.5_fp8_b300.sh:34, minimaxm2.5_fp8_b200.sh:30, dsr1_fp4_mi355x_atom.sh, dsr1_fp4_mi355x_atom_mtp.sh, dsr1_fp8_mi355x_atom.sh, dsr1_fp8_mi355x_atom_mtp.sh, glm5_fp8_mi355x_atom.sh, glm5.1_fp4_mi355x_atom.sh, gptoss_fp4_mi355x_atom.sh, kimik2.5_fp4_mi355x_atom.sh, qwen3.5_fp8_mi355x_atom.sh, qwen3.5_fp8_mi355x_atom_mtp.sh, etc.). dsv4_fp4_b300.sh is the lone outlier.

Fix

1. Add EP_SIZE to the check_env_vars call (lines 8-16).
2. Above the vllm serve block, insert:

   if [ "$EP_SIZE" -gt 1 ]; then
     EP=" --enable-expert-parallel"
   else
     EP=" "
   fi

3. Replace the hardcoded --enable-expert-parallel \ line with $EP \ (matching the pattern in the sibling scripts).

Severity rationale

The project's own review rule classifies this as WARNING (not blocking), and runtime behavior is unaffected today because the YAML always emits ep: 8. It's a convention/robustness issue rather than a current functional bug — filing as nit.

[functionstackx]

supersecded by @Ankur-singh https://github.com/SemiAnalysisAI/InferenceX/pull/1144/changes

#1144