Skip to content

[K3.1-Pro] Day-0 support SGLang on GB200 - #4804

Merged
cquil11 merged 15 commits into
mainfrom
cam/kimik3.1-gb200-sglang
Nov 5, 2026
Merged

cquil11 merged 15 commits into
mainfrom
cam/kimik3.1-gb200-sglang

Conversation

@cquil11

@cquil11 cquil11 commented Nov 4, 2026 •

Copy link
Copy Markdown
Collaborator

Adds Kimi K3.1 Pro day-0 SGLang AgentX points on GB200 NVL72 (cluster:gb200-nv, dynamo-sglang). They cover the same concurrencies and CPU KV offloading that Kimi K3 has on InferenceX for GB200. Speculation uses the RadixArk DFLASH draft with block verification.

Untested shape: the SGLang cookbook marks its GB200 command (TP16 · DCP16, which this PR uses) as an untested placeholder. No K3.1 recipe has run on GB200 yet.

Config key Topology (16 GPUs = 4 trays per server) Concurrency DFLASH drafts (verify width) KV offload
kimik3.1-fp4-gb200-dynamo-sglang-agentic-dflash-agg agg TP16 · DCP16 1, 4, 8 7 (8) HiCache, 120 GB/rank
24, 32, 48, 56 5 (6) HiCache, 120 GB/rank
kimik3.1-fp4-gb200-dynamo-sglang-agentic-dflash-disagg 1P1D, prefill TP16 · DCP16 + decode TP16 · DCP16, Mooncake PD transfer 16 7 (8) HiCache on prefill
32, 48 5 (6) HiCache on prefill
  • Image: lmsysorg/sglang:dev-kimi-k31-pro@sha256:67fc77d1… (multi-arch).
  • Frontend: the image's Dynamo 1.6.0 (dynamo.install: false) with the KV router, session affinity and SGLang's chat processor (dyn-chat-processor: sglang), following Po-Han Huang's GB300 Dynamo SGLang recipes ([NVIDIA][AgentX] GB300 Kimi-K3.1-Pro FP4 Dynamo+SGLang: DFLASH disaggregated and aggregated megakernel points / [NVIDIA][AgentX] GB300 Kimi-K3.1-Pro FP4 Dynamo+SGLang:DFLASH 分离式与聚合式 megakernel 配置点 #4811). The image's Dynamo accepts K3.1 DSA decode at DCP16.
  • MoE front: the TP16 roles set SGLANG_K3_SHARDED_MOE=0. SGLang's K3 sharded MoE front has no warp split-K output tile for TP16's N=1048 (k3_ar_fusion.slice_gemm), and workers crashed during CUDA-graph capture. The engine's replicated fused front stays a BF16 GEMM, and K3 all-reduce fusion stays on.
  • Draft: RadixArk/Kimi-K3.1-Dflash2-Preview with --speculative-use-block-verification, FP8 draft KV and cutedsl_mla draft attention. --enable-linear-replayssm-spec is set on the verifying roles only, and both PD roles use the same verification width, as the cookbook's PD cells do.
  • Synthetic acceptance: the srt driver injects the golden AL (SGLANG_SIMULATE_ACC_LEN) on each speculating role. Nothing is hard-coded.
  • Shape: TP16 · DCP16 follows the cookbook's GB200 cell and Kimi K3's GB200 layout. One 8-GPU GB200 set (~1.5 TB HBM) can't hold the ~1.56 TB checkpoint plus KV.
  • Admission: max-running-requests is 2× concurrency.
  • DRAM cap: dram-utilization: 0.54 gives each tray a 487 GB cap, which covers 4 ranks × 120 GB of HiCache.
  • Launch tables: kimik3.1 joins the gb200-nv shared run root, as Kimi K3 did, and the existing GLM-5.2 FP4 dynamo-sglang AgentX power rule.
  • Client: no AIPERF_EXTRA_INPUTS, matching the K3.1 vLLM recipes, so both engines get identical client requests.

K3.1 week-1 precision policy:

  • Native MXFP4 checkpoint with no quantization flags, so linear ops and shared experts stay BF16.
  • KV cache: kv-cache-dtype: fp8_e4m3.
  • KDA cache: mamba-ssm-dtype: float32. Conv cache stays at the native BF16 default.
  • MoE combine and AllReduce/AG/RS stay BF16: no quantized or FP8 communication flags, and SGLang's custom all-reduce is BF16.
  • EPLB is not enabled.
  • MegaMoE and --enable-symm-mem are not used.
  • The draft is served as shipped: FP8 draft KV only matches the FP8 target KV.

Risks:

  • TP16 · DCP16, DFLASH and HiCache haven't been combined on GB200.
  • The GB200 lane's existing install-torchao.sh setup step (an unpinned pip install torchao) also runs here.

@github-actions

github-actions Bot commented Nov 4, 2026

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 任务通过。临时性失败通常可以通过重新运行恢复;参见重新运行失败任务的说明。

@github-actions

github-actions Bot commented Nov 4, 2026 •

