Mehrere LLMs auf einem GPU-Server betreiben: vLLM-Instanzen, MIG, LoRA-Adapter und Sleep-Modus

Mehrere Modelle auf einem GPU-Server bereitstellen

Wer mehrere LLMs gleichzeitig auf einem GPU-Server betreiben will, startet mit vLLM eine Instanz je Modell, denn ein vLLM-Serverprozess bedient ein Basismodell. Die FAQ von vLLM sagt, dass das gleichzeitige Bereitstellen mehrerer Modelle aus seinem OpenAI-kompatiblen Server „derzeit nicht unterstützt“ wird, und verweist darauf, mehrere Instanzen mit je einem eigenen Modell hinter „einer weiteren Schicht, die die eingehende Anfrage weiterleitet“, zu betreiben. Auf einem GPU-Server bleiben damit fünf dokumentierte Wege, mehrere Modelle unterzubringen: eine Instanz je Karte oder Kartensatz, mehrere Instanzen, die sich über Speicheranteile eine Karte teilen, eine vLLM-Instanz je MIG-Instanz, viele LoRA-Adapter auf einem Basismodell und Modelle, die mit dem Sleep-Modus von vLLM oder einer Modellverwaltung wie der von Triton geladen und wieder entladen werden. Ein vorgeschalteter Router stellt jedes Modell unter seinem Namen an einem OpenAI-kompatiblen Endpunkt bereit.

FAQ von vLLM, Engine-Argumente, Seiten zu LoRA und zum Sleep-Modus sowie Blog von vLLM vom 26. Oktober 2025 (A100, vLLM 0.11.0); CUDA Programming Guide 13.4.2; MIG-Benutzerhandbuch von NVIDIA vom 11. September 2026; Seite des GPU Operators zum GPU-Sharing vom 23. September 2026; Dokumentation zu NIM for LLMs 2.0.13; Dokumentation zur Modellverwaltung von Triton; alle abgerufen am 10. Oktober 2026.

Die Isolierung bestimmt, wie viele Modelle stehen bleiben, wenn ein Prozess oder eine Karte ausfällt, und jedes GB, das Gewichte oder eine zweite Instanz belegen, fehlt dem KV-Cache.

Wir bauen KI-Server mit 4 oder 8 Karten für mehrere Modelle gleichzeitig. Nennen Sie uns die Modelle, die Sie bereitstellen wollen, und die Nutzerzahl je Modell, und wir antworten innerhalb eines Werktages mit Konfiguration und Angebot.

Eine vLLM-Instanz je Karte mit CUDA_VISIBLE_DEVICES

Laut CUDA Programming Guide steuert CUDA_VISIBLE_DEVICES, „welche GPU-Geräte für eine CUDA-Anwendung sichtbar sind und in welcher Reihenfolge sie aufgezählt werden“. Eine vLLM-Instanz, die mit CUDA_VISIBLE_DEVICES=0 gestartet wird, sieht nur die erste Karte; eine zweite mit CUDA_VISIBLE_DEVICES=1 und eigenem --port sieht nur die zweite. Sichtbare Geräte werden ab 0 neu nummeriert, sodass ein Modell auf den Karten 2 und 3 mit --tensor-parallel-size 2 so läuft, als wären es die einzigen Karten im Server.

--served-model-name legt „den oder die in der API verwendeten Modellnamen“ fest, und ohne diese Option ist der Name das Argument von --model; geben Sie also jeder Instanz einen kurzen Namen für den Router und die Clients.

Jedes Modell hat einen eigenen Prozess und eigene Karten, sodass ein Neustart einer Instanz die anderen weiter bedienen lässt und jeder Cache den gesamten Speicher über die Gewichte hinaus erhält; ein 14B-Modell mit wenigen Nutzern belegt aber trotzdem eine ganze Karte mit 96 GB.

Zwei Instanzen auf einer Karte: gpu-memory-utilization

vLLM beansprucht einen Anteil des Speichers jeder Karte, standardmäßig 0,92, für Gewichte, Aktivierungen und den KV-Cache. Seine Engine-Argumente beschreiben die Einstellung als „ein Limit je Instanz, das nur für die aktuelle vLLM-Instanz gilt“, und nennen als Beispiel, dass man bei zwei Instanzen auf derselben GPU „die GPU-Speicherauslastung für jede Instanz auf 0,5 setzen kann“. Die Alternative ist --kv-cache-memory-bytes, die „Größe des KV-Caches je GPU in Byte“, die, wenn gesetzt, „gpu_memory_utilization ignoriert“.

Unsere Sizing-Leitfäden geben dem KV-Cache 0,9 × den vom Treiber gemeldeten Speicher, abzüglich 3 GiB, abzüglich der Gewichte. Aufgeteilt in zwei Instanzen zu 0,45 auf einer RTX PRO 6000 Server Edition, die 95,6 GiB meldet, hat jede Instanz 43,0 GiB. Qwen3-14B in FP8 belegt 15,2 GiB für die Gewichte, und die 3 GiB Overhead fallen je Instanz an; es bleiben 24,8 GiB Cache, Platz für etwa 39 Gespräche zu je 8K mit 0,625 GiB in einem FP8-Cache. Allein auf der Karte hält das Modell etwa 108. Zwei Instanzen halten zusammen etwa 78, weil der zweite Satz Gewichte und Overhead vom Cache abgeht.

Der Anteil ist ein Limit, das jede vLLM-Instanz auf sich selbst anwendet, und keine Partition der Karte. Beide Prozesse laufen auf denselben Streaming-Multiprozessoren und derselben Speicherbandbreite, die die GPU zeitlich zwischen ihnen aufteilt, sodass eine Lastspitze auf einem Modell das andere bremst. NVIDIAs Dokumentation zum GPU Operator sagt über dieses Time-Slicing, dass es anders als bei MIG „keine Speicher- oder Fehlerisolierung zwischen Replikaten“ gibt. Auch ein GPU-Reset stoppt beide, denn nvidia-smi setzt eine Karte nur unter dieser Bedingung zurück: „Es dürfen keine Anwendungen diese Geräte nutzen.“ Time-Slicing, MPS und MIG in Kubernetes vergleicht unser Leitfaden zum GPU-Sharing in Kubernetes.

MIG-Instanzen für kleine Modelle mit eigenem Speicher

MIG unterteilt eine GPU, in den Worten von NVIDIAs MIG-Benutzerhandbuch, „in mehrere isolierte Instanzen, jede mit dedizierten Rechen- und Speicherressourcen“. Seine Profiltabellen geben der RTX PRO 6000 in allen drei Editionen bis zu vier Instanzen 1g.24gb oder zwei 2g.48gb. Für die H200 141 GB, die die GPU-Liste des Handbuchs auch als H200 NVL führt, nennen sie sieben 1g.18gb, vier 1g.35gb, drei 2g.35gb oder zwei 3g.71gb. In jeder MIG-Instanz läuft eine vLLM-Instanz, ausgewählt über CUDA_VISIBLE_DEVICES mit der MIG-UUID; der CUDA-Leitfaden fügt hinzu: „Nur die Aufzählung einer einzelnen MIG-Instanz wird unterstützt“, ein Modell muss also in eine Instanz passen.

Die Größe der Scheiben entscheidet, welche Modelle passen. Ein 8B-Embedding-Modell hat in BF16 15,1 GB Gewichte und passt in eine Instanz 1g.24gb einer RTX PRO 6000 oder 1g.35gb einer H200 NVL, aber nicht in eine 1g.18gb, sobald CUDA-Kontext und Aktivierungen hinzukommen, während ein 0,6B-Embedder mit 1,2 GB in jede davon passt. NVIDIAs MIG-Leitfaden führt die Neukonfiguration als möglich „When Idle“, das Layout ändert sich also nur, wenn keine Workloads auf der Karte laufen, und unser MIG-Runbook für RTX PRO Blackwell beschreibt die Schritte.

