vLLM: KV-Cache-Größe und Maximum concurrency im Start-Log lesen, für RTX PRO 6000

Was die beiden Logzeilen aussagen

Beim Start meldet vLLM, wie viele Token Key/Value-Cache in den belegten GPU-Speicher passen und wie viele Anfragen der deklarierten Maximallänge das sind. Der erste Wert, GPU KV cache size, ist eine Tokenzahl für die ganze Instanz; der zweite, Maximum concurrency, ist diese Zahl geteilt durch die Token, die eine Anfrage belegen darf. 15.70x heißt also: gut fünfzehn Anfragen in voller Länge passen gleichzeitig in den Cache. Das ist der ungünstigste Fall für den deklarierten Kontext, nicht die Zahl der Nutzer eines Servers, und der Wert ändert sich mit jedem Flag, das Speicher oder Kontext beeinflusst.

So sehen die Zeilen aus, im Beispiel aus unserem Leitfaden zu Nutzern pro RTX PRO 6000 (die Werte zeigen nur das Format):

GPU KV cache size: 643,232 tokens

Maximum concurrency for 40,960 tokens per request: 15.70x

Bei einem Modell mit voller Attention in jeder Schicht ist der zweite Wert der erste geteilt durch die angegebene Länge: 643.232 / 40.960 = 15,70. Die Länge in dieser Zeile ist --max-model-len des Servers; ohne Angabe leitet vLLM sie aus der Modellkonfiguration ab, so die Referenz der Engine-Argumente für 0.32.0. Ein Modell mit 128K Kontext erhält deshalb eine Parallelität für 131.072 Token pro Anfrage, solange Sie nichts anderes festlegen. Darum zeigt der erste Start oft eine enttäuschende Zahl.

Die Zeile zählt Anfragen, die ihren ganzen Kontext nutzen. Echte Chat-Anfragen tun das selten: Eine Frage mit einem abgerufenen Dokument belegt vielleicht 6.000 von deklarierten 32.768 Token. PagedAttention in vLLM vergibt Cache-Blöcke, während eine Anfrage wächst, daher hält der Cache mehr kurze Anfragen, als die Zeile vermuten lässt. Ist er voll, pausiert vLLM Anfragen, statt sie abzubrechen: Der Optimierungsleitfaden für 0.32.0 beschreibt die Warnung, eine Sequenz „is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space“, und solche Anfragen „are recomputed when sufficient KV cache space becomes available again“. Preemptions zeigen sich also als Latenz. Unser Leitfaden zu vLLM-Monitoring-Metriken erklärt Alarme auf vllm:num_preemptions_total und die Cache-Auslastung.

Wie vLLM auf die Tokenzahl kommt

Die Rechnung beginnt mit einem Anteil des Kartenspeichers. --gpu-memory-utilization ist „the fraction of GPU memory to be used for the model executor“, ohne Angabe 0,92, und die Referenz ergänzt, dies sei „a per-instance limit“: Zwei vLLM-Instanzen auf einer GPU würden jeweils 0,5 erhalten. vLLM 0.20.0 vom April 2026 hat den Standard von 0,9 auf 0,92 angehoben. Von diesem Anteil zieht vLLM ab, was es beim Start misst.

Engine-Argumente, Optimierungs- und Speicherspar-Leitfaden von vLLM 0.32.0 (Seiten vom 20. August und 9. Oktober 2026), gelesen am 24. Oktober 2026; Bezeichnungen der Anteile wie auf der GPU-Seite von Anyscale zu vLLM, die „model weights“, „non_torch_memory“, „PyTorch activation peak memory“ und den Rest „reserved for the KV Cache“ nennt.

Zwei dieser Anteile werden oft unterschätzt. Die Aktivierungsspitze wächst mit --max-num-batched-tokens, der Zahl der Token in einem Schritt. Ein Nutzer im Forum von vLLM berichtete im April 2026 mit vLLM 0.18.0 auf einer A30 mit 24 GB von 11,32 GiB verfügbarem KV-Cache-Speicher bei einem Budget von 16K Token, 9,64 GiB bei 32K, 6,24 GiB bei 64K und 4,53 GiB bei 80K. Ein größeres Prefill-Budget bringt schnellere erste Token und kostet Cache. Auch CUDA Graphs belegen Speicher: Der Speicherspar-Leitfaden von vLLM schreibt, Graphs „take up extra memory in the GPU“, und die Capture-Größen reichen standardmäßig „up to max_num_seqs“. --enforce-eager schaltet das Capturing ganz ab, zulasten der Decode-Geschwindigkeit.

Wer lieber den Cache als den Anteil festlegt, nutzt --kv-cache-memory-bytes, die „Size of KV Cache per GPU in bytes“; die Referenz vermerkt, dass der Wert, wenn gesetzt, „ignores gpu_memory_utilization“. Das hilft bei zwei Instanzen auf einer Karte oder wenn ein anderer Prozess GPU-Speicher hält.

Die Tokenzahl folgt dann aus der Architektur des Modells. Die Bytes pro Token sind 2 × Schichten × Key/Value-Heads × Head-Dimension × Bytes pro Element; für Llama 3.3 70B mit 80 Schichten, 8 Key/Value-Heads und Head-Dimension 128 sind das 320 KiB pro Token in BF16 und 160 KiB in FP8. Der Restspeicher geteilt durch diesen Wert ergibt die GPU KV cache size.

Rechenbeispiele für eine RTX PRO 6000 und eine H200 NVL

Wir planen mit unserer Regel für Nutzer pro Karte: 0,9 × der vom Treiber gemeldete Speicher, abzüglich 3 GiB Overhead pro Karte, abzüglich der Gewichte. Sie liegt bewusst etwas unter dem Standard 0,92 von vLLM. Für Llama 3.3 70B im FP8-Checkpoint von NVIDIA (67,7 GiB Gewichte) ergibt die Regel nach unserer Schätzung diese Logwerte:

unsere Rechnung nach der Regel für Nutzer pro Karte (95,6 GiB vom Treiber gemeldet je RTX PRO 6000, 140,4 GiB je H200 NVL, × 0,9, abzüglich 3 GiB pro Karte und 67,7 GiB Gewichte; die zweite Zeile mit 0,92), FP8-KV-Cache mit 160 KiB pro Token. Die eigene Messung von Aktivierungen und Graphs in vLLM ersetzt unsere 3 GiB, die angezeigten Werte weichen also ab.

Daraus folgen drei Dinge. Bei 8.192 Token pro Anfrage hält eine Server-Edition-Karte mit FP8-Cache 12 Anfragen in voller Länge, die Zahl aus unseren Seiten zur Dimensionierung, und mit 16-Bit-Cache 6. Bei den vollen 131.072 Token des Modells hält sie weniger als eine: Der Cache fasst nicht einmal eine Anfrage maximaler Länge, deklarieren Sie also den Kontext, den Ihre Nutzer brauchen. Und zwei Karten als Tensor-Parallel-Paar halten 78 statt 24, weil die 67,7 GiB Gewichte nur einmal über beide Karten verteilt liegen; bei Tensor-Parallelität speichert jede Karte ihren Anteil der Key/Value-Heads für jedes Token, die angezeigte Tokenzahl beschreibt also die ganze Instanz.

Der Wert von 44 für die H200 NVL kommt aus ihrem größeren Speicher, 140,4 GiB laut Treiber: Eine Karte hält mehr dieser Anfragen als zwei RTX PRO 6000 Server Edition mit getrennten Kopien, die auf 24 kommen. Unser Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz wägt Geschwindigkeit, NVLink und Leistungsaufnahme ab.

Wir bauen Server mit RTX PRO 6000 Server Edition und H200 NVL und bemessen sie nach diesen Werten; senden Sie uns Modell, Präzision und den geplanten Kontext, und unser Team antwortet mit dem zu erwartenden KV-Cache und einer Konfiguration.

Flags, die Maximum concurrency verändern

Manche Flags ändern den Speicher, den der Cache erhält, andere nur den Divisor. Nur die erste Art lässt den Server mehr Arbeit tragen.

Engine-Argumente und Release Notes von vLLM 0.32.0 (18. Oktober 2026, „NVFP4 KV cache now runs on SM8x and SM12x“, im selben Eintrag auf SM90 erweitert); NVFP4-Faktor nach unserer Rechnung (0,5625 gegen 1 Byte pro Wert, 90 gegen 160 KiB pro Token für Llama 3.3 70B). Gelesen am 24. Oktober 2026.

--max-model-len akzeptiert lesbare Werte wie 8k, und „-1 or 'auto'“ lässt vLLM „choose the maximum model length that fits in GPU memory“: die Maximallänge des Modells, wenn sie passt, sonst „the largest length that can be accommodated“, so die Referenz. Das ist der dokumentierte Ausweg, wenn ein Start scheitert, weil eine Anfrage voller Länge nicht passt. Die Entscheidung bleibt dann aber vor Ihren Nutzern verborgen: Ein Client mit einem längeren Prompt erhält einen Fehler. Legen Sie die Länge im Betrieb deshalb bewusst fest.

--kv-cache-dtype fp8 halbiert die Bytes pro Token gegenüber einem 16-Bit-Cache. Seit 0.32.0 unterstützt vLLM auch nvfp4 als Datentyp des KV-Cache auf SM12x-Karten wie der RTX PRO 6000; nach unserer Rechnung steigt Llama 3.3 70B auf einer Karte damit von 12 auf 21 Anfragen mit 8.192 Token. Der Genauigkeitsverlust ist eine eigene Frage; unser Artikel zum NVFP4-KV-Cache auf der RTX PRO 6000 Server Edition sammelt die veröffentlichten Messungen.

