vLLM unterstützt Mistral Large 4 ab Tag 0: MoE-Modell mit einer Billion Parametern

Was Mistral Large 4 ist

Laut dem vLLM-Team hat Mistral Large 4 insgesamt 1 Billion Parameter, davon 49 Milliarden aktiv pro Token (52 Milliarden inklusive Embeddings und Ausgabeschichten). Es handelt sich um ein Mixture-of-Experts-Modell mit 72 Schichten, 128 geroutetenExperten (Top-4) plus 1 geteiltem Experten und einer Hidden Size von 6144.

Der Attention-Stack ist im DeepSeek-Stil aufgebaut und sparse: MLA (KV-LoRA-Rang 512, RoPE-Dimension 64) kombiniert mit einem DSA-Indexer, der pro Query die Top 2048 Keys auswählt. Dazu nennt vLLM mehrere neue Architekturmerkmale: schichtübergreifendes KV-Sharing, NoPE-Schichten, SSMax und LeRoPE. Das Modell wird mit einem integrierten DSpark-Drafter für Speculative Decoding und einem Pixtral-Vision-Encoder ausgeliefert, der Bildeingaben verarbeitet, auch mehrere Bilder pro Prompt.

Es gibt zwei Checkpoints: FP8 mit blockskalierten Gewichten sowie NVFP4, das NVFP4-Experten und FP8-Attention sowie FP8-geteilte Experten nutzt. Beide verwenden standardmäßig einen latenten FP8-KV-Cache (fp8_ds_mla).

So läuft es, und was vLLM berichtet

Die Unterstützung steckt im Docker-Image vllm/vllm-openai:mistral-large-4, das auch mistral-common 1.13 enthält. Das FP8-Modell läuft auf 8 GPUs mit Tensor Parallelism von 8. Das NVFP4-Modell läuft auf 4 Blackwell-GPUs oder mit --tensor-parallel-size 8 auf 8. Beide Beispiele aktivieren die DSpark-Speculative-Config mit 3 spekulativen Tokens, den Mistral-Tool-Call-Parser und den Mistral-Reasoning-Parser. Für Multi-Node- und disaggregierte Setups verweist vLLM auf ein Rezept für Mistral Large 4.

Laut vLLM akzeptiert der DSpark-Drafter (3 Sliding-Window-MLA-Schichten, Tiefe 3) etwa 2,9 Tokens pro Schritt und liefert auf TP8 rund den doppelten Output-Durchsatz.

Bei NVFP4 gehe die Qualität laut vLLM nicht zulasten der Geschwindigkeit. Über multimodale, Long-Context-, agentische Coding-, Business-Automation- und Cyber-Evaluierungen hinweg liegt es bei jeder Aufgabe höchstens 2,1 Punkte unter FP8, die mittlere Abweichung beträgt -0,3 Punkte. Die durchschnittliche Zahl der Completion-Tokens bleibt innerhalb von etwa 4 % des FP8-Werts. Auf TP8 dekodiert NVFP4 ohne Speculative Decoding pro Token 1,08- bis 1,19-mal schneller als FP8 (mit DSpark 1,18- bis 1,22-mal) und fasst etwa das 1,5-Fache an KV-Cache.

• Genannte Benchmarks sind unter anderem GDP.pdf, MathVision, Graphwalks 512k, DeepSWE, SWE-bench Pro, Terminal-Bench 4, AutomationBench und CyberGym.
• AMD Instinct MI350 Series GPUs werden ab Tag 0 mit ROCm unterstützt, einschließlich DSpark, Bildeingaben und Expert Parallelism mit MXFP4-Experten.

Die Ingenieursarbeit hinter der Unterstützung

Mistral Large 4 läuft ausschließlich auf vLLMs Model Runner V2 (MRV2) und nutzt unterbrechbare CUDA-Graphs ohne torch.compile. Laut vLLM brachten die Graphs gegenüber dem Eager-Modus eine Beschleunigung um etwa das 6-Fache. Handgeschriebene Fusionen, etwa von SSMax mit MLA-RoPE sowie der Query- und Key-Pfade des Indexers, senkten die Decode-TPOT um 8 bis 10 %. Eine spätere Runde, unter anderem mit einem FP32-Router-GEMM und einem fusionierten Kernel aus All-Reduce, Residual und RMSNorm, senkte die c1-TPOT auf TP8 FP8 von 10,22 auf 9,00 ms.

Der Modellcode liegt in einem neuen Paket vllm/models/mistral/. Die Merkmale pro Schicht steuert eine aus params.json erzeugte Layer-Spezifikation, statt modellspezifische Verzweigungen im gemeinsamen Code zu nutzen. Das schichtübergreifende KV-Sharing wurde über das Feld kv_sharing_target_layer_name ergänzt. Neun NoPE-Schichten lesen den latenten Cache von Schicht 35, sodass 63 der 72 Schichten einen eigenen Cache besitzen. vLLM beschreibt dies als modellunabhängig und reicht es in vllm#64095 upstream ein. Pro Token speichert der KV-Cache 47.136 Bytes: 41.328 für das MLA-Latent und 5.808 für den Indexer.

Langer Kontext und disaggregiertes Serving

Da MLA nur einen latenten KV-Head hält, wird der Cache bei Tensor Parallelism auf jedem Rank repliziert. Decode Context Parallelism (DCP) verteilt ihn stattdessen nach Token. Auf TP8 steigert DCP8 laut vLLM die KV-Kapazität bei FP8 von 2,38 Mio. auf 18,88 Mio. Tokens und bei NVFP4 von 3,60 Mio. auf 28,76 Mio. Tokens, also um etwa das 7,9-Fache. Aktiviert wird es mit --decode-context-parallel-size 8, und es setzt den standardmäßigen FP8-KV-Cache voraus. Prefill Context Parallelism in Kombination mit DCP senkt die Time to First Token um bis zu 1,6-fach, und DSpark funktioniert unter beiden.

vLLM zufolge kostete DCP mit Sparse MLA anfangs bei 60k Kontext rund 7 ms pro Decode-Schritt. Das Team ersetzte NCCL-All-Gathers und -Reduce-Scatters durch einen All-to-all-Combine über Symmetric Memory (vllm#61285), einen direkten Top-k-Austausch zwischen den Ranks und eine Top-k-Kompaktierung für Batches ab 32 Tokens.

Die Version umfasst zudem NIXL-basierte Prefill/Decode-Disaggregation mit DP/EP-, TP- und PCP×DCP-Prefill-Knoten, mit DSpark auf beiden Seiten, sowie HiSparse, ein Sparse-KV-Offload in den Host-Speicher, das nun schichtübergreifendes KV-Sharing unterstützt.

Was das für Nutzer bedeutet

Für Teams, die Modelle selbst hosten, liefert die Version ein fertiges Docker-Image und getestete Befehle, um ein Modell mit 1 Billion Parametern auf FP8- oder NVFP4-Hardware zu betreiben, auch auf AMD-GPUs. Die von vLLM berichteten NVFP4-Ergebnisse deuten auf eine schlankere Option mit ähnlichen Eval-Werten hin, während DCP auf Workloads mit sehr langen Kontexten zielt. Mehrere der Änderungen, etwa KV-Sharing und die Verbesserungen beim Context Parallelism, gelten als generisch, sodass auch andere Modelle profitieren könnten, sobald sie upstream übernommen sind.