[Klaud Cold] Update minimaxm3-fp8-h100-vllm-agentic-mtp vLLM image to nightly-d9105ea8001e0a6d77a96327d17515bb5791fb36

[functionstackx]

Summary

Update vLLM image for the H100 MiniMax-M3 MXFP8 AgentX EAGLE3 recipe from vllm/vllm-openai:v0.27.1 (v0.27.1 release) to vllm/vllm-openai:nightly-d9105ea8001e0a6d77a96327d17515bb5791fb36 (2026-09-07 upstream nightly).

• Tag verified on Docker Hub: last pushed 2026-09-07T06:16:01Z, digest sha256:254eebf919e8b7b0d530d97fccc606c36f380ff6724d64bc190951bec1aee838; tag commit vllm-project/vllm@d9105ea8, the same tag the B200 MiniMax-M3 AgentX recipe moved to in [Klaud Cold] Update minimaxm3-fp4-b200-vllm-agentic-mtp vLLM image to nightly-8a728663c1c3eeace834a95f5654fa653cc1998c #2860.
• benchmarks/single_node/agentic/minimaxm3_fp8_h100_mtp.sh is unchanged and pins nothing image-specific: TRITON_ATTN attention, fp8 KV, EAGLE3 with the Inferact EAGLE3-GQA draft on FLASH_ATTN, golden synthetic AL 2.78, Mooncake 0.3.11.post1 on the DRAM-offload arm. Grid unchanged: resident TP8 c1-c5 and Mooncake DRAM offload c6/c8.

Recipes touched: minimaxm3-fp8-h100-vllm-agentic-mtp

Test plan

• full-sweep-enabled sweep passes on cluster:h100-dgxc.

🤖 Generated with Claude Code

---

Note

Low Risk
Benchmark and container image pin changes only; eval concurrency floor is intentional and does not affect reported throughput cells or eval accuracy semantics.

Overview
Updates the minimaxm3-fp8-h100-vllm-agentic-mtp recipe from vllm/vllm-openai:v0.27.1 to vllm/vllm-openai:nightly-d9105ea8001e0a6d77a96327d17515bb5791fb36, aligning with the B200 AgentX bump in #2860.

Eval-only GSM8K was timing out on Slurm at low sweep concurrencies (c1–c3): run_eval uses client parallelism equal to CONC, so ~1319 requests ran almost serially and exceeded the 180-minute limit. The script now floors eval client concurrency at 8 via EVAL_CONCURRENT_REQUESTS when EVAL_ONLY and CONC < 8, and sets --max-num-seqs to 2 * EVAL_CONC so the server can admit that load. Throughput sweeps still use 2 * CONC when not eval-only or when CONC ≥ 8.

Changelog entry added in perf-changelog.yaml.

^{Reviewed by Cursor Bugbot for commit 1e6635f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Update: eval-only concurrency floor

First sweep (run 34174431989): all throughput cells and the c4/c5/c8 evals passed, but the c1/c2/c3 eval-only cells were cancelled by Slurm at 96-98% of GSM8K after 180 minutes. Cause: run_eval drives lm_eval at CONC parallel requests, so at c1-c3 the 1319 GSM8K requests ran nearly serially at ~7 s each on H100. The recipe's previously merged sweep only ran the eval at c8 (195 min on v0.27.1), so this is the wider eval matrix hitting an existing H100 limit, not an image regression (H200 finishes the same evals in 23-33 min). Fix: eval-only runs now floor the client concurrency at 8 via EVAL_CONCURRENT_REQUESTS and size --max-num-seqs to admit it; throughput runs are unchanged (still 2*CONC). Eval accuracy does not depend on client concurrency.

[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]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

🟡 (optional) pr-link is the literal placeholder string PRLINK_PLACEHOLDER, not a real PR URL, so the changelog entry lacks provenance if merged as-is. Fix: replace with the actual GitHub PR URL for this bump before merge (CONTRIBUTING.md requires a real pr-link on every changelog entry).

Extended reasoning...

The new perf-changelog.yaml entry (lines 6923-6931) for minimaxm3-fp8-h100-vllm-agentic-mtp ends with pr-link: PRLINK_PLACEHOLDER. This is the only occurrence of that placeholder in the file (grep confirms). If this merges unedited, downstream tooling/readers that resolve pr-link to trace which PR introduced a perf change get a dead/placeholder reference instead of the actual PR URL, breaking changelog provenance and audit trail for this entry going forward.

Verification: normal. The diff appends a new perf-changelog.yaml entry ending at line 6931 with pr-link: PRLINK_PLACEHOLDER (visible in the diff hunk for perf-changelog.yaml). A grep of the whole file confirms this is the sole occurrence of the placeholder; every other pr-link in the file — including the immediately preceding entry at line 6923 (`pr-link:… | normal. perf-changelog.yaml:6931 (in the diff)…

[github-actions]

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

[github-actions]

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