Skip to content

Update vLLM MiniMax-M3 image tags / 更新 vLLM MiniMax-M3 镜像标签 - #2120

Open
wzhao18 wants to merge 14 commits into
mainfrom
wzhao/m3-b300-update-2
Open

Update vLLM MiniMax-M3 image tags / 更新 vLLM MiniMax-M3 镜像标签#2120
wzhao18 wants to merge 14 commits into
mainfrom
wzhao/m3-b300-update-2

Conversation

@wzhao18

@wzhao18 wzhao18 commented Jul 8, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Re-pin the B200/B300 MiniMax-M3 NVFP4 vLLM STP and EAGLE3 MTP configurations to upstream image vllm/vllm-openai:nightly-4080263bb2c5d10deac17aaeb88e0823bc35bca9.
  • Remove VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm from all four launchers.
  • Set the separate MSA indexer KV cache to FP8 on the two non-EAGLE configurations with --attention_config.indexer_kv_dtype fp8.
  • Append the four affected configuration keys to perf-changelog.yaml.

Validation

中文说明

  • 将 B200/B300 上 MiniMax-M3 NVFP4 的 vLLM STP 与 EAGLE3 MTP 配置统一更新至上游镜像 vllm/vllm-openai:nightly-4080263bb2c5d10deac17aaeb88e0823bc35bca9
  • 从四个启动脚本中移除 VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm
  • 在两个非 EAGLE 配置中通过 --attention_config.indexer_kv_dtype fp8 将独立的 MSA indexer KV cache 设置为 FP8。
  • 将四个受影响的配置键追加到 perf-changelog.yaml

验证

  • 四个配置均已通过完整扫描及评估,12/12 个 GSM8K 评估任务通过。
  • vLLM recipes PR #682 已补充 FP8 indexer cache 参数,但目前仍未合并;本 PR 合并前需先完成该上游合并。

@github-actions

github-actions Bot commented Jul 8, 2026

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

Comment thread perf-changelog.yaml
Comment on lines +4623 to +4628

- config-keys:
- minimaxm3-fp4-b300-vllm
description:
- "update vllm image"
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/2120

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 is materially more than a image bump, but the new perf-changelog entry (perf-changelog.yaml:4623-4628) only says "update vllm image". Per AGENTS.md §"Updating Docker images", each material change should be its own bullet — please also list the new VLLM_MINIMAX_M3_BF16_ROUTER_GEMM=1 env var (with the bf16-router-gate weight patch it enables), the pinned FlashInfer nightly-v0.6.14-20260702 + CuTeDSL split-K gemm patch, and the new --attention_config.indexer_kv_dtype fp8 CLI arg. Also, before dropping the [WIP] marker, please make the PR title bilingual per AGENTS.md (<English title> / <中文标题>).

Extended reasoning...

What the finding is. The perf-changelog entry appended in this PR (perf-changelog.yaml:4623-4628) has a single-bullet description update vllm image, but the PR is doing five distinct things beyond an image bump:

  1. Sets VLLM_MINIMAX_M3_BF16_ROUTER_GEMM=1 in the recipe (benchmarks/single_node/fixed_seq_len/minimaxm3_fp4_b300.sh:92).
  2. Applies patches/minimax-m3-bf16-router-gemm.patch to the installed vLLM, which adds that env var to vllm/envs.py and, when set, switches MiniMaxM3MoE.gate's GateLinear params_dtype from torch.float32 to torch.bfloat16. That's a real numerical change: instead of upcasting bf16 activations to fp32 and running an fp32 gate, the weights are now rounded fp32→bf16 and the gate runs cuBLAS bf16 × bf16 → fp32.
  3. Installs FlashInfer 0.6.14.dev20260702 (nightly-v0.6.14-20260702) explicitly on top of the image, replacing the version baked into the container.
  4. Applies a ~3100-line flashinfer-cutedsl-splitk-gemm.patch to that installed FlashInfer (new CuTeDSL split-K kernel for low-M MXFP8 gemms).
  5. Adds --attention_config.indexer_kv_dtype fp8 to the vllm serve invocation (recipe line 112).

