Add GLM-5.1 FP8 B300 SGLang MTP configuration / 新增 GLM-5.1 FP8 B300 SGLang MTP 配置

[RohitNagraj]

Summary

• Add a GLM-5.1 FP8 B300 SGLang MTP benchmark configuration using lmsysorg/sglang:v0.5.15.post1-cu130.
• Add the matching single-node script with EAGLE speculative decoding and chat-template requests, using the writable model cache when weights are not pre-staged.

中文说明

• 新增 GLM-5.1 FP8 B300 SGLang MTP 基准测试配置，使用 lmsysorg/sglang:v0.5.15.post1-cu130 镜像。
• 新增对应的单节点脚本，启用 EAGLE 投机解码并为请求使用聊天模板；权重未预置时使用可写模型缓存。

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

[RohitNagraj]

Closing in favor of #2320, which now includes both the standard and MTP configurations. / 关闭此拉取请求，#2320 现已包含标准配置和 MTP 配置。

[claude]

🔴 This PR silently un-deprecates GLM-5.1: commit a5bfbe8 (#2276, merged just 5 days earlier) deliberately removed all GLM-5/GLM-5.1 configs repo-wide (archived to configs/deprecated/) because GLM-5.2 is the designated successor, yet this PR re-adds glm5-fp8-b300-sglang-mtp as a brand-new, non-deprecated entry in configs/nvidia-master.yaml along with a near-verbatim copy of the just-deprecated deprecated/glm5_fp8_b300_mtp.sh script (same model, same flags, same NOTE comment — only formatting differs).

Extended reasoning...

The bug: Commit a5bfbe8 (#2276, merged 2026-07-18, titled "chore: deprecate GLM-5 / GLM-5.1 benchmark configs") deliberately removed all 31 GLM-5/GLM-5.1 config entries from the active configs/nvidia-master.yaml and configs/amd-master.yaml, archiving them verbatim to configs/deprecated/{nvidia,amd}-glm5-glm5.1-master.yaml, and moved the corresponding 18 single-node scripts into benchmarks/single_node/fixed_seq_len/deprecated/. The commit message is explicit about intent: it follows the same precedent as the MiniMax M2.5/M2.7 and gpt-oss-120b deprecations, and states "GLM-5.2 ... is out of scope" — i.e., GLM-5.2 is the designated successor and GLM-5.1 was being wound down.

The code path: This PR, opened 5 days later, adds glm5-fp8-b300-sglang-mtp as a fresh top-level entry in configs/nvidia-master.yaml (not under deprecated/), targeting zai-org/GLM-5.1-FP8. It pairs this with a new benchmarks/single_node/fixed_seq_len/glm5_fp8_b300_mtp.sh. I diffed this new script against the just-deprecated benchmarks/single_node/fixed_seq_len/deprecated/glm5_fp8_b300_mtp.sh and they are functionally identical — same model, same SGLang launch flags (NSA attention backend, EAGLE spec-decoding params, fp8 quantization), and the exact same "reuses the GLM5 FP8 B200 SGLang recipe" NOTE comment. The only differences are cosmetic: quoting style, line-continuation formatting, and the relative benchmark_lib.sh source path (corrected back from ../../../ to ../../ since it's no longer nested under deprecated/).

Why existing review/CI doesn't catch this: There's no automated check that cross-references newly-added config keys against recently-deprecated model families — deprecation here was done by moving files/entries into a deprecated/ naming convention, which is a soft, human-readable signal rather than something CI enforces. Nothing prevents a contributor (who may be unaware of #2276, given the 5-day gap) from reintroducing a deprecated model as a "new" config.

Impact: If merged as-is, this silently reverses part of a deliberate, recent maintainer decision. It also means CI's full-sweep-fail-fast benchmark sweep would burn a full B300 GPU sweep run on a model family the repo just decided to stop benchmarking, working against the stated goal of consolidating benchmark effort onto GLM-5.2. The PR description gives no indication this is an intentional reversal — it's framed purely as "add a new B300 MTP config," suggesting the author may not be aware GLM-5.1 was deprecated 5 days prior.

Step-by-step proof:

1. git show a5bfbe8 --stat shows configs/nvidia-master.yaml losing GLM-5/5.1 entries and benchmarks/single_node/fixed_seq_len/glm5_fp8_b300_mtp.sh being moved to benchmarks/single_node/fixed_seq_len/deprecated/glm5_fp8_b300_mtp.sh.
2. The commit message states GLM-5.2 is the successor and GLM-5.1/GLM-5 config entries are deprecated repo-wide, matching the MiniMax/gpt-oss-120b precedent.
3. This PR's diff adds glm5-fp8-b300-sglang-mtp: back into configs/nvidia-master.yaml at the top level (not under any deprecated path), targeting zai-org/GLM-5.1-FP8.
4. diff benchmarks/single_node/fixed_seq_len/deprecated/glm5_fp8_b300_mtp.sh benchmarks/single_node/fixed_seq_len/glm5_fp8_b300_mtp.sh shows only whitespace/quoting/path differences — the launch flags, model, and NOTE comment are identical.
5. configs/nvidia-master.yaml already contains a glm5.2-* entry (the designated successor), and GLM-5.1 appears nowhere else in the active config — confirming this PR is the sole reintroduction point.

Suggested fix: Confirm with maintainers whether un-deprecating GLM-5.1 is intentional (e.g., a B300-specific need not covered by GLM-5.2). If not intentional, retarget this config/script at GLM-5.2 instead, or place it under the deprecated/ path consistent with #2276's decision. If intentional, the PR description should say so explicitly so reviewers don't need to reverse-engineer the conflict with #2276.