Skip to content

[NVIDIA][AgentX] Retune GB300 DSV4.1-Flash Dynamo + SGLang HiCache disagg points on the 20261030 nightly / [NVIDIA][AgentX] 在 20261030 nightly 上重新调整 GB300 DSV4.1-Flash Dynamo + SGLang HiCache 分离式点位 - #4673

Open
weireweire wants to merge 9 commits into
mainfrom
weireweire/dsv41flash-gb300-sgl-disagg-pareto

Conversation

@weireweire

@weireweire weireweire commented Oct 30, 2026 •

Copy link
Copy Markdown
Collaborator

Move the GB300 DeepSeek-V4.1-Flash Dynamo + SGLang agg and prefill-HiCache disagg keys to digest-pinned lmsysorg/sglang:nightly-dev-cu13-20261030-302b78cc (SGLang 0.0.0.dev1+g52604e1d4, Dynamo 1.7.0.dev20261029), and keep one point per interactivity range.

Based on main after #4595 and #4679. The commits change disagg-dep16-hicache-variants.yaml, agg-variants.yaml, the two keys' search spaces and image pins, and add one changelog entry that lists both keys, so the whole Dynamo + SGLang curve comes from this PR's sweep.

Point Prefill Concurrency Decode CUDA graph max BS (per rank) Decode max-running-requests Decode DP balancing Change
agg TP4 c1 / c4 / c16 — 1 / 4 / 16 — — — unchanged
disagg 3 × DEP2 1228 24 384 total_tokens kept (from #4679)
disagg 5 × DEP2 2884 40 640 total_tokens kept
disagg 6 × DEP2 4370 64 1024 total_tokens new, replaces 8 × DEP2 c4096
disagg 7 × DEP2 5540 96 1536 total_tokens new
disagg 9 × DEP2 7480 192 3072 total_requests new, replaces 9 × DEP2 BS 160 c7480

Disagg decode is always one DEP16 worker. Removed: agg TP2/EP2 c16 (from #4679), 8 × DEP2 c4096 and 9 × DEP2 BS 160 c7480.

Why these points:

  • Prefill stays saturated at every point. Concurrency is sized so prefill always has queued work; the decode batch is whatever the prefill rate supports (Little's law: running requests = request rate × decode time per request).
  • Binding decode cap (c4370, c5540). The decode CUDA graph cap sits at the per-rank equilibrium batch. Throughput is the same as with a high cap, because prefill sets the request rate; the extra requests wait for admission instead of widening every decode step.
  • Free decode cap (c7480). At 9 prefill workers, cap 192 with total_requests balancing lets decode take every request prefill delivers. total_requests keeps the per-rank running counts within 2-7 of each other (11-26 with total_tokens); the step is paced by the busiest rank.

Removed published points (rule 18(g), mean interactivity and throughput per GPU; agg TP4 c16, 3 × DEP2 c1228 and the removed points as published, the other kept points from our 3600 s runs below):

Removed point Published Covered by Line value at the removed point's mean interactivity
agg TP2/EP2 c16 57,670 @ mean 377.4 agg TP4 c16 (29,428 @ 545.0) to 3 × DEP2 c1228 (383,313 @ 267.4) about 243,000
8 × DEP2 c4096 803,198 @ 191.4 5 × DEP2 c2884 (717,972 @ 221.9) to 6 × DEP2 c4370 (929,567 @ 183.2) about 884,700
9 × DEP2 BS 160 c7480 1,094,347 @ 111.1 7 × DEP2 c5540 (1,033,494 @ 150.7) to 9 × DEP2 BS 192 c7480 (1,117,063 @ 101.6) about 1,100,900

Throughput gain at the same p90 interactivity (tok/s/GPU). Our points were measured on our GB300 cluster on 302b78cc with the bound recipes of this PR and the AgentX client, not in this PR's sweep. The vLLM column linearly interpolates the currently published GB300 DeepSeek-V4.1-Flash Dynamo + vLLM and vLLM points on their Pareto frontier at our p90 interactivity. A blank cell means no gain.

This recipe Run Throughput p90 interactivity E2E-normalized p90 vs vLLM
5 × DEP2, BS 40, c2884 3600 s 717,972 233.2 50.0
6 × DEP2, BS 64, c4370 3600 s 929,567 193.3 27.7
7 × DEP2, BS 96, c5540 3600 s 1,033,494 157.5 23.5 +5.0 %
9 × DEP2, BS 192, c7480 3600 s 1,117,063 97.4 24.5 +11.1 %

At p90 97.4, the vLLM frontier lies between 1,011,514 @ 75.5 and 993,521 @ 145.6, which gives 1,005,893. At p90 157.5 it lies between 993,521 @ 145.6 and 954,146 @ 196.5, which gives 984,316.

The 3 × DEP2 c1228 point keeps #4679's settings; on 302b78cc a 1200 s run gave about 371,000 tok/s/GPU after the 1200 s → 3600 s factor, at p90 interactivity 281.2 and E2E-normalized p90 91.1, matching the published 383,313 @ 283.3 within the fast-run projection.

Validation details

All runs used nightly-dev-cu13-20261030-302b78cc through srt-slurm on GB300 with the AgentX client (reasoning_effort high, temperature 1) and the golden acceptance length 3.51. Each run's resolved recipe matches the recipe that infx generate binds for this PR, apart from cluster NIC names, scheduler directives and local image/model packaging of the same digest.

中文

将 GB300 DeepSeek-V4.1-Flash Dynamo + SGLang 的 agg 与 prefill-HiCache 分离式 key 换到固定 digest 的 nightly-dev-cu13-20261030-302b78cc(SGLang 0.0.0.dev1+g52604e1d4、Dynamo 1.7.0.dev20261029),每个交互性区间只保留一个点。

基于 #4595 与 #4679 合入后的 main。 本 PR 新增一条同时列出两个 key 的 changelog,让整条 Dynamo + SGLang 曲线都来自本 PR 的 sweep。

  • 保留的点: agg TP4 c1 / c4 / c16(不变);分离式 3 × DEP2 c1228(来自 [NVIDIA][AgentX] Append GB300 DSV4.1-Flash Dynamo + SGLang TP2/EP2 c16 and 3P1D c1228 points (append-only, follows #4595) / [NVIDIA][AgentX] 追加 GB300 DSV4.1-Flash Dynamo + SGLang TP2/EP2 c16 和 3P1D c1228 点(仅追加,接续 #4595) #4679)、5 × DEP2 c2884、6 × DEP2 c4370(BS 64)、7 × DEP2 c5540(BS 96)、9 × DEP2 c7480(BS 192、max-running-requests 3072、total_requests DP 均衡)。decode 都是一个 DEP16 worker。
  • 去掉的点及覆盖关系(按平均交互性与每卡吞吐):
    • agg TP2/EP2 c16(57,670 @ 377.4):在 agg TP4 c16 与 3 × DEP2 c1228 的连线下方(约 243,000)。
    • 8 × DEP2 c4096(803,198 @ 191.4):在 5 × DEP2 c2884 与 6 × DEP2 c4370 的连线下方(约 884,700)。
    • 9 × DEP2 BS 160 c7480(1,094,347 @ 111.1):在 7 × DEP2 c5540 与 9 × DEP2 BS 192 的连线下方(约 1,100,900)。
  • 原则: 每个点都让 prefill 跑满,decode 的 batch 由 prefill 速率决定(Little 定律)。BS 64/96 的上限等于每 rank 的平衡 batch,多出来的请求在准入处等待;BS 192 让 decode 接收 prefill 送来的全部请求。
  • 同交互性下相对 vLLM(302b,3600 s): 9 × DEP2 BS 192 为 1,117,063 @ 97.4(+11.1%);7 × DEP2 BS 96 为 1,033,494 @ 157.5(+5.0%);6 × DEP2 与 5 × DEP2 低于 vLLM。
AI model disclosure
  • Claude Opus 5.5 (runtime identifier aws/anthropic/eccn-claude-opus-5-5) planned the point set from the P/D rate analysis, ran the cluster experiments through delegated agents on the same model, wrote the recipe overrides, master config, changelog entry and this description, and ran independent reviews of the diff through separate delegated agents on the same model.

@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution!

  • Review: If this PR changes files owned by someone other than a repository admin or @SemiAnalysisAI/core, ask one eligible CODEOWNER to complete the latest PR_REVIEW_CHECKLIST.md before contacting a core maintainer on Slack. Follow the template exactly, including As a PR reviewer and CODEOWNER, I have reviewed this and have, so sign-off verification triggers.
  • PR verification: Sweeps run only when the PR appends an inferencex-e2e/perf-changelog.yaml entry and carries exactly one primary label: full-sweep-fail-fast (strongly recommended; canary plus per-matrix fail-fast), full-sweep-enabled (canary; matrix jobs continue after a failure), or non-canary-full-sweep-enabled (no canary or fail-fast). The modifiers all-evals, evals-only, and agentx-fast require a primary label. On fork PRs, a maintainer applies the label. See sweep labels and reuse.
  • After merging: PR authors must ensure all GitHub Actions jobs pass. Transient failures often pass on rerun; see how to rerun failed jobs.
中文

感谢你的贡献!

  • **审阅:**如果 PR 修改的文件归属于仓库管理员及 @SemiAnalysisAI/core 之外的 CODEOWNER,请先联系一位有资格的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,再通过 Slack 联系核心维护者。必须严格遵循模板,并保留 As a PR reviewer and CODEOWNER, I have reviewed this and have,才能触发签核验证。
  • **PR 验证:**只有当 PR 在 inferencex-e2e/perf-changelog.yaml 末尾追加了条目,并且恰好带有一个主标签时,才会运行扫描:full-sweep-fail-fast(强烈推荐;canary 加逐矩阵 fail-fast)、full-sweep-enabled(有 canary;矩阵任务在失败后继续运行)或 non-canary-full-sweep-enabled(无 canary,也无 fail-fast)。修饰标签 all-evals、evals-only 和 agentx-fast 必须与主标签一起使用。fork PR 的标签由维护者添加。参见扫描标签与复用。
  • **合并后:**PR 作者必须确保所有 GitHub Actions 任务通过。临时性失败通常可以通过重新运行恢复;参见重新运行失败任务的说明。

Add 5P bs48 c3615, 6P bs64 c4370 and 7P bs96 c5540 with the decode cap at the
P/D equilibrium batch, and 7P c5800 and 9P c7480 at cap 192 with total_requests
decode balancing. Drop 8P c4096. Each point's bound recipe matches the measured
run's resolved config apart from the unused Mooncake services.
…ys to the 20261030 nightly

nightly-dev-cu13-20261030-302b78cc (index digest d4b7701d) bundles SGLang
52604e1d46, 181 commits after 586355a8, and Dynamo 1.7.0.dev20261029. Recipes
are unchanged; the points are being re-measured on this image before the sweep.
In 3600 s runs on 586355a8, 7P BS 96 c5540 gave 1,031,199 tok/s/GPU at p90
interactivity 155.2 and 7P BS 192 c5800 gave 1,029,432 at 127.1.
@weireweire
weireweire force-pushed the weireweire/dsv41flash-gb300-sgl-disagg-pareto branch from 8542d92 to b8510e8 Compare November 2, 2026 02:39
@weireweire weireweire changed the title [NVIDIA][AgentX] Retune GB300 DSV4.1-Flash Dynamo + SGLang HiCache disagg points (stacked on #4595) / [NVIDIA][AgentX] 重新调整 GB300 DSV4.1-Flash Dynamo + SGLang HiCache 分离式点位(基于 #4595) [NVIDIA][AgentX] Retune GB300 DSV4.1-Flash Dynamo + SGLang HiCache disagg points on the 20261030 nightly / [NVIDIA][AgentX] 在 20261030 nightly 上重新调整 GB300 DSV4.1-Flash Dynamo + SGLang HiCache 分离式点位 Nov 2, 2026
…t covers

Root cause: #4679 added agg TP2/EP2 c16 back to fill the interactivity gap
between agg TP4 c16 and disagg 5P c2884, at ~58k tok/s/GPU.

Fix: add 3 x DEP2 prefill + DEP16 decode at c1024 (decode CUDA graph batch
20, max-running-requests 320, extra slots 30) and remove override_tp2_c16 and
its search-space entry.

Validation: 302b78cc fast run with this recipe: ~320k tok/s/GPU projected full
at conv p90 288-294 (agg TP2/EP2 c16 published: 57,670 @ 292.4) and
E2E-normalized p90 107.9 vs 91.4.
…-gb300-sgl-disagg-pareto

# Conflicts:
#	inferencex-e2e/perf-changelog.yaml
…tivity range

Root cause: the disagg key carried neighbouring points that add little to the
curve (5P c3615 next to 5P c2884, 9P batch 160 next to 9P batch 192, and the
new 3P c1024 next to 3P c1228).

Fix: drop override_5p1d_dep2_dep16_b48_c3615, override_9p1d_dep2_dep16_b160_c7480
and override_3p1d_dep2_dep16_b20_c1024 with their search-space entries, and
rewrite this PR's changelog entry for the final point set.

Validation: rule 18(g) on mean interactivity and tput per GPU with the 302b
3600 s fulls: published 9P batch 160 lies under the 7P c5540 - 9P batch 192
line (+0.6%), agg TP2/EP2 c16 under the agg TP4 c16 - 3P c1228 line, and
8P c4096 under the 5P - 6P line; 5P bs48 cost 0.6% of curve at mean 199.7.
@weireweire weireweire added the full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures label Nov 2, 2026
…-gb300-sgl-disagg-pareto

# Conflicts:
#	inferencex-e2e/perf-changelog.yaml
@weireweire
weireweire marked this pull request as ready for review November 2, 2026 09:44
@weireweire
weireweire requested a review from a team November 2, 2026 09:44
@claude

claude Bot commented Nov 2, 2026 •

Copy link
Copy Markdown
Contributor

Claude finished @weireweire's task in 32s —— View job


Review

  • Read the diff (recipes, master config, changelog)
  • Checked the changelog position, image accessibility, recipe/master consistency and references to removed overrides

LGTM - no blocking issues found

What I checked
  • Changelog: the new entry is appended at the end of inferencex-e2e/perf-changelog.yaml, covers both changed keys and is not append-only.
  • Images: both keys use the public, digest-pinned lmsysorg/sglang:nightly-dev-cu13-20261030-302b78cc@sha256:d4b7…. The router versions and the recipe identity.frameworks both say Dynamo 1.7.0.dev20261029 / SGLang g52604e1d4.
  • Prefill sizing in the recipes: 6×DEP2 on 3 nodes, 7×DEP2 on 4 nodes, and 9×DEP2 on the base nodes: 5. Each fits in 4 GPUs per node.
  • Recipe vs master: the num-worker values and srt-recipe override names in nvidia-master.yaml match the recipe overrides.
  • Removed overrides: override_tp2_c16, override_8p1d_dep2_dep16_c4096 and override_9p1d_dep2_dep16_b160_c7480 are no longer referenced by any config. The remaining matches are in other recipe files or in historical changelog text.
  • Not run: infx.matrix.changed needed a permission I didn't have. The changelog entry is present, so this does not affect the review.

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reviewed this PR and found no bugs. nvidia-master.yaml and the gb300 srt-slurm recipes have designated CODEOWNERS, so one of them should still look over the retuned points.

What was reviewed:

  • Every srt-recipe reference in the two master-config keys points to an override that exists. Prefill num-worker (6/7/9) matches the recipe workers, and the node counts (3/4/inherited 5) have room for those DEP2 workers.
  • The removed overrides (override_tp2_c16, override_8p1d_dep2_dep16_c4096, b160_c7480) are no longer referenced anywhere. Image digests, the dynamo-router version and the recipe identity.frameworks pins agree across both keys.
  • The perf-changelog block is appended only at the end, lists both config keys, and says the base extra-slots of 256 still applies, which matches the recipe.
Extended reasoning...

The change is benchmark config only: two GB300 DSV4.1-Flash Dynamo + SGLang srt-slurm variant recipes, their matching nvidia-master.yaml search-space rows and image/router pins, and one appended perf-changelog entry. It touches no security-sensitive code. The recipe and master config agree, and no dangling override references remain. I deferred instead of approving because .github/CODEOWNERS assigns nvidia-master.yaml and the gb300 srt-slurm recipe paths to specific NVIDIA owners. The tuning choices (decode batch caps, removed points, total_requests balancing) are also performance decisions those owners should confirm.

@github-actions

github-actions Bot commented Nov 2, 2026

Copy link
Copy Markdown
Contributor

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant