[Klaud Cold] glm5.2-fp4-b300-sglang-agentic-mtp: GLM-5.2 NVFP4 B300 AgentX with EAGLE MTP and golden-AL synthetic acceptance / 新增 GLM-5.2 NVFP4 B300 SGLang EAGLE MTP AgentX 配置（黄金 AL 合成接受率）

[functionstackx]

Adds glm5.2-fp4-b300-sglang-agentic-mtp — the speculative-decoding arm of the GLM-5.2 NVFP4 B300 AgentX recipe, and the arm that replaces the existing STP entry once agentic non-MTP is deprecated for GLM-5.2 on 2026-08-03 (MODELS.md). The STP entry is left untouched so the two can be compared before the cut-over.

What's here

File	Change
benchmarks/single_node/agentic/glm5.2_fp4_b300_sglang_mtp.sh	New. The validated STP script, unchanged outside the speculative + simulated-acceptance blocks.
golden_al_distribution/glm5.2_mtp.yaml	New. GLM-5.2 golden AL curve.
golden_al_distribution/README.md, README_zh.md	GLM-5.2 row in the "current golden curves" table.
configs/nvidia-master.yaml	New config-key.
perf-changelog.yaml	New entry.

MTP

GLM-5.2 ships its own nextn head, so SGLang EAGLE runs off the checkpoint with no external draft model:

--speculative-algorithm EAGLE --speculative-num-steps 3 \
--speculative-eagle-topk 1 --speculative-num-draft-tokens 4

3 speculative tokens per verification step — the same shape the GLM-5.2 GB300 dynamo-sglang agentic recipes use.

Synthetic acceptance length

Throughput runs pin acceptance to the committed golden AL, per the AgentX policy in golden_al_distribution/README.md:

SGLANG_SIMULATE_ACC_LEN=2.99
SGLANG_SIMULATE_ACC_METHOD=match-expected
SGLANG_SIMULATE_ACC_TOKEN_MODE=real-draft-token

EVAL_ONLY runs leave it off — simulated acceptance commits drafted tokens regardless of the target logits, so the eval would score ~0.

GLM-5.2 had no committed golden curve, so this PR commits one. golden_al_distribution/glm5.2_mtp.yaml is verbatim from the speedbench-al.yml artifact of run 28058352479 (SPEED-Bench coding, output-len 4096, temperature 1.0, top_p 0.95, thinking_on, num_speculative_tokens 1–8); K=3 is 2.99. Reviewers: this is the one item here that needs the golden-curve review checklist, not just a recipe read. Note the collection ran on the FP8 checkpoint — one curve is committed per model and the NVFP4 checkpoint ships the same nextn head.

Image bump

lmsysorg/sglang:v0.5.15.post1-cu130 → lmsysorg/sglang:v0.5.16-cu130 (verified on Docker Hub, pushed 2026-07-24). SGLANG_SIMULATE_ACC_TOKEN_MODE is only read from v0.5.16 — SIMULATE_ACC_LEN / SIMULATE_ACC_METHOD exist further back, so an older image would silently ignore the token-mode half of the contract. v0.5.16-cu130 is also the tag the GLM-5.2 GB300 dynamo-sglang agentic recipes already run.

Search space

One arm on the AgentX MTP concurrency grid:

- { tp: 8, spec-decoding: mtp, kv-offloading: dram, kv-offload-backend: { name: hicache }, conc-list: [1, 4, 8, 12, 16] }

• Steps of at least 2 — single-step sampling can't separate configurations by more than run-to-run noise on the agentic corpus — and a hard stop at conc 16.
• The STP entry's DEP (attention-DP + EP8) throughput arm is not carried over: its frontier peak is conc 48, above that cap, and at conc ≤ 16 attention-DP leaves 2 sessions per rank and is strictly dominated by TP8. The DEP branch stays in the benchmark script — including the --speculative-moe-a2a-backend none / --speculative-moe-runner-backend triton pair that GLM-5.2-NVFP4's unquantized bf16 nextn layer (hf_quant_config excludes model.layers.78*) needs once expert parallelism puts an all-to-all in the MoE path — so the throughput arm can be added later without re-deriving it.
• HiCache on every point, matching the STP entry: without it the working set outgrows HBM past conc 8 and the radix hit rate collapses to <0.1.

mem-fraction-static stays at 0.85, which is what both the B300 STP script and the GLM-5.2 GB300 aggregated MTP recipe use; hicache-ratio is relative to the device pool, so the nextn layer's own KV only shrinks the host pool.

Validation

• bash -n clean; perf-changelog.yaml / configs/nvidia-master.yaml parse; diff is additions only.
• generate_sweep_configs.py test-config and process_changelog.py against origin/main both select exactly the 5 expected jobs (glm5.2_tp8_conc{1,4,8,12,16}_kvdram-hicache_spec-mtp).
• Launcher resolution simulated: benchmarks/single_node/agentic/glm5.2_fp4_b300_sglang_mtp.sh.

Sweep results to follow.

[github-actions]

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 关于重新运行失败任务的文档

[github-actions]

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 关于重新运行失败任务的文档

[claude]

🟡 AGENTS.md line 7 mandates that every PR body follow the English content with a mirrored Chinese translation (e.g. a ## 中文说明 section) — this applies to every PR and issue. This PR's title is bilingual, but the entire body (What's here, MTP, Synthetic acceptance length, Image bump, Search space, Validation) is English-only with no Chinese section.

Extended reasoning...

AGENTS.md line 7 states, verbatim: "PR and GitHub-issue titles & descriptions must be bilingual — include a Simplified Chinese version in addition to English. ... In the PR/issue body, follow the English content with its Chinese translation (e.g. a ## 中文说明 section mirroring the summary...). This applies to every PR and every issue."

PR #2447's title correctly follows the <English> / <中文> format ("...EAGLE MTP and golden-AL synthetic acceptance / 新增 GLM-5.2 NVFP4 B300 SGLang EAGLE MTP AgentX 配置（黄金 AL 合成接受率）"). However, the description body — the intro paragraph plus the "What's here", "MTP", "Synthetic acceptance length", "Image bump", "Search space", and "Validation" sections — is entirely English. There is no mirrored ## 中文说明 section, nor any trailing Chinese paragraph summarizing the content, anywhere in the body.

This satisfies only half of the explicit, repo-wide bilingual mandate (title done, body not done). The rule is unambiguous and not a matter of subjective style — CLAUDE.md defers entirely to AGENTS.md, and AGENTS.md states this applies to "every PR and every issue," with no carve-out for recipe/config PRs. Nothing in existing tooling enforces this automatically (there's no bot check for body-level bilingual content, only the CODEOWNER sign-off phrase bot), so it falls on human/AI review to catch it.

Proof by inspection: scanning the full PR description body for any Chinese characters or a 中文 heading turns up none outside the title — every section header and every line of prose is ASCII English. Contrast this with recent merged commits in this same repo that do carry bilingual PR titles and (per the AGENTS.md convention) bodies, confirming the convention is actively expected and enforced elsewhere in the project.

Impact and fix: this is purely a documentation/process gap — it does not touch the benchmark script, the master-config entry, the golden AL YAML, or any runtime behavior, so nothing breaks if this merges as-is. The fix is simply for the author to append a ## 中文说明 section (or trailing 中文 paragraph) that mirrors the English summary, following the terminology and idiomatic-translation guidance also laid out in AGENTS.md (e.g. keeping SKU/framework/flag names in English).

Severity is nit: it's a real, verifiable violation of an explicit repo rule, but it affects only the PR description prose, not the code or config under review, and is trivially fixed by editing the description text.

[github-actions]

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

[github-actions]

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