KV-Cache-Offloading in CPU-Speicher und auf NVMe: wann es einem LLM-Server hilft und wie Sie es dimensionieren

KV-Cache-Offloading: was es leistet und wann es hilft

KV-Cache-Offloading lagert Cache-Blöcke, die die GPU für den aktuellen Schritt nicht braucht, aus dem GPU-Speicher in den CPU-Speicher aus und von dort auf NVMe oder gemeinsamen Storage, damit sie später wiederverwendet statt neu berechnet werden. Die Wiederverwendung entsteht durch Chats über mehrere Runden, lange System-Prompts, die viele Anfragen teilen, Agenten, die ihren Verlauf erneut senden, und RAG-Prompts über dieselben Dokumente. Bei einem Treffer kopiert die Engine die gespeicherten Blöcke zurück auf die GPU und überspringt diesen Teil des Prefills; das erste Token kommt dadurch früher, und die GPUs wenden weniger Rechenleistung für wiederholte Prompts auf.

Offloading macht die Token-Erzeugung nicht schneller. Die Dokumentation von vLLM zum automatischen Prefix-Caching, aktualisiert am 13. Oktober 2026, hält fest, dass es „die Zeit für die Erzeugung neuer Token (die Decoding-Phase) nicht verringert“. Der Offloading-Leitfaden von vLLM, aktualisiert am 15. Oktober 2026, beschreibt den Connector als einen, „der den Prefix-Cache erweitert, indem er abgeschlossene KV-Blöcke in langsamere, aber größere Ebenen auslagert“. Nach der Lesart unseres Leitfadens zur Hardware für LLMs mit langem Kontext behält das gerade generierte Gespräch seinen Cache im GPU-Speicher, Offloading erhöht also nicht den längsten Kontext, den eine Karte bedienen kann; die Ausnahme ist das dort beschriebene HiSparse von vLLM für GLM-5.3.

Wie groß der KV-Cache wird: Nutzer mal Kontext

Der Cache wächst mit der Zahl der Gespräche mal ihrer Länge. Bei einem Modell mit voller Attention in jedem Layer belegt ein Token 2 × Layer × KV-Heads × Head-Dimension × Bytes pro Wert, nach der Methode unseres Leitfadens dazu, wie viel VRAM ein LLM braucht. Die config.json von Qwen3-32B auf Hugging Face nennt 64 Layer, 8 KV-Heads und eine Head-Dimension von 128. Mit einem FP8-Cache, in vLLM gesetzt mit --kv-cache-dtype fp8, ergibt das 2 × 64 × 8 × 128 × 1 Byte = 128 KiB pro Token und 1 GiB für ein volles 8K-Gespräch mit 8.192 Token. Der 16-Bit-Standard des Modells verdoppelt beide Werte.

Ein gemeinsamer System-Prompt kostet wenig, weil Prefix-Caching eine Kopie davon für alle Anfragen hält, die mit ihm beginnen. Der Verlauf je Nutzer verhält sich anders, da jedes Gespräch seinen eigenen Cache trägt, und genau diesen hält das Offloading zwischen den Runden vor.

Rechenbeispiel: 500 Nutzer auf vier RTX PRO 6000 Server Edition

Nehmen Sie Qwen3-32B in FP8, eine Kopie je Karte auf einem Server mit vier RTX PRO 6000 Server Edition, und 500 Nutzer, die jeweils ein Gespräch mit bis zu 8K Token führen. Unsere Auslegungsregel nimmt 0,9 der 95,6 GiB, die der Treiber meldet, abzüglich 3 GiB für CUDA-Graphs und Aktivierungen und abzüglich der 32,0 GiB FP8-Gewichte. Damit bleiben 51 GiB Cache je Karte, also 51 Gespräche in voller Länge, und 204 auf den vier Karten.

Die übrigen 296 Gespräche ruhen zwischen den Runden, und ohne Offloading verdrängt die Engine ihre Blöcke, sobald neue Anfragen den Platz brauchen; ein zurückkehrender Nutzer zahlt dann erneut ein volles Prefill. Um alle 500 warm zu halten, muss die CPU-Ebene 500 GiB fassen, etwa 537 GB. Der Offloading-Leitfaden von vLLM verlangt eine CPU-Ebene, die größer ist als der GPU-Cache, denn „eine kleinere CPU-Ebene spiegelt nur, was die GPU bereits hält, und erhöht die Trefferquote nicht“. Bei vier Kopien sind das etwa 125 GiB gepinnter Speicher je Instanz, jeweils mehr als ihre eigenen 51 GiB auf der GPU.

