Skip to content

MiniMax-M3 H100 AgentX EAGLE3 tuning on vLLM v0.27.1 - #2564

Open
cquil11 wants to merge 8 commits into
mainfrom
agent/minimaxm3-h100-agentx-v27
Open

MiniMax-M3 H100 AgentX EAGLE3 tuning on vLLM v0.27.1#2564
cquil11 wants to merge 8 commits into
mainfrom
agent/minimaxm3-h100-agentx-v27

Conversation

@cquil11

@cquil11 cquil11 commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Summary

Refreshes MiniMax-M3 MXFP8 AgentX on H100 with stable vLLM v0.27.1, the EAGLE3-GQA draft, golden synthetic AL 2.78, strict request/profile validation, and required vllm: server metrics.

The completed broad agentx-fast sweep covered TP8, TEP8, DEP8, Mooncake DRAM offload, and a separate vLLM-simple function screen. It located the resident HBM cliff between c5 and c6. The strict matrix retains the useful curve: resident TP8 c1/c2/c3/c4/c5 and Mooncake TP8 c6/c8.

Tuning evidence

Final search space

  • TP8 resident: c1, c2, c3, c4, c5
  • TP8 Mooncake DRAM offload: c6, c8
  • MTP for every point; eval uses real verification.

Validation

  • Exactly 7 generated strict AgentX points.
  • Bash syntax and YAML/perf-changelog validation clean.
  • 251 matrix/changelog tests pass.
  • No relaxed request thresholds or validation exceptions.

functionstackx and others added 2 commits August 11, 2026 16:49
…n-AL synthetic acceptance

Add minimaxm3-fp8-h100-vllm-agentic-mtp, the spec-decoding=mtp variant of the
MiniMax-M3 MXFP8 H100 agentic-coding recipe: Inferact/MiniMax-M3-EAGLE3 draft
head, 3 speculative tokens, FLASH_ATTN drafter, and synthetic acceptance pinned
to the committed golden AL 2.83 (minimaxm3_eagle3.yaml, thinking_on, K=3).
EVAL_ONLY keeps real target verification. Serve shape, Mooncake offload and
search-space arms mirror the non-MTP sibling, trimmed at the top concurrencies.

中文:新增 minimaxm3-fp8-h100-vllm-agentic-mtp,即 MiniMax-M3 MXFP8 H100 智能体
编码配方的投机解码(spec-decoding=mtp)变体:使用 Inferact/MiniMax-M3-EAGLE3
草稿头、3 个投机 token、drafter 固定为 FLASH_ATTN,并将合成接受长度固定为已提交
的黄金 AL 2.83(minimaxm3_eagle3.yaml,thinking_on,K=3)。EVAL_ONLY 场景保留真实
目标验证。服务参数、Mooncake KV 卸载与搜索空间与非 MTP 版本保持一致,仅在高并发端
做了裁剪。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@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 关于重新运行失败任务的文档

@cquil11
cquil11 marked this pull request as ready for review August 11, 2026 21:55
@cquil11
cquil11 requested a review from a team August 11, 2026 21:55
@cquil11 cquil11 added full-sweep-enabled agentx-fast Run AgentX throughput with 1 warmup request per lane and a 20-minute profile; not reusable labels Aug 11, 2026
@claude

claude Bot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Claude finished @cquil11's task in 6m 26s —— View job


PR Review

  • Read the PR diff and changed files
  • Validate master config + perf-changelog pairing and ordering
  • Review benchmark script (MTP requirements, EP pattern, formatting, bugs)
  • Post review feedback

Summary

One 🟡 warning posted inline: the new comment block above minimaxm3-fp8-h100-vllm-agentic-mtp in configs/nvidia-master.yaml cites the non-GQA draft (Inferact/MiniMax-M3-EAGLE3), golden AL 2.83, and minimaxm3_eagle3.yaml, while the script actually pins the GQA draft at AL 2.78 from minimaxm3_eagle3_gqa.yaml (the perf-changelog entry agrees with the script) — a suggested rewrite is attached. No blocking issues: the perf-changelog entry is present and appended at the end of the file, --enable-expert-parallel is correctly conditional on EP_SIZE, the _mtp.sh suffix routing exists in runners/launch_h100-dgxc-slurm.sh:10, the image is public Docker Hub, the server launch is multiline, and the DEP concurrency lists all satisfy the script's 2*CONC % TP == 0 guard.

One note I could not verify offline: every other synthetic-acceptance MTP recipe (dsv4, kimik3, minimaxm3 fp4) pins a vLLM nightly image, while this is the first to use the stable vllm/vllm-openai:v0.27.1 with rejection_sample_method: synthetic — network access is blocked in this environment, so the agentx-fast sweep's server startup will be the real confirmation that v0.27.1 accepts that speculative-config field.