Copy link
Copy Markdown
Contributor

inferencex-e2e/infx diff: +1 -1

Generally most InferenceX submissions don't need to add changes to the infx package. On the off chance they do, generally the diff is small. Please prompt your agent to clean your PR to keep your diff to only necessary & minimal changes too. We have an increased code quality bar for changes to the infx package.

中文

大多数 InferenceX 提交通常不需要修改 infx 包。即使确实需要,改动通常也很小。请让你的 agent 清理 PR,使改动只包含必要且最小的内容。infx 包的改动有更高的代码质量要求。

Comment thread inferencex-e2e/perf-changelog.yaml Outdated
- kimik3.1-fp4-gb200-dynamo-sglang-agentic-dflash-disagg
description:
- "Add Kimi K3.1 Pro day-0 SGLang AgentX points on GB200: aggregated TP16 DCP16 and 1P1D TP16 DCP16, with RadixArk DFLASH block verification and HiCache CPU offload."
pr-link: TBD

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.

🔴 The changelog CI check will reject this PR because the new block's pr-link is TBD. The validator only accepts the canonical PR URL or an XXX placeholder. validate_added_pr_link (infx/workflows/validate_perf_changelog.py:113) raises "new PR entry must use ... or an XXX placeholder". The merge preparer also refuses TBD at prepare_perf_changelog_merge.py:108. Fix: set pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/XXX or use the real PR number, so the merge step can rewrite it.

Why this was flagged

The new block at perf-changelog.yaml:12021 has pr-link: TBD. On a PR run, validate_perf_changelog.py:113 checks every appended entry: link not in PR_LINK_PLACEHOLDERS and link != expected raises ChangelogValidationError. PR_LINK_PLACEHOLDERS (line 21) contains only "XXX" and "https://github.com/SemiAnalysisAI/InferenceX/pull/XXX". On main, CANONICAL_PR_LINK.fullmatch fails for TBD. prepare_perf_changelog_merge.py:108-111 raises "appended entry N has unexpected pr-link 'TBD'", so the automatic link rewrite also fails. No other changelog entry in the file uses TBD, so this PR's changelog validation fails and merge preparation is blocked.

Verification: The diff appends a block that ends with pr-link: TBD (perf-changelog.yaml, new tail block). PR_LINK_PLACEHOLDERS (line 21) holds only "XXX" and "https://github.com/SemiAnalysisAI/InferenceX/pull/XXX". As a result, the check-changelog gate fails and the sweep for the new config keys does not run until the link is changed to XXX or to the real PR URL.

dyn-reasoning-parser: kimi_k3
dyn-tool-call-parser: kimi_k3
speculative-algorithm: DFLASH
speculative-draft-model-path: RadixArk/Kimi-K3.1-Dflash2-Preview

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.

🔴 Kimi K3.1 GB200 worker startups can fail with Hub 429 errors, because every rank fetches the DFLASH draft from Hugging Face at launch. The roles name RadixArk/Kimi-K3.1-Dflash2-Preview but set neither HF_HUB_OFFLINE nor HF_HUB_CACHE. Muse Spark DFlash2 recipes added both after concurrent launches hit the Hub 429 limit. Fix: give every speculating role HF_HUB_OFFLINE: '1' and HF_HUB_CACHE: /hf_hub_cache, and seed the draft in gb200-nv's shared hf-hub-cache; this covers the 3 sites listed. Same pattern at 3 sites (agg-variants.yaml:68, disagg-variants.yaml:75, disagg-variants.yaml:128).

Why this was flagged

The trigger is a sweep that launches several of the 10 new points at once (7 agg and 3 disagg), or gb200-nv compute nodes with no Hub access. With no HF_HUB_OFFLINE, every rank resolves speculative-draft-model-path: RadixArk/Kimi-K3.1-Dflash2-Preview (agg-variants.yaml:68, disagg-variants.yaml:75 and :128) through Hub API calls. The role env blocks set no HF_HUB_CACHE. As a result the draft downloads into each container's default cache, not the shared /hf_hub_cache mount that gb200-nv's agentic-volume-mounts provides (runners.yaml:623-625). The launcher passes HF_HUB_CACHE only to the benchmark client (config.py:236-252). perf-changelog.yaml:10160-10205 records that the Muse Spark DFlash2 points needed HF_HUB_OFFLINE=1 because concurrent launches otherwise hit the Hub 429 API rate limit. Neither safeguard applies to these new recipes, so a rate-limited or offline rank fails worker startup and the point produces no result.

Verification: Every speculating role names a Hub repo id as its draft: speculative-draft-model-path: RadixArk/Kimi-K3.1-Dflash2-Preview (agg-variants.yaml:68, disagg-variants.yaml:75 and :128). None of the role env blocks sets HF_HUB_OFFLINE or HF_HUB_CACHE, and neither file has a base environment: block. The srt driver does not add them for workers either.