Gepinnter Speicher lässt sich nicht in den Swap auslagern, der Offload-Puffer kommt also zum Betriebssystem, zu Containern, einem RAG-Index und dem Page Cache hinzu, der den Checkpoint mit 34,3 GB hält. Unser Leitfaden zu CPU, RAM und Storage für einen Server mit vier GPUs plant diesen Server mit 768 GB in 24 DIMMs zu 32 GB, dem Doppelten seines GPU-Speichers, und mit etwa 1 TB für eine KV-Ebene, die alle 500 Nutzer hält. In 768 GB ließe der Puffer mit 500 GiB nur etwa 230 GB für alles andere übrig; wir planen deshalb die nächste gleichmäßige Stufe, 24 DIMMs zu 48 GB oder 1.152 GB, die neben dem Puffer etwa 615 GB lässt. Die 512 GB des Inferenz-Knotens auf unserer Seite zu KI-Servern sind eine Ausgangskonfiguration, und die Seite hält fest: „das Sizing-Gespräch entscheidet die finale Konfiguration“. Verteilen Sie den Speicher gleichmäßig auf beide Sockel, sodass jeder Sockel die Puffer seiner eigenen zwei Karten hält.

Mit einem 16-Bit-Cache verdoppelt sich jeder Wert, auf 2 GiB je Gespräch und 1.000 GiB für 500 Nutzer, was 24 DIMMs zu 64 GB erfordert. Ein FP8-Cache ist die erste Einsparung, die Sie mit Ihrem Evaluierungsdatensatz testen sollten.

Wir dimensionieren Systemspeicher und Offload-Puffer zusammen mit den GPUs. Nennen Sie uns Ihr Modell, die Kontextlänge und die Zahl der Nutzer im Formular unten, und Konfiguration und Angebot folgen innerhalb eines Werktages.

CPU-Speicher, PCIe und NVMe: Kapazität und Bandbreite je Ebene

Jedes Neuladen läuft über den PCIe-Link zwischen der Karte und ihrem Prozessor, und dieser Link bestimmt die Geschwindigkeit. NVIDIA nennt für die H200 NVL 128 GB/s für PCIe Gen5, also 64 GB/s in jeder Richtung eines x16-Links, und die RTX PRO 6000 Server Edition nutzt dieselbe Gen5-Schnittstelle. AMD nennt für einen Prozessor der Serie EPYC 9005 mit 12 Kanälen DDR5-6400 eine Speicherbandbreite von 614 GB/s je Sockel, mehr als die vier Links eines Servers mit vier Karten zusammen übertragen.

NVIDIA-Seite zur RTX PRO 6000 Server Edition (aktualisiert am 10. März 2026) und H200-Seite (aktualisiert am 27. August 2026); Produktseite der AMD EPYC 9355; Blog von vLLM vom 8. Januar 2026 (H100-System); Kapazitäten und Ladezeiten sind unsere Rechnung.

Ein Gen5-x4-NVMe-Laufwerk hat ein Viertel der Lanes eines x16-Links, sein Datenblattwert liegt also unter 16 GB/s, und vLLM leitet jeden Transfer der Datei-Ebene über den CPU-Speicher, da „nur die primäre CPU-Ebene direkten GPU-Zugriff hat“. Die NVMe-Ebene eignet sich für Gespräche von früher am Tag und für lange Dokumente, die ab und zu wiederkehren, nicht für Nutzer, die innerhalb einer Minute antworten.

