Add MiniMax-M3 modelopt nvfp4 support

[jasonlizhengjian]

Summary

Ports #46380 from minimax-m3-perf onto current main.

The original PR was merged into minimax-m3-perf, but current main was still missing the relevant support points when checked locally: ModelOpt mixed MXFP8 dispatch, the parent-prefix fallback for fused projections, and the NVFP4 MoE SwiGLU-OAI alpha/beta/clamp wiring.

Changes

• Add ModelOpt mixed-precision MXFP8 Linear and RoutedExperts dispatch.
• Add fallback resolution for fused projection prefixes such as qkv_proj and gate_up_proj.
• Pass per-expert gemm1_alpha, gemm1_beta, and gemm1_clamp_limit into FlashInfer TRTLLM NVFP4 MoE kernels, including moe_config.swiglu_* fallback.
• Map both SwiGLU-OAI activation variants to FlashInfer Swiglu.

Validation

• uvx --from pre-commit>=4.5.1 pre-commit run --files vllm/model_executor/layers/fused_moe/experts/trtllm_nvfp4_moe.py vllm/model_executor/layers/quantization/modelopt.py vllm/model_executor/layers/quantization/utils/flashinfer_utils.py

Tested with and without the patch:

vllm serve nvidia/MiniMax-M3-NVFP4 \
    --served-model-name nvidia/MiniMax-M3-NVFP4 \
    --tensor-parallel-size 4 \
    --host 0.0.0.0 \
    --port 8040 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 10240 \
    --block-size 128 \
    --max-num-batched-tokens 16384 \
    --stream-interval 20 \
    --no-enable-prefix-caching \
    --language-model-only \
    --trust-remote-code \
    --enforce-eager

Without patch outputs are garbage.
With patch, outputs are normal.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[xinli-sw]

@jasonlizhengjian please attach vllm serve command and effect of PR (with / w/o behavior), thanks!!

[mgoin]

LGTM just some nits

[mgoin]

Does this behavior work for all the trtllm backends? I see we use this utility in trtllm_bf16_moe.py, trtllm_fp8_moe.py, and trtllm_nvfp4_moe.py
It is probably fine for now if we don't advertise support for those in _supports_activation

[xinli-sw]

good point, I'll check in parallel

[mgoin]

Is this debug cruft we can remove? Maybe it could be demoted to debug_once

[mergify]

Hi @jasonlizhengjian, the pre-commit checks have failed. Please run:

uv pip install pre-commit>=4.5.1
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

[mgoin]

Do you need add SWIGLUOAI in this PR? I think for M3 we only need to add SWIGLUOAI_UNINTERLEAVE and it would just reduce the potential untested cases

[xinli-sw]

true, probably got carried over from https://github.com/vllm-project/vllm/tree/minimax-m3-perf branch. cc @jasonlizhengjian

[jasonlizhengjian]

ok I will test without

[jasonlizhengjian]

removed

[mgoin]

@jasonlizhengjian Looks like some failures are related, PTAL

For instance

[2026-06-25T20:08:01Z] FAILED quantization/test_modelopt.py::test_modelopt_mixed_precision_quantizes_parallel_lm_head - TypeError: ModelOptMixedPrecisionConfig.__init__() missing 1 required positional argument: 'mxfp8_config'

[jasonlizhengjian]

@mgoin remaining failures should not be related

[mgoin]

Confirmed unrelated failures

[eugr]

@jasonlizhengjian - this PR breaks modelOpt mixed precision checkpoints such as nvidia/Qwen3.6-35B-A3B-NVFP4 and nvidia/Nemotron-3-Super-120B-A10B-NVFP4 on DGX Spark, possibly on other hardware too.

The regression was detected by my nightly CI pipeline:

• Good vLLM ref (previous nightly run): a4e3cb40
• Bad vLLM ref (this nightly run): 8e9d70fd

I traced the regression to the following commit: debec6440 from this PR

With today nightly build, simple queries with temperature=0 and chat_template_kwargs={"enable_thinking": false} produce only exclamation marks for nvidia/Qwen3.6-35B-A3B-NVFP4 checkpoint:

• What is the capital of France? Respond with one word. -> !!!!!!!!!!!!!!!!!!!!!!!!
• What is 2+2? Respond with one number. -> !!!!!!!!!!!!!!!!!!!!!!!!

The same recipe on the previous nightly returns Paris and 4.

I then reverted only debec6440 inside the 20260630 container and restarted the same recipe. Output recovered to Paris and 4.

Similar situation with Nemotron-3-Super.

This also regresses on 20260630, producing <unk> / repetitive garbage for the same simple France query. Reverting debec6440 fixes the underlying bad generation behavior there as well.

Likely mechanism (as suggested by Codex, haven't looked into the PR in more detail myself): this PR makes modelopt_mixed actively dispatch MXFP8 layers via ModelOptMxFp8LinearMethod / ModelOptMxFp8FusedMoE, and adds parent-prefix fallback for fused projections. It looks like some existing mixed ModelOpt NVFP4 checkpoints now route a layer or fused projection through an incompatible MXFP8 path, causing numerically corrupted logits without a shape/dtype crash.

@mgoin - FYI.