Skip to content

Refresh GB200 Qwen3.5 AgentX Pareto / 刷新 GB200 Qwen3.5 AgentX Pareto 配置 - #2660

Merged
functionstackx merged 3 commits into
mainfrom
qwen3.5-fp4-gb200-dynamo-sglang-agentic-mtp-pareto-refresh
Aug 19, 2026
Merged

Refresh GB200 Qwen3.5 AgentX Pareto / 刷新 GB200 Qwen3.5 AgentX Pareto 配置#2660
functionstackx merged 3 commits into
mainfrom
qwen3.5-fp4-gb200-dynamo-sglang-agentic-mtp-pareto-refresh

Conversation

@Ankur-singh

Copy link
Copy Markdown
Collaborator

Description

Refresh the GB200 Qwen3.5 NVFP4-V2 AgentX configuration on lmsysorg/sglang:nightly-dev-20260818-c0b6474b.

  • Add a TP2/EP2 HiCache recipe using CPU DRAM KV offload.
  • Update the TP4 and TP2/EP2 resident recipes with extra_buffer_lazy, ReplaySSM speculative verification, and checkpoint page-cache release.
  • Select 16 Pareto points: TP4 C1/C2/C4/C8/C12/C20/C24, TP2/EP2 resident C4/C8/C12/C20, and TP2/EP2 HiCache C22/C24/C28/C32/C40.
  • Pin simulated acceptance to the committed Qwen3.5 thinking-on golden AL of 3.39; the launcher injector disables it for EVAL_ONLY runs.
  • Keep the existing public cluster:gb200-nv launcher and routing unchanged.

Local validation completed:

  • Exact-key schema and matrix generation produced all 16 intended benchmark points and three eval selections.
  • Master/recipe image, topology, offload, and synthetic-AL parity were checked.
  • Committed-ref changelog processing, YAML parsing, Bash syntax, and git diff --check passed.

Recipe requirement: N/A — this is a multi-node dynamo-sglang submission with in-repository srt-slurm recipes.

中文说明

刷新 GB200 Qwen3.5 NVFP4-V2 AgentX 配置,使用 lmsysorg/sglang:nightly-dev-20260818-c0b6474b 镜像。

  • 新增使用 CPU DRAM KV 卸载的 TP2/EP2 HiCache 配方。
  • 更新 TP4 与 TP2/EP2 常驻配方,启用 extra_buffer_lazy、ReplaySSM 推测验证和检查点页缓存释放。
  • 选择 16 个 Pareto 配置点:TP4 C1/C2/C4/C8/C12/C20/C24、TP2/EP2 常驻 C4/C8/C12/C20,以及 TP2/EP2 HiCache C22/C24/C28/C32/C40。
  • 将模拟接受长度固定为已提交的 Qwen3.5 thinking-on 黄金 AL 3.39;启动器注入逻辑会在 EVAL_ONLY 运行中禁用该设置。
  • 保持现有公开 cluster:gb200-nv 启动器与路由不变。

已完成本地验证:

  • 精确配置键的 schema 与矩阵生成产生了预期的 16 个基准测试点和 3 个评测选择。
  • 已核对主配置与配方的镜像、拓扑、卸载和模拟 AL 一致性。
  • 已通过基于提交引用的变更日志处理、YAML 解析、Bash 语法和 git diff --check 检查。

配方要求:不适用——这是使用仓库内 srt-slurm 配方的多节点 dynamo-sglang 提交。

Related Issue

N/A

Type of Change

  • Bug fix
  • New feature
  • Configuration change
  • Documentation update
  • Other (please describe)

Checklist

  • I have tested my changes locally
  • I have updated documentation if necessary
  • For every change that can affect benchmark performance and every recipe addition or modification, I have appended a new entry to the physical end of perf-changelog.yaml and have not edited historical entries
  • Before merging via reuse, an authorized maintainer (OWNER/MEMBER/COLLABORATOR) has commented /reuse-sweep-run on this PR. Do this only once there is a final full sweep that is all green with evals passing, since after this comment the sweep label will no longer automatically kick off new sweeps. Remove and re-add the label to force one.