Why the convention matters here. AGENTS.md §"Updating Docker images" gives an explicit example showing that an image bump paired with a new env var should be TWO bullets, not one:

description:
  - 'Update vLLM image from v0.11.2 to v0.13.0'
  - 'Add VLLM_MXFP4_USE_MARLIN=1 environment variable'

The changelog description is what surfaces on inferencex.com next to the perf delta this PR produces. If any of the five items above moves the numbers — and the bf16-router weight rounding in particular is a change to numerical semantics of the routing GEMM, not a no-op — a reader seeing only "update vllm image" will attribute the delta entirely to the image swap. Sibling entries in the same file (e.g. the glm5 configs above at ~4600-4602 and dsr1 at ~4619-4621) all follow the multi-bullet convention.

Step-by-step proof for the bf16 router GEMM entry alone. In patches/minimax-m3-bf16-router-gemm.patch, the GateLinear construction in vllm/models/minimax_m3/nvidia/model.py changes from params_dtype=torch.float32 to params_dtype=torch.bfloat16 if envs.VLLM_MINIMAX_M3_BF16_ROUTER_GEMM else torch.float32. The recipe sets that env var to 1, so on every run the router gate weights are the bf16-rounded version of the checkpoint's fp32 weights. That's a behavior change independent of the image bump, and it's the kind of item AGENTS.md's example says to list as its own bullet.

Bilingual PR title. Separately, AGENTS.md line 7 states "PR and GitHub-issue titles & descriptions must be bilingual — include a Simplified Chinese version in addition to English. Title format: <English title> / <中文标题>. … This applies to every PR and every issue." The current title [WIP] Update vllm B300 Minimax M3 is English-only. One verifier reasonably observed that this is PR metadata on a WIP PR and would normally be finalized when the WIP marker is dropped — that's fine; the note is just a reminder to update the title before requesting review, consistent with how recent MiniMax-M3 image bumps (#2107, #2003) landed.

How to fix. Expand the changelog description to something like:

- 'Update MiniMax-M3 FP4 B300 vLLM image (…→ nightly-2afa3f7e9502…)'
- 'Install pinned FlashInfer nightly-v0.6.14-20260702 and apply the CuTeDSL split-K gemm patch'
- 'Apply MiniMax-M3 bf16-router GEMM patch and enable it via VLLM_MINIMAX_M3_BF16_ROUTER_GEMM=1'
- 'Add --attention_config.indexer_kv_dtype fp8 to vllm serve'

and update the PR title to Update vllm B300 Minimax M3 / <中文标题> before dropping [WIP].

Severity. Nit — this is a documentation completeness issue on a WIP PR, not a runtime defect. Flagging it now so the changelog can be expanded before the [WIP] marker is dropped.

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

@wzhao18 wzhao18 reopened this Jul 18, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Comment on lines +56 to +57
SITE_PACKAGES=$(dirname "$(python3 -c "import importlib.util; print(importlib.util.find_spec('flashinfer').submodule_search_locations[0])")") \
|| { echo "Could not locate the installed flashinfer package" >&2; exit 1; }

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.

🟡 In minimaxm3_fp4_b300.sh:56-57, SITE_PACKAGES=$(dirname "$(python3 -c ...)") || { echo ...; exit 1; } only checks the exit status of the outer dirname, not the inner python3 command substitution. If python3 fails to locate flashinfer, dirname "" still succeeds and prints ".", so the error guard never fires and SITE_PACKAGES silently becomes ".". Fix by capturing the python3 output into its own variable (checked with ||) before passing it to dirname.

Extended reasoning...

