vLLM liefert Day-0-Unterstützung für MiniMax-M3.1-Flash

MiniMax-M3.1-Flash ist das neueste Modell der MiniMax-M3-Familie mit Verbesserungen bei Reasoning-, Coding-, Agenten- und visuellen Aufgaben. Es ist zudem auf Inferenzeffizienz ausgelegt, mit einem nativen NVFP4-KV-Cache, NVFP4-quantisierten MoE-Gewichten und einem DSpark-Draftmodell für Speculative Decoding.

vLLM unterstützt MiniMax-M3.1-Flash am Tag 0 auf NVIDIA-Blackwell-GPUs, auf NVIDIA-Rubin-GPUs mit speziellen Rubin-Kernels sowie auf AMD MI350-GPUs, mit starker Leistung bei Agenten-Workloads.

TL;DR

• MiniMax Sparse Attention (MSA) mit einem NVFP4-KV-Cache sowohl für den Indexer als auch für den Attention-Pfad, dazu NVFP4-MoE-Gewichte und einen DSpark Drafter.
• Blackwell-MSA-Kernels verwenden die neue CUDA-13.4 QMUL4 Instruktion, um NVFP4 direkt im Kernel nach FP8 zu dequantisieren: bis zu 1.7× schnelleres Indexer-QK-Decode und 1.3× schnelleres Sparse-Attention-Decode.
• NVFP4 MegaMoE mit MXFP8-Shared-Expert-Fusion und früher TMEM-Freigabe: 20 % niedrigere Kernel-Latenz im Prefill und 7 % höherer Prefill-Durchsatz.
• Indexer-Decode-Context-Parallelismus (DCP): bis zu 3.3× schnellerer Indexer pro Sparse-Layer bei 512K Kontext auf 4× GB300.
• QKV-GEMM + Norm + RoPE + KV-Insert-Fusion: 1.1–1.6× schneller Prefill bei 512+ Tokens und etwa 19 % niedrigerer P50 TTFT bei TP4.
• FlashInfer PrimiTS Backend für die DSpark-Drafter-Attention: 1,3–2× schneller als FlashAttention 4, 5 % niedrigere gesamte Forward-Zeit.
• Rubin (SM107) MSA-Kernel sind ebenfalls mit State-of-the-Art-Leistung in vLLM integriert.
• AMD MI350 Serie: Der NVFP4-native MSA-Kernel, Indexer-Decode-Kontextparallelität, Dual-Batch-Overlap und der Mono-Kernel liefern einen 2–3× Leistungsschub auf ganzer Linie.
• Agentic Serving: auf NVIDIA GB300 bis zu 418,9 tok/s pro Nutzer am latenzempfindlichen Ende; auf NVIDIA Rubin bis zu 724,9 tok/s pro Nutzer und 191,5K Gesamt-tok/s pro GPU; auf AMD MI355X bis zu 133,3M Gesamttokens pro Dollar TCO auf dem SemiAnalysis AgentX Benchmark.
• Day-0-RL-Unterstützung: End-to-End-RL mit veRL, FSDP2 und LoRA auf dem NVFP4-Checkpoint.

Schnellstart

Vorgefertigte Images sind für beide Anbieter verfügbar:

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

Beachten Sie, dass das Modell erst nach Überprüfung und Zusammenführung des Codes upstream im nächtlichen PyPI-Wheel verfügbar sein wird, was normalerweise etwa eine Woche dauert. Vollständige Rezepte finden Sie unter vLLM Recipes, und der Checkpoint liegt bei MiniMaxAI/MiniMax-M3.1-Flash.

TP4 auf NVIDIA

Wir empfehlen das CUDA-13.4-Toolkit für die beste Leistung.

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 auf 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

MSA-Grundlagen

Die MiniMax-M3-Modellfamilie ersetzt die vollständige Aufmerksamkeit durch eine Variante der Block-Sparse-Attention (arXiv 2606.13392), um die Inferenz effizienter zu machen. Der KV-Cache wird in Blöcke von 128 Token aufgeteilt. Ein leichtgewichtiger Indexer bewertet jeden Schlüssel im Kontext mit einer Index-Abfrage pro GQA-Gruppe gegen einen einzigen gemeinsamen Index-Schlüssel-Kopf und poolt diese Bewertungen dann per Max-Pooling zu einer Bewertung pro Block. Die Haupt-Aufmerksamkeit läuft dann exakt, aber nur über die Top-16-Blöcke, wobei der jüngste Block immer beibehalten wird. Das begrenzt jede Abfrage auf 2,048 Schlüssel, egal wie lang der Kontext ist.

