Multi-GPU-Inferenz ohne NVLink: Tensor Parallelism, Pipeline Parallelism oder Replicas

Größeres Modell oder mehr Durchsatz, als eine GPU hergibt? WZ-IT betreibt Managed GPU-Server mit NVIDIA RTX PRO 4000 Blackwell (24 GB) und RTX PRO 6000 Blackwell Max-Q (96 GB) inklusive vLLM, Open WebUI und Monitoring. Multi-GPU-Konfigurationen planen wir passend zu Modell und Last. GPU-Server ansehen · Termin vereinbaren

Ein Server mit zwei GPUs liefert nicht automatisch die doppelte Leistung. Entscheidend ist, wie die Inferenz-Software das Modell auf die Karten verteilt, und wie viel Bandbreite zwischen den Karten zur Verfügung steht. Rechenzentrums-GPUs wie H100 oder B200 sind über NVLink gekoppelt. Die RTX PRO Blackwell-Karten, die in vielen Unternehmensservern stecken, kommunizieren nur über PCIe. Damit verschiebt sich die Abwägung zwischen Tensor Parallelism, Pipeline Parallelism und mehreren unabhängigen Instanzen (Replicas). Dieser Artikel erklärt die drei Verfahren, die zugehörigen vLLM-Parameter und eine Entscheidungsregel für Systeme ohne NVLink. Stand Oktober 2026.

Inhaltsverzeichnis

• NVLink und PCIe bei RTX PRO Blackwell
• Drei Arten, ein Modell auf mehrere GPUs zu bringen
• Warum Tensor Parallelism ohne NVLink teuer wird
• Die Entscheidungsregel: so wenig Aufteilung wie möglich
• vLLM-Konfiguration für zwei GPUs
• Was eine öffentliche Messung zeigt
• Topologie prüfen und messen

NVLink und PCIe bei RTX PRO Blackwell

NVLink ist NVIDIAs direkte Verbindung zwischen GPUs. Die fünfte Generation (Blackwell) erreicht laut NVIDIA 1.800 GB/s pro GPU, die vierte Generation (Hopper) 900 GB/s (NVIDIA, NVLink). Zum Vergleich gibt NVIDIA für die PCIe-Gen5-Anbindung einer H100 128 GB/s an (NVIDIA, H100). Der Wert gilt für beide Richtungen einer x16-Verbindung zusammen.

Die RTX PRO Blackwell-Karten in der folgenden Tabelle haben keinen NVLink-Anschluss. Ihre Datenblätter nennen ausschließlich PCIe als Systemschnittstelle:

Die Größenordnung ist wichtig: Innerhalb einer RTX PRO 6000 bewegt der Speicher 1.792 GB/s, zwischen zwei Karten stehen über PCIe 5.0 x16 rechnerisch gut 60 GB/s je Richtung zur Verfügung. Jeder Datenaustausch zwischen den GPUs ist damit um mehr als eine Größenordnung langsamer als ein Zugriff auf den eigenen Speicher. Ob die Karten im Server tatsächlich mit voller Lane-Zahl und ohne Umweg über den zweiten Prozessor verbunden sind, hängt vom Mainboard ab (siehe Topologie prüfen).

Drei Arten, ein Modell auf mehrere GPUs zu bringen

vLLM kennt drei grundlegende Verfahren, die sich kombinieren lassen (vLLM, Parallelism and Scaling):

Alle Parameter haben in vLLM den Standardwert 1 bzw. sind standardmäßig aus (vLLM, Engine Arguments). Die Zahl der benötigten GPUs ergibt sich als Produkt: -dp 2 -tp 2 braucht vier GPUs.

Tensor Parallelism ist das Verfahren, das die meisten Anleitungen zuerst nennen. Die vLLM-Dokumentation empfiehlt es für den Fall, dass ein Modell nicht auf eine GPU, aber auf einen Server passt.

Pipeline Parallelism legt zum Beispiel die erste Hälfte der Schichten auf GPU 0 und die zweite auf GPU 1. Zwischen den Karten wandern nur die Zwischenergebnisse an der Übergabestelle. Eine einzelne Anfrage wird dadurch nicht schneller, weil die GPUs nacheinander arbeiten. Bei vielen gleichzeitigen Anfragen arbeiten beide Stufen parallel an verschiedenen Anfragen.

Replicas sind keine Aufteilung des Modells, sondern mehrere vollständige Instanzen. vLLM bietet dafür --data-parallel-size mit einem gemeinsamen API-Endpunkt und interner Lastverteilung; das funktioniert für dichte und MoE-Modelle (vLLM, Data Parallel Deployment). Alternativ laufen zwei getrennte vLLM-Prozesse, die ein Gateway wie LiteLLM gemeinsam anspricht.

Expert Parallelism betrifft nur Mixture-of-Experts-Modelle. Die Experten werden auf die GPUs verteilt, statt jeden Experten per TP zu zerschneiden; die EP-Größe ergibt sich aus TP mal DP (vLLM, Expert Parallel Deployment).

Warum Tensor Parallelism ohne NVLink teuer wird

Tensor Parallelism geht auf das Verfahren aus Megatron-LM zurück: Die Gewichtsmatrizen von Attention und MLP werden spaltenweise bzw. zeilenweise geteilt, jede GPU rechnet ihren Teil, und nach Attention und MLP werden die Teilergebnisse per All-Reduce zusammengeführt (Shoeybi et al., Megatron-LM). Das sind zwei Synchronisationspunkte pro Transformer-Schicht. Ein Modell mit 60 Schichten synchronisiert bei jedem erzeugten Token also rund 120-mal.

Bei der Token-Erzeugung (Decode) sind die übertragenen Datenmengen pro Schritt klein, aber jede Synchronisation hat eine feste Latenz. Bei der Verarbeitung langer Eingaben (Prefill) fallen große Datenmengen an. Über NVLink fallen beide Effekte kaum ins Gewicht. Über PCIe wartet die GPU messbar auf die andere Karte, und mit jeder zusätzlichen TP-GPU wächst der Anteil dieser Wartezeit.

Die vLLM-Dokumentation zieht daraus eine ausdrückliche Konsequenz: Haben die GPUs eines Servers keine NVLink-Verbindung, etwa bei der L40S, sollte Pipeline Parallelism statt Tensor Parallelism eingesetzt werden, um höheren Durchsatz und geringeren Kommunikationsaufwand zu erreichen (vLLM, Parallelism and Scaling). Die RTX PRO Blackwell-Karten fallen in dieselbe Kategorie.

Daraus folgt nicht, dass TP über PCIe unbrauchbar ist. Bei zwei GPUs bleibt der Aufwand überschaubar, und TP verkürzt die Antwortzeit einer einzelnen Anfrage, was PP nicht tut. Der Abstand wächst mit TP=4 und TP=8 und mit der Zahl gleichzeitiger Anfragen.

Die Entscheidungsregel: so wenig Aufteilung wie möglich

Für Server ohne NVLink lässt sich die Wahl auf eine Regel reduzieren: Das Modell auf so wenige GPUs verteilen, wie nötig sind, damit es mit ausreichend KV-Cache passt, und die übrigen GPUs für weitere Replicas nutzen. Wie viel Speicher Gewichte und KV-Cache brauchen, rechnet GPU- und VRAM-Sizing für LLMs durch; welches Format die Gewichte verkleinert, erklärt LLM-Quantisierung.

Ein Beispiel für den dritten Fall: Qwen3.5-122B-A10B in FP8 belegt allein mit den Gewichten deutlich mehr als die 96 GB einer RTX PRO 6000. Zwei Karten mit TP=2 halten Gewichte und KV-Cache gemeinsam; der Aufbau ist im Beitrag vLLM mit Qwen3.5-122B auf zwei RTX PRO 6000 dokumentiert.

Ein Beispiel für den ersten Fall: Ein Modell mit rund 30 Mrd. Parametern in FP8 oder 4 Bit passt auf eine 96-GB-Karte mit viel Platz für KV-Cache. Mit zwei solchen GPUs liefern zwei Instanzen mehr Durchsatz als eine Instanz mit TP=2.

vLLM-Konfiguration für zwei GPUs

Die folgenden Befehle zeigen die drei Varianten mit vllm serve. Modellnamen, Kontextlänge und Speicheranteil sind Platzhalter, die zum Modell passen müssen.

Tensor Parallelism: ein Modell über beide GPUs

vllm serve <modell> \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Pipeline Parallelism: Schichten blockweise verteilt

vllm serve <modell> \
  --pipeline-parallel-size 2 \
  --max-model-len 32768

Replicas über Data Parallelism: zwei Kopien hinter einem Endpunkt

vllm serve <modell> \
  --data-parallel-size 2 \
  --max-model-len 32768

Replicas als getrennte Instanzen

CUDA_VISIBLE_DEVICES=0 vllm serve <modell> --port 8000
CUDA_VISIBLE_DEVICES=1 vllm serve <modell> --port 8001

Getrennte Instanzen lassen sich einzeln neu starten und aktualisieren. Die Verteilung übernimmt ein Gateway mit Lastverteilung und Health-Checks, etwa LiteLLM. Bei --data-parallel-size übernimmt vLLM die Verteilung selbst; die Warteschlangen-Limits gelten dann für den gesamten Server und nicht je Rang (vLLM, Data Parallel Deployment).

