Long-Context-LLM-Hardware: KV-Cache und VRAM für Gespräche mit 128K bis 1M Token

Long-Context-LLM-Hardware: Der KV-Cache bestimmt den Speicher

Ab 128K Token entscheidet der KV-Cache stärker als die Gewichte darüber, wie viel GPU-Speicher ein Modell braucht, und er wächst mit jedem Token jedes laufenden Gesprächs. Bei Llama 3.3 70B belegt ein Gespräch mit 128K 40 GiB Cache in 16 Bit, mehr als die Hälfte der FP8-Gewichte des Modells. Bei gpt-oss-120b sind es 4,5 GiB und bei DeepSeek-V4-Flash etwa 0,8 GiB. Der Unterschied ergibt sich aus dem Attention-Design in der config.json des jeweiligen Modells, deshalb wird Hardware für Long-Context-LLMs Modell für Modell dimensioniert.

Mit 128K sind hier 131.072 Token gemeint, mit 1M 1.048.576. Die Konfigurationen sind unsere Schätzungen nach der Regel aus unserem Leitfaden dazu, wie viel VRAM ein LLM braucht, also 90 Prozent des vom Treiber gemeldeten Speichers abzüglich 3 GiB je Karte, mit den Gewichten wie in unserem Leitfaden zu den LLM-Hardware-Anforderungen je Modell.

KV-Cache je Token: Formel und Werte nach Modell

Für ein Modell mit voller Attention in jedem Layer beträgt der Cache je Token 2 × Layer × KV-Heads × Head-Dimension × Bytes pro Wert, wobei die 2 für Keys und Values steht. Llama 3.3 70B hat 80 Layer, 8 KV-Heads und eine Head-Dimension von 128, das ergibt 320 KiB je Token in 16 Bit. Modelle mit Multi-Head Latent Attention (MLA) speichern stattdessen je Layer einen komprimierten latenten Vektor aus kv_lora_rank plus der RoPE-Dimension: 512 + 64 Werte bei DeepSeek-V3.2 und GLM-5.3, 256 + 64 bei Mistral Small 4. Layer, die nur ein Fenster oder einen festen Zustand halten, wachsen nicht mit dem Kontext und bleiben deshalb aus dem Wert je Token heraus.

Unsere Rechnung aus den config.json-Dateien auf Hugging Face, abgerufen am 9. Oktober 2026, für Scout aus den Voreinstellungen von Transformers; der Kontext aus den Model Cards und bei GLM-5.3 aus der Dokumentation von Z.ai. Qwen gibt 1.000.000 Token an, etwa 5 Prozent unter der Spalte für 1M. Ein FP8-Cache halbiert die Attention-Werte ungefähr.

Wie Sliding-Window-, lineare und Latent Attention den Cache verkleinern

gpt-oss-120b hat 36 Layer mit 8 KV-Heads der Dimension 64: 18 rechnen Attention über den ganzen Kontext und 18 über ein Sliding Window von 128 Token. Die Designnotizen von vLLM zu seinem hybriden KV-Cache-Manager reservieren in Sliding-Window-Layern Slots „nur für die jüngsten sliding_window_size Token“, deshalb zählen nur die 18 vollen Layer, 36 KiB je Token.

Qwen3.8-27B hält einen vollen Cache in 16 seiner 64 Layer, mit 4 KV-Heads der Dimension 256; die übrigen 48 sind Gated-DeltaNet-Layer mit einem festen Zustand von nach unserer Schätzung etwa 0,14 GiB in 32 Bit je Gespräch. Qwen3.8-Flash-Next hat 12 volle Layer mit 2 KV-Heads, dazu einen Indexer für Qwen Sparse Attention, dessen Cache wir nicht dokumentiert gefunden und nicht mitgezählt haben. Beide Cards nennen „nativ 262.144 und erweiterbar auf bis zu 1.000.000 Token“ mit YaRN, das die Card des 27B nur empfiehlt, wenn lange Kontexte erforderlich sind, da statisches YaRN „möglicherweise die Leistung bei kürzeren Texten beeinträchtigt“.

