Der KV-Cache ist Ihr echtes VRAM-Problem: 128k-Kontext richtig dimensionieren

Es ist eines der häufigsten Gespräche in Dimensionierungsprojekten: Ein Unternehmen hat sich für ein 70B-Modell entschieden, die Rechnung „140 GB Gewichte, also zwei H100 mit 80 GB" wurde aufgemacht, die Hardware steht. Im Pilotbetrieb mit drei Testern läuft alles hervorragend. Dann kommen zwanzig Nutzer dazu, jemand lädt eine 300-seitige Ausschreibung in den Chat – und der Server geht in die Knie. Nicht mit einer sauberen Fehlermeldung, sondern mit Warteschlangen, Zeitüberschreitungen und einem Durchsatz, der auf ein Fünftel einbricht.

Die Ursache ist fast immer dieselbe und sie hat einen Namen: der KV-Cache. Er taucht in keinem Modell-Datenblatt auf, er wird beim Hardwarekauf regelmäßig vergessen, und er ist bei langen Kontexten der Posten, der den VRAM tatsächlich auffrisst. Dieser Artikel rechnet das durch – mit den Formeln, den Zahlen für konkrete Modelle und der ehrlichen Gegenüberstellung, wann sich ein großes Kontextfenster lohnt und wann RAG die wirtschaftlichere Architektur ist.

Warum das Modell passt und der Betrieb trotzdem scheitert

Bei der Inferenz eines Transformer-Modells wird für jedes bereits verarbeitete Token ein Key- und ein Value-Vektor je Layer zwischengespeichert. Das ist kein Luxus, sondern die Grundlage effizienter Generierung: Ohne diesen Cache müsste das Modell bei jedem neuen Token die gesamte bisherige Sequenz neu durchrechnen. Mit Cache genügt eine Aufmerksamkeitsberechnung gegen den gespeicherten Zustand.

Der Haken liegt im Skalierungsverhalten. Die Modellgewichte sind eine Konstante: Ein Llama-3.3-70B in BF16 belegt 140 GB – egal ob ein Nutzer oder hundert Nutzer angemeldet sind, egal ob mit 2.000 oder 128.000 Token Kontext gearbeitet wird. Der KV-Cache dagegen skaliert gleich zweifach linear: einmal mit der Sequenzlänge, einmal mit der Zahl der gleichzeitig aktiven Sequenzen. Zwanzig Nutzer mit je 32k Kontext brauchen exakt zwanzigmal so viel Cache wie einer.

Genau deshalb ist die verbreitete Faustregel „Gewichte plus 30 bis 50 Prozent Aufschlag" gefährlich. Sie stimmt – für kurze Kontexte um 4k bis 8k und kleine Batches. Bei Long Context bricht sie zusammen. Ein Llama-3.1-8B belegt 16 GB an Gewichten; sein KV-Cache bei 128k Kontext beträgt 16 GiB. Der Cache ist dann so groß wie das Modell selbst, also ein Aufschlag von 100 Prozent – für einen einzigen Nutzer. Bei einem 70B-Modell mit 128k liegt der Aufschlag pro Nutzer bei rund 29 Prozent; bei vier gleichzeitigen Nutzern sind es bereits 115 Prozent.

