Qwen3.8-Flash-Next in Produktion: Wie ein Community-Patch den KV-Cache auf 4× RTX 5090 verdoppelt hat

Vor einer Woche stand an dieser Stelle das Urteil: Qwen3.8-Flash-Next läuft stabil, aber nicht als Produktionsspur, weil llama.cpp acht gleichzeitige Anfragen auf zusammen 50,7 Token/s drückt. Das Urteil war richtig und ist trotzdem überholt. Seit dem 3. September bedient das Modell bei uns die Spuren für Text, Reasoning, Vision und den Coding-Agenten, seit dem 6. September mit einem FP8-KV-Cache, der die Zahl gleichzeitiger Vollsitzungen fast verdoppelt hat. Der Weg dorthin ist die eigentliche Geschichte, weil er an drei Stellen anders verlief als geplant.

Erster Umweg: der Checkpoint, den es nicht gab

Auf vLLM gibt es zwei brauchbare Fassungen des Modells: die FP8-Variante von Qwen mit 180 Milliarden Parametern insgesamt und eine NVFP4-Quantisierung von Inferact mit 118 Milliarden. Keine der beiden passt allein auf vier RTX 5090 mit zusammen 128 GB VRAM und 124 GB Hauptspeicher. Die FP8-Fassung ist zu groß, die NVFP4-Fassung trägt die 51-Milliarden-N-Gram-Tabelle in einem Format, das der Loader auf unserer Hardware nicht annimmt. Ein verwandtes Ladeproblem mit einer anderen NVFP4-Fassung ist als Issue #54765 offen.

Also haben wir beides gemischt: die FP8-N-Gram-Tabelle aus dem Qwen-Checkpoint, die NVFP4-Experten aus dem Inferact-Checkpoint, zusammengeführt per Skript, plus ein kleiner Patch in der Embedding-Schicht, damit vLLM die FP8-Tabelle neben NVFP4-Gewichten akzeptiert. Ergebnis: 82,8 GiB Gewichte über vier Karten, Tensorparallelität 4, Expertenparallelität an.

Zweiter Umweg: eine Messung mit leeren Gewichten

Der erste vLLM-Lauf am 1. September lief nur mit dem langsamen Marlin-Backend. Jeder schnelle NVFP4-Kernel brach mit einem Padding-Fehler ab, und wir hielten fest: kein NVFP4-Backend beherrscht Expertenparallelität. Das war falsch. Der Test war mit --load-format dummy gelaufen, also ohne echte Gewichte, und genau dadurch griff die Erkennung des FP8-Tabellenformats nie. Mit echten Gewichten lud flashinfer_cutlass mit Expertenparallelität sauber und lieferte bei 32.768 Token Kontext 205 Token/s über 32 gleichzeitige Ströme. Das dichte 27B, das bis dahin die Produktion trug, sättigt bei rund 172.

Die Lehre ist unspektakulär und war trotzdem teuer: Ein Backend-Test ohne Gewichte prüft das Backend nicht.

Dritter Umweg: der KV-Cache, der nur BF16 kann

Die Sparse-Attention des Modells, von Qwen als QSA bezeichnet, verlangt im Auslieferungszustand einen BF16-KV-Cache. Mit --kv-cache-dtype fp8_e4m3, das auf dem 27B selbstverständlich war, sterben alle vier Worker beim Start. BF16 kostet je Token doppelt so viel Speicher wie FP8, und dieser Unterschied wächst linear mit der Kontextlänge. Bei den vollen 262.144 Token blieben 2,12 gleichzeitige Vollsitzungen übrig. Mit 192.000 Token und 94 Prozent Speicherausnutzung waren es 3,15, und so ging das Modell am 3. September in Betrieb.

Der Betrieb brachte sofort den nächsten Befund: bis zu 87 Anfragen in der Warteschlange bei nur 42 Prozent KV-Auslastung. Ursache war der Parameter --max-num-seqs 3, ein harter Deckel auf alle gleichzeitigen Anfragen, nicht nur auf die langen. Dazu kam ein interner Dienst, der werktags 1.680 Anfragen am Tag zur Stimmungsbewertung schickte. Der Dienst ist inzwischen ohne KI-Anbindung neu ausgerollt, der Deckel steht auf 8.

Der Patch aus dem Issue-Tracker

