vLLM unterstützt MiniMax-M3.1-Flash ab Tag 0 auf GPUs von NVIDIA und AMD

Ein Modell für effiziente Inferenz

MiniMax-M3.1-Flash ist laut vLLM das jüngste Modell der MiniMax-M3-Familie und bringt Verbesserungen bei Reasoning, Coding sowie agentischen und visuellen Aufgaben. Die M3-Familie ersetzt die volle Attention durch eine Variante der Block-Sparse-Attention, die MiniMax Sparse Attention (MSA) heißt.

Bei MSA wird der KV-Cache in Blöcke von je 128 Tokens aufgeteilt. Ein leichtgewichtiger Indexer bewertet jeden Schlüssel im Kontext und fasst diese Werte zu einem Score pro Block zusammen. Die eigentliche Attention läuft anschließend exakt, aber nur über die besten 16 Blöcke, wobei der jeweils jüngste Block immer erhalten bleibt. Dadurch ist jede Anfrage unabhängig von der Kontextlänge auf 2.048 Schlüssel begrenzt. Beim Decoding mit langem Kontext sinkt der HBM-Datenverkehr pro Schritt laut vLLM auf etwa 12,5 Prozent dessen, was dichte Attention liest.

MiniMax-M3.1 wurde nativ quantisierungsbewusst für einen NVFP4-KV-Cache trainiert, und seine geroutet angesprochenen MoE-Gewichte liegen in NVFP4 vor. Laut dem Beitrag schrumpfen die NVFP4-Experten den Checkpoint von 451,5 GB (MiniMax-M3-MXFP8) auf 250,1 GB, also um 44,6 Prozent. Der NVFP4-KV-Cache benötigt 34.560 Bytes pro Token statt 61.440 Bytes in FP8, was einer Einsparung von 43,75 Prozent entspricht. Auf vier NVIDIA-B300-GPUs mit DEP4-Deployment und Sequenzen von 256.000 Tokens passen bei M3.1 76 parallele Sequenzen, bei M3 mit FP8-KV-Cache sind es 28, also rund das 2,7-Fache.

Optimierungen bei Kernels und Serving

vLLM nennt mehrere Optimierungen für das neue Modell:

• Blackwell-MSA-Kernels: Sie nutzen die neue CUDA-13.4-Instruktion QMUL4, um NVFP4 direkt im Kernel nach FP8 zu dequantisieren. Das bringt ein bis zu 1,7-fach schnelleres Indexer-QK-Decoding und ein 1,3-fach schnelleres Sparse-Attention-Decoding.
• NVFP4 MegaMoE: Mit MXFP8-Shared-Expert-Fusion und frühzeitiger TMEM-Freigabe sinkt die Kernel-Latenz im Prefill um 20 Prozent, der Prefill-Durchsatz steigt um 7 Prozent.
• Context Parallelism beim Indexer-Decoding: Pro Sparse-Layer ist der Indexer bei 512K Kontext auf 4× GB300 bis zu 3,3-fach schneller.
• Fusion von QKV-GEMM, Norm, RoPE und KV-Insert: Der Prefill ist ab 512 Tokens 1,1- bis 1,6-fach schneller, die P50-TTFT sinkt bei TP4 auf GB300 um rund 19 Prozent.
• FlashInfer-PrimiTS-Backend für den DSpark-Drafter: 1,3- bis 2-fach schneller als FlashAttention 4 und 5 Prozent weniger Gesamtzeit im Forward-Pass.

Außerdem seien Rubin-MSA-Kernels (SM107) in vLLM integriert, so das Team. Auf GPUs der AMD-MI350-Serie erzielen der NVFP4-native MSA-Kernel, das Context Parallelism beim Indexer-Decoding, Dual-Batch-Overlap und der Mono-Kernel laut vLLM auf breiter Front eine 2- bis 3-fache Leistungssteigerung.

Für agentisches Serving nennt vLLM auf NVIDIA GB300 bis zu 418,9 Tokens pro Sekunde und Nutzer am latenzkritischen Ende. Auf NVIDIA Rubin seien es bis zu 724,9 Tokens pro Sekunde und Nutzer sowie 191,5K Tokens pro Sekunde insgesamt je GPU. Auf AMD MI355X erreiche man im SemiAnalysis-AgentX-Benchmark bis zu 133,3 Mio. Tokens insgesamt pro Dollar TCO.

Erste Schritte und RL-Unterstützung

Für beide Hersteller gibt es fertige Images: vllm/vllm-openai:minimax-m31-flash für NVIDIA und vllm/vllm-openai-rocm:minimax-m31-flash für AMD. Ins nächtliche PyPI-Wheel gelangt das Modell erst, nachdem der Code geprüft und im Upstream gemergt wurde, was in der Regel etwa eine Woche dauert. Vollständige Rezepte stehen bei vLLM Recipes, der Checkpoint ist als MiniMaxAI/MiniMax-M3.1-Flash veröffentlicht.

Der Beitrag enthält Beispielbefehle zum Start mit TP4 für beide Plattformen. Auf NVIDIA empfiehlt vLLM für die beste Leistung das CUDA-13.4-Toolkit; das Setup verwendet einen NVFP4-KV-Cache, einen NVFP4-Indexer-KV-Dtype und die DSpark-Speculative-Konfiguration mit 7 spekulativen Tokens. Das AMD-Beispiel aktiviert Context Parallelism beim Indexer-Decoding, MXFP8 für die MoE-Quantisierung und 3 spekulative Tokens.

Zudem kündigt vLLM Day-0-Unterstützung für Reinforcement Learning an, und zwar durchgängiges RL mit veRL, FSDP2 und LoRA auf dem NVFP4-Checkpoint.

Was das für Anwender bedeutet

Für Teams, die Workloads mit langem Kontext oder agentische Anwendungen betreiben, deuten die Zahlen von vLLM auf einen geringeren Speicherbedarf pro Sequenz und einen höheren Durchsatz auf aktuellen und kommenden Beschleunigern von NVIDIA und AMD hin. Alle Leistungsangaben stammen von vLLM selbst und hängen von der beschriebenen Hardware und den genannten Konfigurationen ab. Wer das Modell im regulären nächtlichen Wheel nutzen will, muss auf den Upstream-Merge warten, die vorgefertigten Images sind dagegen schon verfügbar.