Qwen3.8-Flash-Next auf vLLM 0.32: MTP verdoppelt den Einzelstrom, der Cache wird kleiner

Am 18. Oktober ist vLLM 0.32.0 erschienen. Es unterstützt Qwen3.8-Flash-Next ohne den Fork, den wir seit September fahren, und bringt Multi-Token-Prediction (MTP) für das Modell mit. Wir haben es am selben Tag auf der Maschine mit vier RTX 5090 getestet, auf der die Flash-Next-Spur läuft, und danach unseren NVFP4-Cache-Patch auf die neue Version übertragen.

Qwen3.8-Flash-Next: 125 Milliarden Parameter, 6 Milliarden aktiv, Gated-DeltaNet-Schichten im Wechsel mit Sparse Attention. (Quelle: Alibaba Cloud / Wikimedia, CC0)

Serie: Qwen3.8-Flash-Next im Eigenbetrieb, sechs Beiträge:

Qwen3.8-Flash-Next: 125B-MoE für den lokalen Stack? (31. August), die Ankündigung.

Qwen3.8-Flash-Next im Vier-Tage-Test (3. September), erste Tests mit llama.cpp.

Eine gemietete GPU statt der eigenen Produktion (4. September), Embedding-Tabelle in vLLM auslagern.

Qwen3.8-Flash-Next in Produktion (9. September), FP8-KV-Cache.

Ein Wort im vLLM-Fork (14. September), ein Fehler in der Block-Buchführung.

Dieser Beitrag (18. Oktober), vLLM 0.32, MTP und NVFP4.

Die Messreihe

Alle Läufe nutzen dieselbe Maschine, dasselbe Modell (ein Hybrid-Checkpoint aus FP8-Embeddings und NVFP4-Experten), 220.000 Token Kontext, acht Slots und vier Karten mit Tensor- und Expertenparallelität. Als Last dienten die Skripte aus unseren früheren Messungen und ein Replay von 156 echten Anfragen unserer Agentenspur aus dem Protokoll. Der Vergleichswert ist die bisherige Produktion, warm gemessen.

Ein Nutzer, 600 Token Antwort, ohne Reasoning, warmer Server. NVFP4-Lauf mit 7,0 GB KV-Reserve gemessen. (Quelle: senn-tech, eigene Messung vom 18. Oktober)

Die neue Engine allein bringt 25 Prozent. MTP sagt je Schritt drei Token voraus und prüft sie in einem Durchgang.

Pro Position wurden 62, 31 und 15 Prozent der Vorschläge akzeptiert (Startlog, Lauf mit FP8-KV). (Quelle: senn-tech, eigene Messung vom 18. Oktober)

Die mittlere akzeptierte Länge lag bei 2,1 bis 2,6 Token je Schritt. Bei acht gleichzeitigen Strömen stieg die Summe von 605 auf 1.148 bis 1.184 Token pro Sekunde, beim Prefill von 35.000 Token blieb FP8 mit 11.400 bis 11.800 Token pro Sekunde auf dem Niveau der alten Produktion (9.650).

Acht Ströme mit je 600 Token Antwort, ohne Reasoning, warmer Server. (Quelle: senn-tech, eigene Messung vom 18. Oktober)

156 echte Anfragen unserer Agentenspur, ursprüngliche Abstände auf die Hälfte gestaucht. (Quelle: senn-tech, eigene Messung vom 18. Oktober)

Im Replay der 156 Anfragen fielen die Antwortzeiten:

Konfiguration	Median	95. Perzentil
bisherige Produktion	7,8 s	41,4 s
vLLM 0.32, FP8-KV	5,2 s	30,5 s
vLLM 0.32, FP8-KV, MTP3	3,4 s	12,7 s
vLLM 0.32, NVFP4-KV, MTP3	4,3 s	22,5 s

Was der Cache kostet

Der Gewinn an Geschwindigkeit wird mit Cache bezahlt. Unter dem Strich passen weniger Sitzungen mit vollem Kontext gleichzeitig in den Speicher.

Aus dem Startlog von vLLM. Die Läufe verwenden 7,1 bis 7,6 GiB KV-Reserve je Karte, die alte Produktion 7,6. (Quelle: senn-tech, eigene Messung vom 18. Oktober)

MTP kostet den Pool 17,5 Prozent. Mit identischer Reserve von 7,6 GB fasst er ohne MTP 1.638.571 Token und mit MTP 1.351.242, denn die Draft-Schicht legt ihren eigenen KV-Cache im selben Pool ab, und ihre Gewichte nehmen 0,46 GiB je Karte. Den Rest bis zur alten Produktion (8,23 Sitzungen) haben wir nicht aufgeklärt. Die Blockgröße ist mit 1.600 Token gleich. Sicher ist nur, dass der Port beim Prefill mehr Aktivierungsspeicher braucht und wir deshalb weniger Reserve für den Cache vergeben können.