Der größte Nutzen zeigt sich beim Decode, das durch die Speicherbandbreite begrenzt wird. Jeder Schritt durchsucht weiterhin die Index-Schlüssel für den gesamten Kontext, das sind aber nur 128 Byte pro Token pro Schicht, ein Achtel der 1,024 Byte an K/V, die dichte Aufmerksamkeit lesen würde (FP8, 4 KV-Köpfe × 128 Dimensionen). Das vollständige K/V wird dann nur für die 2,048 ausgewählten Token gelesen. Beim Langkontext-Decode sinkt der HBM-Verkehr pro Schritt auf etwa 12.5% dessen, was dichte Aufmerksamkeit liest.

Abbildung 1: MiniMax Sparse Attention. Der Indexer jeder GQA-Gruppe wählt ihre Top-KV-Blöcke aus, und jeder Abfrage-Kopf in dieser Gruppe attendiert exakt nur über diese Blöcke. Schreiten Sie es Schritt für Schritt durch.

Was ist neu in der MiniMax-M3.1-Architektur

MiniMax-M3.1 verbessert die Inferenzeffizienz gegenüber der vorherigen Generation erheblich: Es wurde nativ quantisierungsbewusst für einen NVFP4-KV-Cache trainiert, und seine gerouteten MoE-Gewichte werden in NVFP4 gespeichert. Die NVFP4-Experten verkleinern den Checkpoint von 451.5 GB (MiniMax-M3-MXFP8) auf 250.1 GB, was 44.6% kleiner ist. Der NVFP4-KV-Cache benötigt 34,560 Byte pro Token statt 61,440 Byte in FP8, eine Einsparung von 43.75% pro Token. Zusammen passen auf vier NVIDIA-B300-GPUs mit DEP4-Deployment und 256K-Token-Sequenzen bei M3.1 76 gleichzeitige Sequenzen, während M3 mit einem FP8-KV-Cache 28 passt, etwa 2.7× so viele auf derselben Hardware, was den Serving-Durchsatz direkt erhöht.

Abbildung 2: MiniMax-M3.1 ist quantisierungsbewusst trainiert, um einen NVFP4-KV-Cache sowohl für den Indexer als auch für die Sparse-Attention zu verwenden. Ändern Sie den KV-Cache-Dtype, die Parallelität, die GPU oder die Kontextlänge, um zu sehen, wie viele Sequenzen passen.

Leistungsoptimierungen

vLLM liefert starke MiniMax-M3.1-Leistung auf mehreren Hardwareplattformen. Auf NVIDIA-GPUs liefern wir Kernel aus, die für den NVFP4-KV-Cache optimiert sind. Unser MSA-Repository (vllm-project/MSA) enthält Kernel, die für verschiedene Workloads und Operationen abgestimmt sind. Dazu gehören MSA-Indexer-Prefill und -Decode, Sparse-Attention-Prefill und -Decode sowie ein MSA-spezifischer Top-k-Kernel.

Abbildung 3: Eine MiniMax-M3.1-Sparse-Decoder-Schicht auf Blackwell beim Decode (M ≤ 32), Kernel für Kernel. Nummerierte Abzeichen markieren die Optimierungen in diesem Beitrag; klicken Sie auf eines, um die zugehörigen Kernel hervorzuheben.

NVIDIA-Blackwell-optimierte MSA-Kernel

Der KV-Cache wird in NVFP4 gespeichert, während die Query in FP8 bleibt, daher können wir die nativen NVFP4-Tensor-Core-Instruktionen nicht für die Matrixmultiplikation verwenden. Stattdessen dequantisiert der Kernel den NVFP4-KV-Cache zu FP8 und führt ein FP8-MMA aus. Um die Dequantisierungskosten niedrig zu halten, verwenden wir eine neue Blackwell-spezifische PTX-Instruktion, die in CUDA 13.4 eingeführt wurde, mul.e4m3x4.e2m1x4.e4m3x4 (SASS QMUL4). Sie skaliert vier NVFP4-Werte mit ihrem Skalierungsfaktor und erzeugt vier FP8-Werte in einer einzigen Instruktion. Das benötigt deutlich weniger CUDA-Core-Instruktionen als der bisherige FP16-Roundtrip-Pfad. Das Ergebnis ist bis zu eine 1.7-fache Beschleunigung beim Indexer-QK-Decode-Kernel und 1.3-fache beim Sparse-Attention-Decode-Kernel.

