vLLM offre un support Day-0 pour MiniMax-M3.1-Flash

MiniMax-M3.1-Flash est le dernier modèle de la famille MiniMax-M3, avec des améliorations dans les tâches de raisonnement, de codage, agentiques et visuelles. Il est également conçu pour l'efficacité de l'inférence, avec un cache KV natif NVFP4, des poids MoE quantifiés en NVFP4 et un modèle de brouillon DSpark pour le décodage spéculatif.

vLLM prend en charge MiniMax-M3.1-Flash dès le jour 0 sur les GPU NVIDIA Blackwell, sur les GPU NVIDIA Rubin avec des kernels dédiés Rubin, et sur les GPU AMD de la série MI350, avec de fortes performances sur les charges de travail agentiques.

TL;DR

• MiniMax Sparse Attention (MSA) avec un cache KV NVFP4 à la fois pour l'indexeur et le chemin d'attention, plus des poids MoE NVFP4 et un générateur de brouillon DSpark .
• Les kernels MSA Blackwell utilisent la nouvelle instruction CUDA 13.4 QMUL4 pour déquantiser NVFP4 en FP8 à l'intérieur du kernel : jusqu'à 1.7× plus rapide pour le décodage QK de l'indexeur et 1.3× plus rapide pour le décodage de l'attention creuse.
• NVFP4 MegaMoE avec fusion MXFP8 de l'expert partagé et libération anticipée de TMEM : latence de kernel réduite de 20% en préremplissage et débit de préremplissage supérieur de 7%.
• Parallélisme de contexte de décodage de l'indexeur (DCP): jusqu'à 3.3× plus rapide pour l'indexeur par couche creuse à un contexte de 512K sur 4× GB300.
• Fusion QKV GEMM + norm + RoPE + insertion KV: 1.1–1.6× plus rapide préremplissage à 512 tokens ou plus et environ TTFT P50 inférieur de 19 % au TP4.
• FlashInfer PrimiTS backend pour l’attention du rédacteur DSpark : 1,3 à 2× plus rapide que FlashAttention 4, 5 % plus bas temps total en avant.
• Kernels MSA Rubin (SM107) sont également intégrés dans vLLM avec des performances de pointe.
• AMD série MI350: le noyau MSA natif NVFP4, le parallélisme de contexte de décodage de l'indexeur, le dual-batch overlap et le mono kernel offrent un 2–3× gain de performance sur toute la ligne.
• Service agentique: sur NVIDIA GB300, jusqu'à 418.9 tok/s par utilisateur à l'extrémité sensible à la latence ; sur NVIDIA Rubin, jusqu'à 724.9 tok/s par utilisateur et 191.5K tok/s au total par GPU; sur AMD MI355X, jusqu'à 133.3M tokens au total par dollar de TCO sur le benchmark SemiAnalysis AgentX.
• Support RL Day-0: RL de bout en bout avec veRL, FSDP2 et LoRA sur le checkpoint NVFP4.

Démarrage rapide

Des images préconstruites sont disponibles pour les deux fournisseurs :

• NVIDIA : vllm/vllm-openai:minimax-m31-flash
• AMD : vllm/vllm-openai-rocm:minimax-m31-flash

Notez que le modèle ne sera disponible dans la wheel PyPI nightly qu'une fois le code examiné et fusionné en amont, ce qui prend généralement environ une semaine. Les recettes complètes se trouvent sur vLLM Recipes, et le checkpoint se trouve à MiniMaxAI/MiniMax-M3.1-Flash.

TP4 sur NVIDIA

Nous recommandons le toolkit CUDA 13.4 pour de meilleures performances.

vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
  -tp 4 \
  --reasoning-parser minimax_m3 \
  --block-size 128 \
  --kv-cache-dtype nvfp4 \
  --attention-config '{"indexer_kv_dtype": "nvfp4"}' \
  --speculative-config '{"method":"dspark","num_speculative_tokens":7,"attention_backend":"FLASHINFER_TS","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
  --disable-hybrid-kv-cache-manager

TP4 sur AMD

vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
  -tp 4 \
  --reasoning-parser minimax_m3 \
  --block-size 128 \
  --kv-cache-dtype nvfp4 \
  --attention-config '{"indexer_kv_dtype": "nvfp4", "indexer_decode_cp": true}' \
  --quantization-config.moe mxfp8 \
  --speculative-config '{"method":"dspark","num_speculative_tokens":3,"attention_backend":"TRITON_ATTN","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
  --disable-hybrid-kv-cache-manager

Guide MSA

La famille de modèles MiniMax-M3 remplace l'attention complète par une variante d'attention creuse par blocs (arXiv 2606.13392) pour rendre l'inférence plus efficace. Le cache KV est divisé en blocs de 128 tokens. Un indexeur léger attribue un score à chaque clé du contexte avec une requête d'index par groupe GQA contre une seule tête de clé d'index partagée, puis effectue un max-pooling de ces scores en un score par bloc. L'attention principale s'exécute alors exactement, mais uniquement sur les 16 blocs les mieux notés, et le bloc le plus récent est toujours conservé. Cela limite chaque requête à 2,048 clés, quelle que soit la longueur du contexte.

Le gain est le plus important en décodage, qui est limité par la bande passante mémoire. Chaque étape balaie toujours les clés d'index pour l'ensemble du contexte, mais cela ne représente que 128 octets par token par couche, soit un huitième des 1,024 octets de K/V que l'attention dense lirait (FP8, 4 têtes KV × 128 dimensions). Le K/V complet n'est ensuite lu que pour les 2,048 tokens sélectionnés. En décodage sur long contexte, le trafic HBM par étape tombe à environ 12.5% de ce que l'attention dense lit.

Figure 1 : MiniMax Sparse Attention. L'indexeur de chaque groupe GQA sélectionne ses meilleurs blocs KV, et chaque tête de requête de ce groupe assiste exactement sur ces seuls blocs. Parcourez-le pas à pas.

Nouveautés de l'architecture MiniMax-M3.1

MiniMax-M3.1 améliore considérablement l'efficacité d'inférence par rapport à la génération précédente : il a été entraîné nativement en tenant compte de la quantization pour un cache KV NVFP4, et ses poids MoE routés sont stockés en NVFP4. Les experts NVFP4 réduisent le checkpoint de 451.5 GB (MiniMax-M3-MXFP8) à 250.1 GB, soit 44.6% de moins. Le cache KV NVFP4 nécessite 34,560 octets par token au lieu de 61,440 octets en FP8, une économie de 43.75% par token. Au total, sur quatre GPU NVIDIA B300 avec un déploiement DEP4 et des séquences de 256K tokens, M3.1 accueille 76 séquences concurrentes là où M3 avec un cache KV FP8 en accueille 28, soit environ 2.7× plus sur le même matériel, ce qui augmente directement le débit de service.

Figure 2 : MiniMax-M3.1 est entraîné en tenant compte de la quantization pour utiliser un cache KV NVFP4 à la fois pour l'indexeur et pour l'attention creuse. Modifiez le dtype du cache KV, le parallélisme, le GPU ou la longueur de contexte pour voir combien de séquences peuvent être accueillies.

Optimisations de performance

vLLM offre de fortes performances MiniMax-M3.1 sur plusieurs plateformes matérielles. Sur les GPU NVIDIA, nous livrons des noyaux optimisés pour le cache KV NVFP4. Notre dépôt MSA (vllm-project/MSA) contient des noyaux optimisés pour différents workloads et opérations. Cela inclut le prefill et le decode de l'indexeur MSA, le prefill et le decode de l'attention clairsemée, et un noyau top-k spécifique à MSA.

Figure 3 : une couche de décodeur clairsemé de MiniMax-M3.1 sur Blackwell en decode (M ≤ 32), noyau par noyau. Les badges numérotés marquent les optimisations de cet article ; cliquez-en un pour mettre en évidence ses noyaux.

Noyaux MSA optimisés pour NVIDIA Blackwell

