GPU-Cluster ohne InfiniBand für LLM-Inferenz: Ethernet, RoCE und wann Multi-Node nötig wird

Zwei bis vier GPU-Server ohne InfiniBand: wann Ethernet reicht

Für LLM-Inferenz auf zwei bis vier Servern reicht meist ein GPU-Cluster ohne InfiniBand. Die meisten Modelle, die ein Unternehmen mit 500 bis 2.000 Mitarbeitern betreibt, passen in einen Server mit acht Karten RTX PRO 6000 Server Edition (768 GB GPU-Speicher) oder acht H200 NVL (1.128 GB). Jeder Server betreibt dann eigene Kopien der Modelle hinter einem Load Balancer, und die Server tauschen untereinander keine Daten aus. Ein solcher Cluster braucht gewöhnliches Ethernet für Anfragen, Modell-Downloads und Monitoring. Unser 70B-Rechenbeispiel plant zwei 25-GbE-Ports je Server, und NVIDIAs Referenzarchitektur gibt dem Management-Controller jedes Knotens einen 1-Gbit-Port.

Eine schnelle Ost-West-Fabric, RDMA über InfiniBand oder RoCE mit 200 bis 400 Gbit/s, wird in zwei Fällen nötig: Ein Modell verteilt sich per Pipeline-, Tensor- oder Experten-Parallelismus über mehrere Server, oder KV-Cache wandert beim disaggregierten Serving zwischen Servern. NVIDIAs Konfigurationsleitfaden für NVIDIA-Certified Systems, zuletzt aktualisiert am 30. September 2026, zieht dieselbe Grenze: „Bereitstellungen auf nur einem Knoten benötigen in der Regel kein Hochgeschwindigkeitsnetzwerk, um mehrere Knoten für Ihren KI-Workload zu verbinden.“ Für Cluster-Workloads verbindet er die Knoten über ein „Hochgeschwindigkeitsnetzwerk (entweder InfiniBand oder RoCE)“ und verlangt „mindestens 200 Gbit/s für Multi-Node-Inferenz“.

Was in jedem Cluster-Muster über das Netzwerk geht

vLLM-Dokumentation zu Parallelismus und Skalierung (6. Mai 2026), zum Deployment mit Experten-Parallelismus (2. Oktober 2026) und zum NixlConnector (1. Oktober 2026); NVIDIAs Konfigurationsleitfaden für NVIDIA-Certified Systems (30. September 2026); Portzahlen aus unserem 70B-Rechenbeispiel und NVIDIAs Referenzarchitektur RTX PRO AI Factory.

vLLMs Dokumentation zum Parallelismus geht von einer Karte aus: „Wenn das Modell auf eine einzige GPU passt, ist verteilte Inferenz wahrscheinlich unnötig.“ Für mehrere Server schreibt sie: „Setzen Sie tensor_parallel_size auf die Zahl der GPUs je Knoten und pipeline_parallel_size auf die Zahl der Knoten.“ Dann geht nur der Verkehr der Pipeline über das Netzwerk. Dieselbe Seite zeigt auch Tensor-Parallelismus über alle GPUs des Clusters und merkt an: „Effizienter Tensor-Parallelismus erfordert schnelle Kommunikation zwischen den Knoten“. Ein Port mit 400 Gbit/s überträgt 50 GB/s je Richtung, weniger als die 64 GB/s eines Steckplatzes PCIe 5.0 x16, und jeder Switch-Hop verlängert die Latenz der beiden All-Reduces, die Tensor-Parallelismus je Schicht braucht. Unser Leitfaden zu einem Modell auf mehreren GPUs über PCIe und NVLink behandelt diesen Verkehr.

Unabhängige Replikate hinter einem Load Balancer

Unser Leitfaden zur Hochverfügbarkeit für ein On-Premise-LLM legt ein Unternehmen mit 2.000 Mitarbeitern und einer Spitze von 80 Anfragen in Bearbeitung auf gpt-oss-120b bei 32K Kontext aus. Zwei Server mit je fünf RTX PRO 6000 oder zwei H200 NVL tragen diese Spitze allein, wenn der andere ausfällt, und drei Server brauchen je drei RTX PRO 6000 oder eine H200 NVL. In beiden Aufbauten betreibt jeder Server vollständige Replikate, und zwischen den GPU-Servern läuft nichts.

Das Netzwerk eines solchen Clusters trägt Anfragen und gestreamte Antworten, also Text, die Aufrufe einer RAG-Pipeline an den Embedding-Dienst und die Vektordatenbank sowie Metriken. Unser 70B-Rechenbeispiel plant zwei 25-GbE-Ports je Server, und der zweite hält Backup-Verkehr und das Laden von Modellen aus dem Nutzernetz heraus. Der Management-Controller erhält einen eigenen 1-GbE-Port in einem separaten Management-Netzwerk.

Acht Karten in einem Server oder je vier in zwei Servern ist eine Frage der Ausfalldomänen, die unser Vergleich von einem Server mit 8 GPUs und zwei Servern mit 4 GPUs behandelt.

KI-Server bauen wir mit 2 bis 8 GPUs je Knoten und passen die NICs, 25 bis 400G, an das Cluster-Muster an. Nennen Sie uns über das Formular unten, wie viele Server Sie planen und welche Modelle jeder bereitstellt.

Wenn sich ein Modell über zwei Server verteilt

Ein Server reicht nicht mehr, wenn die Gewichte und der Cache der Spitze nicht auf seine Karten passen. Unser Leitfaden zur DeepSeek-Hardware nennt ein Beispiel: DeepSeek-V3.2 lässt auf acht RTX PRO 6000 je Karte 2,7 GiB frei, etwa ein Gespräch bei 32K, während acht H200 NVL im Tensor-Parallelismus je Karte 43 GiB freilassen, etwa 18 Gespräche. Ein Modell dieser Größe wechselt entweder auf die größere Karte oder verteilt sich über zwei Server, und das Netzwerk dazwischen trägt dann Verkehr jeder Anfrage.

Pipeline-Parallelismus überträgt am wenigsten. Nur die Aktivierungen an der Grenze zwischen zwei Stufen gehen über das Netzwerk. Die config.json von DeepSeek-V3.2 nennt eine Hidden Size von 7.168, und vLLMs DeepSeek-Code reicht je Token zwei Tensoren dieser Größe an die nächste Stufe weiter, den Hidden State und das Residual; in BF16 belegt ein Token also 28 KiB. Ein Prompt mit 2.000 Tokens schickt etwa 57 MB über die Grenze, nach unserer Rechnung etwa 18 ms bei einer Leitungsrate von 25 Gbit/s und etwa 2,3 ms bei 200 Gbit/s. Jeder Generierungsschritt schickt danach 28 KiB je Anfrage.

Mixture-of-Experts-Modelle bringen eine dritte Möglichkeit, Experten-Parallelismus, den vLLM mit Datenparallelismus kombiniert. Über Server hinweg schickt Experten-Parallelismus Tokens in jeder MoE-Schicht All-to-All. vLLMs Dokumentation zum Experten-Parallelismus führt die DeepEP-Backends für „Multi-node prefill“ und „Multi-node decode“ auf und enthält Hinweise zur Fehlersuche für InfiniBand und RoCE. Dieses Muster braucht RDMA.

Disaggregiertes Serving verschiebt stattdessen den KV-Cache. vLLMs NixlConnector ist „ein Hochleistungs-Connector zur Übertragung des KV-Cache für die Funktion des disaggregierten Prefillings in vLLM“, mit UCX als Standardtransport; wann man Prefill von Decode trennt, behandelt unser Leitfaden zu disaggregiertem Serving mit NVIDIA Dynamo.

RoCE oder InfiniBand für die Ost-West-Fabric

InfiniBand ist eine eigene Fabric mit eigenen Switches, und die Adapter laufen im InfiniBand-Modus. Sie braucht einen Subnet Manager, und NVIDIAs DOCA-Dokumentation (v3.5.0) stellt fest: „Für jedes InfiniBand-Subnetz muss ein SM laufen.“ NCCL, die Bibliothek, über die vLLM Daten zwischen GPUs austauscht, erreicht die Adapter über IB Verbs, und NCCL_IB_HCA legt fest, welche Adapter es nutzt.

RoCE führt RDMA über die Ethernet-Switches. NVIDIAs Dokumentation zu Cumulus Linux 5.16 schreibt, dass „RoCE das Infiniband-Protokoll (IB) über konvergentes Ethernet nutzt“ und dass „RoCEv2 Flusskontrolle für verlustfreies Ethernet erfordert“. Ihr Standardmodus für RoCE ist verlustfrei (lossless), mit Priority Flow Control und ECN auf jedem Switch, den der Verkehr durchläuft, und ein verlustbehafteter Modus (lossy) stützt sich allein auf ECN. NCCL nutzt dieselben Verbs und wählt die Adresse mit NCCL_IB_GID_INDEX, den NCCL 2.32.3 als „den im RoCE-Modus verwendeten Global-ID-Index“ dokumentiert, mit AUTO als Standard seit 2.32u1.

NVIDIAs eigene Ethernet-Option ist Spectrum-X, das in NVIDIAs Worten „speziell entwickelte Ethernet-Switches und SuperNICs kombiniert“; NVIDIA schreibt, dass seine SuperNICs „Netzwerkkonnektivität per RDMA over Converged Ethernet (RoCE) zwischen GPU-Servern“ bereitstellen. Die BlueField-3 SuperNIC in NVIDIAs Referenzarchitektur ist als „400GbE (default mode) /NDR IB“ aufgeführt; dieselbe Karte dient also beiden Fabrics.

Was NVIDIAs Referenzarchitektur RTX PRO AI Factory vorgibt

NVIDIAs Enterprise-Referenzarchitektur RTX PRO AI Factory, zuletzt aktualisiert am 18. Mai 2026, „basiert auf einer 2-8-5-200-Infrastrukturkonfiguration (2 CPUs, 8 GPUs, 5 NICs mit je 200 Gbit/s)“, mit bis zu acht Karten RTX PRO 6000 Blackwell Server Edition je Server. Von den fünf NICs bedienen vier BlueField-3 SuperNICs das Compute-Netzwerk (Ost-West) und eine BlueField-3 DPU das konvergente Netzwerk (Nord-Süd). Für das Compute-Netzwerk nennt die Architektur vier NICs mit 200 Gbit/s oder zwei mit 400 Gbit/s als Minimum und vier NICs mit 400 Gbit/s als Empfehlung, und ihre Scalable Units nutzen die empfohlenen vier.

Sie baut Cluster aus „Scalable Units (SU) auf Basis von 4 Compute-Knoten“. Je Scalable Unit hat das Compute-Netzwerk „16 Verbindungen mit 400 Gbit/s“, vier je Server, und das konvergente Netzwerk „8 Verbindungen mit 200 Gbit/s“, genutzt „für die Kommunikation der Knoten mit Compute sowie für Storage, In-Band-Management und Verbindungen der Endnutzer“. Ein Out-of-Band-Netzwerk mit 1 Gbit/s erreicht jeden Knoten. Die Fabric ist durchgehend Ethernet, mit Switches SN5610 mit 128 Ports zu 400 GbE.

Vier Server mit je acht Karten bilden eine Scalable Unit. Nach unserer Lesart trägt ihr Compute-Netzwerk keinen Inferenzverkehr, solange jeder Server eigene Replikate betreibt, und es lässt sich später ergänzen, wenn jedes Gehäuse PCIe-Steckplätze für die NICs frei hält. NVIDIAs Konfigurationsleitfaden schreibt: „NICs und NVMe-Laufwerke sollten am selben PCIe-Switch oder Root Complex wie die GPUs platziert werden“.

Laden der Modelle, Storage und das Management-Netzwerk

Modelldateien sind die größten Übertragungen in einem Cluster aus Replikaten. DeepSeek-V4-Flash-0731 umfasst 167 GB, also 1.335 Gbit. Bei voller Leitungsrate dauert das nach unserer Rechnung etwa 53 Sekunden bei 25 Gbit/s, 13 Sekunden bei 100 Gbit/s und unter 7 Sekunden bei 200 Gbit/s, bevor irgendetwas in den GPU-Speicher geladen wird. Jeder Neustart eines Replikats liest die Dateien erneut, deshalb hält unser Leitfaden zur Hochverfügbarkeit eine gepinnte Kopie auf lokalem NVMe in jedem Server.

