[DO NOT MERGE][Klaud Cold][TEST] minimaxm3 MI355X: CUDA graphs WITHOUT VLLM_USE_BREAKABLE_CUDAGRAPH=0 (control)

[functionstackx]

Summary — control experiment (not for merge)

Removes --enforce-eager from the MiniMax-M3 MXFP8 MI355X non-MTP recipe (minimaxm3_fp8_mi355x.sh) so it runs with CUDA graphs, but deliberately does NOT set VLLM_USE_BREAKABLE_CUDAGRAPH=0.

Matched control for #1755 (which removes --enforce-eager and sets VLLM_USE_BREAKABLE_CUDAGRAPH=0). Goal: confirm whether the env var is what actually makes CUDA graphs work for MiniMax-M3 on AMD — i.e., does dropping eager alone fail/regress?

• Only script change: the --enforce-eager line is removed. No env var added.
• perf-changelog entry added (minimaxm3-fp8-mi355x-vllm) so the sweep runs.

Expected: if the breakable-cudagraph env var is required, this sweep fails (M3 breakable-cudagraph path at engine init / decode), whereas #1755 passes.

This is a test/control PR and is not intended to merge.

🤖 Generated with Claude Code

---

Note

Low Risk
Benchmark-only control change on a test PR; no production paths or auth/data handling affected.

Overview
Control sweep (not for merge) for MiniMax-M3 MXFP8 on MI355X: the non-MTP vLLM recipe drops --enforce-eager so serving can use CUDA graphs, but does not set VLLM_USE_BREAKABLE_CUDAGRAPH=0.

That pairs with #1755 (same eager removal plus the env var) and #1750 (MI300X uses the env var). The goal is to see whether MI355X needs the breakable-cudagraph disable for stable graphs, or if turning off eager alone is enough.

A perf-changelog.yaml entry for minimaxm3-fp8-mi355x-vllm documents the experiment so the matrix re-runs this variant.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 062cd30. Configure here.}

[github-actions]

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

[github-actions]

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