Le cache KV est stocké en NVFP4 tandis que la query reste en FP8, nous ne pouvons donc pas utiliser les instructions natives des tensor cores NVFP4 pour la multiplication matricielle. À la place, le noyau déquantise le cache KV NVFP4 en FP8 et exécute une MMA FP8. Pour maintenir un faible coût de déquantisation, nous utilisons une nouvelle instruction PTX spécifique à Blackwell introduite dans CUDA 13.4, mul.e4m3x4.e2m1x4.e4m3x4 (SASS QMUL4). Elle met à l'échelle quatre valeurs NVFP4 par leur facteur d'échelle et produit quatre valeurs FP8 en une seule instruction. Cela nécessite bien moins d'instructions CUDA core que le précédent chemin aller-retour FP16. Le résultat est un accélération allant jusqu'à 1,7× sur le noyau de decode QK de l'indexeur et de 1,3× sur le noyau de decode de l'attention clairsemée.

NVFP4 MegaMoE

MegaMoE est un élément clé des déploiements modernes en parallélisme d'experts (EP). Nous avons étendu le MegaMoE de DeepGEMM à la précision NVFP4 avec des experts partagés fusionnés MXFP8, open sourcés dans notre fork (vllm-project/DeepGEMM). Ajouter le support NVFP4 à MegaMoE est plus qu'un simple changement de dtype. Le NVFP4 réduit de moitié les octets par élément et double le débit des tensor cores par rapport au précédent chemin FP8×FP4. Le reste du noyau doit aussi changer, sinon le pipeline se déséquilibre.

Un de ces changements est la libération anticipée de l'étape TMEM dans l'épilogue FC1. Auparavant, l'étape TMEM n'était libérée qu'après la fin de l'épilogue. Cette attente est inutile car l'épilogue s'exécute entièrement dans les registres. TMEM peut être libérée dès que l'accumulateur a été chargé dans les registres, avant tout calcul. Cela réduit la latence totale du noyau de 20% en prefill, où le calcul NVFP4 plus rapide compte le plus. Cela augmente aussi le débit global de prefill de 7%.

NVFP4 indexer DCP (parallelisme du contexte de decode)

En service à faible latence, chaque GPU évalue sa propre tête d'index sur le contexte complet. Sur les quatre GPU, cela signifie que chaque couche d'indexeur lit le cache d'index complet quatre fois. L'indexeur DCP divise le travail par contexte à la place. Chaque GPU évalue les quatre têtes sur un quart des pages. Il envoie ensuite son top-16 local pour chaque tête via NVLink au GPU qui possède cette tête, lequel fusionne les candidats en le top-16 final. La sélection reste exacte, et l'indexeur s'exécute jusqu'à 3,3× plus vite par couche clairsemée à un contexte de 512K sur 4× GPU NVIDIA GB300.

Fusion QKV GEMM + norm + RoPE + insertion KV

Les projections QKV et d'indexeur de MiniMax-M3.1 écrivaient auparavant le tenseur QKV complet en HBM. Un second noyau le relisait ensuite pour la norme, RoPE et l'insertion dans le cache KV. Nous avons fusionné toute la chaîne en un seul noyau GEMM dont l'épilogue traite l'accumulateur FP32 tête par tête. Il applique la norme et RoPE à la query et à la query d'index. Il quantise aussi K, V et la clé d'index en NVFP4 et les écrit directement dans leurs caches. Le tenseur QKV ne touche jamais la HBM. Sur GB300, les batchs de prefill de 512 tokens ou plus s'exécutent 1,1 à 1,6× plus vite, et le P50 du time-to-first-token (TTFT) baisse d'environ 19% en TP4.

FlashInfer PrimiTS pour le drafter DSpark

MiniMax-M3.1 utilise DSpark comme drafter de décodage spéculatif, qui exécute du GQA non causel avec une fenêtre glissante de 4096 tokens. Auparavant, vLLM exécutait le drafter sur FlashAttention 4, qui n'est pas optimisé pour les formes de decode. Nous l'avons basculé sur le backend PrimiTS de FlashInfer. PrimiTS est 1,3 à 2× plus rapide que FlashAttention 4 et réduit le temps global de forward de 5%.

Benchmark de workload agentique sur NVIDIA GB300

