[Klaud Cold] minimaxm3 H200/H100 MTP: start TP-only latency rows at conc 1

[functionstackx]

Summary

Follow-up to #1739 (6e8ebf56). Drops the conc-start of the TP-only (latency) rows from 4 → 1 for the two MiniMax-M3 EAGLE3 MTP configs, so the sweeps capture the single-request latency point — matching the conc-1 start already used on the non-MTP day-zero recipes.

• minimaxm3-fp8-h200-vllm-mtp: TP4 and TP8 (plain) rows in both 1k1k and 8k1k now start at conc 1.
• minimaxm3-fp8-h100-vllm-mtp: TP8 (plain) rows in both 1k1k and 8k1k now start at conc 1.

TEP (tp+ep) and DEP (tp+ep+dp-attn) rows keep their higher concurrency starts (128 / 256) — they only make sense at scale. Config/search-space change only; no script changes.

Validation

• generate_sweep_configs.py test-config --config-keys minimaxm3-fp8-h200-vllm-mtp minimaxm3-fp8-h100-vllm-mtp generates 54 configs; min concurrency per layout confirms TP-only rows now start at 1 (h100 tp8 / h200 tp4 / h200 tp8 → 1), TEP/DEP unchanged (128 / 256).
• perf-changelog entry added so the changelog-driven sweep picks up both keys.

🤖 Generated with Claude Code

---

Note

Low Risk
Benchmark search-space tuning only in YAML; no runtime, auth, or application logic changes.

Overview
Aligns MiniMax-M3 EAGLE3 MTP benchmark sweeps on H200 and H100 with the non-MTP day-zero recipes by lowering conc-start from 4 to 1 on TP-only (latency) search-space rows in both 1k1k and 8k1k scenarios for minimaxm3-fp8-h200-vllm-mtp (TP4/TP8 plain) and minimaxm3-fp8-h100-vllm-mtp (TP8 plain).

TEP (tp+ep) and DEP (tp+ep+dp-attn) rows keep their existing higher concurrency starts (128/256). Adds a perf-changelog.yaml entry for the two config keys so changelog-driven sweeps pick up the change.

^{Reviewed by Cursor Bugbot for commit c8615e8. 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=27475833404
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=27475833404

[github-actions]

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

[github-actions]

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

[functionstackx]

/reuse-sweep-run