890 Byte pro Token: Wie DeepSeek den KV-Cache komprimiert
Bei langen Kontexten kostet meist der Speicher, 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, legt es für jeden Token im Kontext die Key- und Value-Werte der Attention ab. Dieses Zwischenergebnis heißt KV-Cache. Er wächst linear mit der Kontextlänge und bestimmt, wie viele lange Sitzungen gleichzeitig auf einer Karte laufen. Deshalb kostet ein langer Kontext meist Speicher und nicht Gewichte.
Wie viel Platz der KV-Cache belegt, lässt sich mit 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. Die Cache-Verwaltung kommt obendrauf und ist hier nicht eingerechnet.
DeepSeek komprimiert beim V4.1 Flash. Der offizielle Vergleich: Gegenüber der Vorgängergeneration sinkt der HBM-Bedarf des Modells auf ein Viertel, der SSD-Bedarf auf ein Achtel. Gegenüber dem 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 ist der Anteil der Kosten für Cache-Treffer hoch. 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 Ausweg in der Technik 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.