Comment on lines +7109 to +7117
# EAGLE3 speculative-decoding (spec-decoding: mtp) variant of
# minimaxm3-fp8-h100-vllm-agentic, pairing MiniMaxAI/MiniMax-M3-MXFP8 with the
# Inferact/MiniMax-M3-EAGLE3 draft head (3 speculative tokens, FLASH_ATTN
# drafter) and pinning synthetic acceptance to the golden AL 2.83
# (golden_al_distribution/minimaxm3_eagle3.yaml, thinking_on, K=3). Same TP8-only
# layout and KV arms as the non-MTP entry so the spec-decode delta is readable at
# equal concurrency, trimmed at the extreme-conc end: the draft head plus its KV
# eat into the same HBM budget that already puts the GPU-resident cliff near
# conc 6 on 80 GB H100s.

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.

🟡 WARNING: This comment block contradicts what the recipe actually runs, in three places:

  1. The script pins DRAFT_MODEL="Inferact/MiniMax-M3-EAGLE3-GQA" (benchmarks/single_node/agentic/minimaxm3_fp8_h100_mtp.sh:28), not Inferact/MiniMax-M3-EAGLE3.
  2. The script pins SYNTHETIC_ACCEPT_LEN=2.78, which is golden_al_distribution/minimaxm3_eagle3_gqa.yaml thinking_on[3] — not 2.83 from minimaxm3_eagle3.yaml (that's the non-GQA head's table). The perf-changelog entry in this PR also says 2.78.
  3. "Same TP8-only layout and KV arms as the non-MTP entry" — this entry adds two DEP8 (dp-attn: true) arms that the non-MTP entry doesn't have.

Why it matters: this comment is what reviewers and future submitters use to check which acceptance target a submission is pinned to; citing 2.83/minimaxm3_eagle3.yaml invites someone to "fix" the script to the wrong golden AL for the GQA draft.

Fix:

Suggested change
# EAGLE3 speculative-decoding (spec-decoding: mtp) variant of
# minimaxm3-fp8-h100-vllm-agentic, pairing MiniMaxAI/MiniMax-M3-MXFP8 with the
# Inferact/MiniMax-M3-EAGLE3 draft head (3 speculative tokens, FLASH_ATTN
# drafter) and pinning synthetic acceptance to the golden AL 2.83
# (golden_al_distribution/minimaxm3_eagle3.yaml, thinking_on, K=3). Same TP8-only
# layout and KV arms as the non-MTP entry so the spec-decode delta is readable at
# equal concurrency, trimmed at the extreme-conc end: the draft head plus its KV
# eat into the same HBM budget that already puts the GPU-resident cliff near
# conc 6 on 80 GB H100s.
# EAGLE3 speculative-decoding (spec-decoding: mtp) variant of
# minimaxm3-fp8-h100-vllm-agentic, pairing MiniMaxAI/MiniMax-M3-MXFP8 with the
# Inferact/MiniMax-M3-EAGLE3-GQA draft head (3 speculative tokens, FLASH_ATTN
# drafter) and pinning synthetic acceptance to the golden AL 2.78
# (golden_al_distribution/minimaxm3_eagle3_gqa.yaml, thinking_on, K=3). Keeps the
# non-MTP entry's TP8/TEP8 layout and KV arms (plus DEP8 dp-attn arms) so the
# spec-decode delta is readable at equal concurrency, trimmed at the
# extreme-conc end: the draft head plus its KV eat into the same HBM budget
# that already puts the GPU-resident cliff near conc 6 on 80 GB H100s.

@claude claude Bot left a comment

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.

