Add DSV4 FP4 B200 Dynamo-vLLM point-specific disagg recipes

[RohitNagraj]

Adds point-specific DeepSeek-V4-Pro FP4 B200 Dynamo-vLLM disaggregated recipes for the 8k/1k concurrency points c=1, 32, 64, 128, 256, 512, and wires those rows in nvidia-master.yaml (c=16, 1024, 8192, 12345 are left out of this update).

Recipes use vllm/vllm-openai:v0.23.0, DSV4 revision 0366e4e064385807ea86b088a5c6c878ff23343b, and max-model-len 9280, with per-point P1/D1 (1 prefill node DEP=8 / 1 decode node) serving knobs.

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

Config-only PR — new benchmark recipe YAMLs + nvidia-master wiring; nit flagged inline.

Extended reasoning...

Overview

This PR adds five new point-specific DSV4 FP4 B200 Dynamo-vLLM disagg recipe YAMLs under benchmarks/multi_node/srt-slurm-recipes/vllm/deepseek-v4/8k1k/, rewires the dsv4-fp4-b200-dynamo-vllm search-space in .github/configs/nvidia-master.yaml to point each concurrency (c=1/32/64/128/256/512) at its dedicated recipe, and appends a corresponding entry to perf-changelog.yaml. No source code or CI logic is modified.

Security risks

None — these are benchmark recipe YAMLs and a config-keys changelog entry. No auth, crypto, permission, or input-handling surfaces are touched. The container image (vllm/vllm-openai:v0.23.0), model revision, and SLURM resource shapes are pinned by string, not derived from untrusted input.

Level of scrutiny

Low. These files are consumed by the SLURM-based benchmark sweep, not by production-serving code. Mistakes in serving knobs (max-num-seqs, gpu-memory-utilization, etc.) at worst produce a failed or misconfigured benchmark run that can be rerun — they cannot affect end users or shared infrastructure beyond the cluster allocation footprint per row.

Other factors

The bug hunter flagged one nit inline: etcd_nats_dedicated_node is true in the new c1.yaml while the four sibling recipes added in the same PR all have it false despite identical P1/D1 topology. That is a benign sweep-consistency issue — at worst the c=1 row will reserve one extra SLURM node — and is already attached as an inline comment for the author to consider. The overall PR pattern (split point-specific recipes out of an existing aggregate recipe, update the search-space, log to perf-changelog) is the established convention in this repo, and the changes are mechanically straightforward to verify by reading the diff.

[claude]

🟡 etcd_nats_dedicated_node is true in disagg-b200-low-latency-c1.yaml (line 27) but false in the four sibling recipes added in this same PR (disagg-b200-low-latency-c32-c128.yaml, disagg-b200-low-latency-c64.yaml, disagg-b200-low-middle-c256.yaml, disagg-b200-low-middle-c512.yaml, all at line 27). Since all five share an identical P1/D1 topology, this looks like a copy-paste residue from the source disagg-b200-low-latency.yaml that was missed when narrowing c1 — it causes the c=1 job to reserve 3 SLURM nodes (extra dedicated etcd/NATS) while c=32/64/128/256/512 reserve only 2. Either flip c1 to false (likely intent based on the four siblings) or flip the other four to true, so the sweep is consistent.

Extended reasoning...

What the bug is

All five new recipes added in this PR target the same P1/D1 topology described in the PR body ("per-point P1/D1 (1 prefill node DEP=8 / 1 decode node) serving knobs"). Their resources: blocks are byte-for-byte identical: prefill_nodes: 1, decode_nodes: 1, prefill_workers: 1, decode_workers: 1, gpus_per_prefill: 8, gpus_per_decode: 8. The only divergence in the infra: block is etcd_nats_dedicated_node:

Recipe	Line 27
disagg-b200-low-latency-c1.yaml	etcd_nats_dedicated_node: true
disagg-b200-low-latency-c32-c128.yaml	etcd_nats_dedicated_node: false
disagg-b200-low-latency-c64.yaml	etcd_nats_dedicated_node: false
disagg-b200-low-middle-c256.yaml	etcd_nats_dedicated_node: false
disagg-b200-low-middle-c512.yaml	etcd_nats_dedicated_node: false

How this happens

The pre-existing source recipe disagg-b200-low-latency.yaml (which c1 was clearly derived from — they share the same decode max-num-seqs: 256, max-cudagraph-capture-size: 256, env vars, etc.) had etcd_nats_dedicated_node: true. When the five new point-specific recipes were split out of that source, four of them were flipped to false but c1.yaml was not — looks like a missed edit in the narrowing step.

