Wissen
KV Cache
Der KV Cache ist ein temporärer Speicher für die autoregressive Inferenz von Transformer-Sprachmodellen. Für bereits verarbeitete Tokens werden in jedem Attention-Layer die berechneten Key- und Value-Repräsentationen gespeichert. Beim Generieren des nächsten Tokens müssen diese Repräsentationen dadurch nicht erneut berechnet werden. Das beschleunigt Decoding erheblich, lässt den Speicherbedarf jedoch mit der Länge des aktiven Kontexts wachsen.
Key- und Value-Vektoren bereits verarbeiteter Tokens für die Attention-Layer des Modells.
Frühere Tokens müssen bei jedem neuen Decoding-Schritt nicht vollständig erneut durch das Modell berechnet werden.
Weniger redundante Berechnung, dafür wachsender GPU- beziehungsweise Beschleunigerspeicher pro Sequenz.
Dokument-Metadaten
Worum geht es in diesem Wissensbeitrag?
Einordnung des Inhalts
- Entity Class
- Wissen
- Content-Typ
- Technischer Grundlagenbeitrag
- Hauptthema
- KV Cache
- Vollständige Bezeichnung
- Key-Value Cache
- Themenkategorie
- Transformer / Attention / LLM Inference / Serving
- Primäre Phase
- Autoregressive Inferenz beziehungsweise Decoding
- Kernfrage
- Wie kann ein Transformer bei der Generierung neuer Tokens bereits berechnete Attention-Repräsentationen wiederverwenden?
Definition
Was ist ein KV Cache?
Bei Self-Attention werden aus jeder Tokenrepräsentation Query, Key und Value berechnet. Während autoregressiver Generierung bleiben die Keys und Values früherer Tokens für zukünftige Schritte relevant. Der KV Cache speichert diese bereits berechneten Repräsentationen pro Layer und Token.
Definition als Faktenstruktur
- Cache-Inhalt
- Keys und Values bereits verarbeiteter Tokens
- Granularität
- Pro Transformer-Layer, Token und KV-Head
- Lebensdauer
- Temporär während einer aktiven Inferenzsequenz beziehungsweise Session
- Nutzen
- Vermeidung wiederholter Berechnung früherer Key- und Value-Repräsentationen
- Wachstum
- Linear mit der Zahl der gespeicherten Tokens und KV-Heads
- Nicht gespeichert
- Die Query früherer Tokens wird für zukünftige Decoding-Schritte normalerweise nicht benötigt und deshalb nicht analog gecacht
Attention
Warum werden ausgerechnet Keys und Values gecacht?
Beim nächsten Token benötigt das Modell eine neue Query. Diese Query wird mit allen Keys des bisher sichtbaren Kontexts verglichen. Die resultierenden Attention-Gewichte bestimmen, welche gecachten Values in die neue Tokenrepräsentation einfließen.
Das zuletzt erzeugte Token wird als neuer Decoding-Input verarbeitet.
Für die aktuelle Position entsteht eine neue Query-Repräsentation.
Auch Key und Value der aktuellen Position werden berechnet.
Die neue Query wird gegen Keys aller bisherigen Positionen ausgewertet.
Attention-Gewichte aggregieren die zugehörigen Values.
Der neue Key und Value werden für den nächsten Schritt dem Cache hinzugefügt.
Qneu × KcacheT → Attention-Gewichte → gewichtete Vcache
Ohne KV Cache
Warum naive autoregressive Generierung redundant ist
Beispielhafte Tokenfolge
- Schritt 1
- Prompt wird verarbeitet und Token A wird erzeugt
- Schritt 2 ohne Cache
- Prompt + A werden erneut vollständig verarbeitet, um Token B zu erzeugen
- Schritt 3 ohne Cache
- Prompt + A + B werden erneut verarbeitet, um Token C zu erzeugen
- Redundanz
- Die Repräsentationen der bereits bekannten Präfix-Tokens würden bei jedem Schritt erneut berechnet
- Mit KV Cache
- Frühere Keys und Values bleiben erhalten; nur die neue Tokenposition muss durch die Decoder-Layer ergänzt werden
Prefill & Decode
Der KV Cache verbindet zwei unterschiedliche Inferenzphasen
Prompt parallel verarbeiten
Der vollständige Eingabeprompt wird durch das Modell verarbeitet. Dabei entstehen für alle Prompt-Tokens und alle Attention-Layer die initialen Keys und Values des KV Cache.
Zwischenzustand behalten
Nach dem Prefill liegen die K/V-Repräsentationen des gesamten Präfixes im Cache und können bei jedem späteren Token weiterverwendet werden.
Token für Token generieren
Während des Decode wird jeweils nur die neue Position vollständig ergänzt. Ihre Query greift auf die bereits gecachten K/V-Repräsentationen zu.
Prompt → Prefill → initialer KV Cache → Decode Token 1 → Cache erweitern → Decode Token 2 → Cache erweitern → …
Speicherbedarf
Der KV Cache wächst mit jedem aktiven Token
Der Cache muss für jede gespeicherte Position die Key- und Value-Repräsentationen aller relevanten Layer und KV-Heads halten. Deshalb können lange Kontexte und große Batches den Cache zu einem dominanten Speicherfaktor bei der LLM-Inferenz machen.
Jedes zusätzliche Token erzeugt neue K/V-Einträge pro Layer.
Mehr Transformer-Layer bedeuten entsprechend mehr Cache-Repräsentationen.
MHA, GQA und MQA unterscheiden sich erheblich in der Zahl gespeicherter K/V-Heads.
Größere Vektordimensionen erhöhen den Speicher pro K/V-Eintrag.
FP16, BF16, FP8, INT8 oder niedrigbitige Quantisierung verändern Bytes pro Element.
Jede gleichzeitig aktive Sequenz benötigt eigenen beziehungsweise teilweise teilbaren Cache.
KV Cache ≈ Tokens × Layer × 2 × KV-Heads × Head-Dimension × Bytes pro Wert
Der Faktor 2 steht für Key und Value.
Compute vs. Memory
KV Caching macht Attention nicht konstant teuer
Wichtige Abgrenzung
- Gesparte Berechnung
- Frühere Tokens müssen nicht erneut durch alle Projektionen, MLPs und Transformer-Layer verarbeitet werden
- Was weiterhin wächst
- Die neue Query muss weiterhin mit den Keys des gesamten aktiven Kontexts interagieren
- Attention pro neuem Token
- Der Aufwand steigt weiterhin mit der Länge des sichtbaren Key-/Value-Kontexts
- Systemwirkung
- Autoregressives Decoding verschiebt sich bei großen Modellen häufig stark in Richtung Speicherbandbreiten- und Memory-Management-Problem
Attention-Varianten
MHA, MQA und GQA verändern die Größe des KV Cache
Multi-Head Attention
Jeder Query-Head besitzt typischerweise eigene Key- und Value-Heads. Das bietet hohe Ausdruckskapazität, erzeugt aber entsprechend viele K/V-Repräsentationen im Cache.
Multi-Query Attention
Viele Query-Heads teilen sich einen gemeinsamen Key- und Value-Head. Dadurch sinken KV-Cache-Größe und Speicherbandbreite beim Decoding deutlich.
Grouped-Query Attention
Mehrere Gruppen von Query-Heads teilen jeweils einen K/V-Head. GQA liegt zwischen MHA und MQA und zielt auf einen günstigen Trade-off aus Qualität und Inferenzkosten.
MHA: viele KV-Heads → größerer Cache
GQA: gruppierte KV-Heads → kleinerer Cache
MQA: ein gemeinsamer KV-Head → besonders kleiner Cache
LLM Serving
KV Cache ist ein zentrales Scheduling- und Memory-Management-Problem
Bei einem einzelnen Chat ist der Cache bereits relevant. In produktiven Serving-Systemen müssen jedoch viele Sequenzen unterschiedlicher Länge gleichzeitig verwaltet werden. Dadurch entstehen zusätzliche Probleme wie Fragmentierung, dynamische Speicherbelegung und gemeinsam nutzbare Präfixe.
Anfragen besitzen unterschiedlich lange Prompts und Ausgaben.
Naive zusammenhängende Speicherreservierung kann große ungenutzte Bereiche erzeugen.
KV-Speicher begrenzt häufig, wie viele Requests gleichzeitig verarbeitet werden können.
Identische Systemprompts oder Präfixe können prinzipiell zwischen Anfragen wiederverwendet werden.
Serving-Systeme müssen freie Cache-Blöcke, Sequenzwachstum und Request-Prioritäten koordinieren.
Effizientes Cache-Management kann mehr parallele Sequenzen und höheren Gesamtdurchsatz ermöglichen.
PagedAttention
KV-Speicher kann ähnlich wie virtueller Speicher in Blöcken verwaltet werden
Prinzip von PagedAttention
- Problem
- KV Cache wächst dynamisch und verursacht bei naiver Verwaltung Speicherfragmentierung und Überreservierung
- Idee
- Cache-Einträge werden in nicht zwingend zusammenhängenden Speicherblöcken organisiert
- Analogie
- Die Verwaltung orientiert sich an Paging-Konzepten klassischer Betriebssysteme
- Nutzen
- Weniger Speicherverlust, flexiblere Allokation und bessere gemeinsame Nutzung von KV-Blöcken
- System
- vLLM nutzt PagedAttention als Grundlage für speichereffizientes LLM Serving
Prefix Caching
Auch bereits berechnete Prompt-Präfixe können wiederverwendet werden
Wenn viele Anfragen mit demselben langen Präfix beginnen, beispielsweise einem identischen Systemprompt oder statischen Dokumentkontext, können dessen bereits erzeugte K/V-Repräsentationen in geeigneten Serving-Systemen zwischen Requests wiederverwendet werden.
Prefill jedes Mal erneut
Derselbe statische Präfix wird bei jeder neuen Anfrage erneut vollständig durch die Transformer-Layer verarbeitet.
Gemeinsame K/V-Blöcke wiederverwenden
Identische Präfixteile können aus einem bereits vorhandenen Cache übernommen werden und den erneuten Prefill reduzieren.
Nur identischer Modellkontext ist teilbar
Schon Veränderungen an den relevanten vorherigen Tokens können zu anderen Hidden States und K/V-Repräsentationen führen.
Optimierung
Vier große Strategien reduzieren die Kosten des KV Cache
MQA und GQA reduzieren die Anzahl gespeicherter Key-/Value-Heads architektonisch.
Niedrigere Präzision reduziert die Bytes pro gespeicherten K/V-Wert.
Nur ausgewählte ältere Tokens verbleiben dauerhaft im Cache.
Wichtige Cache-Positionen werden selektiv erhalten oder unterschiedlich stark budgetiert.
Effizientere physische Speicherorganisation reduziert Fragmentierung.
Gemeinsame Präfixe können über Prefix Caching oder Cache Sharing erneut genutzt werden.
KV Quantization
Weniger Bits pro Cache-Wert ermöglichen mehr Kontext oder größere Batches
Prinzip
- Ausgangspunkt
- K/V-Werte werden häufig in 16-Bit- oder anderen Floating-Point-Formaten gespeichert
- Quantisierung
- Cache-Werte werden in niedrigere numerische Präzision überführt
- Nutzen
- Weniger Speicher pro Token und geringerer Datentransfer aus dem Cache
- Risiko
- Quantisierungsfehler können Attention und Ausgabequalität beeinflussen
- KIVI
- Untersucht die unterschiedliche Verteilung von Key- und Value-Cache-Elementen und schlägt eine asymmetrische 2-Bit-Quantisierung vor
Eviction & Compression
Nicht jeder frühere Token muss zwangsläufig dauerhaft im Cache bleiben
Neuere Tokens bevorzugen
Eine einfache Strategie behält vor allem die jüngste Kontexthistorie und entfernt weit zurückliegende Positionen.
Attention-relevante Tokens behalten
Verfahren wie H2O versuchen besonders einflussreiche beziehungsweise häufig stark beachtete Tokens zu erhalten.
Pro Attention-Head selektieren
SnapKV nutzt beobachtete Attention-Muster, um für verschiedene Heads relevante Cache-Positionen auszuwählen.
Cache-Budget nach Layer differenzieren
PyramidKV verteilt Speicherbudgets unterschiedlich über Transformer-Layer, statt überall dieselbe Cache-Größe zu erzwingen.
Long Context
Große Context Windows verschärfen das KV-Cache-Problem
Warum Context Length und KV Cache direkt verbunden sind
- Context Capacity
- Mehr sichtbare Tokens bedeuten potenziell mehr gespeicherte K/V-Positionen
- Memory Growth
- Der Cache-Speicher wächst linear mit der gespeicherten Sequenzlänge
- Attention Work
- Auch das Lesen und Verwenden langer K/V-Sequenzen erhöht Aufwand und Speicherbandbreite
- Systemfolge
- Long-Context-Inferenz benötigt nicht nur größere Kontextfenster im Modell, sondern auch effiziente Cache-Architekturen
- Context Engineering
- Auswahl, Retrieval, Compression und Folding können verhindern, dass jede historische Information dauerhaft aktiv bleiben muss
Measurement
Welche Kennzahlen sind für KV-Cache-Effizienz relevant?
Wie viel Cache-Speicher erzeugt ein zusätzliches Token pro Sequenz?
Wie viel Beschleunigerspeicher belegt der Cache unter realer Last maximal?
Wie viele Sequenzen können mit dem verfügbaren Speicher gleichzeitig aktiv sein?
Wie viele Output-Tokens können pro Zeiteinheit generiert werden?
Wie lange benötigt das System durchschnittlich für einen Decoding-Schritt?
Wie häufig können bereits berechnete Präfixe oder Cache-Blöcke wiederverwendet werden?
Wie stark wird der KV Cache gegenüber einer vollständigen Referenz reduziert?
Wie gut bleibt die Modellleistung trotz Quantisierung, Eviction oder Compression erhalten?
Abgrenzung
Was der KV Cache nicht ist
Nicht Teil der trainierten Modellgewichte
Der KV Cache entsteht erst während einer konkreten Inferenz und verändert die permanenten Modellparameter nicht.
Normalerweise nicht dauerhaft persistent
Ein KV Cache ist primär ein temporärer Rechenzustand für eine aktive Sequenz, kein semantisches Langzeitgedächtnis.
Keine Wissenssuche
Der Cache sucht keine externen Dokumente. Er speichert interne Attention-Repräsentationen bereits verarbeiteter Tokens.
Nicht einfach eine gespeicherte Antwort
Gespeichert werden numerische Key-/Value-Repräsentationen, nicht lediglich fertige Textantworten.
Verwandte Entitäten
Welche Leadterion-Wissensobjekte stehen in direkter Beziehung?
Large Language Models
Der Grundlagenbeitrag erklärt Self-Attention, Query, Key, Value und die autoregressive Generierung, auf denen KV Caching aufbaut.
Wissensbeitrag öffnenContext Engineering
Context Engineering bestimmt, welche Tokens überhaupt aktiv in den Modellkontext gelangen und damit KV-Speicher erzeugen.
Wissensbeitrag öffnenContext Folding
Context Folding kann langfristig aktive Historie reduzieren und damit indirekt auch die Zahl benötigter K/V-Positionen begrenzen.
Wissensbeitrag öffnenByte Pair Encoding
Tokenisierung bestimmt, wie viele Tokens ein Text erzeugt. Diese Tokenzahl wirkt direkt auf Context Length und KV-Cache-Größe.
Wissensbeitrag öffnenFAQ
Häufige Fragen zum KV Cache
Wofür steht KV Cache?
KV steht für Key und Value. Der Cache speichert die bereits berechneten Key- und Value-Repräsentationen früherer Tokens in den Attention-Layern eines autoregressiven Transformers.
Warum wird die Query nicht ebenfalls dauerhaft gecacht?
Beim nächsten Decoding-Schritt wird primär die Query der neuen Tokenposition benötigt. Frühere Queries werden nicht erneut gegen zukünftige Tokens ausgewertet, während frühere Keys und Values für neue Queries weiterhin relevant bleiben.
Warum beschleunigt der KV Cache LLM-Inferenz?
Ohne Cache müssten frühere Tokenrepräsentationen bei jedem Generierungsschritt erneut durch das Modell berechnet werden. Mit Cache können deren bereits erzeugte K/V-Repräsentationen wiederverwendet werden.
Wächst der KV Cache mit jedem neuen Token?
Bei einem vollständigen Cache ja. Jeder neue Token erzeugt pro Transformer-Layer zusätzliche Key- und Value-Einträge. Kompressions- oder Eviction-Verfahren können dieses Wachstum begrenzen.
Was ist der Unterschied zwischen Prefill und Decode?
Beim Prefill wird der gesamte Prompt parallel verarbeitet und der initiale KV Cache aufgebaut. Beim Decode werden anschließend neue Tokens schrittweise erzeugt und der Cache jeweils erweitert.
Was ist der Unterschied zwischen MHA, MQA und GQA für den KV Cache?
MHA verwendet viele separate Key-/Value-Heads. MQA teilt einen K/V-Head über viele Query-Heads. GQA bildet einen Mittelweg mit mehreren Gruppen geteilter K/V-Heads. Weniger KV-Heads bedeuten einen kleineren Cache.
Ist der KV Cache das Gedächtnis eines Chatbots?
Nicht im üblichen semantischen Sinn. Er ist ein temporärer Inferenzzustand für Attention. Dauerhafte Erinnerungen oder nutzerbezogenes Memory sind separate Systemkomponenten.
Warum ist der KV Cache bei Long Context besonders wichtig?
Weil der Speicherbedarf mit der Anzahl gecachter Tokens wächst. Sehr große Kontextfenster können deshalb enorme K/V-Speichermengen erzeugen und Batch Size sowie Serving-Kosten begrenzen.
Kann man den KV Cache komprimieren?
Ja. Forschung untersucht unter anderem niedrigbitige Quantisierung, selektives Eviction, attention-basierte Token-Auswahl, layerabhängige Budgets und effizientere physische Speicherverwaltung.
Quellen
Wissenschaftliche Arbeiten zu Attention, KV Cache und effizienter LLM-Inferenz
Die Auswahl verbindet die Transformer-Grundlage mit Arbeiten, die den Speicher- und Bandbreitenbedarf von Keys und Values durch Architektur-, Serving- und Kompressionsverfahren reduzieren.
| Quelle | Autoren / Jahr | Einordnung | Originalquelle |
|---|---|---|---|
| Attention Is All You Need | Ashish Vaswani et al. · 2017 | Führt die Transformer-Architektur und die Query-Key-Value- Formulierung von Attention ein, auf der heutiges KV Caching aufbaut. | arXiv:1706.03762 |
| Fast Transformer Decoding: One Write-Head is All You Need | Noam Shazeer · 2019 | Analysiert den Speicherbandbreitenaufwand von Keys und Values beim inkrementellen Decoding und führt Multi-Query Attention ein, bei der sich mehrere Query-Heads gemeinsame K/V-Heads teilen. | arXiv:1911.02150 |
| GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints | Joshua Ainslie et al. · 2023 | Führt Grouped-Query Attention als Zwischenform von MHA und MQA ein. Mehrere Query-Heads teilen dabei gruppenweise K/V-Heads, wodurch Decoder-Inferenz und KV-Speicher effizienter werden. | ACL Anthology |
| Efficient Memory Management for Large Language Model Serving with PagedAttention | Woosuk Kwon et al. · 2023 | Behandelt dynamische und fragmentierte KV-Cache-Allokation in LLM-Serving-Systemen. PagedAttention organisiert Cache-Daten in Blöcken und ermöglicht eine flexiblere Speicherverwaltung. | arXiv:2309.06180 |
| H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models | Zhenyu Zhang et al. · 2023 | Untersucht selektive KV-Cache-Eviction und hält eine Kombination aus besonders einflussreichen sowie aktuellen Tokens im Cache. | arXiv:2306.14048 |
| KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache | Zirui Liu et al. · 2024 | Analysiert die numerischen Verteilungen von Key- und Value-Caches und schlägt unterschiedliche Quantisierungsrichtungen für beide sowie eine niedrigbitige KV-Cache-Repräsentation vor. | arXiv:2402.02750 |
| SnapKV: LLM Knows What You are Looking for Before Generation | Yuhong Li et al. · 2024 | Nutzt Attention-Muster am Ende des Prompts, um pro Attention-Head besonders relevante K/V-Positionen auszuwählen und den Cache ohne zusätzliches Fine-Tuning zu komprimieren. | arXiv:2404.14469 |
| PyramidKV: Dynamic KV Cache Compression based on Pyramidal Information Funneling | Zefan Cai et al. · 2024 | Untersucht layerabhängige Attention-Muster und verteilt KV-Cache-Budgets dynamisch über die Modellschichten, anstatt in jedem Layer dieselbe Zahl an Positionen zu speichern. | arXiv:2406.02069 |
Wissen
Der KV Cache macht autoregressive Transformer schnell genug für interaktive Generierung
Der zentrale Gewinn entsteht durch Wiederverwendung bereits berechneter Attention-Repräsentationen. Gleichzeitig wird genau dieser Cache bei langen Kontexten und hoher Parallelität zu einem der wichtigsten Speicher- und Serving-Limits moderner LLM-Systeme.