NVIDIA RTX PRO 6000 Blackwell ohne NVLink: TP=2, TP=4 oder Replikate auf 2, 4 und 8 Karten

Tensor-Parallelismus auf der RTX PRO 6000 ohne NVLink

Keine Edition der NVIDIA RTX PRO 6000 Blackwell hat NVLink, weder die Server Edition noch die Max-Q noch die Workstation Edition; ein auf mehrere Karten verteiltes Modell schickt seinen Tensor-Parallel-Verkehr deshalb über PCIe 5.0, und das funktioniert auf 2, 4 und 8 Karten. Betreiben Sie eine Kopie je Karte, solange Modell und Cache darauf passen, nehmen Sie TP=2-Paare für Modelle bis etwa 150 GiB Gewichte und TP=4 bis etwa 310 GiB, und vergleichen Sie auf einem Server mit acht Karten zwei TP=4-Kopien mit einer TP=8-Instanz.

Der wichtigste Unterschied zwischen TP=2 und TP=4 liegt in der Software: Standardmäßig nutzt vLLM seinen eigenen Kernel nur für zwei reine PCIe-GPUs und überlässt vier oder acht der Bibliothek NCCL.

Grenzen nach unserer Auslegungsregel: 0,9 × 95,6 GiB laut Treiber − 3 GiB = 83,0 GiB je Karte, also 166,1, 332,2 und 664,3 GiB für 2, 4 und 8 Karten, mit mindestens 15 bis 25 GiB je Karte für den KV-Cache. All-Reduce-Pfade aus dem Quellcode custom_all_reduce (Dokumentation „latest“) und dem Stand v0.32.0, gelesen am 24. Oktober 2026.

Viele lange Gespräche brauchen mehr Cache als diese Reserven, sodass sich eine Aufteilung auch dann lohnen kann, wenn die Gewichte auf eine Karte passen; unser Artikel zum Verteilen eines Modells über PCIe oder NVLink rechnet das für Llama 3.3 70B durch.

Was vLLM bei TP=2, TP=4 und TP=8 über PCIe macht

Tensor-Parallelismus verteilt jede Schicht auf die Karten, und nach jeder geteilten Schicht addieren die Karten ihre Teilergebnisse in einem All-Reduce. vLLM hat dafür auf einem Knoten zwei Wege: einen eigenen Custom-All-Reduce-Kernel, der per Peer-to-Peer (P2P) direkt in den Speicher der anderen GPUs schreibt, und NVIDIAs Bibliothek NCCL.

Die Regel steht im Quellcode von custom_all_reduce in der aktuellen vLLM-Dokumentation. Liegen die GPUs auf einem Knoten, ist die World Size (die Zahl der beteiligten GPUs) größer als zwei und sind die GPUs nicht voll verbunden, schreibt vLLM „Custom allreduce is disabled because it's not supported on more than two PCIe-only GPUs“ ins Log. Aus bleibt der Kernel auch, wenn der P2P-Test von vLLM fehlschlägt, und bei einer World Size außerhalb von 2, 4, 6, 8 und 16. Von Hand schaltet ihn --disable-custom-all-reduce ab; laut Hilfetext fällt vLLM dann auf NCCL zurück.

Quellcode custom_all_reduce (vLLM-Dokumentation „latest“) und flashinfer_pcie_ipc_all_reduce.py im Stand v0.32.0, gelesen am 24. Oktober 2026, für einen Knoten mit reinen PCIe-GPUs.

TP=2 und TP=4 laufen auf demselben Server also über unterschiedlichen Code. Hängt ein TP=2-Paar, liegt der Verdacht beim Custom-Kernel und beim P2P-Pfad; ist eine TP=4-Instanz langsam, bei NCCL über PCIe. Der Pull-Request zum neuen Backend von vLLM beschreibt die Kosten: Auf reinen PCIe-Systemen mit mehreren GPUs bestimmt der Standard-All-Reduce RING_LL von NCCL die Zeit der kleinen Collectives beim Decoding, also der vielen kleinen All-Reduces bei der Token-Erzeugung („the default NCCL RING_LL all-reduce dominates small-message decode collectives“).

Der optionale FlashInfer-PCIe-IPC-All-Reduce in vLLM 0.30.0

Die Release Notes von vLLM 0.30.0 vom 22. September 2026 nennen einen optionalen „FlashInfer PCIe IPC all-reduce for NVLink-less boxes“ (Pull-Request 53576); das Modul ist auch in 0.32.0 vom 18. Oktober 2026 enthalten. Laut Docstring zielt es auf kleine Tensor-Parallel-All-Reduces auf einem einzelnen Knoten mit reinen PCIe-GPUs („small tensor-parallel all-reduces on a single PCIe-only node“). Standardmäßig ist es aus: VLLM_ALLREDUCE_USE_FLASHINFER_PCIE_IPC ist als Boolean mit False deklariert, und der Pull-Request schaltet es mit VLLM_ALLREDUCE_USE_FLASHINFER_PCIE_IPC=1 ein.

Die Grenzen stehen im Code: World Size 2, 4 oder 8, Tensoren in BF16 oder FP16, alle Ranks auf einem Knoten, CUDA-Graph-Capture-Größen erforderlich, noch keine DBO- oder Multi-Ubatch-Ausführung. Fehlt der installierten FlashInfer-Version PcieIpcAllReduceWorkspace, schreibt vLLM eine Warnung und weicht auf ein anderes Backend aus; prüfen Sie deshalb nach dem Einschalten das Log.

Über den Gewinn ist wenig veröffentlicht.

• Der FlashInfer-Pull-Request zum Kernel zeigt einen Microbenchmark auf acht L40S in BF16: Alle 72 Messpunkte waren schneller als NCCL, um den Faktor 1,22 bis 5,92, über TP 2, 4 und 8 und Batch 1 bis 128.
• Ein dort veröffentlichter Lauf mit einem ganzen Modell auf zwei RTX PRO 6000 Max-Q mit 300 W an PCIe Gen4 und TP=2 verkürzte die Schrittzeit um 4,57 Prozent bei einer gleichzeitigen Anfrage und um 5,59 Prozent bei acht, ohne Gewinn im Prefill.
• Der Pull-Request von vLLM nennt einen End-to-End-Test auf vier RTX PRO 6000 mit TP=4 und DeepSeek-V4-Flash-0731, aber keine Geschwindigkeitswerte.

Einen veröffentlichten End-to-End-Gewinn bei TP=4 oder TP=8 auf RTX PRO 6000 haben wir nicht gefunden. Der Parallelisierungsleitfaden von vLLM, aktualisiert am 15. Oktober 2026, rät für GPUs ohne NVLink weiterhin, Pipeline- statt Tensor-Parallelismus zu nutzen, für höheren Durchsatz und weniger Kommunikationsaufwand, und erwähnt das neue Backend nicht. Behandeln Sie die Option als Kandidaten für einen A/B-Test mit Ihrem Modell, mit NCCL als Basis.

Wir bauen Server mit 2, 4 oder 8 RTX PRO 6000 Server Edition und legen die Steckplätze für die geplante Aufteilung aus; schicken Sie uns Modell, Präzision und Kontextlänge, und unser Team antwortet mit Layout und Konfiguration.

Veröffentlichte Messwerte zu P2P und Tensor-Parallelismus

Level1Techs-Threads „RTX Pro 6000 - Everthing That's Gone Wrong“ und ein Aufbau-Log mit vier Max-Q; StorageReview, Test des HPE ProLiant DL380a Gen12 (6. November 2025); Engineering-Blog von Helix (14. August 2026); Google-Cloud-Blog zu G4-VMs (20. Oktober 2025). Werte wie veröffentlicht, gelesen am 24. Oktober 2026; Forumswerte stammen von einzelnen Systemen.

Daraus folgt dreierlei. P2P wirkt sich stärker auf die Latenz aus als auf die Bandbreite: Mit P2P fiel die Latenz zwischen zwei Karten von 12,68 auf 0,53 µs, die Bandbreite je Richtung stieg nur von etwa 42 auf 46 GB/s und blieb damit unter den 64 GB/s, die PCIe 5.0 x16 je Richtung überträgt. Tensor-Parallelismus über PCIe erreicht brauchbare Werte, Llama 2 70B mit etwa 33 Token pro Sekunde für einen Nutzer auf vier Karten der Server Edition. Und Replikate bringen Durchsatz, wo eine geteilte Instanz an ihre Grenze kommt: Helix verdoppelte den Durchsatz bei 32 gleichzeitigen Anfragen mit zwei TP=4-Instanzen hinter einem Load Balancer mit Session-Bindung. Einen veröffentlichten Vergleich von TP=4 und TP=8 auf demselben RTX-PRO-6000-Server haben wir nicht gefunden.

Workstation-Boards, Server mit zwei Sockeln und PCIe-Switches

Die Verdrahtung der Steckplätze entscheidet, welche Paare schnell miteinander sprechen. nvidia-smi topo -m zeigt den Pfad für jedes Paar: PIX für eine PCIe-Bridge, PXB für mehrere, PHB über eine Host-Bridge, NODE zwischen Host-Bridges eines NUMA-Knotens, SYS über die Verbindung zwischen den Prozessoren.

• Workstations. Jede Karte hängt an einem Root-Port eines Prozessors; zwei Max-Q auf einem Threadripper-PRO-Board zeigten im Level1Techs-Thread NODE. NVIDIA nennt für die Max-Q bis zu vier GPUs in einem System.
• Server mit zwei Sockeln ohne Switches. Die Karten verteilen sich auf zwei NUMA-Knoten. In einem Bericht im vLLM-Forum vom April 2026 saßen acht Karten der Server Edition zu je vier an einem Knoten, und eine TP=2-Instanz hing beim Start, bis --disable-custom-all-reduce gesetzt war. Halten Sie jeden TP-Verbund an einem Sockel.
• Server mit PCIe-Switches. Laut technischem Leitfaden von Dell zum XE7745 (September 2026) hängt jeder GPU-Steckplatz an einem von vier Broadcom-Atlas-II-Switches. Das Datenblatt des Supermicro SYS-422GA-NRT nennt einen „PCIe 5.0 x16 Switch Dual-Root“ für bis zu acht Karten mit 600 W bei 35 °C, mit Server Edition, Max-Q und H200 NVL auf der GPU-Liste; die acht Karten nennt es für die Server Edition, eine Anzahl für die Max-Q gibt es nicht an. NVIDIAs Leitfaden für zertifizierte Systeme (30. September 2026) empfiehlt Gen5-Switches und nennt einen Switch für kostengünstige Inferenzserver optional.

Auf Bare Metal nennt NVIDIAs NCCL-Dokumentation zwei Einstellungen, die den P2P-Pfad stören. CUDA und der NVIDIA-Treiberstack unterstützen PCIe-Peer-to-Peer-Übertragungen bei aktivierter IOMMU nicht. Und ist auf PCI-Switches ACS aktiviert, muss es abgeschaltet werden („If PCI switches have ACS enabled, it needs to be disabled“), weil IO-Virtualisierung den Peer-Verkehr zum Root Complex der CPU umleiten kann, mit deutlichem Leistungsverlust oder sogar einem Hänger. Dieselbe Seite hält fest, dass virtuelle Maschinen ACS brauchen; ein Modell, das in VMs aufgeteilt ist, verzichtet also auf einen Teil dieses Pfads.

Layouts je Modellgröße auf 2, 4 und 8 Karten

Gewichte aus den Hugging-Face-Repositorys von openai und Qwen, gelesen am 24. Oktober 2026 (65,3 GB, 236 GB, 470 GB), von deepseek-ai (Repository mit 167 GB für DeepSeek-V4-Flash-0731; Helix nennt etwa 156 GB im Betrieb) und aus unseren Sizing-Grundlagen für Llama 3.3 70B (Gespräche mit 8.192 Token, FP8-Cache). Platz für den Cache nach unserer Auslegungsregel bei gleichmäßig verteilten Gewichten.

Ein Modell, das auf eine Karte passt, läuft als Replikat am günstigsten: Nichts geht über PCIe, eine ausgefallene Karte nimmt nur eine Kopie mit, und der Durchsatz wächst Karte für Karte. Replikate brauchen allerdings Session-Bindung, damit ein zurückkehrendes Gespräch die Kopie mit seinem Cache erreicht. Aufteilen sollten Sie, wenn die Gewichte nicht passen, wenn ein Nutzer das Tempo mehrerer Karten braucht oder wenn der Cache neben einer Kopie keinen Platz findet: Ein TP=2-Paar fasst nach unserer Auslegungsregel 78 Gespräche mit Llama 3.3 70B, zwei Kopien fassen 24.

Qwen betreibt sein 235B-Modell in FP8 auf der Modellkarte mit TP=4. Laut config.json hat es vier KV-Heads; bei TP=4 liegt also ein Head auf jeder Karte, und der Cache teilt sich gleichmäßig auf. Bei TP=8 wird der Cache laut der vLLM-Dokumentation zu Context Parallel tp_size / H-mal dupliziert, hier doppelt, und der Qwen3-Leitfaden von vLLM rät für MoE-Checkpoints in FP8, deren Expertenanteile nicht durch die Quantisierungsblöcke der Breite 128 teilbar wären, zu TP=4 oder zu TP=8 mit --enable-expert-parallel. Unser Artikel zum Server für KI-Agenten mit 100K Kontext rechnet dieses Modell für lange Gespräche durch, und unser Leitfaden zur Aufteilung von 8 × RTX PRO 6000 verteilt acht Karten auf mehrere Modelle.

TP=2-Hänger: was vLLM-Issue 30682 und die Foren berichten

vLLM-Issue 30682 wurde im Dezember 2025 für zwei RTX PRO 6000 Max-Q mit TP=2 unter vLLM 0.12.0 und Treiber 580.95.05 eröffnet. Das Log wiederholt „No available shared memory broadcast block found in 60 seconds“ und endet mit einem RPC-Timeout. Der Autor schloss das Issue am 19. Dezember 2025, nachdem er iommu=pt in die Kerneloptionen aufgenommen hatte; Nutzer meldeten den Hänger bis Juni 2026 weiter, und kein Maintainer veröffentlichte eine Lösung. Die Workarounds aus den 16 Kommentaren:

• --disable-custom-all-reduce, allein oder mit NCCL_P2P_DISABLE=1: half manchen Nutzern, anderen nicht;
• iommu=pt in den GRUB-Optionen: löste es für den Autor, nicht für einen anderen Nutzer mit anderen GPUs;
• ein neueres NCCL-Paket, vorgeschlagen ohne Ergebnis, und mehr Shared Memory für Docker oder Podman, was einem Nutzer nach eigener Aussage sehr half.

Der Level1Techs-Thread zu zwei Max-Q zeigt dasselbe Muster: Mit P2P hing NCCL beim ersten All-Reduce direkt nach „Connected all rings“. Ein Nutzer löste es, indem er die IOMMU im BIOS abschaltete, ein anderer mit amd_iommu=on iommu=pt und abgeschaltetem ACS; ohne P2P erreichte der All-Reduce auf zwei Karten etwa 31 GB/s Busbandbreite. Ein Aufbau-Log mit vier Max-Q behob einen TP=2-Stillstand, indem ACS und IOMMU im BIOS abgeschaltet wurden.

Eine Reihenfolge, die diesen Quellen folgt: Topologie prüfen, NVIDIAs Beispiel simpleP2P laufen lassen, bis es mit „Test passed“ endet, all_reduce_perf aus den nccl-tests auf jedem TP-Verbund ausführen, den IOMMU-Modus in /proc/cmdline und ACS an den Switches prüfen, danach --disable-custom-all-reduce in vLLM versuchen und NCCL_P2P_DISABLE=1 zuletzt. IOMMU und ACS ändern, wie Geräte voneinander isoliert sind; stimmen Sie das mit den Verantwortlichen für die Sicherheit des Hosts ab.

Was Sie vor der Bestellung eines Servers mit mehreren Karten prüfen

1. Die Edition. Im Rack-Server die RTX PRO 6000 Server Edition, die NVIDIA für Multi-GPU-Server mit passiver Kühlung auslegt („designed for multi-GPU server deployments requiring passive cooling“). Die Max-Q gehört nur dort ins Rack, wo der Hersteller sie aufführt, wie Lenovo im Produktleitfaden LP2364 für zwei ThinkSystem-Server und Supermicro auf der GPU-Liste des SYS-422GA-NRT. Eine Anzahl für die Max-Q nennt Supermicro für dieses Gehäuse nicht; wir lassen sie uns vor dem Angebot für die genaue Konfiguration vom Hersteller bestätigen.
2. Die Topologie für Ihre Bestückung: welche Paare sich einen Switch teilen, welche über die Sockelgrenze laufen, und nvidia-smi topo -m von einem bestückten Gerät.
3. Die BIOS-Optionen für ACS und IOMMU und ob auf dem Host virtuelle Maschinen laufen sollen.
4. P2P- und All-Reduce-Ergebnisse bei der Abnahme, wie in unserem Leitfaden zu Burn-in und Abnahmetest.
5. Die festzuschreibenden Versionen: vLLM, NCCL, Treiber und eine FlashInfer-Version, wenn Sie das optionale Backend testen.
6. Wachstum von zwei auf vier oder von vier auf acht Karten, wie in unserem Leitfaden zum späteren Nachrüsten von GPUs.

Wir liefern die RTX PRO 6000 in allen drei Editionen und bauen den Server um das Layout herum, vor der Lieferung montiert und getestet; beschreiben Sie Modell und Nutzerzahl, und wir antworten mit Kartenzahl und Steckplatzplan.

Wann sich NVLink lohnt

Die H200 NVL verbindet zwei oder vier Karten über NVLink-Brücken mit 900 GB/s je GPU, gegenüber 128 GB/s für PCIe Gen5 laut NVIDIAs H200-Seite; TP=4 in einer Vierer-Domäne hält seine All-Reduces also von PCIe fern. Ein H200-NVL-Server mit acht Karten enthält zwei solche Domänen, wie unser Leitfaden zur NVLink-Brücke der H200 NVL erklärt, und unser Vergleich von RTX PRO 6000 und H200 NVL für LLM-Inferenz wägt 96 gegen 141 GB je Karte ab. TP=8 mit NVLink-Tempo über acht GPUs braucht eine DGX B300, die wir je Projekt anbieten. Für die meisten Modelle bis etwa 300 GiB Gewichte tragen PCIe und ein durchdachtes Layout auf Karten der RTX PRO 6000 Server Edition die Last.

FAQ