NVFP4 MegaMoE

MegaMoE ist ein zentraler Baustein für moderne Expert-Parallel-(EP)-Bereitstellungen. Wir haben DeepGEMMs MegaMoE auf NVFP4-Präzision erweitert, mit fusionierten MXFP8-Shared-Experts, und es in unserem Fork (vllm-project/DeepGEMM) als Open Source veröffentlicht. NVFP4-Unterstützung zu MegaMoE hinzuzufügen ist mehr als ein reiner dtype-Tausch. NVFP4 halbiert die Bytes pro Element und verdoppelt den Tensor-Core-Durchsatz im Vergleich zum bisherigen FP8×FP4-Pfad. Der Rest des Kernels muss sich ebenfalls ändern, sonst gerät die Pipeline aus dem Gleichgewicht.

Eine solche Änderung ist die vorzeitige Freigabe der TMEM-Stage im FC1-Epilog. Bisher wurde die TMEM-Stage erst nach Abschluss des Epilogs freigegeben. Dieses Warten ist unnötig, da der Epilog vollständig in Registern läuft. TMEM kann freigegeben werden, sobald der Akkumulator in Register geladen wurde, noch bevor irgendeine Arithmetik stattfindet. Dies reduziert die Gesamtlatenz des Kernels im Prefill um 20%, wo die schnellere NVFP4-Berechnung am meisten zählt. Zusätzlich steigert es den Gesamtdurchsatz im Prefill um 7%.

NVFP4-Indexer-DCP (Decode Context Parallelism)

Beim Low-Latency-Serving bewertet jede GPU ihre eigene Index-Head über den gesamten Kontext. Über die vier GPUs hinweg bedeutet das, dass jede Indexer-Schicht den vollständigen Index-Cache viermal liest. Der Indexer-DCP teilt die Arbeit stattdessen nach Kontext auf. Jede GPU bewertet alle vier Heads über ein Viertel der Seiten. Anschließend sendet sie ihre lokalen Top-16 für jeden Head über NVLink an die GPU, die diesen Head besitzt, welche die Kandidaten zum finalen Top-16 zusammenführt. Die Auswahl bleibt exakt, und der Indexer läuft bis zu 3.3-fach schneller pro Sparse-Schicht bei 512K Kontext auf 4× NVIDIA GB300 GPUs.

QKV GEMM + Norm + RoPE + KV-Insert-Fusion

MiniMax-M3.1s QKV- und Indexer-Projektionen schrieben früher den vollständigen QKV-Tensor in den HBM. Ein zweiter Kernel las ihn dann wieder für Norm, RoPE und das Einfügen in den KV-Cache zurück. Wir haben die gesamte Kette in einen einzigen GEMM-Kernel fusioniert, dessen Epilog den FP32-Akkumulator Head für Head verarbeitet. Er wendet Norm und RoPE auf die Query und Index-Query an. Außerdem quantisiert er K, V und den Index-Key zu NVFP4 und schreibt sie direkt in ihre Caches. Der QKV-Tensor berührt den HBM nie. Auf GB300 laufen Prefill-Batches mit 512 oder mehr Token 1.1–1.6-fach schneller, und die P50-Time-to-First-Token (TTFT) sinkt bei TP4 um etwa 19%.

FlashInfer PrimiTS für den DSpark-Drafter

MiniMax-M3.1 verwendet DSpark als Drafter für sein Speculative Decoding, der nicht-kausales GQA mit einem 4096-Token-Sliding-Window ausführt. Bisher lief der Drafter in vLLM auf FlashAttention 4, was für Decode-Shapes nicht optimiert ist. Wir haben ihn auf FlashInfers PrimiTS-Backend umgestellt. PrimiTS ist 1.3–2-fach schneller als FlashAttention 4 und reduziert die gesamte Vorwärtszeit um 5%.

Agentic-Workload-Benchmark auf NVIDIA GB300

vLLM liefert starke Leistung bei agentic serving workloads. Wir benchmarken unser Day-0-Image auf NVIDIA GB300 mit dem SemiAnalysis AgentX-Benchmark (detailliert beschrieben in unserem vorherigen Beitrag). Am latenzempfindlichen Ende der Frontier hält MiniMax-M3.1-Flash 418.9 Token pro Sekunde pro Benutzer. Weiter entlang der Frontier hält es jeden Benutzer über 200 Token pro Sekunde, während es 38.6K Token pro Sekunde pro GPU insgesamt serviert. Am Durchsatzende erreicht es 153.8K Token pro Sekunde pro GPU, etwa das 24-fache des interaktivsten Punkts, während jeder Benutzer weiterhin etwa 127 Token pro Sekunde sieht.

