[NV] update B300 disagg recipes#1891
Conversation
# Conflicts: # perf-changelog.yaml
# Conflicts: # .github/configs/nvidia-master.yaml
|
Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook 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 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 保持一致 如果不一致,请先创建一个 PR,之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准,使整个 ML 社区都能从你的辛勤工作中受益!谢谢 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 联系核心维护者。 |
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=27999202538 |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 376f261. Configure here.
| type: "sa-bench" | ||
| isl: 8192 | ||
| osl: 1024 | ||
| concurrencies: "4096" |
There was a problem hiding this comment.
Decode seq cap below concurrency
Medium Severity
The sa-bench concurrency is 4096 while decode max-num-seqs is 1024 with two decode workers. That pairing cannot honor 4096 simultaneous decode slots per worker semantics, so the 4096 sweep point may queue, fail, or report throughput that does not reflect the intended load.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 376f261. Configure here.
| cp -rT "$GITHUB_WORKSPACE/benchmarks/multi_node/srt-slurm-recipes/vllm/minimax-m3" recipes/vllm/minimax-m3 | ||
| SRTCTL_SETUP_SCRIPT="minimax-m3-vllm-fixes.sh" | ||
| # NVIDIA/srt-slurm#38 | ||
| git show 22d46ba9971615016d2339c9ffbc7b4597accfad --format= -- src/srtctl/core/ip_utils/get_node_ip.sh | git apply - || exit 1 |
There was a problem hiding this comment.
Patch apply aborts launcher
Medium Severity
The MiniMax-M3 path runs git apply for the node-IP fix with || exit 1, so if sa-submission-q2-2026 already contains that patch, checkout/setup fails and no B300 MiniMax-M3 job is submitted.
Reviewed by Cursor Bugbot for commit 376f261. Configure here.
…-1887-same-repo-sweep # Conflicts: # .github/configs/nvidia-master.yaml # benchmarks/multi_node/srt-slurm-recipes/vllm/minimax-m3/b300-fp8/8k1k/1p1d-dep2-tp4-marlin-8k1k.yaml # benchmarks/multi_node/srt-slurm-recipes/vllm/minimax-m3/b300-fp8/8k1k/2p2d-dep2-dep8-8k1k.yaml # benchmarks/multi_node/srt-slurm-recipes/vllm/minimax-m3/b300-fp8/8k1k/2p2d-dep2-tep8-8k1k.yaml # benchmarks/multi_node/srt-slurm-recipes/vllm/minimax-m3/b300-fp8/8k1k/4p2d-dep2-dep8-8k1k.yaml
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28028985088 |
1 similar comment
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28028985088 |
|
As a PR reviewer and CODEOWNER, I have reviewed this and have:
Additional detail section:This is a dis-agg config, no recipe PR required. Signed: |
|
@Ankur-singh BLOCKED — Check 3 (recipe) fails: the sign-off's Additional detail section contains no recipe link. This gate requires a public recipe link (vllm-project/recipes or sglang cookbook); "dis-agg config, no recipe PR required" is a bare claim without a link and does not satisfy the standard.
|
|
/reuse-sweep-run 28028985088 |


Copy of #1887 from
biswapanda:pr-1787-latest--updateatd08cc43b7e943a7a53c67194448d4309f338cbc4.The original fork PR triggered
run-sweep.yml, but all downstream benchmark jobs failed before checkout because fork PRs do not receive inherited repository secrets such asREPO_PAT. This same-repo copy is intended to run the sweep with the same diff againstmain.Original PR: #1887
Note
Low Risk
Benchmark and CI YAML only; no runtime application or auth/data-path changes.
Overview
Refreshes the MiniMax-M3 MXFP8 B300 Dynamo-vLLM disaggregated benchmark sweep for 8k1k (and related search-space wiring in
nvidia-master.yaml): concurrency lists, prefill/decode worker counts, and which Slurm recipe YAML each point uses.Several new
8k1krecipes are added for TEP4 (and related) topologies—e.g.1p2d-dep2-tep4,1p4d-dep2-tep4,1p4d-dep2-tep8,4p2d-dep2-tep4—while some older combinations (e.g. conc 128-only, 3p/5p prefill, duplicate 4096 entries) are dropped or remapped. Existing recipes in that folder gain FLASHINFER + TRTLLM attention andkv-cache-dtype: fp8on prefill and decode to align with the updated sweep.perf-changelog.yamldocuments theminimaxm3-fp8-b300-dynamo-vllmconfig change (imageminimax-m3-0618-x86_64-cu130, TEP4/TEP8 8k1k coverage).Reviewed by Cursor Bugbot for commit 6b9fe1e. Bugbot is set up for automated code reviews on this repo. Configure here.