KV-Cache Offloading & Kompression

1. Konzeptüberblick und systemisches Problem

Mit dem Aufkommen von Modellen mit Kontextfenstern von 1–2 Millionen Token (Gemini 2.0, Claude 3.5/3.7) stehen Ingenieure vor einer neuen Infrastrukturkrise:

• Die Gewichte eines 70B-Modells belegen statische 38 GB VRAM.
• Wenn jedoch vier Benutzer Sitzungen mit langem Code-Kontext von jeweils 200.000 Token öffnen, übersteigt die Größe ihres kombinierten KV-Caches 60 Gigabyte!
• Wenn ein Benutzer eine fünfminütige Denkpause einlegt, blockiert sein gigabytischer Cache weiterhin unnötig den VRAM und verhindert, dass andere Benutzer Anfragen senden können.

KV-Cache Offloading & Compression implementiert ein dynamisches Zwei- oder Dreistufen-Speicher-Management für die Inferenz: Der heiße Cache verbleibt im VRAM, der warme Cache wird in den RAM des Servers ausgelagert, und der kalte Cache wird auf NVMe-Speicher geschrieben.

2. Architektonische Taxonomie und mentales Modell

┌─────────────────────────────────────────────────────────────┐
│                 KV-CACHE HIERARCHY & TIERS                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 1: HOT VRAM (HBM3 on GPU)                              │
│ • Latency: < 100 ns | Bandwidth: 2–3 TB/s                   │
│ • Зберігає активні токени генерації поточного такту         │
├─────────────────────────────────────────────────────────────┤
│                          ▲                                  │
│                 Offload  │  Prefetch                        │
│                          ▼                                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 2: WARM SYSTEM RAM (DDR5 on Host Server)               │
│ • Latency: ~100 µs  | Bandwidth: 100–300 GB/s               │
│ • Зберігає сесії користувачів, які чекають у черзі          │
├─────────────────────────────────────────────────────────────┤
│                          ▲                                  │
│                 Swap     │  Restore                         │
│                          ▼                                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 3: COLD NVMe STORAGE (PCIe 5.0 SSD)                    │
│ • Latency: ~10 ms   | Bandwidth: 10–14 GB/s                 │
│ • Довготривале збереження гігантських сесій агентів         │
└─────────────────────────────────────────────────────────────┘

3. Praktische Engineering-Szenarien in der Produktion

01. Zustandsverwaltung nächtlicher Agent-Sessions

Ein Agent hat eine lange Aufgabe abgeschlossen, bei der 150 Dateien analysiert wurden. Sein Kontextzustand (15 GB KV-Cache) wird über Litestream/vLLM Offload auf eine schnelle NVMe-Festplatte ausgelagert. Wenn der Ingenieur am nächsten Morgen eine Klärungsfrage stellt, wird der Cache in einer Sekunde geladen, ohne dass die kostenpflichtige Vorverarbeitung (Prefill) der 150 Dateien erneut durchgeführt werden muss.

02. Implementierung von FP8 KV-Caching in vLLM

Aktivierung der hardwarebeschleunigten Cache-Komprimierung durch einen einzigen Flag:

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.90

Dies ermöglicht es, die Anzahl der gleichzeitigen Sessions zu verdoppeln, ohne zusätzliche GPUs bereitzustellen.

4. Fallstricke, häufige Fehler und Sicherheit

• PCIe Bottleneck (Engpass der Mainboard-Bus-Leitung): Wenn der Server über langsame PCIe-Lanes verfügt (z. B. PCIe 3.0 oder x4-Lanes anstelle von x16), kann die Zeit für das Auslagern und Nachladen des Caches die Zeit für die erneute Generierung überschreiten.
• Quantisierungsrauschen bei extrem langen Kontexten: Bei der Komprimierung des Caches auf 4 Bit (INT4) in Kontexten mit mehr als 100k Token akkumulieren sich Fehler, was zu einem Verlust der Fähigkeit des Modells führt, präzise Zitate zu liefern.

5. Strategisches Fazit für Ingenieure im Jahr 2026

Das Offloading und die Kompression des KV-Caches haben riesige Kontextfenster von einer teuren Exotik zu einem zugänglichen Engineering-Werkzeug gemacht. Das Verständnis der Speicherhierarchie ermöglicht es, Systeme mit Million-Token-Kontext auf moderater Server-Hardware zu entwerfen.