Abbildung 4: AgentX-Pareto-Frontier für MiniMax-M3.1-Flash auf NVIDIA GB300, mit 7 spekulativen Token und synthetischen Akzeptanzlängen von 3.16–3.26 Token (einschließlich des ersten Tokens). Fahren Sie mit der Maus über einen Punkt für seine Metriken.

NVIDIA-Rubin-optimiertes MSA

Wir haben dieses Modell auch auf NVIDIA Rubin GPUs optimiert. Um den Overhead der NVFP4-zu-FP8-Konvertierung zu mildern, konvertieren wir NVFP4 direkt zu FP16 und führen die Score-MMA in FP16 für den Indexer aus. Dies reduziert die Dequantisierungsinstruktionen um etwa ein Drittel, und die Scores werden exakt, statt das E4M3-Re-Runden für die FP8-MMA zu tragen.

Bei ≤4 Queries geht der One-Head-Indexer-Decode-Kernel noch weiter: Er wendet jeden Blockskalierungsfaktor einmal pro MMA-Ergebnis mit SM107s packed fma.rn.f32x2.f16x2an, statt einmal pro K-Wert. Dies ermöglicht zusätzlich mehr Latency Hiding durch das Ausführen von drei CTAs pro SM. Rubins größerer Shared Memory (328 KB gegenüber 228 KB auf Blackwell) und zusätzliche Tensor-Memory-Spalten (576 gegenüber 512 auf Blackwell) machen das möglich.

Schließlich dimensionieren die Work Planner ihre Tiles anhand der SM-Anzahl, da Rubin mehr SMs als Blackwell hat, sodass die Arbeit gleichmäßig über alle 212 von Rubins SMs verteilt wird.

Prefill sparse attention profitieren ebenfalls von Localitäts-Domain-Optimierungen. Wir allokieren die partiellen Puffer über die CUDA Virtual Memory API, sodass 2-MB-Seiten zwischen den beiden Domains abwechseln, und der kombinierte Kernel übergibt jedes Tile an einen CTA, dessen SM in der Domain liegt, die die Daten dieses Tiles enthält. Auf Rubin verwenden die Prefill- & Decode-Attention-Kernel dichte FP8-MMA mit K=64 pro Instruktion, was die MMA-Instruktionsanzahl halbiert und mit der doppelten FP8-Rate von Blackwell läuft.

Agentic-Workload-Benchmark auf NVIDIA Rubin

Auf NVIDIA Rubin treibt MiniMax-M3.1-Flash die Grenze desselben Benchmarks weiter voran. Am latenzempfindlichen Ende hält es 724.9 Token pro Sekunde pro Nutzer. Weiter entlang der Grenze hält es jeden Nutzer über 200 Token pro Sekunde, während es insgesamt 157.3K Token pro Sekunde pro GPU bedient. Am Durchsatzende erreicht es 191.5K Token pro Sekunde pro GPU, während jeder Nutzer weiterhin etwa 134 Token pro Sekunde sieht, etwa 1.5× GB300 bei derselben Pro-Nutzer-Rate.

Abbildung 5: AgentX-Pareto-Grenze für MiniMax-M3.1-Flash auf NVIDIA Rubin. Bewegen Sie den Zeiger über einen Punkt, um seine Konfiguration und Metriken zu sehen.

AMD-GPU-Unterstützung

Auf AMD-GPUs bringen wir NVFP4-KV-Cache-Unterstützung, sodass auch AMD-Deployments das Niedrigpräzisionsformat nutzen können, um KV-Cache-Speicher zu sparen. Für Decode fügen wir Indexer-DCP hinzu, um Long-Context-Decode zu beschleunigen, sowie einen Mono-Kernel, der Low-Latency-Inferenz beschleunigt. Für Prefill senken Sequence Parallelism und Dual-Batch Overlap die Kommunikation innerhalb der Engine, und ein neues KV-Cache-Layout ermöglicht, dass jeder KV-Block in einer einzigen Übertragung zum Decode-Knoten gelangt. Die MSA- und Mono-Kernel sind in FlyDSLgebaut, AMDs Python-DSL für GPU-Kernel, mit Hilfe des FlyDSL-Teams.

