KV-Caching

KV-Caching (Key-Value-Caching) ist ein Zwischenspeicher in großen Sprachmodellen (LLMs), der bereits berechnete Zwischenergebnisse eines Wortbausteins (Token) festhält, damit das Modell sie beim nächsten Token nicht erneut berechnen muss. Ohne diesen Cache müsste die Ausführungsschicht (Inference-Engine, also die Software, die das Modell auf der GPU laufen lässt) bei jedem neuen Token die Beziehung zu allen vorherigen Token neu ausrechnen; mit dem Cache bleibt der Aufwand pro Token konstant und die Antwortzeit wächst nur linear mit der Textlänge statt quadratisch.

Was ist KV-Caching?

Ein Sprachmodell erzeugt Text Stück für Stück: jeweils einen Wortbaustein (Token), dann den nächsten. Für jeden Token muss das Modell prüfen, wie stark er sich auf die vorherigen Token bezieht; dieser Vergleichsschritt heißt Attention (Aufmerksamkeit). Dabei entstehen drei Zahlenlisten (Tensoren) pro Token: Query (die aktuelle Anfrage: „Worauf schaue ich?"), Key (der Adressteil: „Wer bin ich, damit man mich finden kann?") und Value (der Inhaltsteil: „Das ist mein Beitrag."). Der neue Token vergleicht seine Query mit den Keys aller bisherigen Token und liest die passenden Values aus. Ohne Cache müsste das Modell bei Token Nummer 1.000 die Keys und Values aller 999 vorherigen Token noch einmal neu berechnen; der Aufwand steigt quadratisch mit der Textlänge, die Antwortzeit kippt.

Der KV-Cache löst dieses Problem, indem jede Attention-Schicht ihre Key- und Value-Tensoren nach der Berechnung in einem Puffer im GPU-HBM-Speicher hält. Bei jedem neuen Token hängen Engine und Modell einen weiteren Key- und Value-Vektor pro Schicht an; die Query attendiert dann gegen den vollen Puffer. Der Aufwand pro Token bleibt konstant, die Gesamtinferenz linear in der Sequenzlänge. Das Ergebnis ist mathematisch identisch mit einer Neuberechnung ohne Cache, nur die Rechenkosten unterscheiden sich.

Der Cache lebt pro Sequenz separat und wächst linear mit deren Länge. Die Größe folgt einer festen Formel: 2 × num_layers × num_kv_heads × head_dim × dtype_bytes pro Token. Für Llama-3-70B (80 Schichten, 8 KV-Heads über Grouped-Query Attention, head_dim 128, FP16) entspricht das rund 320 KB pro Token pro Sequenz. Bei 32.000 Token Kontext und 16 parallelen Sequenzen kommt der KV-Cache auf rund 160 GB reines Zusatz-Memory, unabhängig vom Modellgewicht.

Der Begriff existiert, weil dieser Puffer die entscheidende Speicherkonstante moderner LLM-Inferenz ist. Er sitzt in der Inference-Engine (vLLM, TensorRT-LLM, SGLang, Hugging Face TGI, LMDeploy) unter der Attention-Schicht des Modells und ist über die API nicht adressierbar. Optimierungen wie [PagedAttention](https://arxiv.org/abs/2309.06180) (Block-basierte Verwaltung, Kwon et al. 2023), Prefix-Sharing (mehrere Sequenzen teilen den gemeinsamen Präfix im Cache) und KV-Cache-Quantisierung (FP8, INT8, INT4) setzen unter der Haube am selben Puffer an. Attention-Architektur-Varianten wie Multi-Query Attention (MQA), Grouped-Query Attention (GQA) und Multi-Head Latent Attention (MLA) verkleinern den Cache um Faktor 4 bis 32, ohne die Modell-Qualität nennenswert zu senken; ein Grund, warum diese Varianten in jedem aktuellen Open-Weight-Modell auftauchen.

Abgrenzung zu Context Caching, Semantic Caching und Context Window

Der Begriff wird häufig mit angrenzenden Cache-Konzepten vermischt, die auf anderen Ebenen sitzen. Die relevanten Trennlinien:

Die zentrale Trennlinie verläuft zwischen KV-Caching und Context Caching, weil beide dieselbe Datenstruktur nutzen. KV-Caching lebt in der Inference-Engine und optimiert die Generierung eines einzelnen Aufrufs; Prefill (Verarbeitung des Prompts) und Decode (Erzeugung der Antwort) teilen sich die berechneten Aktivierungen. Context Caching hebt diese Aktivierungen aus dem Aufruf heraus, persistiert sie über eine TTL und macht sie über die API adressierbar. Anthropic vermarktet das Feature als „Prompt Caching", Google Gemini als „Context Caching", OpenAI als automatischen Prefix-Cache. Unter jeder dieser Marketing-Bezeichnungen liegt ein KV-Cache mit Prefix-Sharing.

Semantic Caching und Response Caching operieren dagegen auf einer anderen Ebene: Sie speichern die fertigen Modell-Ausgaben und lassen die Zwischenzustände im Attention-Stack unangetastet. Semantic Caching ist damit sensibel für Halluzinationen (eine falsche Antwort bleibt im Cache) und für Modell-Updates (der Cache muss beim Modellwechsel invalidiert werden). Der KV-Cache hat diese Probleme nicht, weil das Modell in jedem Aufruf frisch generiert und der Cache nur den mechanischen Rechenweg abkürzt.

Beispiel: KV-Cache als Memory-Konstante beim Self-Hosting

Ein vLLM-Server betreibt Llama-3-70B in FP16 auf zwei H100 mit je 80 GB HBM (Tensor-Parallelismus). Das Modell selbst belegt rund 140 GB und passt damit knapp über beide Karten verteilt. Die Ziel-Konfiguration verlangt 32.000 Token Kontext und 16 parallel bediente Sequenzen. Ergebnis der Formel: rund 160 GB KV-Cache, also mehr als das Modellgewicht.

Ohne PagedAttention hält eine naive Implementierung diesen Cache als kontiguierlichen Speicherblock pro Sequenz. Da Sequenzen unterschiedlich lang sind und laufend enden, entsteht Fragmentierung; die effektive HBM-Auslastung fällt unter 60 Prozent, der Server kippt oft schon bei acht statt 16 parallelen Anfragen. PagedAttention löst das über Block-basierte Verwaltung (analog zu Virtual Memory in Betriebssystemen), teilt gleiche Präfixe (Systemprompt, Tool-Definitionen) zwischen Sequenzen und trägt auf identischer Hardware das 5- bis 24-fache an Durchsatz. Die Modell-Qualität bleibt bit-identisch.

Die Architekturposition ist damit klar: Der KV-Cache ist die Speicherkonstante, an der Self-Hosting-Setups tragen oder kippen. Er entscheidet über GPU-Wahl (H100 80 GB, H200 141 GB, B200 192 GB), über Concurrency-Limits und über die Long-Context-Reichweite jedes Open-Weight-Modells. Wer Inference-Engines vergleicht, ohne den KV-Cache-Bedarf pro Workload durchgerechnet zu haben, wählt nach Marketing-Throughput und landet auf der falschen Karte.