Skip to content

[AMD] Add MiniMax-M3-FP4 MI355X ATOM EAGLE3 / non-EAGLE3 update 0623#1917

Open
seungrokj wants to merge 12 commits into
mainfrom
amd/m3_atom_single_fp4_0623
Open

[AMD] Add MiniMax-M3-FP4 MI355X ATOM EAGLE3 / non-EAGLE3 update 0623#1917
seungrokj wants to merge 12 commits into
mainfrom
amd/m3_atom_single_fp4_0623

Conversation

@seungrokj

@seungrokj seungrokj commented Jun 24, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Add minimaxm3-fp4-mi355x-atom-mtp benchmark script (benchmarks/single_node/fixed_seq_len/minimaxm3_fp4_mi355x_atom_mtp.sh) for MiniMax-M3 MXFP4 on MI355X using ATOM with EAGLE3 speculative decoding
  • Bump minimaxm3_fp4_mi355x_atom.sh image to rocm/atom-dev:MiniMax-M3-20260623
  • Add minimaxm3-fp4-mi355x-atom-mtp recipe to amd-master.yaml (TP2/TP4, ISL=1024/8192, OSL=1024, conc 1–256)
  • Add perf-changelog entry

PR Review Checklist

  • Verified that as of the moment of typing this, this is the latest version of PR_REVIEW_CHECKLIST.md
  • Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
  • Verified that this PR has passed PR validation. Please link to GitHub Action workflow that shows this.
  • Verified that this PR passes evals. Please link to GitHub Action workflow that shows this.
  • Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
  • If a company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
  • Verified that the single-node recipes are similar to the official vLLM recipes and/or the SGLang cookbook:
    • If they are not, I have verified that a PR has been opened in vLLM recipe repo or SGLang repo and linked it below in the additional detail section:
  • If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.

Additional Details

Note on ATOM framework: MiniMax-M3 MXFP4 on MI355X is submitted here via ATOM in addition to the existing vLLM recipe (minimaxm3-fp8-mi355x-vllm). The vLLM submission was made first.

🤖 Generated with Claude Code

seungrokj and others added 6 commits June 24, 2026 16:29
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…60623

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

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

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

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.


感谢你的贡献!对于 vLLM 与 SGLang,请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致

如果不一致,请先创建一个 PR,之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准,使整个 ML 社区都能从你的辛勤工作中受益!谢谢

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。如果选择重新运行失败的任务,PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档:https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

一般而言,PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准,然后再请求核心维护者审阅。

如需更多帮助,PR 作者可通过 Slack 联系核心维护者。

@seungrokj seungrokj changed the title [AMD] Add MiniMax-M3 FP4 MI355X ATOM MTP single-node benchmark [AMD] Add MiniMax-M3-FP4 MI355X ATOM EAGLE3 / non-EAGLE3 update 0623 Jun 24, 2026
@seungrokj seungrokj added the AMD label Jun 24, 2026
seungrokj and others added 6 commits June 24, 2026 17:24
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… fp8 PR)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…o fp8 PR)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…longs to fp8 PR)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ecoding

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional findings (outside current diff — PR may have been updated during review):

  • 🟡 perf-changelog.yaml:4019 — Nit: the new fp8 atom changelog entry (lines 4013-4019) sets pr-link: .../pull/1929, while the sibling fp4 entry added in the same diff hunk points to /pull/1917 (this PR). If this PR was meant to be stacked on a base PR #1929 that introduces the fp8 atom recipe, that intent isn't reflected in the PR title (FP4-only) or description Summary — consider either updating the description to mention the stack on #1929, or changing the pr-link to 1917 so changelog → PR traceability stays intact.

    Extended reasoning...

    What the entry says vs. what this PR ships

    The PR diff adds two new changelog entries to perf-changelog.yaml. The fp4 entry (lines 3987-3994, around perf-changelog.yaml:3987) correctly attributes itself to this PR:

    - config-keys:
        - minimaxm3-fp4-mi355x-atom
        - minimaxm3-fp4-mi355x-atom-mtp
      ...
      pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1917

    The fp8 entry added just below (lines 4013-4019, around perf-changelog.yaml:4019) points elsewhere:

    - config-keys:
        - minimaxm3-fp8-mi355x-atom
        - minimaxm3-fp8-mi355x-atom-mtp
      description:
        - "Add minimaxm3-fp8-mi355x-atom: MiniMax-M3 MXFP8 single-node benchmark on MI355X using ATOM framework"
        - "Uses rocm/atom-dev:MiniMax-M3-20260623; TP4, block size 128, ISL=1024,8192 OSL=1024"
      pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/1929

    The diff for this PR contains exactly the changes described in that fp8 entry: a brand-new yaml block for minimaxm3-fp8-mi355x-atom in amd-master.yaml, the new file benchmarks/single_node/fixed_seq_len/minimaxm3_fp8_mi355x_atom.sh (added from /dev/null), and the image bump for minimaxm3-fp8-mi355x-atom-mtp to rocm/atom-dev:MiniMax-M3-20260623.

    Step-by-step proof

    1. Search the PR diff for files added from /dev/nullminimaxm3_fp8_mi355x_atom.sh is created here, not pre-existing.
    2. Look at amd-master.yaml in the diff context: the new minimaxm3-fp8-mi355x-atom yaml block is added inline (between the modified fp4 atom block and the existing fp8 atom-mtp block).
    3. The sibling fp4 entry (added immediately above the fp8 entry in the same hunk of perf-changelog.yaml) uses pr-link: .../pull/1917 — confirming that the author did know the PR number when writing the fp4 entry.
    4. The fp8 entry uses pr-link: .../pull/1929, which is a different number from 1917.
    5. Anyone consulting this changelog entry to find what introduced minimaxm3-fp8-mi355x-atom will be redirected to a different PR — or to a 404 if #1929 doesn't exist.

    Addressing the stacked-PR refutation

    One verifier proposed this is a stacked PR where #1917 sits on top of base PR #1929 (FP8 atom). The git log ordering does match that hypothesis: 03f5752/a245590/25b8fab (fp8 work) precede 0e1a9e4/c3d8c1f (fp4 work) on this branch. If true, the pr-link of 1929 would be intentional and the diff of #1917 would simply inherit base-PR changes.

    However, the PR doesn't carry the usual signals of a stack: the PR title is "Add MiniMax-M3 FP4 MI355X ATOM MTP single-node benchmark" (FP4-only), and the Summary bullets in the description enumerate only fp4 changes — no mention of #1929 or a stack relationship. Without that explicit signal, a maintainer or future reader cannot distinguish "stacked PR with intentional cross-link" from "transcription typo". Either is plausible.

    Impact and fix

    This is metadata-only — it doesn't affect benchmark execution or runtime behavior. The pr-link is the documented mechanism for changelog → source-PR traceability, so getting it wrong defeats that purpose. The fix is one of:

    • If a stack on #1929 was intended: update the PR description to declare the base and add a Stacked on #1929 note so the cross-link reads correctly.
    • If it was a typo: change 19291917 on perf-changelog.yaml:4019 so the fp8 entry matches the sibling fp4 entry and the actual PR adding the recipe.

Comment thread benchmarks/single_node/fixed_seq_len/minimaxm3_fp4_mi355x_atom.sh Outdated
@github-actions

Copy link
Copy Markdown
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant