KV-Cache-Optimierung: Speichereffizienz für LLMs in der Produktion

Aktualisiert am 11. Dezember 2025

Update Dezember 2025: Traditionelle Inferenz verschwendet 60-80% des KV-Cache-Speichers durch Fragmentierung. vLLMs PagedAttention reduziert die Verschwendung auf unter 4% und ermöglicht 2-4-fachen Durchsatz. Ein 70B-Modell mit 8K-Kontext benötigt ~20GB Cache pro Anfrage, ~640GB für eine Batch-Größe von 32. Der KV-Cache übersteigt mittlerweile oft die Modellgewichte im Speicherverbrauch. Optimierungstechniken ermöglichen längere Kontexte und größere Batches auf bestehender Hardware.

LLM-Inferenzsysteme verschwenden 60-80% des zugewiesenen KV-Cache-Speichers durch Fragmentierung und Überallokation.¹ Diese Verschwendung führt direkt zu reduziertem Durchsatz, höheren Kosten und künstlichen Beschränkungen der Kontextlängen. PagedAttention, eingeführt von vLLM, reduzierte die KV-Cache-Verschwendung auf unter 4% und ermöglichte 2-4-fache Durchsatzverbesserungen, die die Wirtschaftlichkeit der Produktionsinferenz transformierten.² Das Verständnis von KV-Cache-Optimierungstechniken hilft Organisationen, die GPU-Auslastung zu maximieren und mehr Nutzer mit bestehender Infrastruktur zu bedienen.

Das KV-Cache-Management ist zum kritischen Engpass für produktive LLM-Deployments geworden. Der Speicherverbrauch wächst linear mit Sequenzlänge und Batch-Größe und erschöpft schnell selbst GPUs mit hohem Speicher wie H100 und H200. Die Beherrschung von Cache-Optimierungstechniken ermöglicht längere Kontexte, größere Batches und kosteneffektivere Inferenz im großen Maßstab.

Warum KV-Caching wichtig ist

Transformer-Modelle berechnen die Attention über alle vorherigen Token, wenn sie jedes neue Token generieren. Ohne Caching erfordert die Generierung von 1.000 Token eine 1.000-malige Neuberechnung der Attention von Grund auf—die Kosten steigen quadratisch mit der Sequenzlänge.

KV-Caching-Lösung: Speichern Sie Key- und Value-Tensoren von vorherigen Token und verwenden Sie diese für nachfolgende Attention-Berechnungen wieder. Jedes neue Token berechnet die Attention gegen gecachte Werte, anstatt sie neu zu generieren.

Speicherauswirkung: Ein 70B-Parameter-Modell, das 8.192 Token mit Batch-Größe 32 generiert, benötigt allein etwa 40-50GB KV-Cache-Speicher—oft mehr als die Modellgewichte selbst.³

Das Skalierungsproblem: Der KV-Cache-Speicher wächst wie folgt:

Speicher = batch_size × seq_length × num_layers × 2 × hidden_dim × precision_bytes

Für Llama 3.1-70B mit FP16: - Cache pro Token: ~2,5MB - 8K-Kontext: ~20GB pro Anfrage - Batch von 32: ~640GB gesamter KV-Cache

PagedAttention: die grundlegende Optimierung

vLLMs PagedAttention revolutionierte das KV-Cache-Management, indem es GPU-Speicher wie virtuellen Betriebssystemspeicher behandelt:⁴

Funktionsweise

Traditionelle Allokation: Reserviert zusammenhängende Speicherblöcke für die maximal mögliche Sequenzlänge. Ein 4K-Maximalkontext allokiert 4K Cache selbst für 100-Token-Anfragen und verschwendet 97,5% des reservierten Speichers.

Seitenbasierte Allokation: Teilen Sie den KV-Cache in Blöcke fester Größe (Seiten). Allokieren Sie Seiten bei Bedarf, wenn Sequenzen wachsen. Geben Sie Seiten frei, wenn Sequenzen abgeschlossen sind.