更新 GB200 Qwen3.5 AgentX 配置,加入 TP2/EP2 HiCache 分支并刷新 Pareto 配置点。
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

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. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

1 similar comment
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

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. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

在性能变更日志中补充 PR #2660 链接。
Comment thread perf-changelog.yaml Outdated
Comment on lines +6089 to +6098

- config-keys:
- qwen3.5-fp4-gb200-dynamo-sglang-agentic-mtp
scenario-type:
- agentic-coding
description:
- "Refresh GB200 Qwen3.5 NVFP4-V2 AgentX on lmsysorg/sglang:nightly-dev-20260818-c0b6474b without engine patches."
- "Add a TP2/EP2 HiCache branch and update the resident recipes with extra_buffer_lazy, ReplaySSM speculative verification, and checkpoint page-cache release."
- "Select TP4 C1/C2/C4/C8/C12/C20/C24, TP2/EP2 resident C4/C8/C12/C20, and TP2/EP2 HiCache C22/C24/C28/C32/C40 with golden synthetic acceptance length 3.39."
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/XXX

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 new changelog entry's pr-link uses the placeholder pull/XXX instead of the real PR number, even though this PR already exists as #2660. Per docs/configuration-procedures.md:250-254, the only sanctioned pre-PR placeholder is pr-link: TBD, to be replaced with the real URL immediately after PR creation; please change this to pull/2660 so the entry is traceable back to its PR.

Extended reasoning...

Bug: The changelog entry appended at the end of perf-changelog.yaml (lines 6089-6098) sets:

pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/XXX

This is PR #2660 (per the PR metadata), so the link should read pull/2660. Every other entry among the 100+ historical entries in this file uses a concrete pull/<number> link.

Documented convention: docs/configuration-procedures.md:250-254 explicitly documents the workflow for this field: the only sanctioned placeholder to use before the PR exists is the literal string pr-link: TBD, and the author is instructed to replace it with the real URL immediately after creating the PR. XXX is neither the real number nor the sanctioned TBD placeholder — it's an ad hoc stand-in that falls outside the documented convention.

Why it's not caught elsewhere: The changelog-key generation and CI ingest logic only read config-keys and scenario-type from each entry (used to build lookup keys for benchmark results); pr-link is purely a human-facing traceability field and isn't validated or parsed by any downstream tooling. That's why this passes YAML parsing, git diff --check, and CI without complaint — nothing enforces the field's format at build time. One earlier historical entry (line 5598) also uses pull/XXX, so this isn't the first occurrence, but a single unfixed prior instance doesn't make it a sanctioned convention; it's more likely the same slip happening twice.

Impact: Low — this doesn't affect benchmark behavior, CI, or sweep execution. It's a traceability/documentation issue: anyone auditing perf-changelog.yaml later (e.g. to find which PR introduced a given config change) will hit a dead link for this entry instead of being routed to PR #2660.

Proof / walkthrough:

  1. Open perf-changelog.yaml, jump to the last entry (lines 6089-6098, added by this PR).
  2. Read pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/XXXXXX is not a valid PR number.
  3. Check the actual PR: per this PR's metadata, it is PR Refresh GB200 Qwen3.5 AgentX Pareto / 刷新 GB200 Qwen3.5 AgentX Pareto 配置 #2660.
  4. Check docs/configuration-procedures.md:250-254: the documented process says use pr-link: TBD before the PR exists, then swap in the real URL right after creating it — never a placeholder string like XXX.
  5. Fix: replace the line with pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/2660.

Fix: Change line 6098 to pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/2660.

