[Klaud Cold] minimaxm3 H100/H200 non-MTP: conc-1 latency + full TEP coverage (1-256)

[functionstackx]

Summary

Extends the MiniMax-M3 MXFP8 H100 and H200 non-MTP sweeps to concurrency 1 on the latency rows and adds full TEP coverage from conc 1 to 256.

H100 (minimaxm3-fp8-h100-vllm):

• TP8 latency rows (1k1k + 8k1k) now start at conc 1.
• TP8+EP8 (TEP8) now sweeps conc 1→256 (was 256-256 / 128-256).

H200 (minimaxm3-fp8-h200-vllm):

• TP4 and TP8 latency rows (1k1k + 8k1k) now start at conc 1.
• TP4+EP4 (TEP4) and TP8+EP8 (TEP8) now sweep conc 1→256, including a new TEP4 row added to 8k1k (which previously had none).
• TP8+EP8 dp-attn (DEP) rows are unchanged (256→1024 / 256→512), so high concurrency stays covered.

Note: H200 1k1k TEP8 upper bound moves 512 → 256 to make the TEP rows uniformly 1-256 as requested; conc 512 remains covered by the DEP (dp-attn) row. Say the word if you'd rather keep TEP8 at 1-512.

Config/search-space change only; no script changes.

Validation

• generate_sweep_configs.py test-config → 103 configs; per-layout ranges confirm latency rows start at conc 1 and TEP4/TEP8 span 1-256; DEP rows unchanged.

🤖 Generated with Claude Code

---

Note

Low Risk
YAML-only benchmark sweep range changes; no application logic, auth, or data paths.

Overview
Benchmark sweep search-space updates for MiniMax-M3 MXFP8 on H100 and H200 (minimaxm3-fp8-h100-vllm, minimaxm3-fp8-h200-vllm); no runtime or script changes.

Latency (TP-only) rows now start at concurrency 1 instead of 4 (H100: TP8 on 1k1k and 8k1k; H200: TP4 and TP8 on both sequence lengths).

TEP rows sweep 1→256 end-to-end: H100 TP8+EP8; H200 TP4+EP4 and TP8+EP8, including a new TP4+EP4 row for 8k1k where TEP4 was missing. On H200 1k1k, TP8+EP8 upper bound is 512→256 so TEP aligns with 1–256; dp-attn DEP rows are unchanged and still cover higher concurrency.

perf-changelog.yaml documents the same scope for PR #1761.

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

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

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. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[github-actions]

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

[github-actions]

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

[functionstackx]

/reuse-sweep-run

[github-actions]

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