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. Jedes Token wartet auf beide, in jeder Schicht.

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. Unsere Annahmen: Aktivierungen in BF16; zwei All-Reduces je Schicht, wie bei Megatron-LM; ein 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; und kein Aufschlag für Latenz, Protokoll-Overhead oder Überlappung mit der Berechnung.

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.

Daraus ergeben sich zwei Lesarten. Für einen einzelnen Nutzer, der Text erzeugt, sind ein paar MiB je Token nichts 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 wird das Volumen selbst zum Kostenfaktor: 82 bis 143 Millisekunden Übertragung für einen Prompt mit 2.000 Token über PCIe; für zwei oder vier H200 NVL an ihrer Brücke bestenfalls etwa ein Siebtel der 82 und 123 Millisekunden, nach NVIDIAs Werten: 450 GB/s je GPU und Richtung gegenüber 64 GB/s.

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.“ Ein virtualisierter Host tauscht diesen Pfad gegen Isolation ein.

Prüfen Sie, bevor Sie den Karten die Schuld geben. 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. Google hat im Oktober 2025 berichtet, was der Pfad wert ist: „bis zu 168 Prozent mehr Durchsatz und 41 Prozent geringere Latenz (Inter-Token-Latenz)“ beim tensor-parallelen Serving auf seinen Maschinen mit RTX PRO 6000 Server Edition und einem erweiterten PCIe-Peer-to-Peer-Pfad, „im Vergleich zu Standardangeboten ohne P2P“.

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.

Was die veröffentlichten Messungen zeigen

StorageReview: Test des HPE ProLiant DL380a Gen12, 6. November 2025, mit vLLM; 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 Geräten aufteilt. Mit 65,3 GB in seiner ursprünglichen MXFP4-Veröffentlichung passt das Modell auf ein Gerät mit 128 GB; der Test zeigt also den Zielkonflikt und keinen Grund, es aufzuteilen. Unser Artikel zu zwei DGX Spark enthält den Rest dieses Tests. 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, 68 GiB Gewichte, mit einem FP8-Cache von 1,25 GiB je Gespräch mit 8.192 Token, und eine Planungsregel: 90 Prozent der 95,6 GiB, die der Treiber meldet. Nach unserer Rechnung lässt eine Karte 18 GiB für den Cache übrig, etwa 14 Gespräche, zwei Replikate bedienen also 28. Aufgeteilt mit TP=2 hält jede Karte 34 GiB Gewichte und 52 GiB Cache: etwa 83 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, lassen keine Wahl: zwei oder vier Karten, wie unser Artikel zur Workstation mit vier Karten auflistet.

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. Für Mixture-of-Experts-Modelle ist Experten-Parallelismus eine dritte Option, mit seinem All-to-All-Verkehr über dasselbe PCIe.

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.

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

Eurokommerz liefert die RTX PRO 6000 Workstation Edition und Max-Q sowie 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. Schicken Sie uns das Modell und die Zahl der Nutzer, und wir sagen Ihnen, ob es eine Karte, Replikate oder eine Aufteilung braucht.

FAQ