vLLM CUDA out of memory: Ursachen und Lösungen je Startphase, RTX PRO 6000 und H200 NVL

Wo vLLM der Speicher ausgeht

vLLM meldet CUDA out of memory fast immer während des Starts, bevor die erste Anfrage bedient wird: Es prüft, ob der zugewiesene Anteil der Karte frei ist, lädt die Gewichte, misst seinen Arbeitsspeicher, füllt den Rest mit KV-Cache und erfasst danach die CUDA Graphs. Jede Phase scheitert mit einer eigenen Meldung, und jede hat eine andere Lösung. Suchen Sie die letzte Phase, die im Log erscheint; dann wissen Sie, welches Flag Sie ändern müssen und ob die Karte zu klein ist.

Läuft der Server erst einmal, sind Speicherfehler seltener. Der Optimierungsleitfaden von vLLM 0.32.0 schreibt, dass vLLM den Cache aus dem konfigurierten Anteil „pre-allocates“; ein voller Cache pausiert Anfragen, statt die Engine abstürzen zu lassen. Unser Leitfaden zu KV-Cache-Größe und Maximum concurrency in vLLM erklärt diese Pausen und die zugehörigen Logzeilen. Diese Seite beschreibt den Fehlerfall: was jede Meldung bedeutet und was zu tun ist, mit Werten für die RTX PRO 6000 Blackwell Server Edition und die H200 NVL. Das Verhalten von vLLM stammt aus der Dokumentation von Release 0.32.0 (18. Oktober 2026) und aus der Troubleshooting-Seite von NVIDIA NIM 2.0.13, zuletzt aktualisiert am 19. Oktober 2026, gelesen am 25. Oktober 2026.

Meldungsteile wie zitiert in den vLLM-Issues 35313 (Februar 2026) und 19407, NVIDIA NIM 2.0.13 „Troubleshooting GPU Memory Out-of-Memory Errors“ (19. Oktober 2026), Speicherspar-Leitfaden von vLLM 0.32.0 (9. Oktober 2026). Der genaue Wortlaut kann sich zwischen Releases ändern. Gelesen am 25. Oktober 2026.

Phase 1: Ein anderer Prozess belegt GPU-Speicher

--gpu-memory-utilization ist laut Referenz der Engine-Argumente von vLLM „the fraction of GPU memory to be used for the model executor“, ohne Angabe 0,92. Die Referenz nennt den Wert „a per-instance limit“ und gibt als Beispiel zwei vLLM-Instanzen auf einer GPU mit je 0,5; das geht nur auf, wenn sich der Anteil auf die ganze Karte bezieht. Die Dokumentation von vLLM-Omni, einem auf vLLM aufbauenden Projekt, schreibt die Regel aus: requested_memory = total_gpu_memory × gpu_memory_utilization.

Beim Start vergleicht vLLM diese Anforderung mit dem freien Speicher. Ein vLLM-Issue vom Februar 2026 zeigt das Ergebnis, wenn sie nicht passt: „Free memory on device cuda:0 (74.9/142.5 GiB) on startup is less than desired GPU memory utilization (0.9, 128.25 GiB). Decrease GPU memory utilization or reduce GPU memory used by other processes.“ Die Zahlen bestätigen die Regel: 0,9 × 142,5 GiB = 128,25 GiB, bei 74,9 GiB frei.

Auf einer 96-GB-Karte, die der Treiber mit 95,6 GiB meldet, fordert der Standard nach unserer Rechnung 0,92 × 95,6 = 88,0 GiB an. Alles, was mehr als etwa 7,6 GiB der Karte belegt, verhindert den Start: ein Jupyter-Kernel mit geladenem Tensor, ein zweiter Container, ein früherer vLLM-Prozess, der nicht beendet wurde, oder auf einer Workstation der Desktop. nvidia-smi listet die Prozesse und ihren Speicher. Abhilfe: den anderen Prozess beenden oder jeder Instanz auf der Karte einen eigenen Anteil geben, sodass die Summe unter 1 bleibt. --kv-cache-memory-bytes legt den Cache pro GPU in Byte fest und „ignores gpu_memory_utilization“; das passt, wenn ein Prozess bekannter Größe die Karte mitbenutzt.

Hierher gehört eine Falle bei Upgrades. vLLM 0.20.0 vom April 2026 hat den Standard von 0,9 auf 0,92 angehoben; eine Instanz ohne ausdrückliche Einstellung belegt damit auf einer Karte mit 95,6 GiB rund 1,9 GiB mehr als vorher. Zwei Dienste, die knapp nebeneinander passten, können nach dem Upgrade scheitern, ohne dass sich ihre eigene Konfiguration geändert hat. Tragen Sie den Anteil deshalb in jeder Service-Datei ausdrücklich ein.

Phase 2: torch.OutOfMemoryError beim Laden der Gewichte

Endet das Log beim Laden der Gewichte mit torch.OutOfMemoryError: CUDA out of memory, nennt die NIM-Seite von NVIDIA die Ursache klar: Die Karte hat bei der gewählten Präzision und dem gewählten Tensor-Parallel-Grad nicht genug Speicher für die Gewichte („does not have enough memory to hold the model weights at the selected“ …). Ihre Formel: Gewichtsspeicher pro GPU = Parameter × Bytes pro Parameter / TP, mit 2 Byte für BF16 und 1 für FP8.

Llama 3.3 70B zeigt die Rechnung. In BF16 belegen die Gewichte etwa 131 GiB, mehr als eine RTX PRO 6000 und, mit Overhead und Cache gerechnet, auch mehr als eine H200 NVL: Unsere Regel für Nutzer pro Karte lässt auf der H200 NVL 0,9 × 140,4 − 3 = 123,4 GiB für Gewichte und Cache. Der FP8-Checkpoint von NVIDIA belegt 67,7 GiB und passt auf eine Karte jedes der beiden Typen. In BF16 braucht das Modell zwei RTX PRO 6000 Server Edition mit --tensor-parallel-size 2, etwa 65,5 GiB pro Karte.

Zwei Details werden oft übersehen. Ein Checkpoint, der erst beim Laden quantisiert wird, lädt zuerst in 16 Bit: Unser Leitfaden Wie viel VRAM ein LLM braucht zitiert den Hinweis von NVIDIA, dass ein solches FP8-Profil beim Start Platz für die BF16-Gewichte braucht. Und Tensor-Parallelität teilt die Gewichte, nicht den Overhead: Jeder Rang hält seinen eigenen CUDA-Kontext, seine Aktivierungen und Graphs. Auf einem Server mit acht RTX PRO 6000 Server Edition ist die Wahl zwischen einer Kopie mit TP=8 und mehreren kleineren Kopien ebenso eine Frage der Geschwindigkeit wie des Speichers; unser Leitfaden zur RTX PRO 6000 ohne NVLink beschreibt, was das All-Reduce über PCIe kostet.

Phase 3: Kein Platz für den KV-Cache

Lassen sich die Gewichte laden, fasst der Rest aber keine Anfrage der deklarierten Länge, bricht vLLM mit einer Meldung dieser Art ab, wie im vLLM-Issue 19407 zitiert: „To serve at least one request with the models's max seq len (...), (... GiB KV cache is needed, which is larger than the available KV cache memory (... GiB).“ Die Meldung fährt fort mit „Based on the available memory, the estimated maximum model length is ...“ und endet mit „Try increasing gpu_memory_utilization or decreasing max_model_len“. Nutzer im Forum von vLLM berichten außerdem die kürzere Meldung „No available memory for the cache blocks“, wenn für den Cache gar nichts übrig bleibt.

Geprüft wird die Länge --max-model-len, die laut Referenz aus der Modellkonfiguration abgeleitet wird („automatically derived from the model config“), wenn Sie sie nicht setzen. Für Llama 3.3 70B sind das 131.072 Token. Eine Anfrage dieser Länge braucht 40 GiB Cache in 16 Bit und 20 GiB mit FP8-Cache, und nach unserer Regel für Nutzer pro Karte bleiben auf einer RTX PRO 6000 Server Edition nach den FP8-Gewichten etwa 15,3 GiB. Der Start scheitert; die geschätzte Maximallänge in der Meldung, nach unserer Schätzung etwa 100.500 Token mit FP8-Cache, ist der nützliche Wert darin.

Die Lösungen in der Reihenfolge, in der wir sie versuchen würden:

1. Den benötigten Kontext deklarieren. --max-model-len 32768 oder auto, das laut Referenz „the maximum model length that fits in GPU memory“ wählt. Clients mit längeren Prompts erhalten dann einen Fehler; wählen Sie den Wert also bewusst.
2. Den Cache halbieren. --kv-cache-dtype fp8 speichert Keys und Values in 8 Bit; seit 0.32.0 ist nvfp4 auf SM12x-Karten wie der RTX PRO 6000 eine weitere Option.
3. Das Budget pro Schritt senken. Ein großes --max-num-batched-tokens erhöht die Aktivierungsspitze, die vLLM vor dem Bemessen des Cache misst; der oben verlinkte Leitfaden zum KV-Cache zitiert eine Forumsmessung, in der der Cache von 11,32 auf 4,53 GiB schrumpfte, als das Budget von 16K auf 80K Token stieg.

Die NIM-Seite von NVIDIA warnt an dieser Stelle: Ein niedrigeres --gpu-memory-utilization verkleinert das Budget des KV-Cache und kann einen Kapazitätsfehler verschlimmern („reduces the KV-cache budget and can make a KV-capacity failure worse“). Eine Anhebung von 0,92 auf 0,95 bringt auf einer Karte mit 95,6 GiB nach unserer Rechnung etwa 2,9 GiB, auf Kosten des Puffers für Allokationen, die das Profiling nicht sieht.

Wir bauen Server mit RTX PRO 6000 Server Edition und H200 NVL und bemessen sie für den Kontext, den Ihre Nutzer brauchen; senden Sie uns Modell, Checkpoint und Start-Log, und unser Team antwortet mit der Konfiguration, die ihn trägt.

Phase 4: CUDA-Graph-Capture und Warm-up

Zeigt das Log die Cache-Größe und scheitert danach, oft nach „Graph capturing finished“ oder in compile_or_warm_up_model, führt die NIM-Seite das darauf zurück, dass Graph-Capture oder Warm-up „more memory than remains available“ brauchen, und ergänzt, „there is no single amount of headroom that works for every profile“. Der Speicherspar-Leitfaden von vLLM schreibt, CUDA Graphs „take up extra memory in the GPU“, und die Capture-Größen reichen standardmäßig „up to max_num_seqs“.

Drei Maßnahmen, mit steigenden Kosten für die Geschwindigkeit:

• --gpu-memory-utilization etwas senken, das lässt mehr Puffer außerhalb des vLLM-Budgets; NIM nennt 0,9 auf 0,85 als Beispiel, „not a validated value“;
• weniger Graphs erfassen, mit kleinerem --max-num-seqs oder einer ausdrücklichen Liste cudagraph_capture_sizes in der Compilation-Konfiguration, wie der Leitfaden mit den Größen 1, 2, 4, 8 und 16 zeigt;
• mit --enforce-eager starten, um zu bestätigen, dass die Graphs die Ursache sind. Das schaltet das Capturing ganz ab und senkt die Decode-Geschwindigkeit; nutzen Sie es zur Diagnose, nicht als Einstellung im Betrieb.

Eine Variante dieses Fehlers ist Fragmentierung. Die PyTorch-Meldung nennt dann viel Speicher als „reserved by PyTorch but unallocated“ und schlägt PYTORCH_ALLOC_CONF=expandable_segments:True vor. NIM nennt das „particularly common with hybrid architectures“ und vermerkt, dass die Einstellung „does not add GPU capacity“.

Multimodale Modelle: Bilder, Video und der Encoder-Cache

Vision-Language-Modelle brauchen Speicher, den Textmodelle nicht haben. Das Speicher-Profiling von vLLM berücksichtigt beim Start die Bilder, Videos und Audiodaten, die ein Prompt enthalten darf; ein Modell, das mehrere hochaufgelöste Bilder oder ein Video annimmt, reserviert also Platz dafür. Der Speicherspar-Leitfaden nennt zwei Hebel. --limit-mm-per-prompt begrenzt die Elemente pro Prompt, etwa drei Bilder und ein Video, und eine Modalität auf 0 gibt ihren Speicher frei; {"image": 0} betreibt ein multimodales Modell nur für Text. Manche Modelle nehmen außerdem Prozessor-Argumente an, die Eingaben verkleinern, bei der Qwen2-VL-Reihe max_pixels, standardmäßig 1280 × 28 × 28.

Zwei Hinweise aus demselben Leitfaden verhindern falsche Schlüsse. Die Größenangaben in --limit-mm-per-prompt „only affect activation memory profiling“, der Encoder-Cache richtet sich nach den echten Eingaben zur Laufzeit; ein sauber gestarteter Server kann also knapp werden, wenn Nutzer größere Bilder senden als profiliert. Und mm_processor_cache_gb, standardmäßig 4 GiB, ist ein Cache im CPU-Speicher: Ein kleinerer Wert hilft, wenn dem Host der RAM ausgeht, nicht der GPU. Unser Leitfaden zu Vision-Language-Modellen für Dokument-KI bemisst diese Modelle pro Karte.

Mehrere Modelle auf einer Karte und MIG-Instanzen

