Add dsv4f-fp8-b200-vllm: DeepSeek-V4-Flash-0731 FP8 B200 vLLM single-node recipe

[stewtong]

Adds dsv4f-fp8-b200-vllm: the first DeepSeek-V4-Flash config key on B200. The repo covers DeepSeek-V4-Pro on B200 (dsv4-fp4-b200-vllm and siblings) but ships no Flash key on any hardware, and no public Flash recipe on 8x B200 exists anywhere I can find; every published Flash serving configuration is 4 GPUs.

The recipe is the one I validated on an 8x B200 SXM6 node and reported upstream:

• vllm-project/vllm#51454: the full Flash context ladder on 8x B200 (4K through 1M), including a 1M input served in the 65s TTFT class, plus the TP8 vs DP8 result: DP8 holds 7.7x more KV capacity and wins 1M at concurrency.
• Same-node TP8 vs DP8 follow-up comment on #51454: both configurations back to back on one node, closing the cross-node caveat in the report. DP8 advantage at 1M c=8: 3.44x on TTFT p50, 3.2x on makespan and on aggregate input throughput. Honest range across metrics and runs: 3.2-3.7x.
• vllm-project/recipes#762: the proposal to make DP8 the recommended B200 strategy for Flash, on the strength of this data.

What's here

File	Change
benchmarks/single_node/fixed_seq_len/dsv4f_fp8_b200_vllm.sh	New. The validated serve recipe, modeled on dsv4_fp4_b200_vllm.sh.
configs/nvidia-master.yaml	New config key with two search-space entries.
configs/runners.yaml	New cluster:b200-nb label (b200-nb_0, b200-nb_1).
MODELS.md / MODELS_zh.md	New model row, prefix dsv4f.
perf-changelog.yaml	New entry (pr-link carries the XXX placeholder until this PR has a number).

Recipe

• Image vllm/vllm-openai:v0.25.0, digest sha256:e1c1ff1af9a15921bfa11d1d95047258c1797392cdbfa296e7639da446b23f97, vLLM build dd10e03f95f94edbea1975c67ace3a35ec9a8a40.
• Model deepseek-ai/DeepSeek-V4-Flash-0731, snapshot 7872f01b1d1fe23eabc4c98b48bffcef5a386062, pinned in the script as MODEL_REVISION (passed to hf download and --revision when MODEL is a bare HF id; inert when a launcher hands a pre-staged path).
• Flags: --kv-cache-dtype fp8 --block-size 256 --moe-backend deep_gemm_mega_moe --attention_config.use_fp4_indexer_cache=True, the deepseek_v4 tokenizer / tool-call / reasoning parsers, --max-num-batched-tokens 8192, --max-num-seqs 256, --gpu-memory-utilization 0.95.
• Prefix caching stays at the engine default (enabled). The report shows it intact on Flash, with a 22x warm-TTFT speedup on a re-sent 1M document, and the random-id benchmark has no shared prefixes either way.

Two arms, one key

Both arms run expert parallel because vLLM v0.25.0's MegaMoE backend refuses engine init without it (NotImplementedError before weight load, reproduced twice on purpose in the supporting runs). Following the shape of dsv4-fp4-b200-vllm, TP and DP are search-space entries in one key, not two keys:

- { tp: 8, ep: 8, conc-start: 1, conc-end: 64 }
- { tp: 8, ep: 8, dp-attn: true, conc-start: 64, conc-end: 256 }

TP8 is the single-stream and latency arm: at 1M the TP8 vs DP8 break-even is c=3, and TP8 carries c=1 to c=2. DP8 (attention DP + EP8, eight TP1 replicas) is the concurrency and long-context arm, capped at conc 256 by --max-num-seqs.

Runner label

cluster:b200-nb points at the two Nebius B200 nodes already registered under the broad b200 label. A new model prefix needs this: the broad label also schedules b200-dgxc nodes, whose launcher hard-fails on an unknown prefix, and every search-space point should land on the same fleet anyway. The b200-nb launcher is prefix-agnostic (HF-hub cache mount plus in-script download guard), so no launcher change is required.

Validation

• bash -n clean on the new script; all three YAML files parse.
• generate_sweep_configs.py full-sweep on the whole master config and test-config --config-keys dsv4f-fp8-b200-vllm both pass; the key generates exactly 11 jobs (TP8 conc 1-64, DP8 conc 64-256) on cluster:b200-nb.
• pytest utils/matrix_logic/ 224 passed; the full changelog-gate pytest set 171 passed.
• utils/validate_perf_changelog.py --base-ref origin/main --head-ref HEAD: clean; new entry at file tail, additions-only diff.

Sweep results to follow.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.