NVFP4-MSA-Kernel

MiniMax-M3.1 wird mit einem NVFP4-KV-Cache (QAT) sowohl für die Main Attention als auch für den Indexer trainiert, aber CDNA4 hat keine native Instruktion zum Dequantisieren von NVFP4. Um die MSA-Kernel schnell zu halten, machen wir aus der Dequantisierung einen Tabellenlookup. Es gibt nur 256 mögliche E4M3-Skalen und acht E2M1-Magnitude-Werte, daher berechnen wir jeden skalierten Wert, bereits auf FP8 gerundet, in eine 2-KB-Tabelle im LDS vor. Ein v_perm_b32 Byte-Permute plus ein XOR für die Signierbits wandelt dann vier FP4-Werte in FP8 um. Der Kernel dequantisiert außerdem eine Shared-Prefix-Seite nur einmal für bis zu 64 Requests, die sie gemeinsam nutzen. Zusammen machen diese Maßnahmen sparse decode attention bis zu 2.5× schneller als die Konvertierung der ausgewählten Blöcke in FP8 und die Ausführung des FP8-Attention-Kernels.

NVFP4-Indexer-DCP

Wir verwenden denselben Indexer-Decode-Context-Parallelismus auf AMD wie auf NVIDIA, und auf CDNA4 bringt er einen zusätzlichen Gewinn. Ohne DCP bewertet jede GPU bei TP4 ihren eigenen Index-Head über den gesamten Kontext, sodass der Index-Cache viermal gelesen wird. Zudem lässt es die Matrix-Kerne unzureichend ausgelastet. Ein DSpark-3-Decode-Schritt hat nur 4 Query-Zeilen pro Request, was nur 4 der 16 Spalten des 16×16×128-FP8-MFMA füllt. Mit DCP bewertet jede GPU alle vier Heads über ein Viertel des Kontexts, sodass 4 Heads × 4 Zeilen alle 16 Spalten füllen. Ein einzelner Kernel tauscht die Index-Queries aus, bewertet seine Blöcke und schreibt die Scores jedes Heads direkt in den Speicher der besitzenden GPU über Infinity Fabric. Ein Device-seitiger Handshake hält dies innerhalb von HIP-Graphen am Laufen. Der Besitzer wählt dann wie bisher die Top 16, und da die Scores bitgenau identisch mit der Einzel-GPU-Version sind, ist die Auswahl exakt. Auf 4× MI355X läuft der Indexer bis zu 2.8× schneller pro Sparse-Layer bei 45 Requests mit 30K–210K Token.

SP- + DBO-Prefill und einmaliges KV-Lesen

Bei TP4 ist Long-Prompt-Prefill auf MI355X durch Kommunikation limitiert, sowohl zwischen GPUs innerhalb eines Knotens als auch zwischen den Prefill- und Decode-Knoten. Innerhalb der Engine verbirgt Dual-Batch Overlap (DBO) die Tensor-Parallel-Kollektive hinter der Berechnung des anderen Microbatchs. Sequence Parallelism (SP) reduziert den Traffic selbst. Jede GPU behält ein Viertel der Token, die Attention-Ausgabe wird All-to-All in MXFP8 ausgetauscht, sodass jede GPU das vollständige o_proj auf ihren eigenen Token ausführt, und die MoE-Ausgabe wird Reduce-Scattered. Dies senkt den Traffic pro GPU von etwa 36 KB auf 20 KB pro Token pro Layer, und Normen, Quantisierung und der Router laufen nur auf einem Viertel der Token.

Eine schnellere Prefill-Engine hilft nur, wenn der KV-Cache ebenfalls schnell zum Decode-Knoten gelangen kann. vLLMs Layer-für-Layer-KV-Cache-Layout verteilt jeden KV-Block auf 125 kleine Seiten, und jede Seite erfordert eine eigene NIXL-RDMA-Leseoperation. Wir wechseln zu einem Block-Outer-Layout, das jeden Block in einer zusammenhängenden 1.82-MB-Zeile speichert, sodass NIXL ihn in einem einzigen Lesen bewegt. Kombiniert machen die Engine- und KV-Transfer-Änderungen Prefill-Batches mit 16K+ Token auf 4× MI355X 1.8–2.1× schneller.

Low-Latency-Mono-Kernel