DeepSeek-V3.2 und GLM-5.3 ergänzen MLA um einen Indexer für Sparse Attention, dessen FP8-Keys und Skalierungen wir mit 132 Bytes je Token und Layer ansetzen. GLM-5.3 kennzeichnet 57 seiner 78 Indexer-Layer als „shared“; zählt man die Keys in allen 78, ergibt sich eine Obergrenze, und halten die geteilten keine, sind es 90,5 KiB.

Die Konfiguration von DeepSeek-V4-Flash-0731, dem offiziellen Release, führt 43 Layer auf, 20 im Verhältnis 4 komprimiert, 19 im Verhältnis 128 und vier unkomprimiert, mit einem KV-Head der Dimension 512 und einem Sliding Window von 128 Token. Der Blog von vLLM vom 24. April 2026 schreibt, dass manche Layer „rein ein Sliding Window für lokale Informationen ohne Komprimierung nutzen“, nach unserem Verständnis die unkomprimierten, und dass DeepSeek V4 mit einem BF16-Cache „bei 1M Kontext nur 9,62 GiB KV-Cache je Sequenz hat“. Dieselbe Rechnung ergibt für V4-Flash-0731 6,4 KiB je Token und etwa 6,4 GiB bei 1M, und höchstens 3,9 GiB mit dem FP8-Cache, den das vLLM-Rezept setzt.

Die Konfigurationsdatei von Llama 4 Scout ist zugangsbeschränkt (gated), deshalb nutzen wir für Scout die Voreinstellungen von Transformers: 48 Layer, 8 KV-Heads der Dimension 128 und eine attention_chunk_size von 8.192. Die Designnotizen von vLLM nennen für Llama 4 Layer im Verhältnis „3 lokal : 1 voll“, ohne anzugeben, wie viele Token die lokalen Layer halten, deshalb zählen wir alle 48 mit voller Länge; die 12 vollen Layer allein belegen 48 KiB je Token.

Welche Konfiguration 128K, 256K oder 1M Token fasst

Unsere Schätzungen, keine Messungen, mit einem 16-Bit-Cache und den Obergrenzen für Scout und GLM-5.3, ausgehend von 83,0 GiB je RTX PRO 6000, 123,4 GiB je H200 NVL und 102 GB je DGX Spark (128 GB). DeepSeek-V4-Flash und GLM-5.3 halten unter Tensor-Parallelismus ihren vollen Cache auf jeder Karte; DCP steht für Decode Context Parallelism.

Ein DGX Spark fasst gpt-oss-120b mit sieben Gesprächen mit 128K und Qwen3.8-27B in FP8 mit einem Gespräch mit 1M, mit einem Spielraum von etwa 2 GiB; unser Artikel dazu, was in 128 GB auf einem DGX Spark passt, erklärt das Arbeitsbudget von 102 GB.

Auf der H200 NVL setzen die Zeilen zu DeepSeek-V4-Flash voraus, dass seine FP4-Experten Weight-only laufen, was unser Übersichtsartikel anhand der Dokumente von DeepSeek und vLLM nicht bestätigen konnte. Llama 4 Scout braucht bei 1M zwei statt vier Karten, wenn seine lokalen Layer nur ihren Chunk halten.

Wir bauen Inferenz-Server mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Nennen Sie uns die Dokumentgrößen und den Kontext, den Sie brauchen, dazu die Zahl der Gespräche in der Spitze, und wir dimensionieren den Server.

Lange Gespräche auf mehreren GPUs

Tensor-Parallelismus verteilt die KV-Heads eines Modells auf die Karten: acht bei Llama 3.3 70B, gpt-oss-120b und Llama 4 Scout, vier bei Qwen3.8-27B. Der Blog von vLLM vom 7. August 2026 zu Decode Context Parallelism hält fest, dass sich der Cache, „sobald TP die Zahl der KV-Heads übersteigt, über die GPUs hinweg zu duplizieren beginnt“; zehn Gespräche mit 1M von Qwen3.8-27B laufen deshalb als zwei Kopien auf je vier H200 NVL.

Latent Attention hat keine Heads, die sich aufteilen ließen. Derselbe Beitrag hält fest, dass unter Tensor-Parallelismus „der latente KV-Cache vollständig auf jedem TP-Rank repliziert wird“. Der Leitfaden von SGLang zu datenparalleler Attention beschreibt dieselbe Duplizierung für DeepSeeks MLA, während jedes datenparallele Replikat „seinen eigenen KV-Cache verwaltet (keine Duplizierung)“. In beiden Anordnungen hält jede Karte den ganzen Cache jedes Gesprächs, das sie bedient, deshalb begrenzt der freie Speicher einer Karte den längsten Kontext; DeepSeek-V4-Flash mit einem KV-Head verhält sich unter Tensor-Parallelismus genauso.

Decode Context Parallelism (DCP) teilt den Cache einer Anfrage nach Token-Position auf die Karten eines Tensor-Parallel-Verbunds auf. vLLM setzt es mit --decode-context-parallel-size für MLA- und GQA-Modelle, und Release 0.30.0 führt „PCP+DCP on sparse-MLA models“ auf; SGLang setzt es mit --dcp-size und zeigt es für DeepSeek-V3.1. Auch Pipeline-Parallelismus teilt den Cache auf, da jede Karte nur den Cache ihrer eigenen Layer hält. Ein Gespräch mit 1M von GLM-5.3 auf acht H200 NVL, mit etwa 35 GiB je Karte nach den Gewichten, braucht DCP, HiSparse-Offloading oder, mit einem FP8-Cache, zwei Pipeline-Stufen; ein Rezept, das GLM-5.3 oder DeepSeek-V4 mit DCP betreibt, haben wir nicht gefunden. Mit 123 GiB je Karte für Gewichte und Cache gegenüber 83 GiB fasst die H200 NVL lange MLA-Gespräche auf weniger Karten.

Prefix Caching, FP8-KV-Cache und Chunked Prefill

Die folgenden Funktionen beschreiben wir nach der „latest“-Dokumentation von vLLM, einer Developer Preview, Stand 9. Oktober 2026; das aktuelle Release ist 0.31.0 vom 5. Oktober. Automatic Prefix Caching „speichert den KV-Cache vorhandener Anfragen zwischen, sodass eine neue Anfrage den KV-Cache direkt wiederverwenden kann“, wenn das Präfix übereinstimmt, etwa bei wiederholten Fragen zu einem langen Dokument oder in einem Gespräch über mehrere Runden. Es „verkürzt nur die Zeit für die Verarbeitung der Anfragen (die Prefill-Phase)“.

Ein FP8-Cache, gesetzt mit --kv-cache-dtype fp8, „kann seinen Speicherbedarf deutlich verringern“, so vLLM, und halbiert die Attention-Werte in beiden Tabellen ungefähr. Für DeepSeek-V3.2 beschreibt der Beitrag von vLLM vom 29. September 2025 ein FP8-Format mit 656 Bytes je Token und Layer, 57 Prozent der 1.152 Bytes in BF16.

Ein langer Prompt wird vor dem ersten Token in einem Prefill berechnet. In vLLM V1 „ist Chunked Prefill standardmäßig aktiviert, wo immer möglich“: Große Prefills laufen in Chunks, im Batch zusammen mit Decode-Anfragen, sodass ein langer Prompt die Antworten anderer Nutzer weniger aufhält, und max_num_batched_tokens wägt die Latenz zwischen den Token gegen die Zeit bis zum ersten Token ab. Eine Herstellerangabe zur Zeit bis zum ersten Token für einen Prompt mit 128K oder 1M auf diesen Karten haben wir nicht gefunden; testen Sie deshalb mit Ihren eigenen Promptlängen. Unser Vergleich von vLLM, SGLang, TensorRT-LLM und Ollama behandelt die Engines.

KV-Cache-Offloading in CPU-Speicher und auf NVMe

