Der KV-Cache erklärt: Warum langer Kontext eine Speicherrechnung ist und keine Intelligenz

Wer Speicher für lokale Modelle durchrechnet, stößt ständig auf den Begriff „KV-Cache“. Er ist leicht zu berechnen und überraschend schwer zu erklären. Dieser Text ist reine Theorie, ohne Hardwareauswahl und ohne Dateiformate. Am Ende wissen Sie, was im Cache liegt, warum ein Modell ohne ihn nicht laufen kann und warum ein größeres Kontextfenster in Wahrheit eine Anfrage nach Speicher ist und nicht nach Intelligenz.

Warum es den Cache gibt

Ein Sprachmodell schreibt ein Token nach dem anderen und blickt dabei auf alle vorherigen zurück, um das nächste zu wählen. Dieser Blick zurück heißt Attention (Aufmerksamkeit), und er ist ein teurer Schritt.

Stellen Sie sich nun vor, es gäbe gar keinen Cache. Um Token 5 zu erzeugen, verarbeitet das Modell die Tokens 1 bis 4. Für Token 6 die Tokens 1 bis 5. Für Token 7 die Tokens 1 bis 6. Dieselbe Arbeit wird an denselben Tokens wiederholt, und die Verschwendung wächst mit jedem neuen Wort.

Der Cache macht aus wiederholter Arbeit gespeicherte Arbeit. Das Modell achtet weiterhin auf jedes vorherige Token, berechnet sie aber nicht jedes Mal neu. Der Beitrag jedes Tokens wird einmal berechnet, gespeichert und für den Rest des Gesprächs wiederverwendet. Pro Token werden zwei Dinge gespeichert, daher der Name.

Queries, Keys und Values

Ein Token beginnt als Liste von Zahlen, Embedding genannt – man kann es sich als die Bedeutung des Tokens vorstellen, als Koordinaten notiert. Das Modell multipliziert dieses Embedding mit drei separaten, trainierten Matrizen. Sie werden beim Training festgelegt und ändern sich danach nicht mehr. Jede macht aus derselben Eingabe einen anderen Vektor.

Die drei Matrizen gehören zu den Gewichten des Modells und sind für alle Tokens gleich. Nur das eingehende Embedding unterscheidet sich, deshalb hat jedes Token seine eigenen drei Ausgangsvektoren.

Denken Sie an eine Bibliothek. Jedes Buch trägt ein Etikett auf dem Rücken und Text im Inneren. Das Etikett spielt die Rolle des Keys, der Text die Rolle des Values und die Frage, mit der ein Besucher kommt, die Rolle der Query. Niemand liest das ganze Regal. Besucher überfliegen die Buchrücken, wählen die passenden Etiketten und öffnen nur diese Bücher. Attention macht dasselbe mit einer Abwandlung: Sie öffnet alle Bücher und mischt dann ihren Inhalt, wobei sie denen mehr Gewicht gibt, deren Etiketten besser zur Frage passen.

Keys dienen dem Abgleich, Values dem Inhalt. Diese Trennung erklärt, warum beide gespeichert werden müssen. Das eine entscheidet, wie wichtig ein früheres Token ist, das andere teilt mit, was darin steht.

Was weggeworfen wird und was bleibt

Nur das neueste Token stellt eine Frage. Ist sein Zug vorbei, ist die Frage beantwortet und wird nicht mehr gebraucht – deshalb werden Queries verworfen.

Bei Keys und Values ist es anders. Auf Key und Value von Token 5 greift das Modell zurück, wenn es Token 6 schreibt, Token 600 und Token 60.000. Und sie ändern sich nie, denn nichts, was danach geschieht, ändert, was Token 5 beigetragen hat. Einmal berechnen und für immer behalten ist genau der richtige Kompromiss.

Warum der Cache so groß wird

Zurück in die Bibliothek. Jedes eintreffende Token füllt zwei Karteikarten aus – ein Etikett und eine Inhaltskarte – und legt sie in den Karteikasten. Solange das Gespräch offen ist, wird nichts gelöscht. Zwei Umstände machen diesen Kasten größer, als er wirkt.

Erstens haben Modelle viele Schichten, und jede Schicht hat ihre eigene Bibliothek. Achtzig Schichten bedeuten achtzig Gebäude, und in jedem wird pro Token ein Kartenpaar abgelegt. Zweitens teilt jede Schicht die Arbeit auf mehrere Leser auf, Heads genannt, und jeder Leser legt sein eigenes Paar an, sodass sich die Anzahl noch einmal multipliziert.

Bei diesem Modell kostet ein Token Gespräch 320 KiB. Tausend Tokens kosten 320 MiB. Der Cache ist pro Token winzig und pro Gespräch riesig.

Das Ganze als eine Formel