What the bug is. On line 56, SITE_PACKAGES$(dirname "$(python3 -c ...)") nests a python3 command substitution inside a dirname command substitution, then guards the whole assignment with || { echo "Could not locate the installed flashinfer package" >&2; exit 1; }. In bash, the exit status of VAR=$(cmd) is the exit status of cmd — here, dirname, not the nested python3 invocation. If python3 -c "...find_spec('flashinfer').submodule_search_locations[0]..." fails (flashinfer not importable, or find_spec returns None causing an AttributeError on .submodule_search_locations), it exits non-zero and prints nothing to stdout. But dirname "" (dirname of an empty string) itself prints "." and exits 0. The outer || therefore never fires, and SITE_PACKAGES is silently set to "." instead of triggering the intended fail-fast error message.\n\nStep-by-step proof. This can be reproduced directly:\n\nSITE_PACKAGES=$(dirname "$(python3 -c 'import sys; sys.exit(1)')") || echo caught\necho "SITE_PACKAGES=[$SITE_PACKAGES]"\n\nThis does NOT print "caught", and prints SITE_PACKAGES=[.] — confirming the inner python3 failure is fully swallowed by the outer dirname call's own success.\n\nWhy existing guards don't fully prevent it. The immediately preceding lines do install flashinfer with their own || exit 1 guard (the pip install a few lines above), which makes reaching this specific find_spec failure unlikely in the common case — flashinfer should be importable by the time this line runs. And even if SITE_PACKAGES did end up ".", the following line, patch -p1 -d "${SITE_PACKAGES}" < "$FLASHINFER_PATCH", would try to patch flashinfer/gemm/gemm_base.py relative to the script's cwd, which doesn't exist there, so patch itself fails and its own || { echo ...; exit 1; } guard aborts the script anyway. So the net runtime behavior is still a fail-fast abort — just with a less accurate/misleading diagnostic message ("FlashInfer CuTeDSL split-K gemm patch failed" instead of "Could not locate the installed flashinfer package").\n\nContrast with the codebase's own convention. The sibling script minimaxm3_fp8_b300.sh resolves the same kind of path using a single-level $(...) capture around a heredoc that explicitly does if spec is None or not spec.submodule_search_locations: sys.exit(1), then applies its own || exit 1 directly to that capture — no nested command substitution masking the exit status. This PR's script diverges from that established, correctly fail-safe pattern.\n\nFix. Split the resolution into two steps so the || guard actually observes python3's exit status:\n\nFLASHINFER_PKG_DIR=$(python3 -c "import importlib.util; print(importlib.util.find_spec('flashinfer').submodule_search_locations[0])") \\n || { echo "Could not locate the installed flashinfer package" >&2; exit 1; }\nSITE_PACKAGES=$(dirname "$FLASHINFER_PKG_DIR")\n\n\nSeverity rationale. This is a genuine error-handling defect, but not blocking: the trigger condition is nearly unreachable given the preceding guarded pip install, and even in the masked-failure case the script still fails fast via the next patch command's own guard rather than silently continuing to a wrong/successful outcome. It's a robustness/diagnostics-quality issue rather than a functional regression, so it should be fixed but doesn't need to block merge.

@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

2 similar comments
@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

wzhao18 and others added 2 commits July 23, 2026 02:11
- Bump all four fp4 vLLM images to nightly-4080263bb2c5d10deac17aaeb88e0823bc35bca9
- Remove VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm from B200/B200-mtp/B300-mtp scripts
- Add --attention_config.indexer_kv_dtype fp8 to B200 non-eagle config

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

@Ankur-singh

Copy link
Copy Markdown
Collaborator

/reuse-sweep-run 29984401390

@Ankur-singh

Ankur-singh commented Jul 23, 2026

Copy link
Copy Markdown
Collaborator

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. — https://github.com/SemiAnalysisAI/InferenceX/actions/runs/29984401390
  • Verified that this PR passes evals. Please link to GitHub Action workflow that shows this. — https://github.com/SemiAnalysisAI/InferenceX/actions/runs/29984401390
  • 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 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 any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.

