senn-techZwei vLLM-Builds für Qwen3.8-Flash-Next im Vergleich: schneller im Decode, knapper im Speicher
Seit dem 16. September kann vLLM den KV-Cache von Qwen3.8-Flash-Next ohne fremden Patch in FP8 halten. Bis dahin lief unsere Produktion auf einem Build vom Veröffentlichungstag des Modells, in den wir den FP8-Patch aus einem offenen GitHub-Ticket eingebaut hatten. Am Abend des 24. September haben wir beide Builds auf derselben Maschine gegeneinander gemessen. Der neue dekodiert deutlich schneller. Produktiv geht er trotzdem noch nicht, weil ihm bei langen parallelen Anfragen der Speicher knapp wird.
Was wir verglichen haben
Die Maschine hat vier RTX 5090 mit je 32 GB, das Modell läuft mit Tensor- und Expertenparallelität über alle vier Karten. Die Einstellungen waren in beiden Läufen gleich: 220.000 Token Kontext, acht gleichzeitige Anfragen, FP8-KV und ein fest vorgegebenes KV-Budget von 7.440.208.896 Byte je Karte.
Der alte Build ist die vLLM-Fassung vom Erscheinungstag des Modells (0.1.dev20073) mit vier eigenen Änderungen: dem FP8-Patch aus RFC 54426, einem Schalter für die FP8-Einbettungstabelle, einer Korrektur für freigegebene Mamba-Blöcke und einer Korrektur im Tool-Call-Parser. Der neue Build ist der Nightly 0.30.1rc1.dev48 vom 24. September. Er enthält PR 55557 mit FP8-KV auf dem QSA-Pfad und den FP8-Index-Cache aus Version 0.30.0. Von unseren Änderungen braucht er nur noch die Parser-Korrektur, die als kleiner Diff mit ins Image kam. Die anderen drei sind im Hauptzweig angekommen oder durch eine Konfigurationsoption ersetzt.
Die Version 0.30.0 selbst kam nicht in Frage. Ihr Code lehnt FP8 auf dem QSA-Pfad noch mit „requires a BF16 main KV cache“ ab, damit hätte der KV-Pool nur halb so viel Platz.
Wie der Wechsel ablief
Ein Skript hat den Produktionscontainer gestoppt und umbenannt, nicht gelöscht, und den neuen Build auf demselben Port gestartet. Während dieser Zeit liefen die Anfragen über das Gateway auf eine einzelne RTX 5090 in einem anderen Server, die für diesen Fall bereitsteht. Danach prüfte das Skript nacheinander, ob der Server gesund meldet, wie groß der KV-Pool ist, ob Nadeln in 35.000 bis 180.000 Token langen Texten gefunden werden, ob gestreamte Tool-Calls gültiges JSON ergeben, wie viele unserer 21 Testfragen richtig beantwortet werden und ob acht parallele Anfragen ohne Speicherwarnung durchlaufen. Die Vergleichswerte des alten Builds hatten wir eine Stunde vorher mit denselben Skripten im laufenden Betrieb erhoben.
Die Messwerte
Die Antwortqualität ist gleich: Beide Builds beantworten 18 von 21 Testfragen richtig und scheitern an denselben drei. Die Zeit bis zum ersten Token sank im Median von 1,23 auf 0,79 Sekunden. Beim Dekodieren liegt der neue Build mit 138,9 gegen 94,3 Token pro Sekunde rund 47 Prozent vorn.
Der KV-Pool wuchs bei gleichem Byte-Budget von 1.041.901 auf 1.064.800 Token. Das liegt am FP8-Index-Cache, der die Nebenstrukturen der sparsamen Aufmerksamkeit kleiner speichert. Bei 220.000 Token Kontext sind das 4,84 statt 4,74 volle Sitzungen gleichzeitig.
Beim Einlesen langer Texte ist der neue Build langsamer. Eine einzelne Anfrage mit 180.000 Token brauchte 15,7 statt 15,1 Sekunden. Vier gleichzeitige Anfragen mit je rund 128.000 Token waren nach 55 statt nach 39 Sekunden fertig. Auch das Laden der Gewichte dauerte länger, 151 statt 107 Sekunden je Karte.
Warum der alte Build in Produktion bleibt
Im Paralleltest mit den vier langen Anfragen meldete der neue Build zwölfmal, dass eine Speicheranforderung von 205 MB fehlschlug, bei rund 200 MB freiem Speicher je Karte. vLLM hat sich davon erholt, der Server lief weiter und bestand danach auch den Lasttest mit 32 gleichzeitigen Anfragen. Der alte Build zeigte im selben Test keine einzige dieser Warnungen.
Wir nehmen die Warnung ernst, weil genau sie am selben Abend um 20:40 Uhr einem Absturz des alten Builds vorausging. Damals war das KV-Budget noch zehn Prozent größer, acht Anfragen liefen gleichzeitig, und eine Anforderung von 188 MB traf auf rund 100 MB freien Speicher. Der Server beendete sich, und die Anfragen liefen eine Viertelstunde lang über die Ausweichkarte. Danach haben wir das Budget auf den heutigen Wert gesenkt.
Außerhalb des KV-Caches braucht der Nightly also mehr Arbeitsspeicher als die gepatchte Fassung. An der Größe der Prefill-Blöcke liegt es nicht, beide arbeiten mit 2.048 Token. Die genaue Ursache haben wir noch nicht gefunden. Um denselben Sicherheitsabstand zu haben, müssten wir das KV-Budget um etwa ein Gigabyte je Karte senken. Der Pool fiele dann auf ungefähr 900.000 Token.
Das wäre für unsere Last vermutlich verkraftbar. Am 24. September lag die KV-Auslastung tagsüber bei höchstens 70 Prozent, der Engpass waren die acht Plätze für gleichzeitige Anfragen, und bis zu 41 Anfragen warteten in der Schlange. Ein schnellerer Decode gibt diese Plätze früher wieder frei. Bevor wir das Budget senken und den Nightly in Produktion nehmen, wollen wir aber wissen, wofür er den zusätzlichen Speicher braucht.
Das Skript hat nach der siebten Prüfung selbst zurückgerollt. Nach sieben Minuten meldete die gepatchte Fassung wieder gesund, und die Neustart-Regel stand wieder auf dem ursprünglichen Wert.
Wie belastbar die Zahlen sind
Beide Läufe fanden im laufenden Betrieb statt, mit Agentenlast, die wir nicht steuern. Jede Messung lief einmal. Die Unterschiede bei der Decode-Geschwindigkeit und bei den Speicherwarnungen sind groß genug, dass wir sie für echt halten. Die Differenz bei der einzelnen 180.000-Token-Anfrage von 0,6 Sekunden liegt dagegen im Bereich dessen, was ein paralleler Agentenaufruf ausmachen kann.
Was wir als Nächstes tun
Das Image, das Startskript und das Wechselskript liegen auf der Maschine bereit. Wenn vLLM 0.31 mit PR 55557 erscheint oder ein Nightly den Speicherbedarf senkt, genügt ein neuer Image-Name und ein weiterer Lauf mit denselben sieben Prüfungen. Wer Qwen3.8-Flash-Next auf Karten mit 32 GB betreibt und auf den Nightly wechseln will, sollte vorher mehrere lange Anfragen gleichzeitig schicken und das Log nach „memory allocation failed“ durchsuchen, denn der Health-Check bleibt dabei grün.
Weiterführende Quellen
Warum läuft in Produktion weiter der alte vLLM-Build, obwohl der neue schneller dekodiert?+
Der neue Build kam bei vier parallelen Anfragen mit je 110.000 Token bis auf rund 200 MB freien Speicher je Karte heran und meldete zwölf Speicherwarnungen. Der alte Build blieb im selben Test ohne Warnung. Genau dieses Muster ging am selben Abend einem Absturz des alten Builds voraus. Mit einem kleineren KV-Pool wäre der neue Build sicher, hätte dann aber weniger Kapazität als heute.
Ist FP8-KV für Qwen3.8-Flash-Next jetzt in einer vLLM-Version enthalten?+
Im Hauptzweig ja, seit dem Merge von PR 55557 am 16. September 2026. Die Version 0.30.0 lehnt FP8 auf dem QSA-Pfad noch ab. Wer ohne eigenen Patch arbeiten will, braucht bis zur nächsten Version einen Nightly-Build.
Wie haben Sie den Wechsel abgesichert?+
Mit einem Skript, das den alten Container nur beiseitestellt, den neuen startet, sieben Prüfungen abarbeitet und bei einem Fehler selbst zurückrollt. Während des Wechsels beantwortete eine zweite Karte die Anfragen. Der Rückweg dauerte sieben Minuten.