All das lässt sich auf eine Zeile verdichten, und jeder Term steht in der config.json des Modells:

cache bytes = 2  ×  layers  ×  tokens  ×  kv_heads  ×  head_dim  ×  bytes_each
              │        │          │           │            │            │
              │        │          │           │            │            └ 2 at FP16, 1 at 8-bit
              │        │          │           │            └ numbers per head
              │        │          │           └ how many key/value sets per layer
              │        │          └ your context length
              │        └ every layer keeps its own
              └ one key and one value

Wählen können Sie nur einen Term. Schichten, Heads und Dimensionen sind beim Training festgelegt. Die Bytes pro Wert ergeben sich aus der Präzision des Caches. Tokens sind die Kontextlänge, und das ist der Regler, den Sie in der Hand haben.

Weil die Tokens in einer einfachen Multiplikation stehen, ist das Wachstum linear und gnadenlos: Verdoppeln Sie den Kontext, verdoppelt sich der Cache. Mengenrabatt für lange Gespräche gibt es nicht.

Zwei echte Modelle im Vergleich

Mit echten Zahlen wird es weniger abstrakt:

• Qwen3.6-27B hält einen wachsenden Cache nur in 16 seiner 64 Schichten, mit je 4 Sätzen von Keys und Values. Kosten: 64 MiB pro 1000 Tokens.
• Llama-3.1-70B hält ihn in allen 80 Schichten, mit je 8 Sätzen von Keys und Values. Kosten: 320 MiB pro 1000 Tokens.

Das ist pro Token fünfmal so teuer, und der Grund ist die Architektur, nicht die Größe. Die Parameterzahl eines Modells sagt nichts über die Rechnung für seinen Cache aus.

Noch ein Detail: Llama-3.1-70B hat 64 Leser, speichert aber nur 8 Kartensätze. Diese Diskrepanz ist Absicht. Gruppen von acht Lesern teilen sich einen Satz, statt dass jeder eine eigene Kopie anlegt. Die Technik heißt Grouped-Query Attention, und fast jedes moderne Modell nutzt sie. Es ist, als würden vierundsechzig Leute jeweils ihre eigene Zeitung kaufen, und stattdessen kursieren acht Exemplare im Büro. Lesen können weiterhin alle, aber die Rechnung vom Kiosk sinkt auf ein Achtel.

Die Ersparnis ist achtfach bei geringem Qualitätsverlust. Ohne sie bräuchte langer Kontext auf einem 70B-Modell mehr Speicher, als irgendeine einzelne Maschine hat.

Tokens in Seiten umrechnen

Tokenzahlen sind schwer vorstellbar, deshalb hier dieselben Fenster in vertrauten Leseeinheiten, gerechnet mit etwa drei Viertel Wort pro Token:

8K tokens  ≈   6,000 words  ≈   25 pages   a long report
32K tokens  ≈  25,000 words  ≈  100 pages   a short book
128K tokens  ≈  98,000 words  ≈  390 pages   a full novel
256K tokens  ≈ 197,000 words  ≈  790 pages   two novels

Wer ein 128K-Fenster anfordert, bittet das Modell, einen Roman im Kopf zu behalten und nicht mehr loszulassen. Übertragen wir das auf echte Hardware: Llama-3.1-70B mit 8-Bit-Gewichten auf einer Maschine mit rund 114 GiB verfügbarem Speicher.

context      weights      cache      total      left over
   8K        65.2 GiB     2.5 GiB    67.7 GiB    46.0 GiB
  32K        65.2 GiB    10.0 GiB    75.2 GiB    38.5 GiB
 128K        65.2 GiB    40.0 GiB   105.2 GiB     8.5 GiB

Bei 25 Seiten fällt der Cache kaum auf. Bei Romanlänge wächst er auf 40 GiB. Zum Vergleich: Das komplette Qwen3.6-27B mit allen Gewichten belegt 25 GiB – ein einziger Chat in Romanlänge auf dem 70B-Modell braucht also mehr Speicher, als ein gutes 27B-Modell insgesamt benötigt.

Die Gewichte haben sich nicht verändert. Verändert hat sich nur, wie viel Gespräch sich das Modell merken soll.

Ein langes Kontextfenster ist keine Einstellung. Es ist eine dauerhafte Speicherreservierung, die für jedes offene Gespräch neu bezahlt wird.

Dieser Teil wird oft übersehen. Gewichte sind wie der Warenbestand eines Ladens: einmal eingekauft, und alle Kunden sehen sich dasselbe an. Der Cache ist wie eine Umkleidekabine. Jeder Kunde braucht seine eigene, und sie bleibt belegt, bis er geht. Zwei Leser, die jeweils einen eigenen Roman lesen, brauchen zwei Caches mit je 40 GiB. Deshalb kommt ein Modell, das auf einem persönlichen Rechner bequem läuft, ins Schwitzen, sobald mehrere Leute es gleichzeitig nutzen.