Why this matters

When etcd_nats_dedicated_node: true, SLURM reserves an additional dedicated node for etcd/NATS on top of the prefill+decode nodes, so the c=1 row of the sweep will request 3 nodes (1 prefill + 1 decode + 1 etcd/NATS) while every other row in the same sweep requests only 2. The benchmark itself will still run, but:

• Resource accounting / queue wait time / cluster allocation are inconsistent across the sweep.
• The PR description characterises the topology uniformly across all six points, so the c=1 outlier is not explained anywhere.

Step-by-step proof

1. Open disagg-b200-low-latency-c1.yaml line 27 → etcd_nats_dedicated_node: true.
2. Open disagg-b200-low-latency-c32-c128.yaml line 27 → etcd_nats_dedicated_node: false.
3. Diff the resources: blocks of the five recipes → identical (P1/D1, 8 GPUs each).
4. Therefore at SLURM submission time:
   • c=1 → 1 prefill + 1 decode + 1 dedicated etcd/NATS = 3 nodes
   • c=32/64/128/256/512 → 1 prefill + 1 decode (etcd/NATS co-located) = 2 nodes
5. There is no per-point reason (concurrency=1 has the lightest load of any point in the sweep) for c=1 to need a dedicated etcd/NATS node when c=512 does not.

Suggested fix

Most likely intent — given that 4 of 5 siblings already say false — is to flip c1 to false:

# benchmarks/multi_node/srt-slurm-recipes/vllm/deepseek-v4/8k1k/disagg-b200-low-latency-c1.yaml:27
-  etcd_nats_dedicated_node: true
+  etcd_nats_dedicated_node: false

If the c=1 setting was actually deliberate (e.g. you want a dedicated coordinator node for the lowest-concurrency point), then the other four should be flipped to true instead and a comment added explaining why. Either direction is fine — the five recipes in this single-PR sweep should just agree.

[github-actions]

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

[Ankur-singh]

/reuse-sweep-run

[Ankur-singh]

As a PR reviewer and CODEOWNER, I have reviewed this and have:

• Verified that as of the moment of typing this, this is the latest version of PR_REVIEW_CHECKLIST.md
• Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
• Verified that this PR has passed PR validation. Please link to GitHub Action workflow that shows this. Link
• Verified that this PR passes evals. Please link to GitHub Action workflow that shows this. Link
• Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
• If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
• Verified that the single-node recipes are similar to the official vLLM recipes and/or theSGLang cookbook:
  • If they are not, I have verified that a PR has been opened in vLLM recipe repo or SGLang repo and linked it below in the additional detail section:
• If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.

Additional detail section:

• This is a Dis-agg submission, no recipe updated required.

Signed: ankur-singh

[Klaud-Cold]

@Ankur-singh NOT ready to merge: the sign-off's Additional detail section contains no recipe link (Check 3 fails). Everything else is green.

• Check 0 (CODEOWNER): PASS — @ankur-singh is a named owner of .github/configs/nvidia-master.yaml; the benchmarks/** and perf-changelog.yaml paths fall under the * @InferenceX/core catch-all, covered by a listed CODEOWNER.
• Check 1 (sweep+evals on an in-PR commit): PASS — head da84b2e (in the PR) has green, executed multi-node 8k1k / (conc 1/32x128/64/256/512) and multi-node eval / jobs. single-node */ and eval / are skipped because this is a multi-node disagg submission. Run: https://github.com/SemiAnalysisAI/InferenceX/actions/runs/28481566954
• Check 2 (evals real / meet bar): PASS — gsm8k em_strict 0.952/0.965/0.965/0.970 at conc 256/128/512/64 (n_eff=1319), on image vllm/vllm-openai:v0.23.0 matching this PR's config.
• Check 3 (recipe linked AND complete): FAIL — the Additional detail section only states "This is a Dis-agg submission, no recipe update required" with no link to a vLLM recipe / SGLang cookbook PR or published recipe page. A bare no-update claim does not satisfy the link requirement. Server args themselves are internally consistent (DSV4-Pro FP4 B200, P: TP1/DP8/EP, D per-point, kv-cache fp8, NixlConnector) — the only gap is the missing recipe link.
• Check 4 (/reuse-sweep-run posted): PASS — posted by Ankur-singh (COLLABORATOR).

Fix to unblock: add a link to the corresponding recipe (vllm-project/recipes or sglang cookbook PR, or the published recipe page) in the sign-off's Additional detail section.

[RohitNagraj]

/reuse-sweep-run