senn-techKV-Cache in 4 Bit: 8,8 statt 4,7 volle Sitzungen auf denselben vier RTX 5090
Seit dem Abend des 2. Oktober läuft unsere Produktions-Lane für Qwen3.8-Flash-Next mit einem KV-Cache in 4 Bit. Der Pool wächst dadurch von 1.041.901 auf 1.944.081 Token. Bei 220.000 Token Kontext pro Anfrage heißt das: 8,8 statt 4,7 volle Sitzungen passen gleichzeitig in den Grafikspeicher. Die Antwortqualität blieb in allen Prüfungen unverändert, die Geschwindigkeit im Einzelstrom sank um acht Prozent. Gleiches Modell, gleiche vier RTX 5090, gleiches Speicherbudget je Karte.
Was wir geändert haben
Der KV-Cache ist der Teil des Grafikspeichers, in dem das Modell den bisherigen Verlauf einer Anfrage vorhält. Bisher lag er bei uns in FP8, also mit einem Byte pro Wert. Der Schalter int4_per_token_head speichert jeden Wert in 4 Bit und legt die Skalierungsfaktoren pro Token und Attention-Kopf dazu. Das ergibt 264 Byte pro Kopf und Token bei einer Kopfdimension von 256, rund die Hälfte der bisherigen Belegung.
Zwei Details mussten dafür gelöst werden. Unsere vLLM-Fassung kennt den Schreibpfad für INT4 bereits, die Sparse-Attention-Schichten des Modells lasen den Cache aber weiterhin als FP8. Wir haben die Leseseite auf denselben Stand gebracht und gegen die Referenzimplementierung geprüft. Außerdem verweigerte der Server mit der üblichen Blockgröße von 800 Token den Start. Der Mamba-State belegt je Sitzung 408.576 Byte und teilt sich die Seiten mit dem KV-Cache. Eine 800er-Seite fasst bei INT4 nur 211.200 Byte. Mit Blockgröße 1600 passen 422.400 Byte auf eine Seite, und der Server startet.
Derselbe Mamba-State ist auch der Grund, warum der Pool um das 1,7- bis 1,87-Fache wächst und nicht exakt auf das Doppelte. Sein Platzbedarf bleibt gleich, während der KV-Anteil schrumpft.
Die Messwerte
Beim Dekodieren ist der INT4-Lauf im Einzelstrom langsamer: 90,7 gegen 98,6 Token pro Sekunde, gemessen an denselben Prompts bei Temperatur null. Unter paralleler Last fällt das kaum ins Gewicht, weil Anfragen seltener auf freien Cache-Platz warten. Der erste Start mit dem neuen Image dauerte knapp zehn Minuten, weil neue Kernel-Pfade kompiliert werden. Folgestarts liegen bei etwa fünf Minuten.
Die Zahl der gleichzeitigen Anfragen bleibt bei acht, dieser Deckel ist unverändert. Was sich ändert: Alle acht Plätze dürfen jetzt gleichzeitig den vollen Kontext belegen. Vorher teilten sich acht Plätze rechnerisch 4,7 volle Sitzungen, und sehr lange Dokumente mussten warten oder gekürzt werden.
Wie wir die Qualität geprüft haben
Vier Prüfungen, alle am 2. Oktober gelaufen. Ein Kernel-Harness vergleicht die INT4-Ausgabe direkt mit der Torch-Referenz: minimale Kosinus-Ähnlichkeit 0,99982. Dazu Nadel-Tests, bei denen ein versteckter Satz in langen Texten wiedergefunden werden muss. Die Nadel wurde bei 180.000 Token in der Mitte und bei 215.000 Token an den Tiefen 0,3 und 0,9 gefunden. Tiefer geht es auf dieser Konfiguration nicht, weil die Engine bei 220.000 Token begrenzt.
Vier Coding-Aufgaben bei Temperatur null lieferten auf beiden Cache-Formaten dieselben Algorithmen und Strukturen, mit kleinen Unterschieden in Variablennamen und Kommentaren. Zwei der Lösungen, eine LRU-Tabelle und ein Dijkstra, haben wir extrahiert und ausgeführt, beide funktional korrekt. Der letzte Test war ein gemischter Lauf mit vier parallelen Anfragen à rund 128.000 Token, sauber durchgelaufen.
Der Kernel-Zwischenfall am selben Tag
Der Tag hatte noch eine zweite Baustelle. Ein Routinelauf von apt full-upgrade installierte Kernel 7.0.0-38. Dabei baute DKMS das NVIDIA-Modul neu, allerdings aus dem unveränderten Quellbaum. Der Patch, der den direkten Speichertransfer zwischen unseren vier Karten ermöglicht, fehlte danach. Ohne ihn läuft der Austausch zwischen den Karten über den Hauptspeicher, und genau dieser direkte Pfad macht die Tensorparallelität schnell.
Wir haben die gepatchten Module aus unserem Klon von open-gpu-kernel-modules gegen die neuen Kernel-Headers gebaut, die Originalmodule vorher gesichert, den Server neu gestartet und mit nvidia-smi topo -p2p r geprüft: alle Kartenpaare wieder OK. Danach haben wir die Kernel- und NVIDIA-Pakete mit apt-mark hold angepinnt. Ein Kernel-Wechsel passiert jetzt nur noch bewusst, mit dem Rebuild im selben Zeitfenster.
Was das für den Betrieb heißt
Der Engpass der letzten Wochen war der Speicher für lange parallele Anfragen, nicht die Rechenleistung. Mit fast neun vollen Sitzungen im Cache rutschen lange Dokumente seltener in die Warteschlange, und die Agenten, die bei uns den ganzen Tag lesen und schreiben, bekommen ihren Kontext vollständig. Das FP8-Image bleibt auf der Maschine, dazu liegt ein Snapshot des Standes vor dem Wechsel. Wenn im Alltag bei sehr langen Kontexten Qualitätsauffälligkeiten auftreten, geht die Lane mit einem Befehl zurück auf FP8, bis die Ursache steht.
Weiterführende Quellen
- vLLM auf GitHub
- aikitoria/open-gpu-kernel-modules: der P2P-Patch für GeForce-Karten
- AI with Eric: Sparse Attention von Qwen3.8-Flash-Next im Test (Video, 27.08.2026)
- Cloud Codes: Qwen3.8-Flash-Next und das VRAM-Limit (Video, 28.08.2026)
- Der Build-Vergleich mit FP8-KV vom 24. September
- Wie FP8-KV in unsere Produktion kam
Warum wächst der Pool nicht auf genau das Doppelte?+
Der lineare Anteil des Modells, der Mamba-State, belegt je Sitzung 408.576 Byte und teilt sich die Speicherseiten mit dem KV-Cache. Sein Platzbedarf bleibt gleich, während der KV-Anteil halbiert wird. Gemessen landen wir je nach Start bei dem 1,7- bis 1,87-Fachen.
Wird die Antwortqualität durch 4-Bit-KV schlechter?+
In unseren Prüfungen vom 2. Oktober nicht. Der Kernel lag bei einer Kosinus-Ähnlichkeit von 0,99982 zur Referenz, Nadeln in 215.000 Token langen Texten wurden gefunden, und vier Coding-Aufgaben lieferten funktional identische Ergebnisse. Wir beobachten den Betrieb trotzdem weiter, weil kein Test den Alltag vollständig abbildet.
Was passiert, wenn sich im Betrieb doch ein Problem zeigt?+
Der Rückweg ist ein einziger Befehl und dauert gut sechs Minuten. Das FP8-Image und ein Snapshot vom 2. Oktober liegen dafür bereit. Danach läuft die Lane wieder mit dem Pool von 1.041.901 Token.