Viele angepasste Varianten: Multi-LoRA auf einem Basismodell

Wenn mehrere Modelle per Fine-Tuning angepasste Versionen eines Basismodells sind, bedient eine Instanz sie alle als LoRA-Adapter. vLLM startet mit --enable-lora und registriert jeden Adapter als name=path über --lora-modules. Die Adapter erscheinen dann in /v1/models neben dem Basismodell, und ein Client wählt einen davon „wie jedes andere Modell über den Anfrageparameter model“. max_loras, die „maximale Zahl von LoRAs in einem einzelnen Batch“, steht standardmäßig auf 1, sodass Anfragen für verschiedene Adapter erst dann gemeinsam in einen Batch kommen, wenn der Wert auf die Zahl der gleichzeitig genutzten Adapter erhöht wird. max_lora_rank steht standardmäßig auf 16 und muss mindestens dem höchsten Rang unter den Adaptern entsprechen, und max_cpu_loras legt fest, wie viele Adapter im CPU-Speicher bereitliegen.

Adapter lassen sich auch im laufenden Betrieb laden, mit VLLM_ALLOW_RUNTIME_LORA_UPDATING und dem Endpunkt /v1/load_lora_adapter. vLLM warnt, dass dies „Sicherheitsrisiken mit sich bringt“, und rät vom Einsatz im Produktivbetrieb ab, außer in „einer isolierten, vollständig vertrauenswürdigen Umgebung“. NVIDIAs NIM for LLMs 2.0.13, das auf vLLM aufbaut, liest Adapter aus dem Verzeichnis in NIM_PEFT_SOURCE, durchsucht es erneut, wenn NIM_PEFT_REFRESH_INTERVAL gesetzt ist, und hält fest: „Sie können mehrere Adapter gleichzeitig bereitstellen, im Rahmen der Grenzen des GPU-Speichers.“ NIM braucht im Produktivbetrieb eine Lizenz für NVIDIA AI Enterprise je GPU.

Modelle wechseln: Sleep-Modus von vLLM, Triton und Ollama

Modelle, die nur einige Male am Tag genutzt werden, müssen keinen GPU-Speicher belegen. Der Sleep-Modus von vLLM, aktiviert mit --enable-sleep-mode auf CUDA und ROCm, hat zwei Stufen. Auf Stufe 1 „werden die Modellgewichte im CPU-Speicher gesichert“, und der KV-Cache wird verworfen; auf Stufe 2 werden auch die Gewichte verworfen und müssen neu geladen werden. Die Server-Endpunkte /sleep, /wake_up und /is_sleeping gibt es nur mit VLLM_SERVER_DEV_MODE=1, und vLLM schreibt, dass sie „nicht für Nutzer zugänglich gemacht werden sollten“.

Ein Beitrag in vLLMs Blog vom 26. Oktober 2025 nennt Umschaltzeiten auf einer A100 mit vLLM 0.11.0. Qwen3-0.6B wachte aus Stufe 1 in 0,26 s auf, gegenüber durchschnittlich 37,6 s je Wechsel ohne Sleep-Modus, und Phi-3-vision in 0,82 s gegenüber 58,1 s. Aus Stufe 2 dauerte das Aufwachen 0,85 und 2,58 s. Für die RTX PRO 6000 oder die H200 NVL haben wir keine veröffentlichten Zahlen gefunden. Stufe 1 braucht Hostspeicher für die Gewichte jedes schlafenden Modells, 67,7 GiB für Llama 3.3 70B in FP8; der Inferenz-Knoten mit vier Karten auf unserer Seite zu KI-Servern hat 512 GB DDR5-ECC-Speicher.

