Wie der KV-Cache während Generierung wächst: Interaktive Visualisierung mit und ohne GQA
32 / 128
Fig. 1 |Speicherwachstum des KV-Cache während Token-Generierung. X-Achse: Generierte Tokens. Y-Achse: Speicherverbrauch in GB. Mit/Ohne GQA zeigt den Effekt von Head-Sharing.
📊 Beispiel: Llama 2 70B
Layers: 80
Q-Heads: 64
KV-Heads (MHA): 64
KV-Heads (GQA): 8 (8× kleiner!)
Head-Dimension: 128
Speicher pro Token (MHA): ~523 KB
Speicher pro Token (GQA): ~65 KB
Das KV-Cache Wachstums-Problem
1
Lineares Wachstum: Der KV-Cache wächst linear mit Anzahl generierter Tokens. Mit 128 Tokens ist bereits ein 128× größerer Cache als mit 1 Token. Dies ist das Haupt-Speicher-Bottleneck bei lange Sequenzen.
2
Praktisches Problem: Llama 2 70B mit MHA benötigt ~67 GB (FP16) für 128 Token Context. Das ist mehr als eine einzelne 80GB A100 GPU. Mit GQA passt es auf eine GPU (~8 GB für KV-Cache bei 128 Token).
3
GQA ist Game-Changer: Durch Head-Sharing können wir den KV-Cache um bis zu 8× reduzieren (8 KV-Heads statt 64). Dies ermöglicht längere Context-Fenster auf gleicher Hardware.
4
Spezifische Zahlen: Jeder zusätzliche Token kostet bei Llama 2 70B etwa 65 KB KV-Cache (mit GQA). Bei 100K Token Context wären das 6.5 GB nur für KV-Cache – plus andere Overheads.
5
Skalierung Strategies: Zur Bewältigung nutzt man: (1) GQA zur Reduktion, (2) Flash Attention für speicher-effiziente Berechnung, (3) Ring Attention zum Verteilen über GPUs, (4) KV-Quantization um Bits pro Parameter zu sparen.
6
Spätere Skalierungsgesetze: Länger Kontext × mehr Parameter = exponentiell mehr Speicher braucht. Dies ist einer der größten Treiber für spezialisierte Hardware und Inferenz-Frameworks (vLLM, TensorRT, etc).