Ein Modell auf mehreren GPUs: Tensor-, Pipeline- und Experten-Parallelismus über PCIe und NVLink-Brücken

Drei Wege, ein Modell aufzuteilen

Ein Modell, das nicht auf eine GPU passt oder schneller antworten muss, als eine GPU es kann, wird auf mehrere verteilt. Die drei Arten, es aufzuteilen, erzeugen unterschiedlichen Verkehr zwischen den Karten, weshalb die Verbindung für manche mehr zählt als für andere.

Tensor-Parallelismus zerlegt die Gewichtsmatrizen jeder Schicht und verteilt sie auf die GPUs. NVIDIAs Megatron-LM-Paper teilt die erste Matrix jedes MLP-Blocks nach Spalten und die zweite nach Zeilen, die Attention nach Heads, sodass eine Transformer-Schicht „nur zwei All-Reduces im Forward-Pfad“ braucht. Nach einem All-Reduce hat jede GPU die Summe der Teilergebnisse aller GPUs, und jedes Token muss in jeder Schicht auf beide All-Reduces warten.

Pipeline-Parallelismus gibt jeder GPU einen zusammenhängenden Bereich von Schichten, und nur die Aktivierungen an einer Stufengrenze wandern weiter, von Punkt zu Punkt. Das spätere Megatron-LM-Paper von 2021 fasst den Zielkonflikt zusammen: „Pipeline-Modellparallelismus bietet billigere Punkt-zu-Punkt-Kommunikation. Tensor-Modellparallelismus nutzt dagegen All-Reduce-Kommunikation.“ Der Preis ist Leerlauf, die Pipeline-Blase: Im Training beziffert das Paper sie als Zahl der Stufen minus eins, geteilt durch die Zahl der Micro-Batches, als Anteil an der idealen Rechenzeit; klein bleibt sie also nur mit sehr viel mehr Micro-Batches als Stufen. Im Serving hat eine Stufe nur dann Arbeit, wenn genug Anfragen gleichzeitig in Bearbeitung sind, um die Pipeline zu füllen.

Experten-Parallelismus betrifft Mixture-of-Experts-Modelle. Ganze Experten liegen auf verschiedenen GPUs, und jedes Token wandert zu den GPUs, die seine Experten halten, und wieder zurück, ein All-to-All-Austausch, den der technische Bericht zu DeepSeek-V3 Dispatching und Combining nennt. vLLM schaltet ihn mit --enable-expert-parallel ein und setzt die Größe des Experten-Parallelismus auf die Größe des Tensor-Parallelismus mal die Größe des Datenparallelismus.

Megatron-LM-Paper (NVIDIA, 2019; NVIDIA und andere, 2021), technischer Bericht zu DeepSeek-V3, Dokumentation von vLLM zu Experten- und Datenparallelismus. Training mit Datenparallelismus gleicht die Gradienten bei jedem Schritt per All-Reduce ab, und der Datenparallelismus von vLLM für MoE-Modelle synchronisiert die Expertenschichten in jedem Forward-Pass.

Die Verbindung: 128 GB/s oder 900 GB/s

Die RTX PRO 6000 hat in keiner Edition NVLink, ihre Karten tauschen Daten also über PCIe 5.0 x16 aus. NVIDIAs Beschreibung der Hopper-Architektur schreibt einer Schnittstelle mit PCIe Gen 5 x16 „128 GB/s Gesamtbandbreite (64 GB/s in jeder Richtung)“ zu. Bei der H200 NVL kommen Brücken hinzu, die zwei oder vier Karten mit 900 GB/s je GPU verbinden, und NVIDIAs H200-Seite stellt diesen Wert neben die 128 GB/s von PCIe Gen5, etwa siebenmal mehr. NVIDIAs Product Brief zur H200 NVL nennt die 900 GB/s „bidirektional“, und die Hopper-Beschreibung rechnet sie als 18 NVLink-Links zu je 25 GB/s pro Richtung, also 450 GB/s in jeder Richtung: dieselbe Basis wie beim PCIe-Wert. Das „14ד im Product Brief vergleicht sie mit einer Richtung von PCIe. Die Brückendomäne endet bei vier Karten, ein H200-NVL-Server mit acht Karten enthält also nach unserer Lesart zwei NVLink-Domänen, die über PCIe verbunden sind.

Auch der Pfad zwischen zwei Karten zählt. nvidia-smi topo -m gibt ihn für jedes Paar aus: über einen PCIe-Switch (PIX), mehrere Switches (PXB), eine Host-Bridge (PHB), zwischen Host-Bridges eines NUMA-Knotens (NODE) oder über die Verbindung zwischen den Prozessoren (SYS). Akamais Dokumentation zu seinen Instanzen mit RTX PRO 6000 Server Edition warnt, dass Peer-to-Peer-Kopien zwischen GPUs an verschiedenen Root-Complexes „eine verringerte Bandbreite aufweisen können“.

Was Tensor-Parallelismus sendet: ein 70B-Beispiel

Nehmen Sie Llama 3.3 70B. Seine config.json nennt eine Hidden Size von 8.192 und 80 Schichten. Wir nehmen Aktivierungen in BF16 an, zwei All-Reduces je Schicht wie bei Megatron-LM und einen Ring-All-Reduce, bei dem jede GPU mit zwei GPUs das Äquivalent des ganzen Puffers sendet, mit vier das 1,5-Fache des Puffers und mit acht das 1,75-Fache, die Faktoren, die die Testdokumentation von NCCL verwendet. Einen Aufschlag für Latenz, Protokoll-Overhead oder Überlappung mit der Berechnung rechnen wir nicht ein.

Der Aktivierungsvektor eines Tokens umfasst 8.192 × 2 Byte, 16 KiB. Zwei All-Reduces in jeder der 80 Schichten ergeben 160 je Forward-Pass, die 2,5 MiB Daten je Token transportieren.

Unsere Rechnung aus der config.json des Modells, dem Megatron-LM-Paper und der Testdokumentation von NCCL. 64 GB/s ist NVIDIAs Wert je Richtung für PCIe 5.0 x16; reale Übertragungen bleiben darunter.

Aus diesen Zahlen folgt zweierlei. Für einen einzelnen Nutzer, der Text erzeugt, sind ein paar MiB je Token eine geringe Last für die Verbindung; Zeit kosten die 160 Synchronisationspunkte je Token, „wobei jeder einzelne dieser Austausche die nächste Berechnung blockiert“, wie StorageReview es formulierte. Bei langen Prompts und großen Batches kostet das Volumen selbst Zeit, 82 bis 143 Millisekunden Übertragung für einen Prompt mit 2.000 Token über PCIe. Auf zwei oder vier H200 NVL, die über ihre Brücke verbunden sind, dauert die Übertragung bestenfalls etwa ein Siebtel der 82 und 123 Millisekunden, nach NVIDIAs Werten von 450 GB/s je GPU und Richtung gegenüber 64 GB/s. Wir liefern die RTX PRO 6000 und die H200 NVL mit ihren NVLink-Brücken und bauen für beide KI-Server nach Auftrag. Nennen Sie uns Modell und Nutzerzahl, und unser Team hilft Ihnen bei der Wahl der Aufteilung.

Peer-to-Peer über PCIe: IOMMU und ACS

Über PCIe laufen diese kollektiven Operationen am schnellsten, wenn die GPUs direkt in den Speicher der jeweils anderen schreiben. NVIDIAs NCCL-Dokumentation sagt, dass die Bibliothek „sich stark auf GPU Direct stützt“, gemeint sind „direkte Punkt-zu-Punkt-PCI-Nachrichten“, und nennt zwei Einstellungen, die das lahmlegen oder bremsen. Auf Bare-Metal-Linux „unterstützen CUDA und der NVIDIA-Treiberstack keine PCIe-Peer-to-Peer-Speicherübertragung mit aktivierter IOMMU“; der IOMMU-Modus mit Adressübersetzung sollte für den GPU-Pfad also vermieden werden. Und im Abschnitt zu PCI Access Control Services warnt sie, dass IO-Virtualisierung stören kann, indem sie „den gesamten PCI-Punkt-zu-Punkt-Verkehr zum Root-Complex der CPU umleitet, was eine erhebliche Leistungsminderung oder sogar ein Hängen verursacht“; haben PCI-Switches ACS aktiviert, „muss es deaktiviert werden“. Dieselbe Seite ergänzt: „Virtuelle Maschinen benötigen ACS, um zu funktionieren, daher ist das Deaktivieren von ACS keine Option.“ Auf einem Virtualisierungshost bleibt ACS daher aktiv, und der Peer-Verkehr zwischen GPUs, die an virtuelle Maschinen durchgereicht sind, nimmt den Weg über den Root-Complex der CPU.

Testen Sie den Peer-to-Peer-Pfad, bevor Sie Schlüsse über die Karten ziehen. Wer „peer access is not supported between these two devices“ sieht, soll laut der Dokumentation von SGLang --enable-p2p-check hinzufügen, und NVIDIAs Testsuite nccl-tests misst mit all_reduce_perf die All-Reduce-Rate, die eine Maschine tatsächlich erreicht.

Was vLLM und SGLang empfehlen

Die Empfehlung von vLLM ist kurz: „Wenn das Modell auf eine einzelne GPU passt, ist verteilte Inferenz wahrscheinlich unnötig“; ist es zu groß für eine GPU, passt aber in einen Knoten, nutzen Sie Tensor-Parallelismus; über Knoten hinweg setzen Sie die Größe des Tensor-Parallelismus auf die Zahl der GPUs je Knoten und die Größe des Pipeline-Parallelismus auf die Zahl der Knoten. Im Abschnitt zu ungleichmäßigen Aufteilungen ergänzt vLLM einen Hinweis, der für jeden reinen PCIe-Server gilt: „Wenn die GPUs im Knoten keine NVLINK-Verbindung haben (z. B. L40S), nutzen Sie Pipeline-Parallelismus statt Tensor-Parallelismus, für höheren Durchsatz und geringeren Kommunikationsaufwand“. Die Dokumentation von SGLang stellt fest, dass „Datenparallelismus für den Durchsatz besser ist, wenn genug Speicher vorhanden ist“, und dass er sich zusammen mit Tensor-Parallelismus nutzen lässt. Das Megatron-LM-Paper von 2021 nennt dieselbe Regel für das Training: Tensor-Modellparallelismus solle „in der Regel bis zum Grad g bei Servern mit g GPUs“ eingesetzt werden, Pipeline-Parallelismus dann über Server hinweg; jeder seiner Server hatte acht A100-GPUs, verbunden über NVLink und NVSwitch.

Was die veröffentlichten Messungen zeigen

StorageReview: Test des HPE ProLiant DL380a Gen12, 6. November 2025, mit vLLM, Präzision für Llama 2 70B nicht angegeben; Test eines DGX-Spark-Clusters, 11. Mai 2026, OEM-Systeme mit GB10, gekoppelt über eine einzige 200-Gb-Verbindung, gleiche Eingabe- und Ausgabelängen, Serving-Engine nicht angegeben. SE: Server Edition. Werte wie in den Tests angegeben.