vLLM offre de fortes performances sur les workloads de service agentiques. Nous évaluons notre image day-0 sur NVIDIA GB300 avec le benchmark SemiAnalysis AgentX (détaillé dans notre article précédent). À l'extrémité sensible à la latence de la frontière, MiniMax-M3.1-Flash maintient 418.9 tokens par seconde par utilisateur. Plus loin sur la frontière, il garde chaque utilisateur au-dessus de 200 tokens par seconde tout en servant 38.6K tokens au total par seconde par GPU. À l'extrémité débit, il atteint 153.8K tokens par seconde par GPU, soit environ 24× le point le plus interactif, tandis que chaque utilisateur voit encore environ 127 tokens par seconde.

Figure 4 : frontière de Pareto AgentX pour MiniMax-M3.1-Flash sur NVIDIA GB300, avec 7 tokens spéculatifs et des longueurs d'acceptation synthétiques de 3.16 à 3.26 tokens (premier token inclus). Survolez un point pour voir ses métriques.

MSA optimisé pour NVIDIA Rubin

Nous avons aussi optimisé ce modèle sur les GPU NVIDIA Rubin. Pour atténuer le coût de conversion NVFP4 vers FP8, nous convertissons le NVFP4 directement en FP16 et exécutons la MMA de score en FP16 pour l'indexeur. Cela réduit les instructions de déquantisation d'environ un tiers, et les scores deviennent exacts plutôt que de porter le re-arrondi E4M3 nécessaire pour exécuter une MMA FP8.

Avec ≤4 queries, le noyau de decode de l'indexeur à une tête va plus loin : il applique chaque échelle de bloc une fois par résultat de MMA avec le packed de SM107, fma.rn.f32x2.f16x2au lieu d'une fois par valeur K. Cela permet aussi de mieux masquer la latence en exécutant trois CTAs par SM. La mémoire partagée plus grande de Rubin (328 KB contre 228 KB sur Blackwell) et ses colonnes de Tensor Memory supplémentaires (576 contre 512 sur Blackwell) le rendent possible.

Enfin, comme Rubin possède plus de SMs que Blackwell, les planificateurs de travail dimensionnent leurs tuiles à partir du nombre de SMs, si bien que le travail est réparti uniformément sur les 212 SMs de Rubin.

L'attention creuse en préremplissage (prefill) bénéficie également des optimisations de domaine de localité. Nous allouons les buffers partiels via l'API de mémoire virtuelle CUDA afin que les pages de 2 MB alternent entre les deux domaines, et le kernel combiné remet chaque tuile à un CTA dont le SM se trouve dans le domaine qui contient les données de cette tuile. Sur Rubin, les kernels d'attention prefill & decode utilisent des MMA denses FP8 avec K=64 par instruction, ce qui divise par deux le nombre d'instructions MMA et s'exécute à deux fois le débit FP8 de Blackwell.

Benchmark de charge de travail agentique sur NVIDIA Rubin

Sur NVIDIA Rubin, MiniMax-M3.1-Flash repousse davantage la frontière sur le même benchmark. À l'extrémité sensible à la latence, il maintient 724.9 tokens par seconde par utilisateur. Plus loin le long de la frontière, il maintient chaque utilisateur au-dessus de 200 tokens par seconde tout en servant 157.3K tokens au total par seconde par GPU. À l'extrémité débit, il atteint 191.5K tokens par seconde par GPU tandis que chaque utilisateur voit encore environ 134 tokens par seconde, soit environ 1.5× GB300 au même débit par utilisateur.

Figure 5 : frontière de Pareto AgentX pour MiniMax-M3.1-Flash sur NVIDIA Rubin. Survolez un point pour afficher sa configuration et ses métriques.

Prise en charge des GPU AMD

Sur les GPU AMD, nous apportons la prise en charge du cache KV NVFP4, afin que les déploiements AMD puissent également utiliser le format basse précision pour réduire la mémoire du cache KV. Pour le decode, nous ajoutons l'indexer DCP pour accélérer le decode long contexte, ainsi qu'un mono kernel qui accélère l'inférence à faible latence. Pour le prefill, le parallélisme de séquence et le dual-batch overlap réduisent les communications à l'intérieur du moteur, et une nouvelle disposition du cache KV permet à chaque bloc KV de se déplacer vers le nœud de decode en un seul transfert. Les kernels MSA et mono sont construits en FlyDSL, le DSL Python d'AMD pour les kernels GPU, avec l'aide de l'équipe FlyDSL.