Zwei Modelle auf einer RTX PRO 6000 funktionieren, wenn jede Instanz einen eigenen, ausdrücklichen Anteil erhält und die Anteile zusammen mit allen anderen Prozessen unter dem Kartenspeicher bleiben. Ohne MIG teilen sich die Instanzen einen Speicherraum, und eine Lastspitze der einen kann die andere bei ihrem nächsten Start verdrängen.

MIG gibt jeder Instanz einen festen Teil. Auf jeder Edition der RTX PRO 6000 bietet der MIG-Leitfaden von NVIDIA 1g.24gb viermal, 2g.48gb zweimal oder 4g.96gb einmal, wie unsere Seite zu MIG-Profilen der RTX PRO 6000 auflistet. Jede Instanz hat ihren eigenen Speicher, eine Instanz kann der anderen also keinen wegnehmen. Ein 8B-Modell in BF16, nach dem NIM-Beispiel von NVIDIA etwa 16 GB Gewichte, passt nach unserer Schätzung mit kurzem Kontext auf eine 24-GB-Instanz; Llama 3.3 70B in FP8 braucht die ganze Karte. Der MIG-Leitfaden von NVIDIA hält fest, dass „NCCL is currently not supported with MIG“; Tensor-Parallelität, die ihre kollektiven Operationen über NCCL ausführt, kann MIG-Instanzen deshalb nicht verbinden. Unsere Schritt-für-Schritt-Anleitung zu MIG richtet die Instanzen ein.

Wenn die Lösung eine größere oder zweite Karte ist

Jedes Flag oben tauscht etwas ein: Kontextlänge, Cache-Präzision, Geschwindigkeit oder die Zahl gleichzeitiger Anfragen. Startet das Modell nur im Eager-Modus, mit einem Kontext kürzer als Ihre Dokumente oder in einem 4-Bit-Checkpoint, den Sie nicht validiert haben, ist die Karte für die Aufgabe zu klein. Wir planen mit unserer Regel für Nutzer pro Karte: 0,9 × der vom Treiber gemeldete Speicher, abzüglich 3 GiB pro Karte, abzüglich der Gewichte. Für Llama 3.3 70B ergibt sie nach unserer Schätzung diese Werte:

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), FP8-KV-Cache mit 1,25 GiB pro Anfrage mit 8.192 Token; BF16-Gewichte von etwa 131 GiB wie in unserem VRAM-Leitfaden. vLLM misst seinen eigenen Overhead, die Logwerte weichen also ab.

Die H200 NVL hält auf einer Karte mehr solcher Anfragen als zwei RTX PRO 6000 mit getrennten Kopien, die auf 24 kommen, und bietet NVLink-Brücken für größere Modelle. Die RTX PRO 6000 Server Edition bietet 96 GB pro Karte mit FP4-Tensor-Cores; unser Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz wägt das gegen Bandbreite und NVLink ab. Unser Leitfaden zu Nutzern pro RTX PRO 6000 nennt die Werte für weitere Modelle.

Unser Engineering-Partner Vixen.UNO richtet Modelle mit vLLM auf diesen Servern im Rahmen unseres Service Private AI/ML ein; schreiben Sie uns Fehlermeldung, Modell und Zahl der Nutzer, und wir antworten mit der Einstellung oder der Konfiguration, die das Problem löst.

So beheben Sie einen OOM in vLLM, Schritt für Schritt

1. Phase bestimmen. Die letzte Zeile vor dem Fehler zeigt, ob vLLM freien Speicher prüfte, Gewichte lud, den Cache bemaß oder Graphs erfasste.
2. Prozesse auflisten. nvidia-smi auf dem Host zeigt jeden Prozess auf der Karte; bei MIG prüfen Sie die Instanz, die der Container sieht.
3. Anteil ausdrücklich setzen. Tragen Sie --gpu-memory-utilization in jede Service-Datei ein, damit ein geänderter Standard beim Upgrade ihn nicht verschiebt.
4. Kontext deklarieren. Den längsten Prompt plus Antwort, den Ihre Anwendung sendet, nicht das Maximum des Modells.
5. Checkpoint prüfen. Das geladene Format, FP8, NVFP4 oder BF16, bestimmt den Gewichtsspeicher; ein Profil, das beim Laden quantisiert, braucht zuerst Platz für 16 Bit.
6. Graphs mit Eager-Modus diagnostizieren, dann zurück. Server im Betrieb behalten CUDA Graphs, bei Bedarf mit weniger Capture-Größen.
7. Funktionierende Einstellungen festhalten. Unser Leitfaden zum Betrieb einer privaten LLM-Plattform führt Out of Memory beim Start und nach einem Upgrade in seiner Runbook-Tabelle.

FAQ