Bei niedriger Konkurrenz ist Decode auf AMD-GPUs launch-gebunden: Der Kernel-Start-Overhead nimmt mehr Zeit in Anspruch als die Mathematik. Mono Decode behebt dies, indem jeder sparse MoE-Decoder-Layer als ein einzelner FlyDSL-Kernel-Start ausgeführt wird. Dieser eine Start deckt alles ab, von der QKV-Projektion und sparse attention bis zu den Tensor-Parallel-All-Reduces und der MXFP4-MoE, und ersetzt etwa 1,170 Kernel-Starts. Auf MI350X bei TP4 macht dies den Decode-Schritt bis zu 2.3× schneller und verdoppelt den 8K-in/1K-out-Durchsatz bei niedriger Konkurrenz. Bei einem Agentic-Coding-Trace steigert es die Interaktivität um 50–65%.

Agentic-Workload-Benchmark auf AMD MI355X

Unsere AMD-Implementierung liefert auch starke Leistung pro Kosten. Auf dem InferenceX AgentX-Benchmark hält MiniMax-M3.1-Flash 331.0 Token pro Sekunde pro Nutzer am latenzempfindlichen Ende der Grenze. Weiter entlang der Grenze hält es jeden Nutzer über 170 Token pro Sekunde, während es 34.6M Token insgesamt pro Dollar TCO liefert. Am kosteneffizienten Ende erreicht es 133.3M Token pro Dollar, fast 10× den interaktivsten Punkt, während jeder Nutzer weiterhin etwa 79 Token pro Sekunde sieht.

Abbildung 6: AgentX-Pareto-Frontier für MiniMax-M3.1-Flash auf AMD MI355X, in Tokens pro Dollar TCO insgesamt. c1 und c4 verwenden eine synthetische Akzeptanzlänge von 3.2 Tokens mit 7 spekulativen Tokens; die anderen Punkte verwenden 2.45 Tokens mit 3 spekulativen Tokens. Fahren Sie mit dem Mauszeiger über einen Punkt, um seine Metriken zu sehen.

Day-0-RL-Unterstützung

Wir betreiben RL auf MiniMax-M3.1 ausgehend von seinem NVFP4-Checkpoint und trainieren nur LoRA-Adapter vom Rang 32. Der veRL-Trainer quantisiert das Basismodell auf dieselbe Weise, wie die Engine es bereitstellt, mit NVFP4 auf den gerouteten Experten und MXFP8 auf den anderen Projektionen, und synchronisiert nach jedem Schritt nur die Adapter mit der Engine. Auf Seiten der Engine läuft Expert-LoRA innerhalb des TRTLLM NVFP4 MoE-Kernels von FlashInfer, sodass die Basis-Experten weiterhin auf dem normalen Serving-Kernel laufen.

Vor dem Training haben wir auf drei Arten überprüft, dass Trainer und Engine übereinstimmen. Die Engine erhält exakt die Gewichte, die der Trainer sendet, beide routen jeden Token an dieselben Experten (Routing-Replay), und beide weisen denselben Tokens ähnliche Logprobs zu.

Die verbleibende Differenz wird mit Token-level Importance Sampling (TIS) korrigiert, wobei das Importance-Verhältnis auf 2 begrenzt ist. Da jeder Batch einen einzelnen Optimiererschritt erhält, verwendet der Trainer die Rollout-Logprobs als alte Logprobs und überspringt den zusätzlichen Forward-Pass, der sie neu berechnen würde.

Auf DAPO-Math-17K mit 16 GB300-GPUs steigt die AIME-2024-Genauigkeit über 200 GRPO-Schritte von 36.3% auf 67.5%. Über denselben Lauf steigt der Trainings-Reward von −0.06 auf 0.67, und der Train/Rollout-KL bleibt niedrig und fällt von 0.040 auf 0.024.

Abbildung 7: Day-0-RL auf MiniMax-M3.1-Flash mit veRL auf DAPO-Math-17K (16× GB300, 200 GRPO-Schritte): AIME-2024-Genauigkeit, Trainings-Reward und Train/Rollout-KL. Wechseln Sie über die Tabs zwischen ihnen.

Danksagungen

Wir danken dem MiniMax-Team aufrichtig für die Open-Source-Veröffentlichung von MiniMax-M3.1-Flash. Wir danken außerdem Inferact, NVIDIA und AMD (Hongxia Yang für den Mono-Kernel, Felix Marty, Andy Luo, Felix Li, Hattie Wu, Gilbert Lei und Peng Sun) für die Day-0-Unterstützung des Modells in vLLM sowie dem FlyDSL-Team für seine Hilfe bei den AMD-Kernels und der vLLM-Community.