[Klaud Cold] MI300X MiniMax-M3 nightly image and FP8 KV cache

[cquil11]

What changed

• pin minimaxm3-fp8-mi300x-vllm to vllm/vllm-openai-rocm:nightly-b53b1c7ffe7aebdafd0876350f30e51d1226c92a
• launch the MI300X MiniMax-M3 server with --kv-cache-dtype fp8
• exclude unprovisioned chi-mi300x-121 from Slurm allocation
• append an MI300X-only performance changelog entry

Why

Use the updated ROCm vLLM build and reduce KV-cache memory use for the MI300X MiniMax-M3 sweep. The node exclusion prevents Pyxis failures on a node missing required Enroot/RAID provisioning.

Validation

• Bash syntax validation
• targeted MI300X MiniMax-M3 full-sweep config generation

---

Note

Medium Risk
FP8 KV cache shifts memory/accuracy behavior for a recipe that previously documented BF16 KV to avoid bad FP8 attention scales; the nightly image pin also changes the serving stack for benchmark comparability.

Overview
Updates the MI300X MiniMax-M3 MXFP8 vLLM benchmark to a pinned ROCm nightly (vllm/vllm-openai-rocm:nightly-b53b1c7…) and turns on --kv-cache-dtype fp8 in minimaxm3_fp8_mi300x.sh, replacing the prior BF16 KV default that avoided uncalibrated ROCm FP8 attention scales.

Slurm allocation for MI300X now also excludes chi-mi300x-121 (missing Enroot/RAID provisioning), alongside the existing bad-node list. Config comments and perf-changelog.yaml document the image, KV, and node changes for minimaxm3-fp8-mi300x-vllm.

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

[cquil11]

/reuse-sweep-run

[github-actions]

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

[github-actions]

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

[cquil11]

/reuse-sweep-run