Am 30. August hatte ein Nutzer im vLLM-Repository einen RFC eröffnet: FP8-KV-Cache auf dem QSA-Pfad, funktionierender Patch, gemessen auf genau einer Maschine, einem DGX Spark, mit der Bitte um Bestätigung auf anderer Hardware. Der Diff ist klein, zwei Dateien, 17 Hunks, und er umgeht auch die Sperre, die FlashAttention auf unserer Kartengeneration sonst gegen FP8-KV einlegt. Wir haben ihn auf eine Kopie unseres Images gelegt und den Container mit dem neuen Datentyp gestartet. Alles andere blieb unverändert.

Vor dem Umschalten der Produktionsspur lief beides, BF16 und FP8, gegen dieselben Prompts bei Temperatur 0:

Damit war das RFC um eine zweite Hardware ergänzt, und zwar um eine, die im offiziellen vLLM-Rezept gar nicht vorkommt. Dort stehen 4× GB300, 8× H200, 4× H100 und 4× MI355X, kein einziger Consumer-Aufbau. Inzwischen liegen zwei Pull Requests für dieselbe Funktion vor: #55557 nur für FP8, eröffnet am 6. September, und #54846 für FP8 und NVFP4, der auf seiner Hardware 1,9× und 3,1× KV-Pool meldet. NVFP4 haben wir bewusst nicht genommen: Die Perplexity-Strafe ist real, und der Prefill verdoppelt sich.

Was das Modell heute kann und was nicht

Es bedient 192.000 Token je Anfrage, acht Anfragen gleichzeitig, rund 5,9 volle Sitzungen im KV oder etwa 45 typische Chats mit 25.000 Token. Vision funktioniert mit echten Bildern, Tool-Calling funktioniert. Die 262.144 Token des Datenblatts wären mit FP8-KV rechnerisch bei etwa 4,2 Vollsitzungen wieder erreichbar, gemessen haben wir das nicht.

Drei Dinge bleiben offen. Erstens ist Temperatur 0 nicht deterministisch, weil die Reduktionsreihenfolge über Tensor- und Expertenparallelität variiert; der Fix liegt als PR #55122 vor. In der Praxis heißt das: Dieselbe Anfrage kann einmal antworten und einmal ihr gesamtes Token-Budget im Nachdenken verbrauchen. Zweitens ist unsere 21-teilige Korrektheitsbatterie auf dem Hybrid-Checkpoint nie gelaufen, weder mit BF16 noch mit FP8; das Qualitätsgate oben ist ein Rauchtest. Drittens läuft Community-Code auf einem Entwicklungs-Build. Sobald einer der beiden Pull Requests gemergt ist, wechseln wir auf ein offizielles Image.

Zum Vergleich, was andere melden: Auf einer einzelnen RTX 5090 mit 128 GB RAM erreicht das Modell unter llama.cpp mit einer 2-Bit-Quantisierung rund 48 Token/s bei 64.000 Token Kontext. Der Intelligence Index von Artificial Analysis führt das Modell mit 46 Punkten, ausdrücklich als Schätzung. Beides passt zu dem, was wir vor einer Woche gesehen haben: Ein 125B-MoE mit 6 Milliarden aktiven Parametern spielt in der Liga eines dichten 27B. Was sich geändert hat, ist nicht die Qualität, sondern der Durchsatz je Karte.

Stand jetzt

Flash-Next trägt die Produktion. Der Rückweg ist dreistufig und dauert je Stufe rund sechseinhalb Minuten: ungepatchtes Image mit BF16-KV, dann die Fassung vom 3. September mit drei Slots, dann das dichte 27B, das gestoppt auf derselben Maschine liegt. Wenn die Warteschlange bei unter 70 Prozent KV-Auslastung wieder auftaucht, ist der nächste Schritt nicht mehr Speicher, sondern ein höherer Slot-Deckel.

Weiterführende Quellen

• Qwen3.8-Flash-Next auf Hugging Face
• On the Design of Qwen3.8-Next Architecture, arXiv 2608.30320
• vLLM: Quantized KV Cache
• vLLM-Rezept für Qwen3.8-Flash-Next
• RFC #54426: FP8-KV auf dem QSA-Pfad
• llama.cpp PR #27742: Flash-Next-Unterstützung
• Unser Vier-Tage-Test unter llama.cpp
• Der Cloud-Test mit vLLM und PLE-Auslagerung