Prüfen Sie auf einem Server mit zwei Sockeln mit nvidia-smi topo -m, zu welchem NUMA-Knoten jede Karte gehört, und starten Sie jede Instanz mit ihrem Puffer auf diesem Knoten, zum Beispiel mit numactl --cpunodebind=0 --membind=0. Auch das Schreibvolumen zählt. Der Blog von vLLM vom 10. September 2026 schreibt, dass sein Tiering „Chunks gleichzeitig an alle konfigurierten sekundären Ebenen weitergibt“, jeder neu ausgelagerte Prompt-Block wird also auch auf NVMe geschrieben. Bei 1 GiB je 8K-Prompt schreiben 2.000 neue Gespräche am Tag etwa 2,1 TB. Vergleichen Sie das mit den spezifizierten Drive Writes per Day des geplanten Laufwerks.

KV-Cache-Offloading in vLLM: nativer Connector und Flags

vLLM bietet CPU-Offloading laut seinem Blog vom 8. Januar 2026 seit Release 0.11.0 und das gestufte Framework laut dem Beitrag vom September seit 0.22. Die folgenden Namen sind die des aktuellen Release 0.31.0 vom 5. Oktober 2026, wie seine Engine-Argumente und sein Offloading-Leitfaden sie definieren; die Entwicklungsdokumentation vom 15. Oktober 2026 nennt dieselben.

1. Die Kurzform ist --kv-offloading-size 125, der Puffer in GiB. Standardmäßig ist er nicht gesetzt, und „es ist kein KV-Offloading aktiviert“, und „bei TP > 1 ist dies die gesamte Puffergröße, summiert über alle TP-Ranks“.
2. --kv-offloading-backend wählt native, den Standard, oder lmcache.
3. Die vollständige Form ist --kv-transfer-config mit "kv_connector": "OffloadingConnector", "kv_role": "kv_both" und, innerhalb von kv_connector_extra_config, dem Pflichtfeld cpu_bytes_to_use, das der Leitfaden definiert als „gesamte Bytes an Host-Speicher, die für die CPU-Ebene über alle Worker reserviert werden (nicht pro Worker)“. Für 125 GiB sind das 134217728000.
4. Für NVMe setzen Sie "spec_name": "TieringOffloadingSpec" und führen unter secondary_tiers eine Ebene mit "type": "fs" und einem root_dir auf dem Laufwerk auf.

Die Option offload_prompt_only steht standardmäßig auf true, sodass „nur Prompt-Blöcke (Prefill) ausgelagert werden; Decode-Blöcke werden übersprungen“. Nach unserer Lesart findet ein zurückkehrendes Gespräch seine früheren Prompts in der CPU-Ebene, und die letzte Antwort wird neu berechnet, sofern sie nicht noch im GPU-Speicher liegt. Die CPU-Ebene gehört zu einer Instanz. Bei vier Kopien des Modells bekommt ein zurückkehrender Nutzer nur auf der Kopie einen Treffer, die das Gespräch hält, und genau das leistet das KV-Cache-bewusste Routing in NVIDIA Dynamo und llm-d. Eine Dateisystem-Ebene auf demselben root_dir kann alle Instanzen bedienen, was laut Leitfaden „standardmäßig funktioniert“, es sei denn, die xxhash-Hash-Optionen sind ohne gemeinsamen PYTHONHASHSEED gesetzt. Die Seite von Dynamo zum nativen Offloading von vLLM, für Release 1.5.1, nutzt denselben OffloadingConnector und ergänzt an ihrem Frontend --router-mode kv.

LMCache, NVIDIA Dynamo KVBM und SGLang HiCache

Projektdokumentation, Quellcode an den Release-Tags und PyPI, gelesen am 16. Oktober 2026; die Leitfäden von LMCache und SGLang tragen keine Versionsnummer.

LMCache steht unter der Lizenz Apache 2.0 und kann als separater Multiprozess-Server laufen, den die vLLM-Worker über ZMQ oder gRPC mit dem LMCacheMPConnector erreichen; seine Dokumentation erwähnt außerdem den LMCacheConnectorV1, der im selben Prozess läuft. Diese Dokumentation trägt keine Versionsnummer, die Namen hier entsprechen also dem Stand vom 16. Oktober 2026, mit 0.5.6 als aktuellem Release. --l1-size-gb setzt die CPU-Ebene, und mehrfach angegebene Optionen --l2-adapter ergänzen Storage. Seine PyPI-Seite gibt an, dass es bei Workloads mit langem Kontext, mehreren Gesprächsrunden und RAG „die TTFT senkt“.

