KV-Cache

Expertenniveau

Wie das Speichern berechneter Key-Value-Paare die autoregressive Textgenerierung in Transformern drastisch beschleunigt.

Zuletzt aktualisiert: 13. Sept. 2026

Was ist KV-Cache?

Während der autoregressiven Generierung muss ein Transformer für jedes neue Token die Attention über alle vorherigen Token berechnen. Der KV-Cache speichert die Key- und Value-Projektionen vorheriger Token, damit sie nicht neu berechnet werden müssen. Das reduziert die Berechnung pro Schritt von O(n²) auf O(n) — eine massive Beschleunigung für lange Sequenzen.

Key-Cache

Speichert die Key-Projektionen für jedes Token in jeder Schicht. Diese werden verwendet, um Attention-Scores zwischen dem neuen Token und allen vorherigen Token zu berechnen.

Value-Cache

Speichert die Value-Projektionen für jedes Token in jeder Schicht. Sobald die Attention-Gewichte berechnet sind, werden diese gecachten Values zur Ausgabeerzeugung verwendet.

Warum es wichtig ist

Caching vermeidet es, frühere Keys und Values bei jedem Decode-Schritt neu zu berechnen. Die Ersparnis wächst mit der Sequenzlänge; der Cache benötigt dafür Speicher.

⚡

Geschwindigkeit

Vermeidet die Neuberechnung der Attention für alle vorherigen Token bei jedem Schritt. Generierung wird von quadratisch zu linear.

🔁

Inkrementell

Jedes neue Token muss nur sein eigenes Q, K, V berechnen und auf die gecachten K, V vorheriger Positionen zugreifen.

📉

Kompromiss

Tauscht GPU-Speicher gegen Rechenzeit. Der Cache wächst linear mit Sequenzlänge und Modelltiefe.

🔬

Interaktiver KV-Cache Explorer

Beobachte den Cache Token für Token wachsen

Gehe schrittweise durch die autoregressive Generierung, um zu sehen, wie der KV-Cache sich aufbaut. Vergleiche die Berechnungskosten mit und ohne Caching — die Einsparungen werden bei längeren Sequenzen dramatisch.

Die Zähler zählen Paare von K/V-Projektionen pro Token, nicht sämtliche Attention-Operationen. Jede neue Query bewertet weiterhin die gecachten Keys. Die gezeigten Vektoren sind illustrative Beispiele.

TokenKV
Ohne Cache: 0 K/V-Projektionen
Mit Cache: 0 K/V-Projektionen

KV-Speicher und Kontext

2 × 32 × 8 × 128 × 8192 × 2 bytes

Speicher (GiB): 1.00

Durchgerechnetes Beispiel: 32 Schichten (n_layers), 128 Head-Dimension, FP16.

Speicher-Auswirkungen

Der KV-Cache ist der Hauptengpass beim Speicher während der Inferenz. Bei großen Modellen mit langem Kontext kann er Dutzende Gigabyte GPU-Speicher verbrauchen.

KV Cache Memory = 2 × num_layers × seq_len × d_head × num_kv_heads × dtype_size

Normale FP16-KV-Tensoren brauchen 2 Bytes pro Wert. Bei 80 Schichten, 8 KV-Heads und Head-Dimension 128 brauchen 8.192 Tokens 2,5 GiB pro Sequenz; 131.072 Tokens brauchen 40 GiB. Runtime-Allokation und weitere Puffer kommen hinzu.

Optimierungstechniken

Multi-Query & Grouped-Query Attention (MQA/GQA)

Anstatt separate K/V-Heads pro Attention-Head zu verwenden, teilt MQA ein einzelnes K/V-Head über alle Query-Heads, während GQA einige gemeinsame Gruppen nutzt. Dies reduziert die KV-Cache-Größe um das 4-32-fache bei minimalem Qualitätsverlust. Llama 3 und Mistral verwenden GQA. Siehe den Artikel über Aufmerksamkeitsmechanismen für weitere Details.

Sliding-Window-Attention

Anstatt alle Token zu cachen, werden nur die letzten W Token im Cache gehalten. Wird von Mistral-Modellen verwendet. Reduziert den Speicher von O(seq_len) auf O(W), begrenzt aber die Fähigkeit des Modells, auf sehr frühe Token zuzugreifen.

Paged Attention (vLLM)

Inspiriert von virtuellem Speicher in Betriebssystemen. Anstatt zusammenhängenden Speicher für den KV-Cache jeder Sequenz zuzuweisen, verwaltet vLLM den Cache in „Pages" fester Größe, die dynamisch zugewiesen und freigegeben werden können. Das eliminiert Speicherfragmentierung und ermöglicht effizientes Batching von Anfragen mit unterschiedlichen Sequenzlängen.

TurboQuant, PolarQuant & QJL (Google Research, 2025)

TurboQuant untersucht Vektorkompression mit wenigen Bits für die Inferenz. Quantisierer und Fehlerschätzer sollen die Aufgabenqualität bei weniger Speicherbedarf erhalten. Ähnliche Benchmark-Ergebnisse bedeuten keine exakte Rekonstruktion jedes komprimierten Vektors.

PolarQuant — der Kern-Kompressor
Das Paper verwendet Transformationen und skalare Quantisierung zur Begrenzung der Verzerrung. Das kleine Beispiel unten nutzt einen einfacheren gleichmäßigen Quantisierer, damit Rundung und Skalierungs-Overhead nachvollziehbar bleiben.
QJL — der 1-Bit Fehlerkorrektur
Ein unverzerrter Schätzer kann im Erwartungswert stimmen und bei einzelnen Schätzungen Fehler machen. QJL ist kein verlustfreier Reparaturcode für jeden Originalvektor.
Warum das für Inferenz wichtig ist
Bei 80 Schichten, 8 KV-Heads und Head-Dimension 128 belegt ein normaler FP16-Cache mit 128K Tokens 40 GiB pro Sequenz. Ob Kompression die Aufgabenqualität erhält, hängt von Quantisierer, Modell und Auswertung ab. Das Paper nennt seine gemessenen Konfigurationen.
🔬

Was Rotation und Quantisierung tatsächlich verändern

Orthogonale Transformation, echte Rundung und sichtbarer Rekonstruktionsfehler

Rotation und verlustbehaftete Quantisierung

Berechnetes Toy-Beispiel, keine TurboQuant-Implementierung. Eine orthogonale Rotation erhält die Norm. Ein gleichmäßiger skalarer Quantisierer rundet anschließend die Werte. Seine Umkehr stellt das Original nicht exakt wieder her. Verändere Winkel und Präzision und beobachte den Fehler.

Durchgerechnetes BeispielQuadratische Norm
Original
0.8200, -0.4100, 0.6700, -0.2300
1.342300
Rotationswinkel
0.9151, 0.0549, 0.6952, 0.1358
1.342300
Rekonstruiert
0.8230, -0.4047, 0.6727, -0.1770
1.325084
Vier FP16-Werte: 64 bits
Quantisierter Speicher: 48 bits (4 × 4 + 32)
Skalierung (FP32): 0.9151
Fehler (MSE): 7.121e-4

64 / 48 = 1.33×

Dieser kleine Block enthält eine 32-Bit-Skalierung. Die Kompression kann unter 1× liegen. TurboQuant verwendet andere Quantisierer und Verfahren zur Fehlerschätzung. Seine Benchmark-Qualität bedeutet keine verlustfreie Rekonstruktion.

TurboQuant (2025)

Wichtige Erkenntnisse

  • 1Der KV-Cache speichert Key- und Value-Projektionen vorheriger Token und vermeidet redundante Berechnungen während der Generierung
  • 2Caching verwendet frühere K/V-Projektionen erneut. Jede neue Query beachtet weiterhin die gecachten Keys. Die Attention-Kosten pro Schritt wachsen mit dem beachteten Kontext.
  • 3Der KV-Cache-Speicher wächst linear mit Sequenzlänge × Schichten × KV-Heads — das ist der Hauptengpass beim Inferenz-Speicher
  • 4Techniken wie GQA, Sliding Window und Paged Attention adressieren die Speicherkosten bei gleichbleibender Generierungsgeschwindigkeit