Erschwerend kommt hinzu, dass das Symptom untypisch aussieht. Moderne Inferenz-Engines wie vLLM reservieren beim Start einen festen Anteil des VRAM als KV-Cache-Pool (in vLLM per gpu_memory_utilization). Ist dieser Pool voll, stürzt nichts ab – die Engine schiebt Anfragen in die Warteschlange oder verdrängt („preemptet") laufende Sequenzen, deren Cache dann neu berechnet werden muss. Aus Nutzersicht wirkt das wie ein diffuses Performanceproblem, nicht wie eine Speichergrenze. Wer im Monitoring nur auf „VRAM belegt" schaut, sieht ohnehin fast immer 90 Prozent und hält das für normal.

Die Rechenformeln, die Sie brauchen

Es sind drei Formeln. Die erste kennen die meisten, die zweite ist die wichtige, die dritte ist die, mit der Sie eine Beschaffung begründen.

1. Modellgewichte

Der Speicherbedarf der Gewichte folgt direkt aus der Bit-Breite der Quantisierung: rund 2 GB pro Milliarde Parameter bei FP16/BF16 (2 Byte je Parameter), rund 1 GB bei FP8, rund 0,5 GB bei INT4. Für ein 70B-Modell heißt das: 140 GB in BF16, 70 GB in FP8, 35 GB in INT4. Diese Zahl ist konstant und leicht zu prüfen – sie steht faktisch schon in der Dateigröße der Modellgewichte auf Hugging Face.

2. KV-Cache – die vollständige Formel

Hier lohnt es sich, nicht mit einer Faustregel zu arbeiten, sondern mit der echten Gleichung:

KV-Cache = 2 × Layer × KV-Heads × head_dim × Bytes_pro_Wert × Kontextlänge × gleichzeitige Sequenzen

Die Faktoren im Einzelnen: Die 2 steht für Key und Value. Layer, KV-Heads und head_dim lesen Sie direkt aus der config.json des Modells (num_hidden_layers, num_key_value_heads, head_dim bzw. hidden_size / num_attention_heads). Bytes_pro_Wert ist 2 bei BF16 und 1 bei FP8-KV-Cache.

Der entscheidende Punkt: In dieser Formel kommt die Parameterzahl des Modells überhaupt nicht vor. Der KV-Bedarf hängt an der Attention-Architektur, nicht an der Modellgröße. Zwei Modelle, die beide „7B" heißen, können sich im KV-Bedarf um den Faktor 4 bis 9 unterscheiden. Wer mit einer parametrischen Faustregel rechnet, reproduziert systematisch falsche Zahlen.

3. Nutzerbudget

Max_Nutzer = (GPU-Speicher − Gewichte − Aktivierungs-/Framework-Overhead) ÷ KV-Cache pro Nutzer

Für Aktivierungen, CUDA-Graphs und Framework-Overhead sollten Sie 5 bis 10 GB je GPU einplanen, bei sehr großen Batches eher mehr. Das Ergebnis ist eine harte Obergrenze: Mehr gleichzeitige Sessions mit dem konfigurierten Kontextlimit passen physikalisch nicht in die Karte. Alles darüber landet in der Warteschlange.

Konkrete Zahlen für 7B und 70B

Rechnen wir die Formel für ein 70B-Modell der Llama-3.x-Klasse durch: 80 Layer, 8 KV-Heads (dank Grouped-Query-Attention statt 64), head_dim 128, BF16. Das ergibt 2 × 80 × 8 × 128 × 2 Byte = 327.680 Byte pro Token – exakt 320 KiB je Token und Nutzer. Diese eine Zahl ist der Hebel für alles Weitere.

Kontextlänge	KV-Cache BF16 (1 Nutzer)	Mit FP8-KV-Cache	Gesamt mit 140 GB Gewichten
8K	2,5 GiB (2,7 GB)	1,25 GiB	≈ 143 GB
32K	10 GiB (10,7 GB)	5 GiB	≈ 151 GB
128K	40 GiB (42,9 GB)	20 GiB	≈ 183 GB
256K *	80 GiB (85,9 GB)	40 GiB	≈ 226 GB
512K *	160 GiB (171,8 GB)	80 GiB	≈ 312 GB
1M *	320 GiB (343,6 GB)	160 GiB	≈ 484 GB

* Llama-3.1/3.3-70B ist mit max_position_embeddings = 131.072 konfiguriert, unterstützt also nativ nur 128K. Die Zeilen ab 256K sind Extrapolationen der Formel – sie zeigen, was diese Kontextlängen bei gleicher Architektur kosten würden, und gelten sinngemäß für Modelle mit größerem Fenster.

Die praktisch wichtigste Zeile ist die 128K-Zeile: exakt 40 GiB pro Nutzer. Das ist die halbe Kapazität einer H100 mit 80 GB – für eine einzige Session. Wer also „128k für alle" freischaltet und mit zwanzig aktiven Nutzern plant, braucht allein für den Cache 800 GiB. Das sind zehn H100 – nur für Zwischenspeicher, ohne ein einziges Modellgewicht.

Warum „7B" keine Aussage über den KV-Bedarf ist

Bei kleineren Modellen wird die Architekturabhängigkeit besonders deutlich. Drei Beispiele, jeweils in BF16 und pro Nutzer:

Modell	Architektur	je Token	4K	32K	128K
Llama-3.1-8B	32 Layer, 8 KV-Heads, head_dim 128	128 KiB	0,54 GB	4,3 GB	17,2 GB
Qwen2.5-7B	28 Layer, 4 KV-Heads, head_dim 128	56 KiB	0,24 GB	1,9 GB	7,5 GB
Llama-2-7B (ohne GQA)	32 Layer, 32 KV-Heads, head_dim 128	512 KiB	2,1 GB	17,2 GB	68,7 GB

Drei Modelle derselben Größenordnung, ein Faktor von rund 9 zwischen dem sparsamsten und dem verschwenderischsten. Der Unterschied liegt ausschließlich in der Attention-Variante: Grouped-Query-Attention reduziert die Zahl der KV-Heads gegenüber der Zahl der Attention-Heads und schrumpft den Cache proportional. Genau deshalb hat sich GQA seit Llama 3 durchgesetzt – und deshalb gehen moderne Mixture-of-Experts-Modelle mit komprimierten Attention-Varianten noch weiter. Bei ihnen hängt der Cache an der aktiven Attention-Architektur, nicht an der Gesamtparameterzahl; ein MoE-Modell mit 35 Milliarden Gesamt- und wenigen Milliarden aktiven Parametern kann deutlich unter den Werten liegen, die man aus der Gesamtgröße ableiten würde.

Long-Context gegen RAG: die Kostenrechnung

Seit die großen Anbieter Kontextfenster von einer Million Token anbieten, hält sich die These, RAG sei damit überflüssig: Man werfe einfach die gesamte Dokumentation in den Prompt. Die Rechnung dagegen ist eindeutig – und zwar in beiden Dimensionen, Kosten und Latenz.

Kosten

Bei einem Input-Preis von 2,00 USD je Million Token kostet ein einzelner 1M-Token-Aufruf rund 2,00 USD. Eine RAG-Query, die stattdessen fünf bis zehn relevante Passagen einbettet, liegt bei rund 0,0016 USD – ein Verhältnis von etwa 1:1.250. Konservativer, dafür peer-reviewed: Eine Messung über zwei LLMs (arXiv 2606.20898) ermittelte 0,1181 USD je Anfrage für Long-Context-Prompting gegenüber 0,0046 USD für Keyword-RAG und 0,0045 USD für semantisches RAG – also gut Faktor 26. Je nach Prompt-Größe liegt der reale Vorteil von RAG damit zwischen Faktor 25 und Faktor 1.250. In keiner Konstellation ist Long Context billiger.

Bemerkenswert und kontraintuitiv am aktuellen Markt: Der frühere Long-Context-Aufschlag oberhalb von 200K Token ist bei den führenden Modellen entfallen. Anthropics Claude Opus 5 kostet 5,00 USD je Million Input-Token und 25,00 USD je Million Output-Token, Claude Sonnet 5 liegt bei 3,00 USD Input (Einführungspreis 2,00 USD bis 31.08.2026) und 15,00 USD Output – das volle 1M-Fenster wird zum Standardpreis abgerechnet. Der Long-Context-Nachteil entsteht also nicht mehr durch einen Strafzuschlag, sondern schlicht durch die Menge der abgerechneten Token.

Latenz

Die zweite Dimension ist die, die Nutzer tatsächlich spüren. Time-to-First-Token wächst mit der Kontextlänge überproportional, nicht linear, weil der Prefill quadratisch in die Attention-Berechnung eingeht. Gemessene Werte: rund 20 Sekunden bei etwa 160K Token, über 60 Sekunden bei etwa 890K Token, im Produktivmittel rund 45 Sekunden bei 1M-Token-Prompts. Eine RAG-Pipeline liegt end-to-end bei etwa einer Sekunde. Long Context ist damit 30- bis 60-mal langsamer.

Die konkreteste verfügbare Illustration stammt aus einem Cluster mit 16 Knoten und 128 H100: Der Prefill von 128K Token dauert dort rund 3,8 Sekunden, der von 1M Token rund 77 Sekunden. Achtfacher Kontext, zwanzigfache Zeit. Prefill ist der eigentliche Long-Context-Killer – und er kostet dieselbe GPU-Zeit, ob der Nutzer die Antwort braucht oder nicht.

Prefix Caching als Mittelweg

Zwischen „alles in den Prompt" und „nur Retrieval-Snippets" liegt ein Mechanismus, der in der Dimensionierung oft übersehen wird: Prefix Caching. Die Idee ist einfach – wenn viele Anfragen denselben Präfix teilen (System-Prompt, Rollendefinition, ein fest eingebettetes Handbuchkapitel, ein Block mit Tool-Definitionen), muss der KV-Cache dafür nur einmal berechnet und dann über alle Anfragen hinweg wiederverwendet werden.

Die beiden führenden Open-Source-Engines lösen das unterschiedlich:

• vLLM – Automatic Prefix Caching (APC): Block-Level-Hashing. Der KV-Cache wird in Blöcke fester Größe zerlegt, jeder Block über seinen Token-Inhalt und seine Präfixposition per Chained Hashing gehasht. Trefferquoten sind hoch, aber die Granularität ist der Block – ein Präfix, der mitten im Block abweicht, invalidiert den Rest.
• SGLang – RadixAttention: Ein Token-Level-Radix-Tree über alle laufenden und beendeten Anfragen. Gemeinsame Präfixe werden automatisch und tokengenau erkannt, auch bei verzweigenden Konversationen. Das ist feingranularer und spielt seine Stärke bei Multi-Turn- und Agenten-Workloads aus.

Zu den Zahlen ist Präzision angebracht: Das SGLang-Paper (arXiv 2312.07104) weist bis zu 6,4-fachen Durchsatz gegenüber State-of-the-Art-Systemen aus – als Best Case über eine gemischte Workload-Sammlung (Agent-Control, Logical Reasoning, Few-Shot Learning, JSON-Decoding, RAG, Multi-Turn-Chat), nicht als prefix-spezifische Messung. Realistischere Werte aus Vergleichen von 2026: SGLang erreicht auf kleineren Modellen rund 16.200 Token pro Sekunde gegenüber rund 12.500 bei vLLM, also etwa 29 Prozent mehr. Der RadixAttention-Vorteil greift messbar, sobald mehr als 60 Prozent der Anfragen einen gemeinsamen Präfix teilen.

Für die Dimensionierung heißt das konkret: Ein 20.000-Token-System-Prompt, den 50 Nutzer teilen, kostet mit Prefix Caching einmal Cache statt fünfzigmal. Das ist kein Nebeneffekt, sondern oft der Unterschied zwischen „passt" und „passt nicht". Wer seine Prompts entsprechend baut – Statisches zuerst, Variables ans Ende – erhöht die Trefferquote ohne jede Investition.

KV-Offloading und Kompression

Wenn der VRAM nicht reicht, gibt es zwei technische Auswege: den Cache auslagern oder ihn verkleinern. Beide funktionieren, beide haben Grenzen.

Offloading in CPU-DRAM

Der Cache wandert bei Bedarf über PCIe in den Hauptspeicher und zurück. Der Haken ist Physik: PCIe liefert rund zwei Größenordnungen weniger Bandbreite als der HBM-Speicher auf der Karte. Der Transfer wird damit selbst zum Flaschenhals – als Puffer für seltene Langkontexte oder für Cache-Wiederverwendung über Sessions hinweg sinnvoll, als Dauerlösung für den Hot Path nicht.

Die Praxiszahlen aus dem vLLM-Projekt sind allerdings besser, als diese Warnung vermuten lässt: Für Llama-3.1-8B auf einer H100 sinkt die Time-to-First-Token bei CPU-Cache-Treffern um Faktor 2 bis 22 – je nach Prompt-Größe –, der Durchsatz bei parallelen Anfragen steigt um bis zu 9x. Der DMA-basierte Transfer erreicht 83,4 GB/s bidirektional gegenüber 68,5 GB/s beim vorherigen Custom-Kernel. Allein zwischen v0.11.0 und v0.12.0 verbesserten sich TTFT um Faktor 4 und Durchsatz um Faktor 5.

Die Entwicklung geht weiter: vLLM v0.23.0 vom 12. Juni 2026 brachte mit 408 Commits unter anderem ein Object-Store-Tier als Secondary Tier im KV-Offloading-Framework (PR #41968), HMA standardmäßig aktiviert für fähige Connectors (#41847), Tiering für HMA-Modelle (#44287) sowie eine Per-Request-Offloading-Policy über den on_new_request-Hook (#43205). Ergänzend kam selektive Prefix-Cache-Retention für Sliding-Window-KV-Cache (#43447). Praktisch bedeutet das: Sie können pro Anfrage entscheiden, ob deren Cache ausgelagert werden darf – etwa Batch-Auswertungen ja, interaktive Chats nein.

Kompression

Der zweite Weg quantisiert den Cache selbst. FP8-KV-Cache ist der pragmatische Standard und halbiert exakt. Darüber hinaus wird es interessant: Googles TurboQuant (ICLR 2026; ursprünglich arXiv 2504.19874, April 2025, Google Research gemeinsam mit der NYU) quantisiert den KV-Cache auf rund 3 Bit je Koordinate und erreicht damit mindestens 6-fache Speicherreduktion sowie bis zu 8-fach schnellere Attention-Berechnung auf einer H100 – bei praktisch verlustfreier Qualität. Das Verfahren kombiniert PolarQuant (eine rotationsbasierte Koordinatentransformation, AISTATS 2026) mit einer 1-Bit-QJL-Residualkorrektur (AAAI 2025). Es ist datenunabhängig, benötigt kein Training und liegt innerhalb von Faktor 2,7 der informationstheoretischen Grenze. Mehrere Open-Source-Implementierungen existieren bereits.

Für eine Beschaffungsentscheidung heute gilt: FP8 einplanen, aggressivere Kompression im Blick behalten. Wer eine Anlage auf drei bis fünf Jahre auslegt, sollte nicht davon ausgehen, dass die heutigen KV-Werte für die gesamte Laufzeit gelten – sie werden eher sinken.

Vom VRAM-Budget zur Serverkonfiguration

Die Reihenfolge, in der diese Entscheidungen getroffen werden, ist der eigentliche Unterschied zwischen einem funktionierenden und einem enttäuschenden Projekt. Richtig ist:

1. Nutzerzahl und Gleichzeitigkeit festlegen. Nicht die Zahl der Lizenzen, sondern die Zahl der Sessions, die zur Spitzenzeit gleichzeitig aktiv sind. Erfahrungswert im Mittelstand: 10 bis 20 Prozent der Gesamtnutzer.
2. Kontextlimit pro Rolle festlegen. Ein Support-Chat braucht 8k, ein Vertragsprüfer vielleicht 128k. Ein globales Limit von 128k für alle ist die teuerste Konfiguration, die Sie treffen können.
3. Modell und Quantisierung wählen. Erst danach steht der Gewichteanteil fest.
4. KV-Budget berechnen – mit der vollständigen Formel und der config.json des konkreten Modells, nicht mit einer Faustregel.
5. Hardware ableiten, mit 20 bis 30 Prozent Reserve für Lastspitzen und künftig größere Modelle.

Ein durchgerechnetes Beispiel für die Brücke von der Formel zur Kaufentscheidung: Llama-3.3-70B in BF16 sind 140 GB Gewichte. Zusammen mit 40 GiB KV-Cache für einen einzigen 128k-Nutzer passt das nicht auf zwei H100 mit 80 GB (160 GB gesamt). In FP8 dagegen – 70 GB Gewichte plus 40 GiB Cache – passt es, mit Raum für etwa zwei bis drei gleichzeitige 128k-Sessions oder ein Vielfaches davon bei 16k bis 32k Kontext. Dieselbe Hardware, zwei völlig verschiedene Betriebsrealitäten, entschieden durch eine Konfigurationsoption.

Zwei weitere Stellschrauben lohnen sich bei größeren Installationen. Erstens: Kontextlimits pro Rolle sind das mit Abstand billigste Steuerungsinstrument – eine Konfigurationszeile ersetzt hier regelmäßig eine fünfstellige Hardwareinvestition. Zweitens: Prefill-Decode-Disaggregation trennt die Prefill-Phase (rechenlastig, profitiert von starker Compute-Leistung) von der Decode-Phase (bandbreitenlastig, profitiert von HBM-Durchsatz) auf getrennte Knoten oder Karten. Das verhindert, dass ein einzelner 128k-Prefill die Antwortzeiten aller laufenden Chats blockiert – ein Effekt, der in gemischten Workloads sonst zuverlässig für Beschwerden sorgt.

Wenn Sie diese Rechnung für Ihren Fall aufmachen wollen: Unser TCO-Rechner übersetzt Nutzerzahl und Modellwahl in Hardware- und Betriebskosten, und unter On-Premise-KI-Server finden Sie die konkreten Konfigurationen, die wir für die hier beschriebenen Szenarien ausliefern. Wer zuerst wissen will, ob sich der Aufwand überhaupt lohnt, startet mit dem KI-Schnellcheck.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. GitHub v0.23.0
2. vllm.ai 2026 01 08 kv offloading connector
3. research.google turboquant redefining ai efficiency with extreme compression
4. arXiv 2504.19874
5. arXiv 2312.07104
6. medium.com prefix caching sglang vs vllm token level radix tree vs block level hashing b99e
7. tianpan.co 2026 04 09 long context vs rag production decision framework
8. arXiv 2606.20898
9. spheron.network vllm vs sglang 2026

Häufig gestellte Fragen zum KV-Cache

Wie viele Nutzer schafft eine 96-GB-Karte mit einem 70B-Modell?

Das hängt fast vollständig am Kontextlimit. Ziehen Sie die quantisierten Gewichte vom Kartenspeicher ab und teilen Sie den Rest durch den KV-Cache pro Nutzer – bei 32k Kontext sind das andere Größenordnungen als bei 128k.

Ist RAG durch 1-Million-Token-Kontext überflüssig geworden?

Nein. Der Preisunterschied pro Anfrage liegt bei Faktor tausend und mehr, die Latenz steigt von wenigen Sekunden auf 45 Sekunden und mehr. RAG bleibt die wirtschaftliche Architektur – lange Kontexte sind ein Werkzeug für Sonderfälle.

Hilft KV-Offloading in den Arbeitsspeicher?

Es verschiebt den Engpass. PCIe liefert rund zwei Größenordnungen weniger Bandbreite als HBM, damit wird der Transfer selbst zum Flaschenhals. Als Puffer für seltene Langkontexte sinnvoll, als Dauerlösung nicht.

Warum brauchen MoE-Modelle oft weniger KV-Cache als erwartet?

Weil der Cache an der Attention-Architektur hängt, nicht an der Gesamtparameterzahl. Moderne MoE-Modelle mit komprimierten Attention-Varianten kommen bei gleichem Kontext mit deutlich weniger Cache aus.