@cquil11
cquil11 force-pushed the cam/kimik3.1-gb200-sglang branch 3 times, most recently from 3b0bf0e to 5ff93c4 Compare November 4, 2026 23:05
Aggregated TP16 DCP16 and 1P1D TP16 DCP16 dynamo-sglang points on gb200-nv
with RadixArk DFLASH block verification, HiCache CPU offload and Mooncake
PD transfer, at Kimi K3's GB200 concurrencies.
Remove the DCP comm backend and the custom all-reduce and DCP push-combine env vars, which the SGLang cookbook's GB200 command does not use.
@cquil11
cquil11 force-pushed the cam/kimik3.1-gb200-sglang branch from 5ff93c4 to 3f7acfd Compare November 4, 2026 23:11
@cquil11 cquil11 added the non-canary-full-sweep-enabled Run the full sweep without the canary gate (full search space, no trim) label Nov 4, 2026
The SGLang image ships no Dynamo, and published Dynamo wheels cannot load the kimi_k31 tokenizer or accept DCP decode for K3.1's DSA layers. Install ai-dynamo/dynamo#18124, which fixes both, and record it as the router version.
…lang

# Conflicts:
#	inferencex-e2e/perf-changelog.yaml
@github-actions

github-actions Bot commented Nov 5, 2026 •

Copy link
Copy Markdown
Contributor

No Dynamo revision both builds and loads the kimi_k31 tokenizer, so the workers run
sglang.launch_server behind the image's sglang-router 0.3.2. The configs become plain
sglang (keys drop dynamo-), the Dynamo services and router args go, the reasoning and
tool-call parsers move to SGLang's own flags, and the gb200-nv AgentX power rule accepts
sglang. Engine args, topology, offload and forced acceptance are unchanged.
At TP16 the K3 sharded MoE front builds an N=1048 slice GEMM that the warp
split-K kernel has no output tile for, so every worker capturing graphs above
17 tokens crashed. SGLANG_K3_SHARDED_MOE=0 selects the engine's replicated
fused front; the front stays BF16 and K3 all-reduce fusion stays on.
The K3.1 SGLang image ships Dynamo 1.6.0, whose SGLang argument check lets
Kimi-K3.1 decode with DCP on its DSA backend. Following Po-Han Huang's GB300
recipes, the frontend runs the KV router with SGLang's chat processor, which
renders kimi_k31 requests the frontend tokenizer cannot load; the aggregated
and prefill workers publish KV events and advertise session affinity. The
configs return to dynamo-sglang with the image's dynamo-router 1.6.0. Engine
args, topology, offload and forced acceptance are unchanged.
The workers had no HF_HUB_CACHE, so every node downloaded the DFlash2 draft
into its container on each start. Load times varied from seconds to minutes,
and agg c1 and c24 failed when one node finished more than SGLang's 480 s
post-load barrier after the others. Point the workers at the mounted shared
cache, as Po-Han's GB300 recipes and other GB300 SGLang recipes on main do.
…lang

# Conflicts:
#	inferencex-e2e/perf-changelog.yaml
@cquil11

cquil11 commented Nov 5, 2026

Copy link
Copy Markdown
Collaborator Author

/use 41990398212

@github-actions

github-actions Bot commented Nov 5, 2026 •

Copy link
Copy Markdown
Contributor

@cquil11 staged run 41990398212.

This run remains available across future /stage-results requests. Staging the same run ID again updates its staged data. Staging workflow

@cquil11

cquil11 commented Nov 5, 2026

Copy link
Copy Markdown
Collaborator Author

/reuse-sweep-run 41990398212

@cquil11

cquil11 commented Nov 5, 2026

Copy link
Copy Markdown
Collaborator Author

/reuse-sweep-run 41990398212

@cquil11
cquil11 merged commit 146a0b6 into main Nov 5, 2026
25 checks passed
@cquil11
cquil11 deleted the cam/kimik3.1-gb200-sglang branch November 5, 2026 16:26
@github-actions

github-actions Bot commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

Ingest report — ✅ Results ingested into the production database.

Ingest workflow · Merge Ingest run · Benchmark source run

Category new duplicate skipped unmapped failed
benchmark 10 0 0 0 0
eval 7 7 0 0 0
trace 10 0 0 0 0
power 52 0 0 0 0

benchmarkFiles 10, rawBenchmarkRows 10, coveredByPerJobFiles 0, purgedPoints 0, failedRunRows 0, runStatsNew 0, runStatsDuplicate 0, evalSamplesNew 9233, gpuMetricSamplesNew 1142864, powerPublicationPoints 10, changelogEntriesWritten 1

Counts cover only this run. Rows: benchmark_results, eval_results, agentic rows linked to a trace, gpu_metrics series. This comment updates if the ingest is rerun.

中文

Ingest 报告 — ✅ 结果已写入 production 数据库。

上表仅统计本次运行写入的数据,各行单位依次为 benchmark_results 行、eval_results 行、已关联 trace 的 agentic 行和 gpu_metrics 序列。重新运行 ingest 时本评论会原地更新。

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

Labels

non-canary-full-sweep-enabled Run the full sweep without the canary gate (full search space, no trim)

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant