1.0x
Das Problem: Ohne KV-Cache muss bei jedem neuen Token die Attention über ALLE bisherigen Tokens neu berechnet werden. Das ist ineffizient!

Die Lösung: Speichere Key- und Value-Vektoren aller bisherigen Tokens. Bei neuem Token: Nur Query berechnen, mit gecachtem K und V kombinieren.
1
Initialisierung: Input-Tokens werden eingebettet
Query (Q)
Neu berechnet
Key (K) Cache
0 Tokens
Value (V) Cache
0 Tokens

Cache-Wachstum

Sequence Length: 0
K Cache Größe: 0 KB
V Cache Größe: 0 KB
Gesamt KV-Cache: 0 KB
Cache-Wachstum (dieses Token)
0%

Recheneffizienz

Attention Komplexität: O(n)
Q neu berechnen: O(d²)
K·V Berechnung: O(1) cached
Speedup vs ohne Cache: ~10x

Speicherformel für KV-Cache

Cache Bytes = 2 × Layers × Heads × Head_Dim × Seq_Len × Bytes_Per_Token

Beispiel (Llama 2 7B):

2 × 32 Layers × 32 Heads × 128 Dim × Seq_Len × 2 Bytes (FP16)

= 524.288 Bytes pro Token = ~512 KB pro Token

Bei 32K Tokens = ~16 GB

Fig. 1 | Die Speichermenge des KV-Cache wächst linear mit der Sequenzlänge. Ohne Cache: O(n²), mit Cache: O(n)

Mit vs. Ohne KV-Cache

Merkmal Ohne KV-Cache Mit KV-Cache
Attention pro Token O(n²) bei n Tokens O(n) nur Query × K
Speicherverbrauch Effizient (nur Input) O(Layers × Heads × Seq_Len)
Generierungsgeschwindigkeit Langsam (alles neu) ~5-10x schneller
Praktische Anwendung Kaum genutzt Standard in allen LLMs

KV-Cache Größe in realen Modellen

Modell Größe Layers Heads KV-Cache / Token (FP16) Bei 32K Tokens
Claude 4.5 ~100B 80 64 ~1.5 MB ~48 GB (200K ctx) ✓
Qwen 3 ~100B 96 32 ~1 MB ~32 GB (256K ctx) ✓
Llama 4 Maverick 400B (17B aktiv) 128 64 ~2.5 MB ~80 GB (1M ctx) ✓
Gemini 3 ~600B 256 128 ~4 MB ~128 GB (10M ctx) ✓

Hinweis: Das KV-Cache wird zum Flaschenhals bei langen Kontexten. Deshalb sind Optimierungen wie GQA (Kapitel 2.2), Quantization und Sparse Attention (Kapitel 2.4) essentiell. Sparse Attention reduziert die Cache-Größe dramatisch, indem nur relevante Token-Paare gespeichert werden — ermöglicht 1M+ Token-Kontexte bei praktikablen Speicheranforderungen.