Block-Tabellen-Mapping: Wie OS-Seitentabellen verwaltet PagedAttention Zuordnungen zwischen logischen Sequenzpositionen und physischen Speicherorten. Sequenzen sehen kontinuierlichen Speicher, während die physische Speicherung nicht zusammenhängend bleibt.

Leistungsauswirkung

• Speicherverschwendung: 60-80% → unter 4%
• Durchsatz: 2-4-fache Verbesserung gegenüber traditioneller Allokation
• Speicherfragmentierung: Praktisch eliminiert⁵

Implementierung in vLLM

from vllm import LLM, SamplingParams

# PagedAttention ist standardmäßig aktiviert
llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.90,  # 90% des GPU-Speichers nutzen
    max_model_len=32768,
)

vLLM verwaltet automatisch Seitenallokation, -freigabe und Speicherfreigabe ohne explizite Konfiguration.

Prefix-Caching und Speicherfreigabe

PagedAttention ermöglicht effiziente Speicherfreigabe über Anfragen mit gemeinsamen Präfixen:

Gemeinsame System-Prompts: Wenn mehrere Anfragen identische System-Prompts verwenden, werden die physischen Seiten, die diese Token speichern, gemeinsam genutzt statt dupliziert.

Automatisches Prefix-Caching: vLLMs Automatic Prefix Caching (APC) erkennt gemeinsame Präfixe über Anfragen hinweg und teilt KV-Cache-Blöcke automatisch:

llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    enable_prefix_caching=True,
)

Auswirkung in der Produktion: Anwendungen mit konsistenten System-Prompts oder wiederholtem Kontext (RAG mit gemeinsamen Dokumenten, Few-Shot-Beispiele) sehen dramatische Speichereinsparungen und Latenzreduzierung. Cache-Trefferraten von 87%+ sind mit gut strukturierten Prompts erreichbar.⁶

KV-Cache-Quantisierung

Die Kompression von KV-Cache-Werten reduziert den Speicherbedarf auf Kosten einer geringfügigen Genauigkeitsverschlechterung:

FP8 KV-Cache

Hopper- und Blackwell-GPUs unterstützen nativen FP8 KV-Cache:

# vLLM FP8 KV-Cache
llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    kv_cache_dtype="fp8",
)

FP8 halbiert den KV-Cache-Speicher gegenüber FP16 mit minimaler Qualitätseinbuße für die meisten Anwendungen. Die Optimierung wird für Long-Context-Inferenz, wo der Cache den Speicherverbrauch dominiert, unverzichtbar.

INT4 KV-Cache

Experimentelle 4-Bit-KV-Cache-Unterstützung reduziert den Speicher weiter:⁷ - Speicherreduzierung: 4x gegenüber FP16 - Qualitätsauswirkung: Aufgabenabhängig, erfordert Evaluierung - Am besten für: Speicherbeschränkte Long-Context-Anwendungen

Quantisierungsauswahl

Cache-Eviction-Strategien

Wenn der Speicherdruck die verfügbare Kapazität übersteigt, bestimmen Cache-Eviction-Richtlinien, welche Token verworfen werden:

Sliding-Window-Attention

Nur aktuelle Token im Cache behalten, älteren Kontext verwerfen:

# Konzeptionelles Sliding Window
def sliding_window_cache(kv_cache, window_size):
    if len(kv_cache) > window_size:
        kv_cache = kv_cache[-window_size:]
    return kv_cache

Einfach, aber effektiv für Anwendungen, bei denen der aktuelle Kontext am wichtigsten ist. Architekturelles Sliding Window (wie bei Mistral) implementiert dies nativ.

Attention-basierte Eviction

Token mit den niedrigsten Attention-Scores entfernen, wichtigen Kontext behalten:

