Kapitel 2 — Die KV-Cache-Herausforderung

Zweiter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel benennt die Datenstruktur, die jedem Serving-System das VRAM auffrisst, bevor die Gewichte überhaupt zum Zug kommen.

Warum es dieses Kapitel gibt

Die autoregressive Schleife aus Kapitel 1 vermeidet quadratische Arbeit durch Erinnerung. In jedem Dekodierschritt muss das Modell auf jedes vorangegangene Token achten, und dies jedes Mal von Grund auf zu tun würde bei jedem Durchlauf den gesamten Prefill wiederholen — ein N-facher Aufschlag über die Länge einer Vervollständigung hinweg. Der Key-Value-Cache ist der Arbeitsspeicher, der diese Arithmetik einspart. Er speichert die K- und V-Projektionen pro Token auf jeder Schicht, sodass spätere Tokens nur ihre eigenen K und V berechnen und die früheren zurücklesen. Der Cache ist der Grund, warum Dekodierung ungefähr O(N) statt O(N²) bleibt. Und er ist in jedem Produktionssystem, das ich mir angesehen habe, der größte einzelne VRAM-Verbraucher. Kapitel 2 geht die Formel ab, die seine Größe bestimmt, die architektonischen Varianten, die ihn schrumpfen, und das Fragmentierungsproblem, das die naive Art der Allokation zerstört.

2.1 Die Formel, die die Cache-Größe bestimmt

Der KV-Speicher für eine Sequenz ist 2 × L × H_kv × D × S × Bytes: zwei Tensoren (K und V), L Schichten, H_kv Key-/Value-Köpfe, Kopfdimension D, Sequenzlänge S und Bytes pro Element gemäß Präzision. Für die Flottenzahl multipliziert man mit der Batchgröße. Jede Achse geht multiplikativ ein. Llama-3-70B mit L=80, H_kv=8 (GQA), D=128, bei S=8.192 und BF16 hält etwa 40 GB Cache pro Sequenz — vor Batch. Bei Batch 32 nähert sich der Cache allein 1,3 TB, mehrfach den Gewichten und mehrfach dem VRAM einer H100. Llama-2-70B, das letzte große MHA-Modell, hat H_kv=64 statt 8, und sein Cache ist bei gleicher Konfiguration achtmal so groß. Die Formel ist keine Kuriosität; sie ist die Zahl, die bestimmt, wie viele gleichzeitige Nutzer ein Chip halten kann. Jedes andere Speicherbudget auf der Karte — Aktivierungen, Framework-Overhead, temporäre Puffer — muss sich darum herum einfügen.

2.2 MHA, GQA und MQA sind Cache-Größen-Design-Entscheidungen

Der Term H_kv ist der Term, an dem moderne Architekturen gearbeitet haben. Multi-Head-Attention (MHA) verwendet einen K- und V-Kopf pro Query-Kopf; der Cache ist dick, die Qualität am höchsten, und jeder Kopf kann seine Vorstellung von Aufmerksamkeit spezialisieren. Multi-Query-Attention (MQA) kollabiert auf einen einzigen geteilten K- und V-Kopf; der Cache schrumpft um den Faktor H, aber die Köpfe verlieren Spezialisierung und messbare Qualität geht bei längeren Kontexten verloren. Grouped-Query-Attention (GQA), 2023 eingeführt und inzwischen die vorherrschende Wahl für Llama-3, Mistral, Mixtral, Qwen und DeepSeek, teilt die Query-Köpfe in G Gruppen auf, die sich K und V teilen; ein typisches G = H/8 liefert eine achtfache Cache-Reduktion bei einem Qualitätsverlust, den Bewertungssuiten kaum verlässlich sehen können. GQA ist nicht umsonst — es reduziert auch die Parameterzahl der K/V-Projektionen, und dieses Budget wird anderswo im Modell verteilt —, aber empirisch schadet die Umverteilung selten. MLA (Multi-Latent Attention, DeepSeek-V2) geht mit einem niedrigrangigen latenten Cache weiter; es ist die Forschungsrichtung, aber Produktions­deployments sind 2026 GQA-dominiert.

2.3 Naive Allokation verschwendet den größten Teil des Budgets

Der naheliegende Weg, KV-Speicher zu allokieren — ein zusammenhängender Slab pro Sequenz, dimensioniert auf die maximal mögliche Länge — scheitert am realen Traffic. Die meisten Anfragen bleiben weit unter dem Maximum; der reservierte Rest ist toter Speicher. Auf Llama-3-70B mit einer 32K-Grenze verschwendet eine 1.000-Token-Vervollständigung 31 Slabs' Wert an KV-Cache. Batch 32 mit 8K-Limit und Durchschnittslänge 800 lässt zu jedem Zeitpunkt rund 90 Prozent des reservierten KV-Caches ungenutzt. Schlimmer noch: das Layout ist unflexibel; ein Neuankömmling kann den ungenutzten Rest einer anderen Sequenz nicht verwenden, weil dieser Rest bereits reserviert ist. Die Nebenläufigkeit stürzt auf das ab, was das Worst-Case-Budget zulässt, nicht auf das, was der durchschnittliche Traffic tragen würde. Das Problem heißt interne Fragmentierung — genau das Versagen, das Betriebssysteme in den 1960er-Jahren mit Paging gelöst haben. Kapitel 8 zeigt, wie PagedAttention diese Lösung übernimmt.

Was Kapitel 2 vorbereitet

Die Cache-Formel und ihre Achsen tauchen jedes Mal wieder auf, wenn spätere Kapitel darüber nachdenken müssen, wie viele Nutzer auf eine GPU passen. Kapitel 3 nutzt sie, um zu erklären, warum die VRAM-Kapazität bei der Wahl einer Serving-GPU wichtiger ist als FLOPs. Kapitel 7 nutzt sie, um zu erklären, warum Continuous Batching am KV-Cache und nicht am Modell begrenzt ist. Kapitel 8 nutzt sie, um PagedAttention, H2O-Eviction und Präfix-Caching zu rechtfertigen — drei Techniken, deren einziger Zweck es ist, den Cache eher wie einen paged virtuellen Speicher als wie einen reservierten Byte-Slab arbeiten zu lassen. Die Formel ist die Grammatik der weiteren Speicherargumente dieses Buches.

Als Nächstes — Kapitel 3: Rechenzentrums-GPUs für generative KI. Das Silizium, das sowohl die Gewichte als auch den KV-Cache halten muss, gelesen nach Mechanismus statt nach Datenblatt.