Additional detail section:

  • Scope: image-tag update for the MiniMax-M3 NVFP4 vLLM family — minimaxm3-fp4-b200-vllm, minimaxm3-fp4-b200-vllm-mtp, minimaxm3-fp4-b300-vllm, minimaxm3-fp4-b300-vllm-mtp — all repinned to vllm/vllm-openai:nightly-4080263bb2c5d10deac17aaeb88e0823bc35bca9 (upstream vLLM repo; b200-vllm-mtp moves off the prior custom vllm-minimax-m3-perf-* tag onto the shared nightly). Also drops VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm from all four scripts.
  • Validation & evals: Run Sweep https://github.com/SemiAnalysisAI/InferenceX/actions/runs/29984401390 (head 0b896e92) is green top-level with non-skipped single-node 8k1k benchmark jobs and dedicated eval jobs passing for all four config keys; collect-evals/collect-results/compare-results all succeeded.
  • Chat template (spec decode): both MTP configs run EAGLE3 (Inferact/MiniMax-M3-EAGLE3) and pass --use-chat-template in run_benchmark_serving, so the AL distribution is aligned to real-world chat usage.
  • Indexer dtype: the two non-EAGLE configs add --attention_config.indexer_kv_dtype fp8. This lowers the precision of the indexer KV cache only — it does not skip the indexer or reduce model-architecture FLOPs — and the configs pass evals, so it is an allowed lower-precision optimization.
  • Recipe: MiniMax-M3 is documented upstream — published recipe: https://github.com/vllm-project/recipes/blob/main/models/MiniMaxAI/MiniMax-M3.yaml PR: Minimax M3 agg vllm-project/recipes#682
  • No engine patching: none of the four scripts patch the engine/serving stack; NVFP4 support (vllm-project/vllm #46380) is baked into the pinned image and runs as shipped.
  • Agentic item (unchecked): not applicable — these are single-node fixed-seq-len (8k1k) benchmarks, not agentic workloads; agentic/golden-AL jobs are correctly skipped in the sweep.

Signed: Ankur-singh

@Klaud-Cold

Copy link
Copy Markdown
Collaborator

❌❌❌ REJECTED ❌❌❌

@Ankur-singh — blocking: --attention_config.indexer_kv_dtype fp8 (added to the B200/B300 non-EAGLE scripts) is a precision/kv-cache-dtype arg that is absent from the published MiniMax-M3 recipe, and vLLM defaults the indexer K cache to bf16 — so the benchmarked number is not reproducible from upstream documentation. Document the flag upstream (e.g. an NVFP4 benchmark-reproduction note in the recipe, as its MXFP4 section already does) or drop it, then re-sign.

✅ Check 0 (CODEOWNER): PASS — Ankur-singh owns configs/nvidia-master.yaml; remaining paths are catch-all-owned and covered by a recognized CODEOWNER.
✅ Check 1 (sweep on in-PR commit): PASS — head 0b896e9 carries 88 executed single-node 8k1k / and 12 eval / check-runs, all success, from https://github.com/SemiAnalysisAI/InferenceX/actions/runs/29984401390.
✅ Check 2 (evals pass): PASS — 12/12 GSM8K scores 0.948–0.958 (bar 0.90, n_eff 1319) covering all four configs, run on this PR's image vllm/vllm-openai:nightly-4080263….
❌ Check 3 (recipe): FAIL — MAJOR arg --attention_config.indexer_kv_dtype fp8 (minimaxm3_fp4_b200.sh, minimaxm3_fp4_b300.sh) is missing from the published recipe (https://github.com/vllm-project/recipes/blob/main/models/MiniMaxAI/MiniMax-M3.yaml): the recipe documents only --kv-cache-dtype fp8, and the indexer cache is a separate field defaulting to bf16. All other major args match (model, TP/TEP/DEP strategies, --block-size 128, fp8 KV, --language-model-only, EAGLE3 Inferact/MiniMax-M3-EAGLE3 + FLASH_ATTN); harness knobs (--stream-interval, capture size, batched-tokens, tag pin) are expected InferenceX-specific diffs.
✅ Check 4 (reuse command): PASS — /reuse-sweep-run 29984401390 posted by Ankur-singh (COLLABORATOR).
✅ Check 5 (latest template): PASS — all current-template items present and checked; the agentic item is unchecked with a valid N/A explanation in the detail section.
✅ Check 6 (upstream images / engine-first): PASS — all four entries are framework: vllm on B200/B300 with upstream vllm/vllm-openai:nightly-4080263… (b200-vllm-mtp moves off the custom vllm-minimax-m3-perf-* tag); no new non-vLLM/SGLang frameworks.
✅ Check 7 (no arch hacks): PASS — the indexer fp8 knob is precision-only (indexer still executes, FLOPs unchanged, native vLLM option) and evals pass; no --hf-overrides or config edits.
✅ Check 8 (spec-decode chat template): PASS — both MTP scripts pass --use-chat-template to run_benchmark_serving.
✅ Check 9 (no engine patches): PASS — no patch/heredoc/monkey-patching; NVFP4 support (vllm-project/vllm#46380) ships in the pinned image; only client-side pip install datasets pandas.
➖ Check 10 (agentic golden AL): N/A — fixed-seq-len 8k1k configs only, no agentic spec-decode changes; no synthetic-acceptance knobs present on these non-agentic configs.

@faradawn

Copy link
Copy Markdown

recipe. vllm-project/recipes#682

@Ankur-singh Ankur-singh changed the title Update vllm Minimax M3 image tags Update vLLM MiniMax-M3 image tags / 更新 vLLM MiniMax-M3 镜像标签 Jul 27, 2026
@Ankur-singh

Copy link
Copy Markdown
Collaborator

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. — https://github.com/SemiAnalysisAI/InferenceX/actions/runs/29984401390
  • Verified that this PR passes evals. Please link to GitHub Action workflow that shows this. — https://github.com/SemiAnalysisAI/InferenceX/actions/runs/29984401390
  • 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 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 any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.

Additional detail section:

  • Scope: image-tag update for the MiniMax-M3 NVFP4 vLLM family — minimaxm3-fp4-b200-vllm, minimaxm3-fp4-b200-vllm-mtp, minimaxm3-fp4-b300-vllm, and minimaxm3-fp4-b300-vllm-mtp — all repinned to upstream image vllm/vllm-openai:nightly-4080263bb2c5d10deac17aaeb88e0823bc35bca9. The four launchers also remove VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm.
  • Validation and evals: Run Sweep 29984401390, attempt 1, passed at in-PR commit 0b896e92f975d0ef8e374fdc284b06444fc95242 with 88/88 executed single-node 8k1k benchmark jobs and 12/12 eval jobs successful. GSM8K scores were 0.9484–0.9575 against the 0.90 threshold (n_eff=1319). That commit remains an ancestor of current head d9924c6e8295cdb2f3d4e36b9612691446869e22; the four launcher blobs and relevant configuration blocks are unchanged.
  • Reuse authorization: /reuse-sweep-run 29984401390 was posted by authorized collaborator Ankur-singh: Update vLLM MiniMax-M3 image tags / 更新 vLLM MiniMax-M3 镜像标签 #2120 (comment)
  • Chat template: both EAGLE3 MTP configurations use Inferact/MiniMax-M3-EAGLE3 and pass --use-chat-template to run_benchmark_serving.
  • Indexer dtype: the two non-EAGLE launchers use --attention_config.indexer_kv_dtype fp8. This changes only indexer KV-cache precision; it does not skip indexer computation or reduce architecture FLOPs, and the configurations passed evals.
  • Recipe: vLLM recipes PR #682 is MERGED at commit 83ff28002d9ae0e0fc55331eb1d19bbcc38151c0. The published MiniMax-M3 recipe includes --attention_config.indexer_kv_dtype fp8 for the NVFP4 variant.
  • No engine patching: none of the four launchers patches or rewrites the engine or serving stack; the pinned upstream image runs as shipped.
  • Agentic item (unchecked): not applicable — these are single-node fixed-sequence 8k1k benchmarks, not agentic workloads.

Signed: Ankur-singh

中文:

  • 范围: 本 PR 将 B200/B300 上四个 MiniMax-M3 NVFP4 vLLM STP/MTP 配置统一更新至上游 nightly 镜像,并从四个启动脚本中移除 VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm
  • 扫描与评估: 扫描运行 29984401390 在本 PR 提交 0b896e92f975d0ef8e374fdc284b06444fc95242 上通过,88/88 个单节点 8k1k 基准测试任务及 12/12 个评估任务成功;GSM8K 得分为 0.9484–0.9575,高于 0.90 阈值。当前 head 中四个启动脚本及相关配置块保持不变。
  • 投机解码: 两个 EAGLE3 MTP 配置均使用 --use-chat-template
  • Indexer 精度: 两个非 EAGLE 配置仅将 indexer KV cache 精度降至 FP8,不会跳过计算或减少模型架构 FLOPs,并已通过评估。
  • 上游配方: vLLM recipes PR #682 已合并;发布的 MiniMax-M3 NVFP4 配方现已包含 --attention_config.indexer_kv_dtype fp8
  • 引擎完整性: 启动脚本未修补或重写推理引擎,固定的上游镜像按原样运行。
  • Agentic 条目(未勾选): 不适用;这些是单节点固定序列长度 8k1k 基准测试,并非 Agentic 工作负载。

@Klaud-Cold

Copy link
Copy Markdown
Collaborator

✅✅✅ Verdict: PASS ✅✅✅

✅ Check 0 (CODEOWNER): PASS — Ankur-singh is a named owner of configs/nvidia-master.yaml; remaining paths are catch-all-only.
✅ Check 1 (green sweep on in-PR commit): PASS — in-PR commit 0b896e92 has 88/88 executed single-node 8k1k / + 12/12 executed eval / check-runs, all success (run 29984401390).
✅ Check 2 (evals real & above bar): PASS — 12 GSM8K results, em_strict 0.9484–0.9575 vs 0.90 default bar (n_eff=1319), all run on this PR's image vllm/vllm-openai:nightly-4080263bb2c5d10deac17aaeb88e0823bc35bca9.
✅ Check 3 (recipe merged & args match): PASS — vllm-project/recipes#682 is MERGED (2026-07-28, commit 83ff2800); the MiniMax-M3 recipe NVFP4 variant covers --attention_config.indexer_kv_dtype fp8, --trust-remote-code, VLLM_FLOAT32_MATMUL_PRECISION=high, --block-size 128, fp8 KV cache, and EAGLE3 (Inferact/MiniMax-M3-EAGLE3, FLASH_ATTN). Remaining diffs (--max-num-batched-tokens, --stream-interval, --no-enable-prefix-caching, cudagraph size, gpu-mem-util) are InferenceX harness tuning — informational only.
✅ Check 4 (reuse command): PASS — /reuse-sweep-run 29984401390 posted by COLLABORATOR Ankur-singh.
✅ Check 5 (latest checklist): PASS — all current-template items present and checked; the agentic item is unchecked with an explicit N/A explanation in the detail section.
✅ Check 6 (upstream images / engine-first): PASS — all four entries are framework: vllm on B200/B300 with upstream vllm/vllm-openai:nightly-…; no non-vLLM/SGLang framework added.
✅ Check 7 (no architecture hacks): PASS — --attention_config.indexer_kv_dtype fp8 lowers indexer KV-cache precision only (recipe-documented, evals pass); no --hf-overrides or FLOPs reduction.
✅ Check 8 (spec-decode chat template): PASS — both EAGLE3 MTP scripts pass --use-chat-template to run_benchmark_serving.
✅ Check 9 (no engine patches): PASS — no patch files, heredoc rewrites, or engine wheel installs; pip install datasets pandas is client-side only.
➖ Check 10 (agentic golden AL): N/A — fixed-seq-len 8k1k benchmarks, no agentic speculative-decoding changes.

@wzhao18

wzhao18 commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator Author

@Ankur-singh What is the plan for merging this one?

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.

6 participants