Looks good — the only finding is a documentation-comment nit in the new config entry (wrong draft-head name/AL cited in the comment, with zero runtime impact since the script's actual constants are correct).

Extended reasoning...

Overview

This PR adds a new AgentX MTP (speculative decoding) benchmark recipe for MiniMax-M3 MXFP8 on H100, mirroring the existing non-MTP sibling (minimaxm3_fp8_h100.sh) and other MiniMax-M3 MTP recipes already in the repo (e.g. minimaxm3_fp4_b200_mtp.sh, minimaxm3_fp4_b300_mtp.sh). Changes are confined to a new benchmark script, a new config matrix entry in nvidia-master.yaml, and a perf-changelog.yaml entry — no production serving code, auth, or shared library logic is touched.

Security risks

None identified. This is benchmark/tooling infrastructure operating on trusted internal config; no user input, network-facing auth, or credential handling is introduced. The Mooncake KV-offload wiring and hf-download retry loop follow the same patterns already used elsewhere in the repo.

Level of scrutiny

Low-to-moderate is appropriate: this is a new but highly templated benchmark recipe, structurally near-identical to several already-merged siblings. The one bug found (comment citing the wrong draft-head name and golden AL in nvidia-master.yaml) is inert documentation — the script's actual DRAFT_MODEL=Inferact/MiniMax-M3-EAGLE3-GQA and SYNTHETIC_ACCEPT_LEN=2.78 are correct and consistent with the perf-changelog entry, so nothing incorrect actually executes.

Other factors

Two additional candidate issues (missing FULL_DECODE_ONLY cudagraph mode setting, and duplicated hf-download retry logic) were raised and refuted by verifier agents as not real bugs. The PR description reports clean bash/YAML validation and 231 passing matrix/schema tests. Given the nit is cosmetic-only and the rest of the change follows established conventions, I don't think this needs to block on human review.

Comment on lines 7108 to +7116

# EAGLE3 speculative-decoding (spec-decoding: mtp) variant of
# minimaxm3-fp8-h100-vllm-agentic, pairing MiniMaxAI/MiniMax-M3-MXFP8 with the
# Inferact/MiniMax-M3-EAGLE3 draft head (3 speculative tokens, FLASH_ATTN
# drafter) and pinning synthetic acceptance to the golden AL 2.83
# (golden_al_distribution/minimaxm3_eagle3.yaml, thinking_on, K=3). Same TP8-only
# layout and KV arms as the non-MTP entry so the spec-decode delta is readable at
# equal concurrency, trimmed at the extreme-conc end: the draft head plus its KV
# eat into the same HBM budget that already puts the GPU-resident cliff near

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 comment block above the new minimaxm3-fp8-h100-vllm-agentic-mtp entry (configs/nvidia-master.yaml:7108-7116) names the wrong draft head and golden AL: it says Inferact/MiniMax-M3-EAGLE3 and AL 2.83 from minimaxm3_eagle3.yaml, but the script it drives (minimaxm3_fp8_h100_mtp.sh) actually uses Inferact/MiniMax-M3-EAGLE3-GQA with AL 2.78 from minimaxm3_eagle3_gqa.yaml.

Extended reasoning...

The new minimaxm3-fp8-h100-vllm-agentic-mtp config entry at configs/nvidia-master.yaml:7108-7116 carries a doc comment describing the recipe's speculative-decoding setup. It states the recipe pairs the target with the Inferact/MiniMax-M3-EAGLE3 draft head and pins synthetic acceptance to golden AL 2.83 from golden_al_distribution/minimaxm3_eagle3.yaml (thinking_on, K=3).

That doesn't match the script this config entry actually drives, benchmarks/single_node/agentic/minimaxm3_fp8_h100_mtp.sh. Line 27 sets DRAFT_MODEL="Inferact/MiniMax-M3-EAGLE3-GQA" (the GQA variant, not the plain one named in the comment), and line 144 sets SYNTHETIC_ACCEPT_LEN=2.78, with the script's own adjacent comment correctly attributing that value to minimaxm3_eagle3_gqa.yaml thinking_on[3].

Step-by-step proof:

  1. golden_al_distribution/minimaxm3_eagle3.yamlminimax-m3.thinking_on[3] = 2.83 (non-GQA head).
  2. golden_al_distribution/minimaxm3_eagle3_gqa.yamlminimax-m3.thinking_on[3] = 2.78 (GQA head).
  3. The script sets DRAFT_MODEL=Inferact/MiniMax-M3-EAGLE3-GQA and SYNTHETIC_ACCEPT_LEN=2.78 — this is the GQA value from file (2), not the 2.83 from file (1).
  4. perf-changelog.yaml's new entry for this PR independently confirms this, stating "EAGLE3-GQA synthetic golden AL 2.78".
  5. Yet the nvidia-master.yaml comment cites the non-GQA model name, the non-GQA file, and the non-GQA AL value (2.83) — all three details are inconsistent with what the script and changelog actually implement.

The two golden_al_distribution files hold distinct measured acceptance-length values for genuinely different draft heads (GQA vs non-GQA attention in the EAGLE3 head), so this isn't a rounding or trivial wording slip — it names a different model checkpoint and cites a different measurement entirely. Nothing in the YAML schema or config loader cross-checks free-text comments against the script's runtime constants, so there's no existing mechanism that would have caught this drift, and it will keep misleading anyone reading the config to reconcile it with what's actually benchmarked.

There is no runtime impact: the comment is inert documentation and the script's own hardcoded DRAFT_MODEL/SYNTHETIC_ACCEPT_LEN values are what actually execute. The fix is simply to update the comment at configs/nvidia-master.yaml:7108-7116 to say Inferact/MiniMax-M3-EAGLE3-GQA, cite golden_al_distribution/minimaxm3_eagle3_gqa.yaml, and use golden AL 2.78, matching both the script and the new perf-changelog entry.

@github-actions

Copy link
Copy Markdown
Contributor

恢复基础设施丢失点,并在 H100 MiniMax-M3 拐点附近测试 vLLM SimpleCPUOffloadConnector。
…agentx-v27

# Conflicts:
#	perf-changelog.yaml
将 vLLM SimpleCPUOffloadConnector 接入实际的 MiniMax-M3 MTP 运行时,按检查点与模型预留计算主机内存,并排除已确认 NVML 故障的 H100 节点。
@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@cquil11 cquil11 removed full-sweep-enabled agentx-fast Run AgentX throughput with 1 warmup request per lane and a 20-minute profile; not reusable labels Aug 12, 2026
@github-actions

Copy link
Copy Markdown
Contributor

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

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants