Was ist ein KV-Cache? Wie LLMs Attention-Zustände wiederverwenden

Ein KV cache (Key-Value-Cache) ist eine Inferenzoptimierung, bei der ein großes Sprachmodell die pro Schicht berechneten Key- und Value-Attention-Tensoren bereits verarbeiteter Token speichert. Bei der autoregressiven Decodierung verwendet das Modell diese gespeicherten Zustände wieder, statt bei jedem Schritt alle früheren Token neu zu berechnen. Das reduziert redundante Berechnungen bei wachsenden Sequenzen.

Ob Sie gehostete APIs aufrufen oder Modelle mit offenen Gewichten auf eigenen GPUs ausführen: Der KV cache steht im Zentrum von Latenz, Speicherdruck und Durchsatz. Wer seine Funktionsweise versteht, erkennt, warum sich die Zeit bis zum ersten Token von der Streaming-Geschwindigkeit unterscheidet, warum lange Kontexte so viel VRAM verbrauchen und warum Prompt-Caching über API-Anfragen hinweg exakt übereinstimmende Präfixe erfordert.

Wie funktioniert Attention ohne KV cache?

Ohne KV cache muss ein autoregressiver Transformer jedes Mal, wenn er ein einzelnes neues Token in einem KI-Modell generiert, die Attention-Projektionen für die gesamte Sequenz von Grund auf neu berechnen.

In jeder Decoder-Schicht des Transformers projiziert Self-Attention jede Eingabe-Tokenrepräsentation in drei Vektoren:

• Query ($Q$): Repräsentiert die aktuelle Position, die nach relevantem Kontext sucht.
• Key ($K$): Repräsentiert, was jede Position zum Abgleich mit Querys anbietet.
• Value ($V$): Enthält die Informationen, die nach der Berechnung der Attention-Gewichte aus den Query-Key-Skalarprodukten zusammengeführt werden.

Da reine Decoder-Sprachmodelle Text Token für Token generieren, benötigt die Generierung von Token $t+1$ nur den Query-Vektor des neuesten Tokens, um auf die Keys und Values der Token $1$ bis $t$ zuzugreifen. Verwirft die Laufzeit diese Keys und Values nach der Ausgabe von Token $t$, muss Schritt $t+1$ jedes Präfix-Token erneut durch alle Schichten laufen lassen, nur um exakt dieselben $K$- und $V$-Tensoren wiederherzustellen. Mit längerem Prompt und längerer Ausgabe wächst diese wiederholte Arbeit über den gesamten Generierungsdurchlauf quadratisch.

Warum ermöglicht kausale Attention das KV-Caching?

Kausale Maskierung stellt sicher, dass die Key- und Value-Tensoren eines Tokens nur von vorhergehenden Token abhängen, niemals von später generierten Token.

In einem kausalen Decoder (von links nach rechts) kann Token $i$ auf keine Position $j > i$ zugreifen. Da Informationen nur vorwärts durch die Sequenz fließen:

1. Ist die Repräsentation von Token $i$ in Schicht $l$ vollständig festgelegt, sobald die Token $1 \dots i$ verarbeitet wurden.
2. Verändert das Anhängen von Token $i+1$ am Ende der Sequenz in keiner Schicht die verborgenen Zustände, Keys oder Values der Positionen $1 \dots i$.
3. Kann die Laufzeit die neu berechneten Vektoren $K_{i+1}$ und $V_{i+1}$ an einen Puffer pro Schicht, den KV cache, anhängen und beim nächsten Decodierungsschritt nur das neueste Token übergeben.

Wie der Hugging Face Transformers KV cache-Leitfaden und die Übersicht zur Transformers-Cache-Architektur dokumentieren, verwandelt Caching jeden Decodierungsschritt von einem Durchlauf über die gesamte Sequenz in eine inkrementelle Aktualisierung eines einzelnen Tokens, die frühere Keys und Values aus dem Speicher liest.

Wie nutzen Prefill und Decode den KV cache unterschiedlich?

Die LLM-Inferenz besteht aus zwei getrennten Phasen, Prefill und Decode, die auf grundlegend unterschiedliche Weise mit dem KV cache interagieren und auf unterschiedliche Hardware-Engpässe stoßen.

Inferenzphase	Was mit dem KV cache geschieht	Wichtigster Hardware-Engpass	Für Nutzer sichtbare Kennzahl
Prefill (Prompt-Verarbeitung)	Berechnet $K$ und $V$ für alle Prompt-Token parallel und befüllt den anfänglichen Cache über alle Schichten hinweg.	Rechengebunden (große Matrix-Matrix-Multiplikationen über den gesamten Prompt).	Zeit bis zum ersten Token (TTFT).
Decode (Token-Generierung)	Berechnet $Q$, $K$ und $V$ für jeweils ein neues Token, hängt den neuen $K$/$V$-Eintrag an und liest den gesamten Cache-Verlauf.	Speicherbandbreitengebunden (Laden der Modellgewichte und der wachsenden KV-Zustände bei jedem Schritt).	Latenz zwischen Token / Ausgabe-Streaming-Geschwindigkeit.

Wie in NVIDIAs technischer Erklärung zu Prefill, Decode und KV-Caching erläutert, verarbeitet die Prefill-Phase alle Eingabe-Token gleichzeitig. Da der gesamte Prompt im Voraus bekannt ist, können GPUs die Projektionen zu dichten Matrixoperationen bündeln, die Recheneinheiten auslasten und den KV cache in einem Durchlauf befüllen. Lange Prompts, etwa Kontexte aus mehreren Dokumenten in Retrieval-Augmented-Generation-Pipelines (RAG), erhöhen direkt den Prefill-Aufwand und verlängern die Zeit bis zum ersten Token.

Nach der Ausgabe des ersten Tokens beginnt die Decode-Phase. Jeder Schritt verarbeitet nur ein neues Token pro Sequenz, hängt dessen Key- und Value-Vektoren an den Cache an und liest alle zuvor gespeicherten $K$- und $V$-Tensoren aus dem GPU-Hochbandbreitenspeicher (HBM), um Attention zu berechnen. Da die arithmetische Intensität pro Schritt gering ist, während die Speicherzugriffe mit Sequenzlänge und Batch-Größe wachsen, wird die Decodierung schnell durch Speicherbandbreite und verfügbaren VRAM statt durch reine Rechen-FLOPs begrenzt.

Wie viel Speicher benötigt ein KV cache?

Der Speicherbedarf eines KV cache wächst linear mit der Sequenzlänge, der Batch-Größe, der Anzahl der Schichten und der Anzahl der Key-Value-Attention-Heads.

Aus den Tensorformen standardmäßiger Transformer-Caches, bei denen jede Schicht einen Key- und einen Value-Tensor über Batch, KV-Heads, Sequenzlänge und Head-Dimension speichert, lässt sich die Cache-Größe pro Sequenz symbolisch ausdrücken:

bytes ≈ 2 × layers × kv_heads × head_dim × seq_len × bytes_per_element

Jeder Term der Formel ist ein Ansatzpunkt für Modellarchitekten und Inferenzingenieure, um den Speicherbedarf zu kontrollieren:

• 2: Berücksichtigt die Speicherung sowohl der Key- (K) als auch der Value-Tensoren (V).
• layers: Gesamtzahl der Transformer-Decoderblöcke im Modell.
• kv_heads und head_dim: Anzahl der Key/Value-Attention-Heads pro Schicht und Dimension jedes Heads.
• seq_len: Gesamtzahl der gecachten Token (Prompt-Token plus bisher generierte Token).
• bytes_per_element: Numerische Präzision der gespeicherten Tensoren (zum Beispiel 2 Bytes für FP16/BF16, 1 Byte für 8-Bit-Formate oder ein kleinerer Bruchteil bei 4-Bit-KV cache-Quantisierung wie NVFP4).

kv_heads verkleinern: MHA, MQA und GQA

Bei klassischer Multi-Head Attention (MHA) hat jeder Query-Head einen eigenen Key- und Value-Head (kv_heads = query_heads). Als Kontextfenster und Batch-Größen wuchsen, wurde das Speichern separater K- und V-Projektionen für jeden Head zu einem großen Speicherengpass.

Zwei Architekturänderungen reduzieren kv_heads in der obigen Formel direkt:

• Multi-Query Attention (MQA): MQA wurde von Noam Shazeer in Fast Transformer Decoding: One Write-Head is All You Need (arXiv:1911.02150) vorgestellt und teilt einen einzigen Key- und Value-Head zwischen allen Query-Heads einer Schicht (kv_heads = 1). Das reduziert die Größe des KV cache und den Speicherbandbreitenverkehr bei der Decodierung deutlich.
• Grouped-Query Attention (GQA): GQA wurde von Ainslie et al. in GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints (arXiv:2305.13245) vorgestellt und teilt Query-Heads in G Gruppen, wobei jede Gruppe einen Key- und Value-Head gemeinsam nutzt. GQA liegt zwischen MHA und MQA, bewahrt eine Qualität nahe der Multi-Head Attention und senkt gleichzeitig Speicherbedarf und Bandbreitenbedarf des KV cache proportional zur Verringerung der Gruppen.

Neben GQA reduzieren Inferenz-Engines auch bytes_per_element, indem sie gecachte K- und V-Tensoren in Formate geringerer Präzision quantisieren. So passen längere Kontexte oder größere gleichzeitige Batches in den GPU-Speicher.

Wie verwalten Serving-Engines KV cache-Speicher im großen Maßstab?

Serving-Engines im Produktivbetrieb verwalten KV cache-Speicher, indem sie zusammenhängende Tensoren in Blöcke fester Größe aufteilen. So können GPUs mehr gleichzeitige Anfragen verarbeiten, ohne VRAM zu verschwenden.

In einfachen Implementierungen reserviert eine Serving-Laufzeit vorab einen zusammenhängenden GPU-Speicherbereich entsprechend der maximal möglichen Sequenzlänge jeder Anfrage. Da die tatsächlichen Ausgabelängen nicht im Voraus bekannt sind, verursacht diese Vorabreservierung erhebliche interne und externe Speicherfragmentierung: Reservierte Plätze bleiben ungenutzt, während neue Anfragen nicht ausgeführt werden können.

Kwon et al. begegneten diesem Engpass mit PagedAttention in Efficient Memory Management for Large Language Model Serving with PagedAttention (arXiv:2309.06180), dem Kernmechanismus von vLLM. Inspiriert von virtuellem Speicher und Paging in Betriebssystemen:

• Nicht zusammenhängende Blöcke fester Größe: PagedAttention teilt den KV cache jeder Anfrage in Blöcke fester Größe auf, die Keys und Values für eine festgelegte Anzahl von Token enthalten und über eine Tabelle logischen auf physische Blöcke abgebildet werden.
• Bedarfsgerechte Zuweisung: Neue physische Blöcke werden erst zugewiesen, wenn neue Token generiert werden. Das beseitigt interne Fragmentierung nahezu vollständig.
• Präfixfreigabe auf Blockebene: Teilen mehrere Anfragen ein identisches Prompt-Präfix, etwa einen System-Prompt oder gemeinsame Few-Shot-Beispiele, können ihre logischen Blocktabellen auf dieselben physischen KV-Blöcke im Speicher zeigen. Copy-on-Write wird erst verwendet, wenn die Sequenzen auseinanderlaufen.

In der Auswertung der vLLM-Arbeit (arXiv:2309.06180) erreichte diese seitenbasierte KV-Verwaltung bei vergleichbarer Latenz einen 2–4× höheren Durchsatz als FasterTransformer und Orca, indem sie deutlich größere Batches im selben GPU-Speicher unterbrachte. Moderne Serving-Stacks wie vLLM und NVIDIAs KV cache-Wiederverwendungssystem in TensorRT-LLM setzen auf blockbasierte KV-Verwaltung, um gemeinsame Präfixe wiederzuverwenden und die Parallelität zu maximieren.

Was ist der Unterschied zwischen KV cache und Prompt-Caching?

Ein KV cache ist der zugrunde liegende Inferenzmechanismus pro Anfrage, der Attention-Zustände über Decodierungsschritte hinweg wiederverwendet. Prompt-Caching ist dagegen eine anfrageübergreifende Serving- und API-Funktion, die diese KV-Blöcke über getrennte Aufrufe mit identischem Präfix hinweg speichert und wiederverwendet.

Da Entwickler bei der Optimierung von Latenz und Kosten häufig beiden Begriffen begegnen, lohnt es sich, einen einzelnen Generierungsaufruf von mehreren API-Anfragen zu unterscheiden:

Aspekt	KV cache (Decodierung innerhalb einer Anfrage)	Prompt-Caching (Präfixwiederverwendung über Anfragen hinweg)
Umfang	Eine Anfrage über die Token-Generierungsschritte hinweg.	Mehrere Anfragen innerhalb eines kurzen Aufbewahrungszeitraums.
Was vermieden wird	Neuberechnung früherer Token innerhalb derselben Antwort bei der Decodierung jedes neuen Tokens.	Erneuter Prefill-Durchlauf für wiederholte statische Prompt-Präfixe über getrennte Aufrufe hinweg.
Lebenszyklus	Bei Prefill erstellt, bei Decode erweitert und nach Abschluss der Anfrage freigegeben oder verdrängt.	Für spätere Aufrufe im Blockspeicher (GPU- oder Host-Speicher) mit Verdrängungsstrategie und TTL aufbewahrt.
Sichtbarkeit in der Abrechnung	Teil der Standardinferenz; kein eigener Rechnungsposten.	Von API-Anbietern häufig als vergünstigter Preis für gecachte Eingabe-Token und niedrigere TTFT ausgewiesen.

Kausale Attention schreibt für Prompt-Caching eine strenge Regel vor: Das Präfix muss vom allerersten Token an exakt übereinstimmen. Da die Key- und Value-Tensoren jedes Tokens von der genauen Sequenz der vorherigen Token abhängen, macht schon die Änderung eines einzigen Zeitstempels, einer Nutzer-ID oder einer Anweisung am Anfang eines Prompts die gecachten $K$- und $V$-Zustände aller folgenden Token ungültig.

Anbieterspezifische Aufbewahrungsregeln, Mindestschwellen für Token und Rabattstrukturen finden Sie in unserem ausführlichen Leitfaden zu Prompt-Caching und dessen Preisgestaltung durch Anbieter.

Praktische Erkenntnisse für Entwickler und Teams

Das Verständnis des KV cache führt unmittelbar zu besserer Prompt-Architektur, gleichmäßigerer Latenz und niedrigeren Infrastrukturkosten:

1. Statische Inhalte ganz an den Anfang des Prompts stellen: Platzieren Sie Systemanweisungen, Tool-Schemas und gemeinsame Referenzdokumente vor dynamischen Nutzereingaben oder Metadaten einzelner Anfragen. Ein identisches Präfix ermöglicht sowohl gehosteten APIs als auch lokalen Engines wie vLLM oder TensorRT-LLM die Wiederverwendung gecachter KV-Blöcke statt redundanter Prefill-Durchläufe.
2. Beobachten, wie die Kontextlänge die Parallelität auf selbst gehosteten GPUs beeinflusst: Da die Größe des KV cache linear mit seq_len wächst, halbiert eine Verdopplung der durchschnittlichen Kontextlänge die Anzahl gleichzeitiger Anfragen, die der GPU-Speicher aufnehmen kann. Bevorzugen Sie bei Modellen mit offenen Gewichten für das Self-Hosting Architekturen mit Grouped-Query Attention (GQA) und Laufzeiten, die seitenbasierte KV-Zuweisung und KV-Quantisierung unterstützen.
3. Unnötigen Kontext auch bei großen Kontextfenstern kürzen: Große Verläufe bei jeder Gesprächsrunde erhöhen die Prefill-Latenz, den KV-Speicherdruck und die Token-Kosten. Kombinieren Sie Präfix-Caching mit gezieltem Retrieval und regelmäßiger Zusammenfassung. Diese zentralen Methoden behandeln unser Leitfaden zum Senken von KI-API-Kosten und unser KI-API-Preisvergleich.

Häufig gestellte Fragen

Verändert ein KV cache die Ausgabequalität des Modells?

Ein standardmäßiger KV cache in der nativen Inferenzpräzision des Modells, etwa FP16 oder BF16, ist mathematisch gleichwertig zur Neuberechnung des Präfixes bei jedem Schritt, da kausale Maskierung verhindert, dass zukünftige Token frühere Key- und Value-Vektoren verändern. Qualitätseinbußen kommen erst bei verlustbehafteter KV cache-Quantisierung, etwa 8-Bit- oder 4-Bit-Komprimierung, oder beim Verdrängen älterer Token zur Speicherersparnis ins Spiel.

Warum kann ein KV cache Token in der Mitte eines Prompts nicht wiederverwenden, wenn sich der Anfang geändert hat?

In einem kausalen Transformer berücksichtigt die Repräsentation jedes Tokens per Attention alle vorhergehenden Token der Sequenz. Ändern sich die ersten zehn Token eines Prompts, ändern sich auch die verborgenen Zustände und damit die Key- und Value-Projektionen ab Token elf. Da diese Zustände vom exakten vorhergehenden Präfix abhängen, können Serving-Engines gecachte KV-Blöcke über Anfragen hinweg nur bei einer Übereinstimmung des Präfixes von Anfang an wiederverwenden.

Enthält der KV cache die Modellgewichte?

Nein. Modellgewichte sind statische, beim Training gelernte Parameter, die von allen auf der GPU bedienten Anfragen gemeinsam genutzt werden. Der KV cache enthält dynamische, anfragespezifische Aktivierungstensoren (die Key- und Value-Projektionen der aktuell im Kontext befindlichen Token). Der gesamte GPU-Speicher muss bei der Inferenz die statischen Modellgewichte, temporäre Laufzeitaktivierungen und die dynamischen KV caches aller aktiven Anfragen im Batch aufnehmen.

Warum verlangsamt sich die Generierung weiterer Ausgabe-Token bei hoher Parallelität?

In der Decode-Phase muss bei jedem neuen Token-Schritt für alle aktiven Anfragen im Batch auf die gespeicherten Key- und Value-Tensoren aller vorherigen Token zugegriffen werden. Mit steigender Sequenzlänge und Anzahl gleichzeitiger Anfragen wächst die Menge der pro Schritt aus dem GPU-Speicher übertragenen KV-Daten. Das lastet die Speicherbandbreite aus und zwingt den Scheduler, die Batch-Größe zu begrenzen oder auf Speicherzugriffe zu warten.

Quellen

• Hugging Face Transformers — KV Cache Strategies and Optimization
• Hugging Face Transformers — Cache Explanation and Architecture
• NVIDIA Technical Blog — Optimizing Inference for Long Context and Large Batch Sizes with NVFP4 KV Cache
• Kwon et al. (2023) — Efficient Memory Management for Large Language Model Serving with PagedAttention (arXiv:2309.06180)
• Ainslie et al. (2023) — GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints (arXiv:2305.13245)
• Shazeer (2019) — Fast Transformer Decoding: One Write-Head is All You Need (arXiv:1911.02150)
• NVIDIA TensorRT-LLM Documentation — KV Cache System