Warum LLMs bei langen Texten langsamer werden – wie KV‑Caching hilft

Bei langen Eingaben oder laufenden Chats fällt häufig auf: Die Antwort eines großen Sprachmodells wird mit wachsendem Textumfang langsamer. Das passiert nicht, weil das Modell mehr „denken“ müsste, sondern weil die mathematischen Schritte zur Berechnung der Aufmerksamkeit mit jedem zusätzlichen Token aufwendiger werden. Genau an dieser Stelle setzt eine einfache Idee an: bereits berechnete Zwischenwerte zu speichern und beim nächsten Token wiederzuverwenden. Diese Technik heißt KV‑Caching und ist heute ein Standardbaustein für schnelle, interaktive Anwendungen mit Transformer‑Modellen. Der folgende Text zeigt, wie KV‑Caching funktioniert, welche Kompromisse es gibt und welche technischen Maßnahmen in Produktionsteams üblich sind, damit lange Kontexte trotzdem flott bearbeitet werden können.

Transformer‑Modelle berechnen bei jedem generierten Token eine sogenannte Self‑Attention: Das neue Token fragt die vorherigen Token gewissermassen ab, welche Teile des bisherigen Texts wichtig sind. Formal entstehen dabei für jede Schicht große Key‑ (K) und Value‑(V)‑Matrizen, die mit den Query‑Vektoren des neuen Tokens verrechnet werden. Ohne Cache würde das Modell bei jedem Schritt die gesamte K/V‑Struktur erneut berücksichtigen. Das kostet Rechenzeit und Speicher, weil die Kosten mit der Länge des bisherigen Texts wachsen.

Für längere Kontexte ändert sich die Arbeit pro Token von praktisch quadratisch zu linear, sobald gespeicherte K/V‑Werte wiederverwendet werden.

Auf den Punkt gebracht: Ohne Optimierung müssen bei T bisherigen Token und beim nächsten Schritt O(T) Vergleiche pro Position ausgeführt werden, was über alle Positionen insgesamt O(T^2) Arbeit ergibt. In der Praxis bedeutet das: doppelt so langer Kontext kann mehr als doppelt so lange Rechenzeit erzeugen, abhängig von Modell und Hardware. Diese Skalierung erklärt, warum Generierung mit 2 000 Tokens deutlich langsamer wirkt als mit 200.

Der Performance‑Flaschenhals tritt besonders bei interaktiven Anwendungen zutage, die Token für Token erzeugen. Bei Stapelverarbeitung (Batching) lassen sich einige Kosten durch parallele Verarbeitung ausgleichen, doch für Echtzeit‑Chat ist Batching oft limitiert. Die einfache Einsparungsidee lautet deshalb: Wenn K und V für alte Tokens gleich bleiben, muss man sie nicht immer neu berechnen. KV‑Caching speichert diese Matrizen und macht die Rechenschritte für jedes neue Token erheblich günstiger.

Wenn Zahlen helfen: KV‑Caching verschiebt die asymptotische Kosten pro Token von O(T^2) näher zu O(T) in Bezug auf die Arbeit, die zur Berücksichtigung des historischen Kontexts nötig ist. Konkrete Zeitgewinn‑Faktoren hängen jedoch stark von Modellgröße, GPU‑Typ und Implementierungsdetails ab.

KV‑Caching speichert für jede Attention‑Schicht die Key‑ und Value‑Matrizen, die beim Durchlauf eines Tokens entstehen. Bei autoregressiver Erzeugung bleibt diese Information für vergangene Tokens konstant. Das Modell muss beim nächsten Token nur die neuen Query‑Vektoren berechnen und diese mit den gespeicherten K/V‑Werten zusammenführen. Dadurch entfällt die wiederholte Erzeugung der gleichen K/V‑Matrizen und die aufwendige Neuverarbeitung des gesamten Kontexts.

Technisch besteht die Arbeit in drei Schritten: (1) Beim sogenannten Prefill‑Durchlauf werden für alle Eingabe‑Tokens die K/V‑Werte erzeugt und in einem Cache‑Objekt abgelegt. (2) Bei jedem weiteren Generierungsschritt werden nur die neuen K/V‑Werte für das gerade erzeugte Token angehängt; Queries werden neu berechnet. (3) Die Attention wird zwischen neuen Queries und dem gesamten K/V‑Cache ausgeführt.

Die meisten Open‑Source‑Bibliotheken bieten heute eingebaute Unterstützung: Die Transformers‑Bibliothek stellt dafür Parameter wie past_key_values oder use_cache bereit. Betriebsynonyme sind OffloadedCache (ausgelagerter Speicher), QuantizedCache (komprimierte Speicherung) oder ChunkedCache (gestückelte Speicherung). Offloading verschiebt Teile des Caches auf den Host‑RAM oder NVMe, um GPU‑Speicher zu sparen; Quantisierung reduziert den Speicherbedarf, kann aber die Latenz oder Numerik leicht verändern.

KV‑Caching ist keine Qualitätsveränderung des Modells: Die Ausgabe verändert sich nicht, nur die Art und Weise, wie Ergebnisse berechnet werden. Entsprechend ist KV‑Caching eine Optimierung auf der Inferenz‑Ebene und funktioniert bei den gängigen Transformer‑Architekturen gleich.

Wichtig für Entwickler: Die Implementierung muss mit Speicherverwaltung und Concurrency umgehen. Bei vielen gleichzeitigen Anfragen wachsen die kombinierten K/V‑Caches schnell; Strategien wie gepufferte Host‑Transfers, gepinnter Host‑Speicher oder adaptive Chunk‑Größen sind gängige Techniken, um die Latenz im praktischen Betrieb klein zu halten.

In produktiven Systemen zeigt sich der Nutzen vor allem dort, wo Benutzer längere Kontexte nutzen oder über Sessions hinweg interagieren. Beispiele sind Chat‑Schnittstellen, Assistenzsysteme mit Gesprächsverlauf oder Texteditoren, die lange Entwürfe fortschreiben. Durch den geringeren Rechenaufwand pro Token sinkt die Latenz für neue Antworten, was die Nutzererfahrung deutlich verbessert.

Ein praktisches Messbeispiel aus Entwicklerberichten: Bei einem mittleren Modell war die Token‑Generierung mit aktiviertem Cache oft zwei- bis dreimal schneller als ohne Cache. Solche Zahlen sind stark hardwareabhängig, geben aber einen Eindruck, wie spürbar die Wirkung sein kann. Für Echtzeit‑Chat ist dieser Unterschied oft entscheidend.

Technisch setzen Teams verschiedene Muster ein: Bei ausreichend GPU‑RAM wird der gesamte KV‑Cache auf der GPU gehalten. Steht weniger GPU‑RAM zur Verfügung, wird der Cache auf den Host ausgelagert (offloading) oder quantisiert abgespeichert. Moderne Inferenz‑Stacks nutzen oft eine mehrstufige Strategie: GPU für die aktuell benötigten, heißgenutzten Teile, gepinnter Host‑RAM für große, seltenere Teile und NVMe als letzte Stufe.

Beim Betrieb ist Metrik‑Telemetrie wichtig. Relevante Messwerte sind Token/s, Latenzverteilung per Request, Cache‑Evictions und die Menge an Daten, die zwischen GPU und Host transferiert werden. Diese Kennzahlen helfen zu entscheiden, ob Offload, Quantisierung oder Recomputation (neu berechnen statt swapen) vorteilhafter sind. Automatisierte A/B‑Tests mit realen Workloads sind der beste Weg, um die Balance zu finden.

Für Entwickler heißt das: KV‑Caching aktivieren, Telemetrie einrichten, dann die Parameter empirisch anpassen — etwa Chunk‑Größe, ob gepinnter Host genutzt wird, und Quantisierungsstufe. Bibliotheken wie Transformers und vLLM bieten passende Optionen, sodass erste Tests schnell möglich sind.

KV‑Caching verringert Rechenarbeit, verschiebt aber die Herausforderung auf den Speicher. Der Cache wächst linear mit der Anzahl der Tokens; bei sehr langen Sessions kann er GPU‑RAM sprengen. Deshalb sind hybride Strategien notwendig: Offloading, Quantisierung oder selektives Verwerfen älterer Token.

Offloading (Auslagern auf Host‑RAM oder NVMe) spart GPU‑Speicher, kann jedoch durch PCIe‑Transfers Latenz hinzufügen. Ob Offload schneller ist als die Neuberechnung von K/V‑Werten (Recompute) hängt von drei Faktoren zusammen: I/O‑Overhead pro Transfer, Rechenkosten für die Neuberechnung und Größe der verschobenen Chunks. Forschungsergebnisse zeigen, dass bei großen, gut gepackten Transfers Offload gewinnt; bei vielen kleinen Transfers ist Recomputation manchmal effizienter.

Quantisierung reduziert Speicherbedarf deutlich, etwa durch int8 oder int4 Formate. Das hilft bei sehr langen Kontexten, kann aber die Rechenzeit erhöhen, wenn Konvertierungen nötig sind, oder die numerische Stabilität leicht beeinflussen. Daher prüfen Teams Quantisierung schrittweise: erst int8, dann int4, während sie Qualität und Latenz beobachten.

Weiterhin ist Concurrency ein Thema: Viele parallele Requests erzeugen komplexe Zugriffsprofile auf den KV‑Cache. Architekturen, die Cache‑Segmente gemeinsam nutzen oder dedizierte Caches pro Session einsetzen, müssen sorgfältig orchestriert werden, um Engpässe zu vermeiden.

Zusammengefasst sind die gängigen Optimierungsansätze: adaptives Offloading mit großen Transfers, quantisierte Speicherung als Kompromiss zwischen RAM und Latenz, und Telemetrie‑gesteuerte Entscheidungen, ob evicted Einträge recomputed oder ausgelagert werden. Diese Maßnahmen erlauben, die Vorteile von KV‑Caching auch bei sehr großen Kontexten zu nutzen.

KV‑Caching ist eine pragmatische und effektive Antwort auf das Problem, dass Sprachmodelle bei langen Texten langsamer werden. Es entfernt redundante Berechnungen, indem es Key‑ und Value‑Strukturen speichert und wiederverwendet, und sorgt so für deutlich geringere Kosten pro zusätzlich generiertem Token. In der Praxis müssen Teams aber Speicherstrategien, Offloading und gegebenenfalls Quantisierung prüfen, denn die Einsparungen bei der Rechenlast kommen nicht ohne Speicherkompromisse. Wer Telemetrie und kontrollierte Experimente einsetzt, kann die optimale Balance finden und lange Kontexte in interaktiven Anwendungen performant anbieten.