Vier Wege, die Rechnung zu senken

Hier sind vier Hebel in der Reihenfolge, in der man sie ansetzen sollte.

1. Begrenzen Sie den Kontext passend zur Aufgabe. Das ist die billigste Lösung. Ein typischer Chat nutzt ein paar tausend Tokens, und 32K decken die meisten Programmieraufgaben ab. Wer für jede Aufgabe das maximale Fenster anfordert, zahlt jedes Mal den Höchstpreis.
2. Quantisieren Sie den Cache, aber mit Bedacht. Jede Zahl in 8 statt 16 Bit zu speichern, halbiert ihn. Der Haken: Keys und Values vertragen das unterschiedlich. Veröffentlichte Messungen zeigen, dass 8-Bit-Keys rund 98 % Übereinstimmung mit einem Lauf in voller Präzision halten, während 4-Bit-Keys auf etwa 12 % abfallen. Values vertragen eine gröbere Behandlung, also komprimieren Sie zuerst die Values und halten die Keys bei 8 Bit oder mehr.
3. Wählen Sie Architekturen, die dafür gebaut sind. Grouped-Query Attention ist inzwischen überall, und hybride Architekturen gehen weiter: Die meisten Schichten bekommen eine kleine Zusammenfassung fester Größe statt eines wachsenden Kartenstapels. So kann ein Modell 256K bewerben und trotzdem passen.
4. Überdenken Sie die Gewichte. Geringere Präzision bei den Gewichten macht Speicher für den Cache frei. In der 128K-Zeile oben machen 4-Bit-Gewichte aus 8,5 GiB freiem Platz 37,8 GiB.

Ein Modell mit Blick auf den Cache wählen

Rechnen Sie die Zahlen für drei Modelle nebeneinander durch, alle mit 8-Bit-Gewichten auf derselben Maschine, und das Bild kann sich in eine unerwartete Richtung verschieben.

Dasselbe Cache-Budget bringt beim besten der drei sechzehnmal so viel Kontext. Die Parameterzahlen unterscheiden sich, so wie man sie üblicherweise vergleicht, kaum, die Cache-Kosten aber um das 16-Fache.

Qwen3.6-35B-A3B ist hier das gute Modell für den Alltag. Bei 20 MiB pro 1000 Tokens ist Kontext fast gratis, und selbst das volle 256K-Fenster braucht nur 5 GiB Cache. Man muss nicht mehr mit Kontext geizen, und genau dafür lohnt sich eine leistungsstarke Maschine. Braucht eine kurze Aufgabe mehr Tiefe im Denken, ist der nächste Schritt das dichte 27B-Modell, pro Token dreimal so teuer – was immer noch wenig ist.

Llama-3.1-70B ist bei langem Kontext auf einer 114-GiB-Maschine schwerer zu rechtfertigen. Das Modell ist nicht schwächer. Bei 128K belegt es 105 GiB, und bei 256K will es 145 GiB, die schlicht nicht da sind. Um seinen Cache bei vernünftigen 20 GiB zu halten, müsste man den Kontext auf etwa 66K begrenzen. Wenn ein Modell einen ohnehin zum Geizen mit Kontext zwingt, steckt man den Speicher besser in eines, das das nicht tut.

Daraus folgt eine nützliche Gewohnheit: Schauen Sie sich die Cache-Kosten pro 1000 Tokens vor der Parameterzahl an. Die Parameter sagen, was es kostet, das Modell zu laden. Die Cache-Zahl sagt, was es kostet, es zu benutzen. Das sind Antworten auf verschiedene Fragen, und der Modellname wirbt nur mit einer davon.

Kurz gesagt

Der KV-Cache ist eine Aufzeichnung des bisherigen Gesprächs, einmal pro Token angelegt, damit das Modell sie nie neu berechnen muss. Für jedes Token, in jeder Schicht und für jeden Satz von Keys und Values speichert er einen Key, der entscheidet, wie wichtig dieses Token ist, und einen Value, der festhält, was das Token beiträgt.

Er ist außerdem der einzige Teil der Speicherrechnung, der wächst, während das Modell läuft. Gewichte kosten beim Laden einen festen Betrag, der Cache dagegen ist eine laufende Ausgabe, die mit der Zahl der Tokens und der offenen Gespräche steigt.

Wenn Sie das nächste Mal eine Kontextlänge festlegen, denken Sie in Gigabyte statt in Tokens. Bei den hier betrachteten Modellen kostet ein 128K-Fenster je nach Wahl zwischen 8 und 40 GiB – die Entscheidung sollte also bewusst fallen.