[NV] Update MiniMax-M3 B200 MTP, B300, and B300 MTP vLLM serving settings

[xinli-sw]

Summary

Extends the B200 fixes from #1779 to the three remaining MiniMax-M3 Blackwell variants:

• minimaxm3_fp8_b200_mtp.sh / minimaxm3_fp8_b300.sh / minimaxm3_fp8_b300_mtp.sh: set VLLM_FLOAT32_MATMUL_PRECISION=high; replace dynamic CAPTURE_SIZE computation with hardcoded --max-cudagraph-capture-size 2048
• nvidia-master.yaml — add TP4+EP4 coverage to three config keys:
  • minimaxm3-fp8-b300-vllm: add tp4ep4 dp-attn for 1k1k; add tp4ep4 and tp4ep4 dp-attn for 8k1k
  • minimaxm3-fp8-b200-vllm-mtp: same additions (concs trimmed at high end per MTP convention)
  • minimaxm3-fp8-b300-vllm-mtp: same additions as B200 MTP

Test plan

• CI sweep on minimaxm3-fp8-b200-vllm-mtp
• CI sweep on minimaxm3-fp8-b300-vllm
• CI sweep on minimaxm3-fp8-b300-vllm-mtp

Generated with Claude Code

---

Note

Low Risk
Benchmark and CI sweep configuration only; no application runtime or security-sensitive code paths.

Overview
Brings MiniMax-M3 B200 MTP, B300, and B300 MTP vLLM fixed-seq-len serving in line with the B200 changes from #1779.

The three benchmark launch scripts now export VLLM_FLOAT32_MATMUL_PRECISION=high and pass a fixed --max-cudagraph-capture-size 2048 instead of computing capture size from concurrency (and spec-token count on MTP).

nvidia-master.yaml gains TP4+EP4 sweep rows for minimaxm3-fp8-b300-vllm, minimaxm3-fp8-b200-vllm-mtp, and minimaxm3-fp8-b300-vllm-mtp: DP-attention at 1k1k, plus non-DP and DP-attention at 8k1k (with MTP-appropriate concurrency caps). perf-changelog.yaml records the same for those config keys.

^{Reviewed by Cursor Bugbot for commit bb0bca9. 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]

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=27593402054
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=27593402054

[xinli-sw]

duplicate of #1784 #1781

[xinli-sw]

closed as duplicate