Der Blog von vLLM vom 10. September 2026 schreibt, dass sein gestuftes Offloading „verdrängte KV-Daten über Host-Speicher, Storage und entfernte Peers hinweg erhält“, und bei einem Treffer „lädt vLLM die Daten aus einer tieferen Ebene neu“, statt sie neu zu berechnen. Seine Entwicklungsdokumentation führt --kv-offloading-size auf, den CPU-Puffer in GiB, mit den Backends native und lmcache. Die Dokumentation von NVIDIA Dynamo für Release 1.5.1 beschreibt den nativen Pfad: „vLLM kopiert versiegelte GPU-KV-Blöcke in gepinnten CPU-Speicher.“

LMCache 0.5.5 vom 12. September 2026 verlagert KV-Caches in CPU-RAM, lokale SSDs und entfernte Backends wie Redis/Valkey oder S3-kompatiblen Storage; seine PyPI-Seite gibt an, dass es „die TTFT senkt“ und den Durchsatz bei Workloads mit langem Kontext, mehreren Gesprächsrunden und RAG verbessert. Der KV Block Manager (KVBM) von Dynamo umfasst laut seiner Entwicklungsdokumentation GPU-Speicher, gepinnten Host-Speicher, entfernten Speicher und SSDs für vLLM und TensorRT-LLM, und NVIDIA schreibt, Offloading sei „am wirksamsten, wenn der KV-Cache den GPU-Speicher übersteigt und die Wiederverwendung des Caches den Aufwand der Datenübertragung überwiegt“.

Diese Dokumente behandeln ausgelagerte Blöcke als Cache zur Wiederverwendung durch eine zurückkehrende Session oder ein wiederholtes Dokument. Nach unserem Verständnis behält das gerade generierte Gespräch seinen Cache im GPU-Speicher; dieses Offloading spart also Prefill-Zeit, statt den längsten Kontext zu erhöhen, den eine Konfiguration fasst.

HiSparse von vLLM für Sparse Attention geht weiter. Der Blog von vLLM vom 8. September 2026 berichtet von GLM-5.3 mit seinem vollen Kontext von 1M auf einem Knoten mit acht H200 mit Hybrid HiSparse, das die Cache-Seiten, die der Indexer nicht auswählt, in gepinnten CPU-Speicher verlagert, wenn der GPU-Speicher knapp wird. HiSparse kam mit Release 0.30.0, 0.31.0 führt „HiSparse hardening“ auf, und laut dem Beitrag ist es „derzeit nur für NVIDIA-GPUs implementiert“.

Unsere KI-Server haben ECC-Speicher, ausgelegt auf den GPU-Pool, und NVMe-Ebenen für Modelle und Indizes. Schreiben Sie uns die Kontextlängen und wie oft sich Prompts wiederholen, und wir dimensionieren Arbeitsspeicher und Storage für den ausgelagerten Cache zusammen mit den GPUs.

Langer Kontext oder RAG

Langer Kontext bringt den ganzen Dokumentbestand in jede Anfrage, mit eigenem Cache und Prefill je Gespräch, während Retrieval-Augmented Generation nur die abgerufenen Passagen einfügt. Langer Kontext eignet sich für ein großes Dokument oder eine Codebasis, die wiederholt abgefragt wird, wobei Prefix Caching den wiederholten Prefill spart. RAG eignet sich für einen Bestand, der größer ist als jeder Kontext, und für Dokumente mit unterschiedlichen Zugriffsrechten, die unser Leitfaden zu RAG auf Unternehmensdaten beim Abruf filtert.

Was wir liefern

Wir liefern die DGX Spark Founders Edition, die RTX PRO 6000 als Workstation, Max-Q und Server Edition sowie die H200 NVL mit Zweifach- und Vierfach-NVLink-Brücken, als Karten oder in auf Bestellung gebauten KI-Servern. Wir dimensionieren und beschaffen GPUs, Arbeitsspeicher und NVMe-Storage zusammen, unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie, und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Unser Sortiment professioneller GPUs führt jede Karte. Serving-Engines, RAG und MLOps sind unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