Im Modellsteuerungsmodus EXPLICIT von Triton Inference Server „lädt Triton nur die Modelle, die ausdrücklich mit der Kommandozeilenoption --load-model angegeben sind“, und zwar beim Start, und lädt oder entlädt andere auf Anfrage über seine API. Standardmäßig hält Ollama ein Modell nach der Nutzung 5 Minuten lang geladen und hält bis zu dreimal so viele Modelle, wie GPUs vorhanden sind; passt ein neues nicht hinein, warten Anfragen in der Warteschlange, während ungenutzte Modelle entladen werden. Unser Vergleich von vLLM, SGLang, TensorRT-LLM und Ollama behandelt die Engines.

Ein Endpunkt für alle Modelle: Routing nach Modellname

Jede Anfrage im OpenAI-Format nennt ihr Modell im Feld model, und ein Router leitet sie an die Instanz weiter, die dieses Modell bedient. In Kubernetes dokumentiert die Gateway API Inference Extension das als Body-based Routing, das „den Modellnamen aus dem Body der Anfrage extrahiert und ihn in den Header X-Gateway-Model-Name einfügt“, nach dem das Gateway routet. Der Leitfaden warnt: „LoRA-Namen müssen über alle Basis-KI-Modelle hinweg eindeutig sein“, denn Adapter teilen sich den Server ihres Basismodells. Außerhalb von Kubernetes leistet ein OpenAI-kompatibler Proxy dasselbe anhand einer Liste von Modellnamen und Backends.

Auch Schlüssel je Team, Rate Limits und das Query-Log gehören an den Router, denn der eigene API-Schlüssel von vLLM deckt nur einen Teil seiner Endpunkte ab. Unser Leitfaden zu einer privaten LLM-Plattform auf Kubernetes behandelt das Gateway, den Endpoint Picker und ihre Versionen.

Beispielbelegungen auf einem Server mit 4 und mit 8 Karten

Die Beispiele nutzen die Sizing-Regel von oben, 3 GiB Overhead je Instanz, einen FP8-Cache und Gespräche zu 8K in voller Länge. Einen Plan für das Unternehmen, also welche Abteilung welche Karten bekommt, enthält unser Leitfaden zur Aufteilung von acht RTX PRO 6000.

Unsere Schätzungen: vom Treiber gemeldeter Speicher 95,6 GiB auf der RTX PRO 6000 Server Edition und 140,4 GiB auf der H200 NVL; Gewichte 67,7 GiB (Llama 3.3 70B), 32,0 GiB (Qwen3-32B) und 15,2 GiB (Qwen3-14B) aus den FP8-Checkpoints auf Hugging Face; MIG-Profile aus NVIDIAs MIG-Benutzerhandbuch.

Die beiden Kopien von Llama halten dieses Modell verfügbar, wenn eine Karte ausfällt. Auf dem Server mit RTX PRO 6000 liegt jedes Modell auf einer Karte, da die Karten kein NVLink haben und ein aufgeteiltes Modell seine Daten über PCIe austauschen würde.

Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Schicken Sie uns Ihre Modelle, ihre Präzision und die Nutzer je Modell über das Formular unten.

Was wir liefern

Wir bauen KI-Server nach Auftrag für Multi-Model-Serving, mit 4 oder 8 Karten: mit der RTX PRO 6000 Server Edition, die MIG und vGPU unterstützt, der H200 NVL mit NVLink-Bridges und der L40S oder L4 für kleine Modelle, jeweils mit Herstellergarantie unter einem EU-Vertrag und auf einer Rechnung. Die GPUs liefern wir auch als Karten für Server, die Sie bereits betreiben. Auf Wunsch kommen die Server mit installiertem Betriebssystem, Treibern, CUDA und einer Container-Runtime an, und NVIDIA-AI-Enterprise-Lizenzen für NIM stehen auf derselben Rechnung. Die Serving-Plattform darauf, mit privaten Modellen auf vLLM oder NVIDIA AI Enterprise und einem Query-Log, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