Comment on lines 7232 to 7244
disagg: false
scenarios:
agentic-coding:
- dram-utilization: 0.70
- dram-utilization: 0.90
search-space:
# Measured Pareto points from the complete fast sweep. TP4 covers the
# low-latency branch; HiCache extends the high-throughput branch.
# TP4 covers the low-latency branch. TP4 HiCache is omitted because the
# half-GPU TP2/EP2 branch already dominates that operating range.
- spec-decoding: mtp
kv-offloading: none
conc-list: [1, 4, 8, 12, 16, 20, 32, 40]
conc-list: [1, 2, 4, 8, 12, 20, 24]
prefill:
num-worker: 1
tp: 4

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.

🟡 This PR removes the last reference to agg-gb200-tp4-mtp-hicache.yaml from configs/nvidia-master.yaml (the TP4 HiCache search-space branch is replaced by the new TP2/EP2 resident + HiCache branches), leaving that recipe file orphaned and unable to pick up the new nightly image/flags its siblings received. Since unreferenced recipe files are common in this directory already, this is a minor nit — consider deleting it (or noting it as intentionally parked) as part of this cleanup.

Extended reasoning...

What changed: configs/nvidia-master.yaml previously wired one of the agentic-coding search-space branches under qwen3.5-fp4-gb200-dynamo-sglang-agentic-mtp to CONFIG_FILE=recipes/sglang/qwen3.5/gb200-fp4/agentic/agg-gb200-tp4-mtp-hicache.yaml. This PR removes that branch entirely and replaces it with two new branches — a TP2/EP2 resident arm and a TP2/EP2 HiCache arm — pointing at agg-gb200-tp2ep2-mtp.yaml and the newly-added agg-gb200-tp2ep2-mtp-hicache.yaml.