Der PCIe-Server betreibt ein vierfach aufgeteiltes 70B-Modell ohne NVLink mit etwa 33 Token pro Sekunde für einen Nutzer. Die beiden OEM-Systeme vom Typ DGX Spark, deren 200-Gb-Verbindung 25 GB/s je Richtung überträgt, gegenüber 64 GB/s bei einem Steckplatz mit PCIe 5.0 x16, zeigen beide Seiten des Zielkonflikts: Pipeline-Parallelismus steigert den Durchsatz bei Batch 128 auf mehr als das Doppelte, während Tensor-Parallelismus für einen einzelnen Nutzer 37 Prozent schneller ist, weil er das Lesen der Gewichte für jedes Token zwischen den beiden Systemen aufteilt. Mit 65,3 GB in seiner ursprünglichen MXFP4-Veröffentlichung passt das Modell auf ein System mit 128 GB; der Test zeigt also den Zielkonflikt und keinen Grund, es aufzuteilen. Unser Artikel zu zwei DGX-Spark-Knoten im Verbund enthält den Rest dieses Tests. Bei einem Nutzer und TP=2 bewegt jeder der 160 All-Reduces pro Token nach unserer Rechnung etwa 16 KiB je GPU, rund 0,26 µs bei den 64 GB/s von PCIe 5.0 x16; für die Token-Erzeugung zählt also die Verzögerung jedes Austauschs mehr als die Bandbreite, und funktionierendes P2P verkürzt sie, weil die Kopie über den Arbeitsspeicher des Hosts entfällt. Einen veröffentlichten direkten Vergleich von Tensor- und Pipeline-Parallelismus auf Servern mit RTX PRO 6000 haben wir nicht gefunden.

Wann eine Kopie je GPU besser ist als das Aufteilen

Replikate, also eine vollständige Kopie des Modells je Karte hinter einem Load Balancer, senden nichts zwischen den Karten, fallen unabhängig voneinander aus und steigern den Durchsatz Karte für Karte. Das Aufteilen lohnt sich in drei Fällen: Das Modell passt nicht auf eine Karte; ein Nutzer braucht mehr Tempo, als eine Karte liefert, denn Tensor-Parallelismus verteilt das Lesen der Gewichte für jedes Token; oder viele lange Gespräche brauchen mehr Cache, als eine Kopie je Karte übrig lässt.

Der dritte Fall wird leicht übersehen. Nehmen Sie zwei RTX PRO 6000 und Llama 3.3 70B in FP8, mit 68 GiB Gewichten und einem FP8-Cache von 1,25 GiB je Gespräch mit 8.192 Token. Als Planungsregel nehmen wir 90 Prozent der 95,6 GiB, die der Treiber meldet, abzüglich 3 GiB je Karte für Aktivierungen und CUDA-Graphen. Nach unserer Rechnung lässt eine Karte 15 GiB für den Cache übrig, 12 Gespräche, zwei Replikate bedienen also 24. Aufgeteilt mit TP=2 hält jede Karte 34 GiB Gewichte und 49 GiB Cache: etwa 78 Gespräche für eine Instanz, bezahlt mit 160 All-Reduces je Forward-Pass. Modelle wie Qwen3-235B-A22B, 134 GB in NVFP4 und 236 GB in FP8 (Version 2507), brauchen ohnehin zwei oder vier Karten, wie unser Artikel zur Workstation mit vier Karten auflistet.

Für ein konkretes Modell rechnen wir beide Anordnungen durch, Replikate oder eine Aufteilung, mit der Kartenzahl, die jede braucht, und liefern die Karten für beide Varianten. Schreiben Sie uns, um welches Modell es geht und wie viele lange Gespräche es gleichzeitig halten muss.

Eine Anordnung je Plattform

RTX PRO 6000. Replizieren Sie alles, was auf eine Karte passt. Für alles Größere funktioniert Tensor-Parallelismus über PCIe am besten dort, wo Peer-to-Peer funktioniert; testen Sie im Vergleich dazu Pipeline-Parallelismus, wie vLLM es für GPUs ohne NVLink nahelegt, und halten Sie die Karten eines Modells auf dem kürzesten Pfad, den nvidia-smi topo -m anzeigt. Zwei und vier Karten verhalten sich in vLLM unterschiedlich: Sein eigener All-Reduce-Kernel läuft auf zwei PCIe-Karten mit funktionierendem Peer-to-Peer, sein Quellcode schaltet ihn aber in der Standardeinstellung für mehr als zwei Karten ohne NVLink ab („not supported on more than two PCIe-only GPUs“), sodass TP=4 jedes All-Reduce NCCL überlässt, solange das unten beschriebene, optional zuschaltbare Backend nicht aktiviert ist. Auf einem Server mit vier Karten der RTX PRO 6000 Server Edition lohnt es sich deshalb, ein Modell, das auf zwei Karten passt, als zwei Instanzen mit TP=2 zu testen, jedes Paar möglichst an einem Prozessor oder PCIe-Switch, und mit einer Kopie mit TP=4 zu vergleichen; einen veröffentlichten Vergleich der beiden gibt es nicht, deshalb entscheidet ein Lasttest mit Ihrem Modell. Für Mixture-of-Experts-Modelle ist Experten-Parallelismus eine dritte Option, mit seinem All-to-All-Verkehr über dasselbe PCIe. Wir bauen KI-Server nach Auftrag, auch in einer Konfiguration mit vier Karten der RTX PRO 6000 Server Edition. Schicken Sie uns das Modell und die geplante Aufteilung, und wir antworten innerhalb eines Werktages mit einer Konfiguration und einem Angebot.

