890 Byte pro Token: So komprimiert DeepSeek den KV-Cache
Bei langen Kontexten ist der Speicher oft der Engpass, nicht die Gewichte. DeepSeek V4.1 Flash drückt den KV-Cache auf rund 890 Byte pro Token. Der HBM-Bedarf sinkt auf ein Viertel der Vorgängergeneration, der SSD-Bedarf auf ein Achtel.

Verarbeitet ein Modell ein langes Dokument, speichert es für jeden Token im Kontext die Key- und Value-Werte der Attention. Dieses Zwischenergebnis ist der KV-Cache. Er wächst linear mit der Kontextlänge und bestimmt, wie viele lange Sitzungen gleichzeitig auf einer Karte laufen. Deshalb ist bei langen Kontexten meist der Speicher der Engpass, nicht die Gewichte.
Wie viel Platz der KV-Cache belegt, lässt sich an einem offenen Modell nachrechnen. Die öffentliche Konfiguration von Qwen3-8B ergibt unter BF16 oder FP16 bei 2 Byte pro Zahlenwert pro Token eine KV-Datenmenge von 147456 Byte, also etwa 147 KB. Die Rechnung lautet: 2 mal K/V mal 36 Schichten mal 8 KV-Köpfe mal 128 Dimensionen pro Kopf mal 2 Byte. Zusätzliche Overheads wie die Cache-Verwaltung sind hier nicht eingerechnet.
DeepSeek setzt beim V4.1 Flash auf Kompression. Der offizielle Vergleich: Gegenüber der Vorgängergeneration sinkt der HBM-Bedarf des Modells auf ein Viertel, der SSD-Bedarf auf ein Achtel. Im Vergleich zum ersten Modell ist der KV-Cache um den Faktor 437 kleiner. Aus offiziellen Angaben und verschiedenen Beschreibungen ergibt sich für V4.1 Flash ein KV-Cache von rund 890 Byte pro Token.
Warum zählt diese Zahl? Bei Agent-Aufgaben machen die Kosten für Cache-Treffer einen hohen Anteil aus. Ein Coding-Agent liest wiederholt Code, sucht Material und führt Tests aus. Die Historie wächst dabei immer weiter. Passt sie nicht in den Grafikspeicher, löscht das System einen Teil des Caches. In der nächsten Runde muss das Prefill erneut laufen, und die Nutzer warten länger auf das erste Token.
Der technische Ausweg ist die Aufteilung in Stufen. Daten, die gerade erzeugt werden, bleiben im HBM. Was kurzfristig wiederverwendet werden könnte, wandert in den DDR-Speicher auf der CPU-Seite. Länger nicht zugegriffene Daten sinken auf SSD oder entfernten Speicher ab. Das KV Offloading von vLLM etwa lagert Cache-Blöcke in den CPU-Speicher aus und lässt sich um eine zweite Speicherebene ergänzen. Der Rückweg führt über die Cache-Ebene auf der CPU-Seite.
890 Byte sind also nicht nur eine Zahl. Derselbe Grafikspeicher trägt mehr gleichzeitige lange Sitzungen, und Teams mit eigenem Inferenzdienst kaufen weniger Karten. Für Einkauf und Betrieb ist die Größe des KV-Cache inzwischen genauso wichtig wie die Qualität des Modells. Sie gehört in die Auswahlliste.
Quellen
3Alle Zahlen und Zitate in diesem Text stammen aus den unten genannten Quellen.
Die Materialien wurden vom Redaktionsteam mit Unterstützung von KI erstellt.
Kommentare
0- Noch keine Kommentare — seien Sie der Erste.