PagedEviction (2025): Block-weiser Eviction-Algorithmus, der für PagedAttention optimiert ist und Blöcke mit geringer Wichtigkeit identifiziert und entfernt, ohne CUDA-Kernel zu modifizieren.⁸

Entropie-gesteuertes Caching: Cache-Budget basierend auf der Attention-Entropie der Schichten zuweisen—Schichten mit breiteren Attention-Mustern erhalten mehr Cache, fokussierte Schichten erhalten weniger.⁹

Streaming LLM

Für Generierung unbegrenzter Länge behält Streaming LLM bei: - Initiale "Attention-Sink"-Token (erste 4-8 Token) - Aktuelle Token innerhalb des Sliding Window - Verwirft mittleren Kontext

Der Ansatz ermöglicht theoretisch unbegrenzte Generierung mit festem Speicher, obwohl die Qualität bei Aufgaben, die Long-Range-Abhängigkeiten erfordern, abnimmt.

KV-Cache-Offloading

Wenn der GPU-Speicher nicht ausreicht, Cache auf langsamere Speicherebenen auslagern:

CPU-Offloading

Inaktive Sequenz-Caches in den Systemspeicher verschieben:

# LMCache-Integration für Offloading
from lmcache import LMCacheEngine

cache_engine = LMCacheEngine(
    backend="cpu",
    max_gpu_cache_size="20GB",
    cpu_cache_size="100GB",
)

Latenzauswirkung: CPU-GPU-Transfer fügt 10-50ms pro Cache-Abruf hinzu. Geeignet für Batch-Workloads oder wenn GPU-Speicherbeschränkungen die Bedienung überhaupt verhindern.

Leistung: LMCache mit vLLM erreicht 3-10-fache Latenzreduzierung gegenüber Neuberechnung durch Caching im CPU-Speicher anstatt Regenerierung.¹⁰

Festplatten-Offloading

Für Extremfälle, Cache auf NVMe-Speicher: - Latenz: 100-500ms pro Abruf - Anwendungsfall: Sehr lange Kontexte, die sonst unmöglich wären - Nicht geeignet für interaktive Anwendungen

Gestaffeltes Caching

Produktionssysteme implementieren oft Multi-Tier-Caching:

1. GPU HBM: Heiße Sequenzen, die aktiv generieren
2. CPU RAM: Warme Sequenzen, kürzlich aktiv
3. NVMe SSD: Kalte Sequenzen für potenzielle Wiederverwendung

Intelligente Promotion- und Demotion-Richtlinien verschieben den Cache zwischen den Ebenen basierend auf Zugriffsmustern.

KV-Cache-bewusstes Routing

Verteilte Inferenz profitiert vom Routing von Anfragen zu Pods, die relevanten Cache halten:

llm-d-Framework

Kubernetes-natives Framework mit KV-Cache-bewusstem Routing:¹¹

# llm-d Cache-Routing-Konfiguration
routing:
  strategy: kv_cache_aware
  cache_hit_weight: 0.8
  load_balance_weight: 0.2

Leistungsergebnisse: - 87% Cache-Trefferrate bei Prefix-lastigen Workloads - 88% schnellere Time-to-First-Token bei warmen Cache-Treffern - Signifikante Reduktion redundanter Berechnungen im Cluster

Implementierungsmuster

Sticky Sessions: Anfragen aus derselben Konversation zum selben Pod routen.

Prefix-Hashing: System-Prompts hashen, um Pod-Routing zu bestimmen und Prefix-Cache-Treffer sicherzustellen.

Lastbewusstes Routing: Cache-Lokalität gegen Pod-Auslastung abwägen, um Hotspots zu vermeiden.

Produktions-Dimensionierungsleitfaden

Speicherschätzung

KV-Cache-Anforderungen vor dem Deployment berechnen:

def estimate_kv_cache_memory(
    num_layers: int,
    hidden_dim: int,
    num_kv_heads: int,
    head_dim: int,
    max_seq_len: int,
    max_batch_size: int,
    precision_bytes: int = 2,  # FP16
) -> float:
    """Schätze KV-Cache-Speicher in GB"""
    per_token = num_layers * 2 * num_kv_heads * head_dim * precision_bytes
    total = per_token * max_seq_len * max_batch_size
    return total / (1024 ** 3)

# Llama 3.1-70B Beispiel
memory_gb = estimate_kv_cache_memory(
    num_layers=80,
    hidden_dim=8192,
    num_kv_heads=8,  # GQA
    head_dim=128,
    max_seq_len=8192,
    max_batch_size=32,
)
print(f"KV-Cache-Speicher: {memory_gb:.1f} GB")

Kapazitätsplanung

Faustregel: Reservieren Sie 40-60% des GPU-Speichers für den KV-Cache, den Rest für Modellgewichte und Aktivierungen.

Beispiel H100 80GB: - Modellgewichte (70B FP16): ~140GB → 2x GPU mit Tensor-Parallelismus - Pro GPU verfügbar für Cache: ~30-35GB nach Gewichten und Overhead - Maximale gleichzeitige Sequenzen: Abhängig von der durchschnittlichen Kontextlänge

Optimierungspriorität

1. PagedAttention aktivieren: Standard in vLLM, großer Effizienzgewinn
2. Prefix-Caching aktivieren: Wenn Workloads gemeinsame Präfixe haben
3. FP8 KV-Cache implementieren: Bei Verwendung von Hopper/Blackwell-GPUs
4. Cache-bewusstes Routing hinzufügen: Bei Cluster-Skalierung mit verteilter Inferenz
5. Offloading in Betracht ziehen: Nur wenn GPU-Speicher nicht ausreicht

Monitoring und Observability

KV-Cache-Metriken in der Produktion verfolgen:

Wichtige Metriken: - Cache-Auslastung: Prozentsatz des allokierten Cache in Verwendung - Cache-Trefferrate: Prefix-Cache-Effektivität - Eviction-Rate: Häufigkeit von Cache-Überlauf - Speicherfragmentierung: Verschwendeter Platz innerhalb allokierter Blöcke

vLLM-Metriken-Endpunkt:

# Prometheus-Metriken verfügbar unter /metrics
# kv_cache_usage_percent
# kv_cache_total_blocks
# kv_cache_used_blocks
# prefix_cache_hit_rate

Alerting-Schwellenwerte: - Cache-Auslastung > 90%: Kapazität skalieren oder Batch-Größe reduzieren - Trefferrate < 50%: Prefix-Caching-Konfiguration überprüfen - Hohe Eviction-Rate: Speicherallokation erhöhen oder Prompts optimieren

Organisationen, die produktive LLM-Inferenz deployen, können Introls Infrastruktur-Expertise für GPU-Kapazitätsplanung und Optimierung über globale Deployments hinweg nutzen.

Das Gebot der Speichereffizienz

KV-Cache-Optimierung stellt eine der wirkungsvollsten Verbesserungen für produktive LLM-Deployments dar. PagedAttention allein liefert 2-4-fache Durchsatzverbesserungen—gleichbedeutend mit einer Verdopplung oder Vervierfachung der GPU-Investition ohne zusätzliche Hardwarekosten.

Die Optimierungslandschaft entwickelt sich weiter. Microsofts FastGen demonstrierte 50% Speicherreduzierung durch adaptive Kompression. Entropie-gesteuertes Caching allokiert Budget intelligent über Schichten hinweg. Cache-bewusstes Routing ermöglicht Effizienzgewinne auf Cluster-Ebene, die zuvor unmöglich waren.

Für Organisationen, die Inferenz im großen Maßstab betreiben, sollte KV-Cache-Optimierung zu den ersten evaluierten Optimierungen gehören. Die Techniken erfordern mini

[Inhalt für Übersetzung gekürzt]