vLLM 0.30.0, veröffentlicht am 22. September 2026, hat für Server ohne NVLink ein optional zuschaltbares FlashInfer-PCIe-IPC-All-Reduce ergänzt (Pull Request 53576), das auch in 0.33.0 vom 2. November 2026 enthalten ist. Es ist standardmäßig aus und wird mit VLLM_ALLREDUCE_USE_FLASHINFER_PCIE_IPC=1 eingeschaltet. Der Code unterstützt Tensor-Parallel-Größen von 2, 4 und 8 mit Tensoren in BF16 oder FP16 auf einem Knoten, braucht CUDA-Graph-Capture-Größen und einen FlashInfer-Build mit PcieIpcAllReduceWorkspace und fällt sonst mit einer Warnung im Log auf ein anderes Backend zurück. Über den Gewinn ist wenig veröffentlicht. FlashInfers Pull Request für den Kernel nennt einen Mikrobenchmark auf acht L40S in BF16, in dem er NCCL an allen 72 Messpunkten schlug, um den Faktor 1,22 bis 5,92; ein dort veröffentlichter Lauf mit einem ganzen Modell auf zwei RTX PRO 6000 Max-Q mit TP=2 verkürzte die Schrittzeit um 4,57 Prozent bei einer gleichzeitigen Anfrage und um 5,59 Prozent bei acht, ohne Vorteil beim Prefill. vLLMs Leitfaden zur Parallelisierung, aktualisiert am 15. Oktober 2026, empfiehlt auf GPUs ohne NVLink weiterhin Pipeline-Parallelismus und erwähnt das Backend nicht; behandeln Sie es deshalb als A/B-Test gegen NCCL mit Ihrem eigenen Modell. Unser Vergleich von TP=2, TP=4 oder Replikaten ohne NVLink beschreibt seine Grenzen im Einzelnen.

H200 NVL. Verbinden Sie die Karten, die sich ein Modell teilen, per Brücke: Tensor-Parallelismus innerhalb einer NVLink-Domäne aus zwei oder vier Karten, Pipeline-Parallelismus zwischen den beiden Domänen eines Servers mit acht Karten; das ist die Regel von vLLM für Knoten, auf Domänen angewandt. Die Kartenzahl je Modell steht in unserem Leitfaden zur H200 NVL, die Wahl zwischen Zweifach- und Vierfach-Brücke in unserem Artikel zur NVLink-Brücke.

Jenseits von beiden. Ein Modell, das Tensor-Parallelismus über acht GPUs bei interaktiver Latenz braucht, oder ein Training, das bei jedem Schritt Gradienten austauscht, gehört auf ein NVLink-System wie ein DGX B300, wie unser B300-Vergleich darlegt.

Was wir liefern

Wir liefern die RTX PRO 6000 in allen drei Editionen (Workstation, Max-Q und Server Edition) und die H200 NVL mit ihren Zweifach- und Vierfach-NVLink-Brücken EU-weit mit Herstellergarantie, als Karten oder in Workstations und KI-Servern, die nach Auftrag mit der Steckplatzbelegung gebaut werden, die ein aufgeteiltes Modell braucht.

FAQ