--max-num-seqs ist von anderer Art. Es begrenzt, wie viele Sequenzen der Scheduler in einem Schritt bearbeitet, und bestimmt die CUDA Graphs, reserviert aber keinen Cache. Die Scheduler-Referenz von vLLM nennt den eingebauten Wert 128 „mainly for convenience when testing“ und sagt, der eigentliche Standard werde beim Erzeugen der Engine-Konfiguration gesetzt; der gpt-oss-Leitfaden von vLLM beschreibt ihn als „a large number like 1024 on GPUs with large memory sizes“. Liegt Maximum concurrency bei Ihren realen Promptlängen unter --max-num-seqs, läuft zuerst der Cache voll und Anfragen werden verdrängt; liegt sie darüber, staut zuerst die Batch-Grenze die Anfragen. Ein kleineres --max-num-seqs spart Graph-Speicher und bringt so etwas mehr Cache.

Sliding-Window-, Hybrid- und MoE-Modelle

Die einfache Division gilt für Modelle mit voller Attention in jeder Schicht wie Llama 3.3 70B. Neuere Modelle mischen Schichttypen. Die Designseite des Hybrid-KV-Cache-Managers von vLLM (vom 19. August 2026) schreibt, Sliding-Window-Schichten reservieren „slots only for the most recent sliding_window_size tokens“ und geben Blöcke außerhalb des Fensters frei, während Schichten mit voller Attention alle behalten; alle Schichttypen teilen sich einen Speicherpool mit einer Seitengröße. Bei solchen Modellen sinken die Bytes pro Token mit wachsendem Kontext, und die Parallelitätszeile ist nicht einfach die Tokenzeile geteilt durch die Länge. gpt-oss-120b mit abwechselnd voller und gefensterter Attention braucht für ein Gespräch mit 128K etwa 4,5 GiB 16-Bit-Cache, Llama 3.3 70B 40 GiB, wie unser Leitfaden zu Hardware für lange Kontexte zeigt. Mamba-Schichten halten einen Zustand pro Anfrage statt pro Token, und dieselbe Designseite vermerkt, dass vLLM die Blockgröße der Attention anhebt, damit ihre Seiten zum größeren Mamba-Zustand passen. Lesen Sie bei diesen Modellen die Parallelitätszeile, statt sie auszurechnen.

Mixture-of-Experts-Modelle ändern die Gewichte, nicht den Cache. Ein solches Modell liest pro Token nur seine aktiven Experten, speichert aber alle, und sein Cache hängt nur an den Attention-Schichten. Unsere Seite zu den Hardware-Anforderungen von gpt-oss-120b rechnet ein solches Modell durch.

Von der Logzeile zur Zahl der Nutzer

Maximum concurrency beantwortet, wie viele Anfragen voller Länge gleichzeitig passen. Für die Dimensionierung brauchen Sie die Zahl der gleichzeitig bearbeiteten Anfragen zum Spitzenzeitpunkt, gemessen am Gateway, und deren Länge. Unser Leitfaden zu Pilotprojekten mit privater KI erklärt, wie Sie beides messen. Drei Prüfungen verbinden die Werte.

1. Realistischen Kontext deklarieren. Setzen Sie --max-model-len auf den längsten Prompt plus Antwort, den Ihre Anwendung sendet, nicht auf das Maximum des Modells; die angezeigte Parallelität bezieht sich dann auf eine Anfrage, die in der Praxis vorkommt.
2. Mit der Spitze vergleichen. Liegt die gemessene Spitze unter der angezeigten Parallelität für diesen Kontext, läuft der Cache selbst dann nicht voll, wenn jede Anfrage lang ist. Liegt sie darüber, beginnen Preemptions, sobald genug lange Anfragen zusammentreffen.
3. Live-Werte beobachten. Cache-Auslastung und Preemptions unter /metrics zeigen, wie nah die echte Mischung an die Grenze kommt; kurze Anfragen lassen den Server deutlich über der angezeigten Zahl laufen, ohne dass etwas verdrängt wird.

Muss ein Server mehr lange Anfragen gleichzeitig tragen, braucht er mehr Cache: einen FP8- oder NVFP4-Cache, NVFP4-Gewichte, ein Tensor-Parallel-Paar oder eine Karte mit mehr Speicher. Unser Leitfaden zu Nutzern pro Karte nennt die Werte je Modell und Layout, und unser Leitfaden zum Auslagern des KV-Cache in CPU-Speicher und NVMe behandelt den Fall, dass zwischengespeicherte Präfixe statt laufender Anfragen den Platz aufbrauchen. Unser Engineering-Partner Vixen.UNO richtet Modelle mit vLLM im Rahmen unseres Service Private AI/ML ein; schreiben Sie uns mit dem Start-Log Ihres aktuellen Servers, und wir bemessen den nächsten danach.

FAQ