Der NVFP4-Cache musste portiert werden

NVFP4 ist NVIDIAs 4-Bit-Format mit Block-Skalen. Der Cache speichert Schlüssel und Werte darin und braucht so rund ein Viertel des Speichers von BF16. (Quelle: NVIDIA)

vLLM 0.32 beendet den Start mit NotImplementedError: Qwen4Exp QSA requires a BF16 or FP8-e4m3 main KV cache, sobald man --kv-cache-dtype nvfp4 setzt. Der Pull Request vLLM #54846 mit der Unterstützung ist offen, die FP8-Hälfte ist in #55557 gelandet. Wir haben die NVFP4-Teile per Drei-Wege-Merge auf 0.32 übertragen: Kernel-Zweig, Cache-Geometrie, Schreibpfad, Warmup. Kernel-Tests gegen eine Referenz in float64 liefen für alle Kachelprofile durch, und die Skalenanordnung haben wir am echten Schreiber von vLLM nachgemessen (K linear, V verschränkt).

Zwei der drei Fehler zeigten sich erst nach dem Start und liefen nicht als Absturz auf. (Quelle: senn-tech, eigener Betrieb)

Der zweite Fehler war der gefährliche. vLLM wählt für dieses Hybridmodell ein Speicherlayout, bei dem die K- und V-Köpfe pro Token verschränkt liegen. Dann überlappen die NVFP4-Skalen die Daten. Der Server startete, antwortete und lieferte nach wenigen Wörtern Buchstabensalat, ohne einen Fehler zu melden. Mit VLLM_KV_CACHE_LAYOUT=BLHNC ist das Layout kopfweise, und die Antworten stimmen. Danach lief der Prefill von 35.000 Token bei 8,2 GB Reserve in einen Speicherfehler, bei 7,6 GB nicht mehr, auch nicht bei 150.000 Token (25 Sekunden). Wer NVFP4 mit dem Port nutzt, braucht beides.

Offen ist der Prefill: Mit NVFP4 sinkt er auf 6.170 Token pro Sekunde, weil dem Port die Optimierungen unseres früheren Patches fehlen. Ob die vLLM-Issue #58422 (stilles Einfrieren bei MTP, NVFP4 und GDN auf SM120) uns trifft, haben wir mit einem Burst-Test geprüft: 120 Anfragen in zwölf Runden zu je zehn gleichzeitigen, null Fehler, kein stehender Token-Zähler.

Was wir nicht gemessen haben

Das Modell von NVIDIA liegt auf Hugging Face, ist mit Quantization-Aware Distillation erzeugt und enthält den MTP-Kopf. Es braucht einen Community-Container. (Quelle: Simple Icons, Datei huggingface.svg (CC0))

Die Antwortqualität gegenüber dem BF16-Modell ist nicht neu bestimmt. Unser Replay erkennt Zeichensalat und Abbrüche, keine feinen Verluste. NVIDIAs fertiges FP4-Modell (Qwen3.8-Flash-Next-FP4-Local) läuft laut Karte nur mit einem Community-Container, dessen Repository keine Lizenzdatei hat, deshalb haben wir es nicht getestet.

Auf der Maschine läuft derzeit der NVFP4-Port mit MTP3. Eine Woche echte Last steht noch aus. Wer ohne Zusatzpatch auskommen will, nimmt vLLM 0.32 mit FP8-KV und MTP3: schnellster Prefill, bestes 95. Perzentil, dafür 4,3 statt 6,1 Sitzungen mit vollem Kontext.

Weiterführende Quellen

Fragen?

Was bringt vLLM 0.32 für Qwen3.8-Flash-Next?+

Das Modell läuft ohne eigenen Fork. Die Release Notes nennen eine zusammengelegte Projektion in der Sparse-Attention (1,45- bis 1,68-fach schneller laut vLLM) und NVFP4-KV-Cache auf SM12x. Bei uns stieg der Einzelstrom von 104 auf 130 Token pro Sekunde, mit Multi-Token-Prediction auf 209. Der Boot dauert 280 statt 394 Sekunden.

Warum ist der Cache mit MTP kleiner?+

Die Draft-Schicht für die Spekulation legt ihren eigenen KV-Cache im selben Pool ab. Mit identischem Speicher fasst der Pool dadurch 17,5 Prozent weniger Token (1,64 statt 1,35 Millionen), außerdem belegen die Draft-Gewichte 0,46 GiB je Karte. Weniger spekulierte Token ändern daran nichts, die Schicht fällt je Token an.

Ist der NVFP4-Cache in vLLM 0.32 für dieses Modell fertig?+

Nein. Auf der Qwen-Attention bricht vLLM 0.32 mit NVFP4 beim Start ab, weil der PR 54846 noch offen ist. Wir haben ihn auf 0.32 portiert. Das läuft stabil in unseren Tests, ist aber ein Patch mit einem Autor und nicht Teil des Releases.