Der Management-Controller gehört in ein separates Netzwerk. NVIDIAs Konfigurationsleitfaden verlangt einen Controller, der „kompatibel mit Redfish 1.0 (oder höher)“ ist, und die Referenzarchitektur bindet jeden Knoten mit 1 Gbit/s über Management-Switches mit 48 Ports an.

Das Ost-West-Netzwerk braucht eine eigene Isolation. vLLMs Sicherheitsdokumentation, aktualisiert am 9. Oktober 2026, stellt fest, dass „jede Kommunikation zwischen Knoten in einer Multi-Node-Bereitstellung von vLLM standardmäßig unsicher ist“ und „geschützt werden muss, indem die Knoten in ein isoliertes Netzwerk gelegt werden“, und dass „die Kommunikation zwischen Knoten standardmäßig unverschlüsselt ist“.

Ein Multi-Node-Setup mit vLLM vor der Inbetriebnahme prüfen

Wenn sich ein Modell über mehrere Server verteilt, bestätigen Sie vor jedem Lasttest, dass NCCL RDMA nutzt.

1. Installieren Sie auf jedem Server dasselbe Image; vLLM verlangt, dass „jeder Knoten eine identische Ausführungsumgebung bereitstellt, einschließlich des Modellpfads und der Python-Pakete“.
2. Setzen Sie VLLM_HOST_IP auf die Adresse jedes Servers im isolierten Ost-West-Netzwerk, NCCL_SOCKET_IFNAME auf diese Schnittstelle und NCCL_IB_HCA auf die RDMA-Adapter.
3. Prüfen Sie bei RoCE, dass jeder Switch zwischen den Servern denselben RoCE-Modus fährt, verlustfrei mit Priority Flow Control und ECN oder verlustbehaftet mit ECN.
4. Führen Sie den All-Reduce-Test aus NVIDIAs nccl-tests zwischen den Servern aus und vergleichen Sie die gemeldete Busbandbreite mit der Leitungsrate der NICs.
5. Starten Sie vLLM mit NCCL_DEBUG=TRACE und suchen Sie im Log nach „[send] via NET/IB/GDRDMA“; „[send] via NET/Socket“ bedeutet einfaches TCP, das vLLM „nicht effizient für Tensor-Parallelismus über Knoten hinweg“ nennt.

Aufbauten für zwei, drei und vier Server

Kartenzahlen aus unserem Leitfaden zur Hochverfügbarkeit (gpt-oss-120b bei 32K, 16-Bit-Cache, Spitze von 80 Anfragen in Bearbeitung); 25-GbE-Ports aus unserem 70B-Rechenbeispiel; Mindestwerte für das Netzwerk aus NVIDIAs Konfigurationsleitfaden (30. September 2026) und der Referenzarchitektur RTX PRO AI Factory (18. Mai 2026).

Vier Server lassen Raum, zwei davon einem großen Modell zu geben, während die anderen beiden Replikate betreiben, und nur die beiden Server, die sich ein Modell teilen, brauchen die RDMA-Fabric.

Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen, und Konfiguration und Angebot folgen innerhalb eines Werktages. Schicken Sie uns über das Formular unten die Modelle, die Spitzenzahl der Anfragen in Bearbeitung und die Zahl der Server.

Was wir liefern

Wir bauen KI-Server auf Bestellung mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern, montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente und Lieferung in die ganze EU. Zu den Karten gehören die RTX PRO 6000 Server Edition, die H200 NVL mit NVLink-Bridges, die L40S und die L4, und jeder Server kommt mit NICs für 25, 100, 200 oder 400G und Out-of-Band-Management, ausgelegt auf das Cluster-Muster. NVIDIA-AI-Enterprise- und vGPU-Lizenzen kommen unter demselben EU-Vertrag und auf dieselbe Rechnung. Die Plattform darüber, die Bereitstellung der Modelle on-premise mit vLLM auf einer Kubernetes-basierten Plattform, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