Weitere Parameter, die auf PCIe-Systemen eine Rolle spielen:

Die Beschreibungen stammen aus der Referenz der Engine-Argumente (vLLM, Engine Arguments). Wie sich vLLM insgesamt von Ollama unterscheidet, zeigt vLLM vs. Ollama.

Was eine öffentliche Messung zeigt

Belastbare, veröffentlichte Messungen zu TP gegen Replicas auf PCIe-Systemen sind selten. Eine nachvollziehbare Messreihe ist vllm-topology-bench. Sie vergleicht auf vier RTX 3090 ohne NVLink eine Instanz mit TP=4 gegen zwei Replicas mit je TP=2:

Das Muster bestätigt die Regel: Bei einer einzelnen Anfrage liegen beide Varianten fast gleichauf, mit steigender Last sättigt die Variante mit mehr TP-GPUs früher. Eine Kopie pro Karte (4 x TP=1) war in dieser Messung nicht möglich, weil die Gewichte die 24-GB-Karten fast vollständig belegen.

Die Einschränkungen nennt das Projekt selbst: eine Messung je Punkt, Consumer-Karten, kurze Kontextlänge, ein einzelnes MoE-Modell. Die absoluten Zahlen lassen sich nicht auf RTX PRO Blackwell oder andere Modelle übertragen. Übertragbar ist die Richtung, und die sollte vor jeder Festlegung auf dem eigenen System mit der eigenen Last geprüft werden.

Topologie prüfen und messen

Wie gut zwei GPUs miteinander kommunizieren, hängt nicht nur von der Karte ab, sondern auch vom Server. Drei Prüfungen gehören vor jede Multi-GPU-Konfiguration:

1. Verbindung zwischen den GPUs anzeigen. nvidia-smi topo -m zeigt die Topologiematrix. Stehen die GPUs am selben PCIe-Switch oder Root Complex, ist der Weg kurz. Steht zwischen ihnen SYS, läuft der Verkehr über die Verbindung zwischen zwei Prozessoren, was TP zusätzlich ausbremst.
2. Lane-Zahl und Generation prüfen. nvidia-smi -q zeigt die aktuelle PCIe-Generation und Link-Breite. Eine Karte, die nur mit x8 oder PCIe 4.0 angebunden ist, halbiert die verfügbare Bandbreite.
3. Mit realistischer Last messen. Durchsatz und Zeit bis zum ersten Token bei der erwarteten Zahl gleichzeitiger Nutzer und der tatsächlichen Eingabelänge vergleichen, jeweils für TP=2, PP=2 und Replicas, sofern das Modell es zulässt. vLLM bringt dafür ein eigenes Benchmark-Werkzeug mit (vllm bench serve).

Beim Start mit TP protokolliert NCCL, über welchen Weg die GPUs kommunizieren. Die vLLM-Dokumentation beschreibt, wie sich diese Ausgaben lesen lassen (vLLM, Parallelism and Scaling). Wer mehrere Server statt mehrerer GPUs in einem Server verbinden möchte, steht vor denselben Fragen auf Netzwerkebene; für GB10-Systeme beschreibt das AI Cubes mit ConnectX-7 verbinden.

Was das für Ihr Projekt heißt

Zwei GPUs ohne NVLink sind eine gute Basis für den Produktivbetrieb, wenn die Aufteilung zum Ziel passt. Für mehr Nutzer mit einem Modell, das auf eine Karte passt, sind Replicas der direkte Weg. Für Modelle, die eine Karte übersteigen, ist TP=2 der verbreitete Standard und PP=2 die Alternative, die sich bei hoher Last lohnen kann. TP über vier oder mehr PCIe-GPUs sollte nur nach eigener Messung gewählt werden.

WZ-IT stellt Managed GPU-Server mit einer dedizierten NVIDIA RTX PRO 4000 Blackwell (24 GB, ab 699 € netto/Monat) oder RTX PRO 6000 Blackwell Max-Q (96 GB, ab 1.799 € netto/Monat) bereit, jeweils mit vLLM, Open WebUI und Monitoring. Multi-GPU-Konfigurationen, getrennte Instanzen hinter einem Gateway und redundante Modell-Endpunkte planen wir passend zu Modell, Kontextlänge und Nutzerzahl und weisen sie im Angebot aus. Für den Betrieb im eigenen Haus ist der AI Cube die Alternative. Support, Beratung und Implementierung durch WZ-IT.

Welches Modell überhaupt in Frage kommt, ordnet Welches LLM selbst hosten? ein. Wie viele Nutzer ein Server tragen kann, beschreibt Lokalen KI-Server nach Nutzerzahl dimensionieren, und den Unterschied zwischen den Inferenz-Engines vergleicht der Beitrag vLLM, Ollama und llama.cpp im Vergleich.