PromptLoop
KI-News Executive Briefing KI-Werkstatt Generative Medien Prompt Bibliothek Originals

KV Cache

Was ist ein KV Cache?

Der KV Cache (Key-Value Cache) ist ein Speicherpuffer in Transformer-basierten Large Language Models (LLMs), der die Key-Vektoren und Value-Vektoren aus dem Self-Attention-Mechanismus für alle bisher verarbeiteten Tokens persistiert. Während der Inferenz – konkret im sogenannten Decode-Schritt – wird für jedes neu generierte Token nur noch der aktuelle Query-Vektor berechnet und gegen die gecachten Keys und Values der gesamten bisherigen Sequenz gerechnet. Das Konzept existiert, weil Transformer-Modelle bei der Textgenerierung autoregressive Dekodierung betreiben: Token für Token, immer auf Basis aller vorherigen. Ohne Caching würde die Rechenkomplexität quadratisch mit der Sequenzlänge skalieren – mit KV Cache bleibt sie linear.

Wie funktioniert ein KV Cache?

Im Attention-Layer eines Transformers werden aus dem Input-Embedding drei Vektoren projiziert: Query (Q), Key (K) und Value (V). Beim sogenannten Prefill-Schritt verarbeitet das Modell den gesamten Prompt auf einmal und legt dabei alle K- und V-Vektoren jedes Attention-Heads jeder Schicht im Cache ab. Im anschließenden Decode-Schritt wird für jedes neue Token nur noch der Q-Vektor frisch berechnet; K und V werden direkt aus dem Cache gelesen und mit dem neuen K/V-Paar des aktuellen Tokens erweitert. Der Speicherbedarf wächst dabei linear mit der Sequenzlänge und der Modellgröße – bei langen Kontexten kann der KV Cache schnell mehrere Gigabyte RAM belegen. Moderne Ansätze wie KV-Cache-Quantisierung adressieren genau diesen Engpass: Googles TurboQuant (präsentiert auf der ICLR 2026) komprimiert die gespeicherten Vektoren auf 3–4 Bits per KV-Paar mittels Vektorquantisierung – ohne messbare Genauigkeitsverluste, dafür mit bis zu 8-facher Beschleunigung der Attention-Berechnung auf H100-GPUs und 6-facher Reduktion des Speicherbedarfs. Parallel dazu adressiert NVIDIA Dynamo 1.0 den KV Cache auf Systemebene: durch Disaggregated Prefill/Decode, Cache-Pinning und agentisches Routing verbessert das Framework die Time-to-First-Token (TTFT) um bis zu 30 % und den Gesamtdurchsatz um 25 %.

KV Cache in der Praxis

In produktiven LLM-Deployments ist der KV Cache längst kein Implementierungsdetail mehr, sondern ein zentraler Kostenhebel. vLLM und SGLang nutzen Paged Attention, um den Cache-Speicher in feste Blöcke aufzuteilen und so Fragmentierung zu minimieren – ähnlich wie virtuelle Speicherverwaltung in Betriebssystemen. Im Bereich langer Dokumente – etwa bei Legal-Tech-Anwendungen oder Code-Analyse über große Repositories – entscheidet die KV-Cache-Effizienz direkt darüber, ob ein 128k-Kontext überhaupt wirtschaftlich betreibbar ist. Benchmarks wie LongBench oder Needle In A Haystack messen explizit, wie zuverlässig Modelle auf Informationen aus langen, gecachten Kontexten zugreifen. Ein weiterer Praxisfall sind Multi-Turn-Chatbots im Enterprise-Einsatz: Durch KV-Cache-Sharing zwischen Requests lassen sich System-Prompts einmalig prefill-en und für tausende parallele Nutzersessions wiederverwenden – was Latenz und Infrastrukturkosten gleichzeitig senkt.

Vorteile und Grenzen

Der offensichtlichste Vorteil: Der KV Cache macht autoregressive Textgenerierung überhaupt erst skalierbar. Ohne ihn wäre jede Konversationsrunde mit einem großen Modell rechnerisch prohibitiv teuer. Der Cache ermöglicht außerdem Techniken wie Speculative Decoding und Prompt-Caching auf API-Ebene – beides setzt voraus, dass K/V-Zustände persistent und adressierbar sind. Die Grenzen sind jedoch nicht zu unterschätzen: Der Speicherbedarf skaliert mit Sequenzlänge × Anzahl Layer × Anzahl Attention Heads × Embedding-Dimension – bei großen Modellen und langen Kontexten ein ernsthafter GPU-RAM-Engpass. KV-Offloading auf CPU-RAM, SSD oder sogar Objektspeicher wie S3 ist technisch möglich, erkauft sich aber höhere Latenz. Quantisierungsmethoden wie TurboQuant reduzieren den Footprint erheblich, sind aber noch nicht überall produktionsreif. Und: In Multi-User-Deployments entstehen komplexe Cache-Invalidierungs- und Isolationsprobleme, die sorgfältiges Systemdesign erfordern.

❓ Häufig gestellte Fragen

Was ist der Unterschied zwischen Prefill und Decode beim KV Cache?
Im Prefill-Schritt verarbeitet das Modell den gesamten Eingabe-Prompt auf einmal und befüllt dabei den KV Cache mit Key- und Value-Vektoren für jedes Token. Im Decode-Schritt wird dann Token für Token generiert – dabei werden nur noch die K/V-Vektoren des jeweils neuen Tokens berechnet und dem Cache hinzugefügt. Alle vorherigen Vektoren werden direkt aus dem Cache gelesen, was die Rechenarbeit pro Token drastisch reduziert.
Warum belegt der KV Cache so viel GPU-Speicher?
Der Speicherbedarf ergibt sich aus dem Produkt mehrerer Faktoren: Sequenzlänge × Anzahl der Transformer-Layer × Anzahl der Attention Heads × Embedding-Dimension × 2 (für K und V) × Datentyp-Größe. Bei einem großen Modell mit langen Kontexten (z. B. 128k Tokens) kann das schnell 10–80 GB GPU-RAM bedeuten – oft mehr als die Modellgewichte selbst. Quantisierung (z. B. auf 4-Bit) und Offloading auf CPU oder SSD sind die gängigsten Gegenmaßnahmen.
Was ist Prompt Caching und wie hängt es mit dem KV Cache zusammen?
Prompt Caching ist eine API-seitige Optimierung, bei der ein Anbieter den KV Cache für wiederkehrende, identische Prompt-Präfixe (z. B. einen langen System-Prompt) über mehrere Requests hinweg persistent hält. Statt bei jedem API-Call den Prefill-Schritt für den System-Prompt zu wiederholen, wird der gecachte K/V-Zustand direkt wiederverwendet. Das senkt sowohl Latenz als auch Kosten erheblich – besonders bei Anwendungen mit vielen parallelen Nutzern und konstantem System-Prompt.
📬 KI-News direkt ins Postfach