Kernel MSA NVFP4

MiniMax-M3.1 est entraîné avec un cache KV NVFP4 (QAT) à la fois pour l'attention principale et pour l'indexer, mais CDNA4 n'a aucune instruction native pour déquantiser le NVFP4. Pour garder les kernels MSA rapides, nous transformons la déquantisation en une consultation de table. Il n'y a que 256 échelles E4M3 possibles et huit magnitudes E2M1, donc nous précalculons chaque valeur mise à l'échelle, déjà arrondie en FP8, dans une table de 2 KB en LDS. Un v_perm_b32 byte permute plus un XOR pour les bits de signe convertissent ensuite quatre valeurs FP4 en FP8. Le kernel déquantise également une page de préfixe partagé une seule fois pour jusqu'à 64 requêtes qui la partagent. Ensemble, ces optimisations rendent l'attention creuse en decode jusqu'à 2.5× plus rapide que la conversion des blocs sélectionnés en FP8 et l'exécution du kernel d'attention FP8.

Indexer DCP NVFP4

Nous utilisons le même parallélisme de contexte de decode de l'indexer sur AMD que sur NVIDIA, et sur CDNA4 il apporte un gain supplémentaire. Sans DCP, chaque GPU en TP4 évalue sa propre tête d'index sur le contexte complet, donc le cache d'index est lu quatre fois. Cela laisse également les cœurs matriciels sous-utilisés. Une étape de decode DSpark-3 n'a que 4 lignes de requête par requête, ce qui ne remplit que 4 des 16 colonnes du MFMA FP8 16×16×128. Avec DCP, chaque GPU évalue les quatre têtes sur un quart du contexte, donc 4 têtes × 4 lignes remplissent les 16 colonnes. Un seul kernel échange les requêtes d'index, évalue ses blocs et écrit les scores de chaque tête directement dans la mémoire du GPU propriétaire via Infinity Fabric. Une synchronisation côté device maintient cela fonctionnel à l'intérieur des graphes HIP. Le propriétaire sélectionne ensuite le top 16 comme auparavant, et comme les scores sont identiques bit à bit à la version mono-GPU, la sélection est exacte. Sur 4× MI355X, l'indexer s'exécute jusqu'à 2.8× plus rapidement par couche creuse sur 45 requêtes de 30K à 210K tokens.

Prefill SP + DBO et transfert KV en une seule lecture

En TP4, le prefill de longs prompts sur MI355X est limité par les communications, à la fois entre les GPU à l'intérieur d'un nœud et entre les nœuds de prefill et de decode. À l'intérieur du moteur, le dual-batch overlap (DBO) masque les collectives tensor-parallel derrière le calcul de l'autre microbatch. Le parallélisme de séquence (SP) réduit le trafic lui-même. Chaque GPU conserve un quart des tokens, la sortie d'attention est échangée en all-to-all en MXFP8 afin que chaque GPU exécute le o_proj sur ses propres tokens, et la sortie du MoE est réduite par reduce-scatter. Cela fait passer le trafic par GPU d'environ 36 KB à 20 KB par token par couche, et les normes, la quantification et le routeur ne s'exécutent que sur un quart des tokens.

Un moteur de prefill plus rapide n'aide que si le cache KV peut également atteindre rapidement le nœud de decode. La disposition du cache KV couche par couche de vLLM divise chaque bloc KV sur 125 petites pages, et chaque page nécessite sa propre lecture RDMA NIXL. Nous passons à une disposition block-outer qui stocke chaque bloc dans une seule ligne contiguë de 1.82 MB, de sorte que NIXL le déplace en une seule lecture. Combinées, les modifications du moteur et du transfert KV rendent les batchs de prefill de 16K tokens ou plus 1.8 à 2.1× plus rapides sur 4× MI355X.