In Dynamo 1.5.1 definiert der KV Block Manager DYN_KVBM_CPU_CACHE_GB als „Größe des Caches im Host (G2, gepinnter CPU-Speicher) in GB“ und empfiehlt einen Disk-Cache, der mindestens so groß ist wie der CPU-Cache. Ein Filter für das Offloading auf Disk ist standardmäßig aktiv, und O_DIRECT und GPUDirect Storage sind als Optionen verfügbar. NVIDIAs Übersicht zu KVBM hält fest, dass Offloading „am wirksamsten ist, wenn der KV-Cache den GPU-Speicher übersteigt und die Wiederverwendung des Caches den Aufwand der Datenübertragung überwiegt“.

HiCache von SGLang erweitert RadixAttention auf Host-Speicher und Storage. In SGLang 0.5.22 setzt --hicache-ratio „das Verhältnis der Größe des Host-KV-Cache-Speicherpools zur Größe des Device-Pools“, im Cache-Modus standardmäßig 2,0, und --hicache-size in GB überschreibt diesen Wert. Der HiCache-Leitfaden merkt an: „L1 und L2 sind privat für eine einzelne Inferenz-Instanz; nur L3 kann gemeinsam genutzt werden.“ Unser Vergleich von vLLM, SGLang und TensorRT-LLM behandelt die Engines selbst.

Veröffentlichte Ergebnisse und wann sich Offloading nicht lohnt

Der Blog von vLLM vom 8. Januar 2026 berichtet für Llama 3.1 8B auf einer H100 80 GB mit 500 GB Host-Speicher, dass „das Laden von KV-Werten aus der CPU die TTFT je nach Promptgröße um X2-X22 senkt“, und von Durchsatzgewinnen bis zum Neunfachen, wenn die Trefferquote in der CPU-Ebene steigt. Er hält außerdem fest, dass der Connector „bei Cache-Misses nur minimale Auswirkungen auf die TTFT hat“. Der Beitrag vom September maß die Prefill-Worker eines disaggregierten Aufbaus für Qwen3.6-35B-A3B auf zwei H100, mit einer Dateisystem-Ebene auf lokalem NVMe. Oberhalb von 128 Gesprächen erreichte diese Ebene „mehr als den doppelten Durchsatz im Vergleich zu den Alternativen“. Keiner der beiden Aufbauten nutzt eine RTX PRO 6000 oder eine H200 NVL; lesen Sie diese Werte deshalb als Richtung für Ihren eigenen Test.

Offloading lohnt sich, wenn Prompts sich wiederholen und der Cache zurückkehrender Sessions nicht in den GPU-Speicher passt. Wenig bringt es bei Anfragen mit nur einer Runde und einmaligen Prompts, bei kurzen Prompts, deren Prefill wenig kostet, oder wenn jedes Gespräch bereits auf die GPUs passt. Der Beitrag vom Januar nannte hybride Modelle „derzeit nicht für den Offloading-Connector optimiert“; der Beitrag vom September führt DeepSeek V4, GLM 5.3 und Nemotron 3 unter den hybriden Architekturen auf, die das gestufte Framework unterstützt, testen Sie ein solches Modell also mit dem Release, das Sie betreiben.

Unser Engineering-Partner Vixen.UNO setzt vLLM im Rahmen unserer Leistung Private AI/ML on-premise auf. Beschreiben Sie Ihre Prompt-Längen und wie oft Nutzer zurückkehren im Formular unten; das erste Gespräch ist kostenlos.

Was wir liefern

Wir bauen KI-Server auf Bestellung mit 2 bis 8 GPUs pro Knoten, mit DDR5-ECC-Speicher, ausgelegt auf den GPU-Pool, und NVMe-Ebenen für Modelle, Indizes und Scratch, montiert und im Burn-in getestet. Für einen Offloading-Aufbau dimensionieren wir GPUs, Systemspeicher und NVMe-Laufwerke gemeinsam und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Die Karten dieses Artikels, die RTX PRO 6000 Server Edition und die H200 NVL mit NVLink-Bridges, gehören zu unserem Sortiment professioneller GPUs, mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Serving-Engines, Routing und RAG sind unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