The orphan: benchmarks/multi_node/srt-slurm-recipes/sglang/qwen3.5/gb200-fp4/agentic/agg-gb200-tp4-mtp-hicache.yaml (added in PR #2568) is not touched by this PR's diff at all. A repo-wide grep for agg-gb200-tp4-mtp-hicache after this diff applies returns zero matches anywhere in configs/ or the recipe tree — the file simply stops being reachable from the master config. It still carries the old lmsysorg/sglang:v0.5.17-cu130 image and the pre-refresh flag set (no extra_buffer_lazy, no ReplaySSM, no checkpoint page-cache release) that its siblings (agg-gb200-tp4-mtp.yaml, agg-gb200-tp2ep2-mtp.yaml) just received in this same PR.

Why this isn't caught elsewhere: there's no CI check that cross-references recipe files against master-config CONFIG_FILE= references, so nothing flags an orphaned recipe automatically — it just sits in-tree, increasingly stale relative to its siblings, until someone notices.

Counter-consideration (from a reviewer who refuted this as a blocking issue): a repo-wide check shows roughly 191 of 423 recipe YAMLs under srt-slurm-recipes/ are already unreferenced by any master-config CONFIG_FILE=, so parking an inactive recipe in-tree is the established norm for this directory (it functions as a reusable recipe library, not a strict 1:1 mirror of the active sweep). That's a fair point, and it's why this is filed as a nit rather than a blocker — leaving the file is consistent with existing practice, and a future TP4-HiCache revival could reuse it as a starting point. The residual concern is narrower: this file was actively wired moments before this PR and became orphaned by this PR's own change (not pre-existing drift), and it now silently diverges from the nightly image/flag refresh its direct siblings received in the same diff, which could mislead a future reader into assuming the TP4-HiCache path is still validated against current settings.

Proof of orphaning:

  1. Before: configs/nvidia-master.yaml line ~7266 (pre-diff) contains CONFIG_FILE=recipes/sglang/qwen3.5/gb200-fp4/agentic/agg-gb200-tp4-mtp-hicache.yaml under the kv-offloading: dram / kv-offload-backend: hicache branch with tp: 4.
  2. After: that entire branch is deleted; the diff hunk at configs/nvidia-master.yaml:7232-7244 shows it replaced by a tp: 2, ep: 2, kv-offloading: none branch and a tp: 2, ep: 2, kv-offloading: dram/hicache branch, both pointing at agg-gb200-tp2ep2-mtp*.yaml.
  3. grep -r "agg-gb200-tp4-mtp-hicache" . post-diff → no hits outside the file's own path.
  4. The file on disk still declares container: { image: lmsysorg/sglang:v0.5.17-cu130 } while its siblings now read lmsysorg/sglang:nightly-dev-20260818-c0b6474b — confirming the drift.

Suggested fix: delete benchmarks/multi_node/srt-slurm-recipes/sglang/qwen3.5/gb200-fp4/agentic/agg-gb200-tp4-mtp-hicache.yaml as part of this cleanup, or leave a one-line note if it's intentionally kept for a future TP4-HiCache revival.

@github-actions

Copy link
Copy Markdown
Contributor

3 similar comments
@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@Ankur-singh

Copy link
Copy Markdown
Collaborator Author

/reuse-sweep-run 32177976542

@Ankur-singh

Copy link
Copy Markdown
Collaborator Author

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.
  • Verified that this PR passes evals. Please link to GitHub Action workflow that shows this.
  • Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
  • For agentic workloads: verified that speculative-decoding configs (EAGLE / MTP / draft models) run with simulated synthetic acceptance, with the acceptance-length value taken from the committed golden AL curve in golden_al_distribution/ for that model, thinking mode, and draft length. A submission may choose any supported draft length, but it may not substitute a different acceptance target.
  • Verified against the current MODELS.md that this PR does not submit a deprecated model, scenario, or model-scenario combination.
  • Verified that the model architecture isn't changed with benchmark hacks like using --hf-overrides to skipping indexer for every x layers on models that don't natively support this. As a general rule, we won't accept optimizations that reduces the number of model architecture FLOPs. Anything that makes that same computation run faster is fair game; FLOPs at lower precisions is fine, given that the config passes private evals. As an general north star princple, we should only use optimizations which is used in production by customers that care about accuracy
  • If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have verified that the respective vLLM submission made using upstream https://hub.docker.com/u/vllm docker repo, upstream SGLang https://hub.docker.com/u/lmsysorg docker repo. 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 as supported by vLLM/SGLang community maintainers
  • If an company claims that they support vLLM/SGLang as first class upstream in-tree 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 every single-node vLLM/SGLang recipe in this PR is documented in the official vLLM recipes and/or the SGLang cookbook:
    • I linked the corresponding upstream PR in the vLLM recipe repo or SGLang repo and verified that it is MERGED before this InferenceX PR merges. An opened, draft, or closed-without-merge upstream PR does not satisfy this requirement. If the matching recipe was already published, I linked the published recipe/cookbook page in the additional detail section below.
  • Verified that this PR does not patch the inference engine or serving stack — the pinned image must run as shipped. This covers .patch files / git apply / patch, inline patches embedded in benchmark scripts (e.g. a python3/sed heredoc that rewrites installed engine sources before serving), in-place edits of site-packages, monkey-patching, overwriting container files, and installing forked/rebuilt engine wheels on top of the pinned image. The only exception is a patch covered by a filled-out waiver at docs/waiver/<PR_NUMBER>.md — named after the PR that introduces the patch and filed in that same PR, stating what is patched, why the unmodified upstream image cannot run this benchmark, the upstream PR/issue link, and the removal plan — which I have linked below in the additional detail section.
  • If this PR uses append-only: true, verified that it only adds generated points or recipe variants inside a selected existing config/scenario and existing same-image visual curve: every previously generated point remains present with the same recipe, no prior point is removed or rerun, and every benchmark-affecting change in the complete diff can affect only the corresponding newly appended points (never an existing point), regardless of which file contains it.
  • If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.

Additional detail section:

  • Chat-template item is out of scope: this PR's scenario-type is agentic-coding, which uses the agentic golden-AL item above instead of chat templates.
  • Single-node vLLM/SGLang recipe item (and its upstream-PR sub-item) is out of scope: the changed master-config entry uses framework: dynamo-sglang with multinode: true and CONFIG_FILE= recipes, not a single-node vLLM/SGLang recipe.
  • append-only item is out of scope: this PR does not set append-only: true on the changed entry.

Signed: Ankur-singh

@Klaud-Cold

Copy link
Copy Markdown
Collaborator

✅✅✅ Verdict: PASS ✅✅✅

✅ Check 0 (CODEOWNER): PASS — Ankur-singh owns configs/nvidia-master.yaml (specific CODEOWNERS line); remaining files fall to the catch-all, covered by a recognized CODEOWNER.
✅ Check 1 (sweep on in-PR commit): PASS — head 7a4a06b carries run 32177976542 with all 16 multi-node agentic / benchmark jobs and all 3 multi-node agentic eval / jobs executed with conclusion success (this multi-node agentic matrix has no single-node lanes; those buckets are empty/skipped by design).
✅ Check 2 (evals pass): PASS — downloaded eval artifacts show GSM8K em_strict 0.9780 (TP2/EP2 c20), 0.9757 (TP2/EP2 HiCache c40), 0.9742 (TP4 c24), n_eff=1319 each, all on lmsysorg/sglang:nightly-dev-20260818-c0b6474b, the exact image this PR pins.
➖ Check 3 (recipe link): N/A — disaggregated/multi-node submission (framework: dynamo-sglang, multinode: true, recipes under benchmarks/multi_node/srt-slurm-recipes/**); the recipe-link requirement applies to single-node recipes only.
✅ Check 4 (reuse command): PASS — /reuse-sweep-run 32177976542 posted by Ankur-singh (COLLABORATOR).
✅ Check 5 (latest checklist): PASS — sign-off matches the current docs/PR_REVIEW_CHECKLIST.md item-for-item; the three unchecked items (chat-template, recipe link, append-only) are each explained as out of scope in the additional detail section.
✅ Check 6 (upstream image / engine-first): PASS — image lmsysorg/sglang:nightly-dev-20260818-c0b6474b is from the upstream lmsysorg org; no new non-vLLM/SGLang config entry is added (existing SGLang-engine entry refreshed).
✅ Check 7 (deprecations): PASS — qwen3.5 fp4 agentic-coding MTP is the active published arm per MODELS.md as of 2026-08-19.
✅ Check 8 (no architecture hacks): PASS — no --hf-overrides/model-config edits; changes are engine scheduling/caching/spec-verification knobs (extra_buffer_lazy, ReplaySSM, HiCache, weight-loader prefetch) with evals green.
➖ Check 9 (chat template): N/A — all spec-decode changes are agentic-coding configs governed by the golden-AL simulated-acceptance standard (Check 11), as the sign-off states.
✅ Check 10 (no engine patches): PASS — YAML recipe/config changes only; no patch files, heredocs, site-packages edits, or wheel installs.
✅ Check 11 (golden AL): PASS — all three branches pin SYNTHETIC_ACCEPTANCE=true + SYNTHETIC_ACCEPTANCE_LENGTH=3.39, matching golden_al_distribution/qwen3.5_mtp.yaml thinking_on at 3 speculative tokens (recipes use speculative-num-steps: 3); the injector adds SGLANG_SIMULATE_ACC_LEN (match-expected, real-draft-token) and correctly skips EVAL_ONLY runs.
➖ Check 12 (append-only): N/A — the new perf-changelog entry does not set append-only: true.

@functionstackx

Copy link
Copy Markdown
Collaborator

/reuse-sweep-run

@functionstackx
functionstackx merged commit 2719ad8 into main Aug 19, 2026
28 checks passed
@functionstackx
functionstackx deleted the qwen3.5-fp4-gb200-dynamo-sglang-agentic-mtp-pareto-refresh branch August 19, 2026 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Development

Successfully merging this pull request may close these issues.

3 participants