Mono kernel à faible latence

À faible concurrence, le decode sur les GPU AMD est limité par les lancements : la surcharge de lancement des kernels prend plus de temps que les calculs. Mono decode corrige cela en exécutant chaque couche de décodeur MoE creuse comme un seul lancement de kernel FlyDSL. Ce seul lancement couvre tout, de la projection QKV et de l'attention creuse aux all-reduce tensor-parallel et au MoE MXFP4, remplaçant environ 1,170 lancements de kernels. Sur MI350X en TP4, cela rend l'étape de decode jusqu'à 2.3× plus rapide et double le débit 8K-in/1K-out à faible concurrence. Sur une trace de codage agentique, cela améliore l'interactivité de 50 à 65 %.

Benchmark de charge de travail agentique sur AMD MI355X

Notre implémentation AMD offre également de fortes performances par coût. Sur le benchmark InferenceX AgentX, MiniMax-M3.1-Flash maintient 331.0 tokens par seconde par utilisateur à l'extrémité sensible à la latence de la frontière. Plus loin le long de la frontière, il maintient chaque utilisateur au-dessus de 170 tokens par seconde tout en délivrant 34.6M tokens au total par dollar de TCO. À l'extrémité économe en coûts, il atteint 133.3M tokens par dollar, soit près de 10× le point le plus interactif, tandis que chaque utilisateur voit encore environ 79 tokens par seconde.

Figure 6 : frontière de Pareto d'AgentX pour MiniMax-M3.1-Flash sur AMD MI355X, en tokens totaux par dollar de TCO. c1 et c4 utilisent une longueur d'acceptation synthétique de 3.2 tokens avec 7 tokens spéculatifs ; les autres points utilisent 2.45 tokens avec 3 tokens spéculatifs. Survolez un point pour voir ses métriques.

Support RL au jour 0

Nous exécutons le RL sur MiniMax-M3.1 à partir de son checkpoint NVFP4 et n'entraînons que des adaptateurs LoRA de rang 32. Le trainer veRL quantifie le modèle de base de la même manière dont le moteur le sert, avec NVFP4 sur les experts routés et MXFP8 sur les autres projections, et ne synchronise que les adaptateurs vers le moteur après chaque étape. Côté moteur, les LoRA d'experts s'exécutent dans le noyau TRTLLM NVFP4 MoE de FlashInfer, de sorte que les experts de base continuent de tourner sur le noyau de service normal.

Avant l'entraînement, nous avons vérifié que le trainer et le moteur concordent de trois manières. Le moteur reçoit exactement les poids que le trainer envoie, tous deux routent chaque token vers les mêmes experts (rejeu du routage), et tous deux attribuent des logprobs proches aux mêmes tokens.

L'écart restant est corrigé par importance sampling au niveau du token (TIS), avec un ratio d'importance plafonné à 2. Comme chaque lot reçoit une seule étape d'optimisation, le trainer utilise les logprobs de rollout comme anciens logprobs et saute la passe avant supplémentaire qui les recalculerait.

Sur DAPO-Math-17K avec 16 GPU GB300, 200 étapes GRPO font passer la précision AIME-2024 de 36.3% à 67.5%. Sur la même exécution, la récompense d'entraînement passe de −0.06 à 0.67, et la KL train/rollout reste faible, passant de 0.040 à 0.024.

Figure 7 : RL au jour 0 sur MiniMax-M3.1-Flash avec veRL sur DAPO-Math-17K (16× GB300, 200 étapes GRPO) : précision AIME-2024, récompense d'entraînement et KL train/rollout. Utilisez les onglets pour basculer entre elles.

Remerciements

Nous exprimons notre sincère gratitude à l'équipe MiniMax pour la mise en open source de MiniMax-M3.1-Flash. Nous remercions également Inferact, NVIDIA et AMD (Hongxia Yang pour le noyau mono, Felix Marty, Andy Luo, Felix Li, Hattie Wu, Gilbert Lei et Peng Sun) pour la fourniture du support au jour 0 du modèle dans vLLM, ainsi que l'équipe FlyDSL pour son aide sur les noyaux AMD et la communauté vLLM.