Zwei DGX Sparks verbinden: QSFP, SSH, RoCE und Cluster Assistant

Ein DGX Spark ist ein leistungsfähiger Inferenzhost für einen einzelnen Knoten. NVIDIA sieht zwei über ConnectX-7 verbundene Sparks als Erweiterung für Modelle und Agenten-Workloads vor, die nicht in einen kohärenten Speicherpool mit 128 GB passen oder Tensor-Parallelität über mehrere Knoten benötigen.

Dieser Artikel folgt der offiziellen Clustering-Architektur von NVIDIA und dem connect-two-sparks-Playbook. Er ersetzt nicht die aktuelle Dokumentation am Tag der Verkabelung.

Primärquellen (hier starten):

• ConnectX-7 Networking / Clustering (DGX Spark User Guide)
• connect-two-sparks-Playbook
• NVIDIA Sync (Cluster Assistant)
• Produktkontext: DGX Spark · DGX Spark: was es ist · Praxis der lokalen Inferenz

Eine Neukonfiguration des Netzwerks kann einen Knoten isolieren oder den Verwaltungszugang unterbrechen. Stellen Sie einen nachweislich funktionierenden SSH-Zugang über die 10-GbE- beziehungsweise Management-Schnittstelle sicher, bevor Sie die Netplan-Konfiguration für ConnectX-7 ändern. Verwenden Sie freigegebene QSFP-Kabel und drücken Sie einen falsch ausgerichteten Stecker niemals mit Gewalt in den Port. Laut NVIDIA kann der Port dadurch beschädigt werden.

Was Sie bauen

Auf hoher Ebene:

1. Verbinden Sie die ConnectX-7-Ports der beiden Systeme physisch mit einem QSFP-Kabel. Dieser Verbindungspfad gehört zur 200-Gbit/s-Klasse; das Kabel muss mindestens 200 Gb/s unterstützen.
2. Weisen Sie den für diesen Port angezeigten Linux-Ethernet-Schnittstellen IP-Adressen zu. Jeder QSFP-Port entspricht zwei logischen Schnittstellen.
3. Verwenden Sie auf beiden Systemen denselben Benutzernamen.
4. Richten Sie passwortloses SSH zwischen den Knoten ein.
5. Führen Sie verteilte Workloads über die Hochgeschwindigkeitsverbindung aus, etwa NCCL-/RoCE-Verkehr für Inferenz oder Trainingsrezepte mit mehreren Knoten.

Das Playbook von NVIDIA enthält eigene Zeit- und Risikoschätzungen. Verstehen Sie diese als Planungshinweise des Herstellers, nicht als Zusage für Ihre Umgebung. Lesen Sie die aktuelle README vor der Änderung erneut, da sich Hinweise zu Schnittstellen und Voraussetzungen ändern können.

Voraussetzungen

Aus dem offiziellen Playbook:

Optional, aber nützlich: Eine zweite Person behält die SSH-Sitzungen für die Verwaltung im Blick. Halten Sie außerdem die Ausgabe von ip addr und ibdev2netdev vor der Änderung schriftlich fest.

Pfad A: NVIDIA Sync Cluster Assistant

Wenn Sie die Netplan-Konfiguration nicht vollständig manuell vornehmen möchten, bietet NVIDIA den NVIDIA Sync Cluster Assistant als geführten Weg an:

• Automatische Erkennung und Netzwerkerstellung für unterstützte Topologien.
• Anwendung der ConnectX-7-Einstellungen, Prüfung der Verbindungsleistung und SSH-Konfiguration zwischen den Knoten.
• Unterstützung für bis zu drei direkt per Kabel verbundene Sparks sowie bis zu vier bei Verwendung eines Switches, laut NVIDIA-Sync- und Clustering-Dokumentation.

Installieren Sie Sync auf Ihrem Laptop, fügen Sie die Sparks hinzu und verwenden Sie Cluster Assistant anstelle einer manuellen YAML-Bearbeitung, sofern Ihre Topologie unterstützt wird. Lesen Sie für die physischen Verkabelungsregeln, die Ausrichtung der linken und rechten Ports sowie die Hintergründe zur Benennung der Schnittstellen weiterhin ConnectX-7 Networking. Cluster Assistant verringert den manuellen Konfigurationsaufwand, ersetzt aber weder die richtigen Kabel noch einen Rollback-Plan.

Pfad B: Manuelles Playbook (connect-two-sparks)

1. Gleicher Benutzername

whoami

Wenn die Namen voneinander abweichen, legen Sie auf beiden Systemen einen Benutzer mit demselben Namen an. Das Beispiel im Playbook verwendet nvidia. Gewähren Sie diesem Benutzer sudo-Rechte und setzen Sie die Einrichtung unter diesem Konto fort. Rezepte für verteilte Workloads und Skripte für SSH-Schlüssel setzen übereinstimmende Benutzernamen voraus.

2. Physische QSFP-Verbindung

• Stecken Sie ein QSFP-Kabel zwischen die beiden Sparks.
• Verwenden Sie bei NCCL-orientierten Playbooks möglichst auf beiden Geräten dieselbe physische Portposition. NVIDIA weist darauf hin, dass eine konsistente Portwahl Testprobleme vermeiden kann.
• Richten Sie die Zuglasche nach oben aus und führen Sie den Stecker ohne Gewalt vollständig ein.
• Prüfen Sie den Verbindungsstatus mit ibdev2netdev. Die betreffenden Schnittstellen sollten Up anzeigen.

Jeder physische QSFP-Port erscheint als zwei Linux-Ethernet-Schnittstellen samt zugehörigen RoCE-Geräten. NVIDIAs Playbook verwendet für denselben physischen Port beispielsweise Namen wie enp1s0f1np1 und enP2p1s0f1np1. Die Namen auf Ihren Systemen können abweichen; maßgeblich ist die Ausgabe von ibdev2netdev auf Ihren Geräten.

Laut NVIDIAs Clustering-Dokumentation sind die QSFP-Ports des Spark für Ethernet konfiguriert. Verwenden Sie Kabel, die NVIDIA als geeignet für ≥200 Gb/s aufführt. Ein schnelleres Kabel erhöht die Obergrenze des Ports von 200 Gb/s nicht.

3. IP-Konfiguration

Das Playbook bietet:

• Option 1: netplan (/etc/netplan/40-cx7.yaml): bleibt nach einem Neustart erhalten; chmod 600; sudo netplan apply.
• Option 2: ip addr add: schneller für einen Test; die IP-Adressen bleiben nach einem Neustart nicht erhalten.

Beispiel für die Adressierung aus dem Playbook (passen Sie die Schnittstellennamen an die aktiven Schnittstellen Ihres Systems an):

Beide Adressen oben gehören zu den zwei logischen Schnittstellen desselben verkabelten Ports; eine Verbindung mit einem Kabel nutzt also bereits zwei Subnetze. Das Playbook von NVIDIA gibt an, dass die volle Bandbreite bereits mit einem einzigen QSFP-Kabel erreichbar ist, und NVIDIAs eigener Benchmark-Leitfaden für zwei Sparks misst die RoCE-Bandbreite über ein Kabel und summiert die beiden Verbindungen dieses Ports auf rund 190 Gb/s, also die Obergrenze des Ports von 200 Gb/s. Die einzige Aussage des Playbooks zu einem zweiten Kabel ist eine Konfigurationsanforderung: Sind zwei Kabel angeschlossen, müssen alle vier Schnittstellen IP-Adressen erhalten, um die volle Bandbreite zu erreichen. NVIDIA dokumentiert ein zweites Kabel zwischen denselben beiden Systemen nicht als Durchsatzgewinn. Planen Sie ein zweites Kabel deshalb als Topologie, also als dritten Knoten oder als geswitchtes Netz, nicht als zusätzliche Bandbreite für dasselbe Paar.

Prüfen Sie die Konfiguration mit ip addr show <iface> auf beiden Knoten, bevor Sie nach SSH-Fehlern suchen.

4. Passwortloses SSH

Automatisch: Führen Sie das discover-sparks-Skript des Playbooks auf einem Knoten aus, um die anderen Knoten zu erkennen und Schlüssel zu verteilen. Dabei werden Sie möglicherweise einmalig nach den Passwörtern gefragt.

Manuell: Übertragen Sie Ihren öffentlichen Schlüssel mit ssh-copy-id unter dem gemeinsamen Benutzernamen an die ConnectX-7-IP-Adressen beider Knoten.

Prüfen:

ssh <node1-cx7-ip> hostname
ssh <node2-cx7-ip> hostname

5. Verteilte Workloads und RoCE

Passwortloses SSH und L3-Erreichbarkeit bilden die Grundlage. Rezepte für Inferenz und Training auf mehreren Knoten nutzen anschließend den ConnectX-7-/RoCE-Pfad für kollektive Kommunikation, etwa mit NCCL. Wi-Fi 7 und der 10-GbE-RJ-45-Port sind nicht für diesen Cluster-Verkehr vorgesehen.

Die nächsten Schritte nach dem Herstellen der Verbindung finden Sie meist in anderen Playbooks, etwa für vLLM auf mehreren Knoten, NCCL-Tests oder bestimmte Modelle. Prüfen Sie die kollektive Kommunikation mit den von NVIDIA dokumentierten NCCL- und Clustering-Tests für Ihre Softwareversion, bevor Sie die Ursache beim Modellserver suchen.

Stolperstein bei Schnittstellennamen (vor dem Bearbeiten der YAML-Datei lesen)

NVIDIAs Clustering-Leitfaden erklärt, warum das ConnectX-7-Layout des Spark für Personen ungewohnt ist, die pro Netzwerkkarte eine Schnittstelle wie eth0 erwarten:

• Jeder QSFP-Port hat zwei PCIe-Pfade in den SoC.
• Linux stellt deshalb zwei Ethernet-Schnittstellen pro physischem Port sowie die zugehörigen RoCE-Geräte bereit.
• Die Beispiele aus dem Playbook (enp1s0f1np1, enP2p1s0f1np1, …) dienen nur zur Veranschaulichung. Ordnen Sie die Schnittstellen nach dem Einstecken des Kabels immer anhand von ibdev2netdev auf Ihrem Gerätepaar zu.

Wenn Netplan auf die Schnittstellen mit dem Status Down verweist und das aktive Paar ignoriert, suchen Sie möglicherweise lange am falschen Ort nach einem vermeintlichen Kabelfehler. Halten Sie bei der ersten Inbetriebnahme die Zuordnungstabelle aus der Clustering-Dokumentation neben Ihrem Terminal bereit.

Sicherheitshinweise für das CX7-Subnetz

Behandeln Sie die ConnectX-7-Verbindung als vertrauenswürdiges Clusternetz, nicht als Gast-WLAN:

• Binden Sie es nicht ohne sorgfältige Prüfung als Bridge an das Benutzer-VLAN eines Unternehmens an.
• Begrenzen Sie, welche Prozesse RPC-, NCCL- und Inferenzports an diese IP-Adressen binden dürfen.
• Denken Sie daran: Passwortloses SSH zwischen den Knoten ermöglicht weitreichende laterale Bewegungen, wenn eines der Systeme kompromittiert wird. Schützen Sie deshalb den physischen Zugang und die Betriebssystemkonten entsprechend.
• Verwenden Sie für die Verwaltung und menschliche SSH-Zugriffe weiterhin den dokumentierten Management-Pfad, damit ein CX7-Fehler nicht zum vollständigen Aussperren führt.

Risiko, Validierung und Rollback

Rollback-Konzept (NVIDIA-Playbook an den Host anpassen):

• Stellen Sie vor dem Editieren fest, ob /etc/netplan/40-cx7.yaml bereits existiert und ob eine andere Netplan-Datei dieselben Interfaces konfiguriert. Sichern Sie die betroffenen Dateien und notieren Sie Hashes, Eigentümer und Rechte.
• Entfernen Sie eine bereits vorhandene Datei nicht blind. Stellen Sie exakt die Dateien vor der Änderung wieder her, führen Sie sudo netplan generate aus, prüfen Sie das erzeugte Ergebnis und wenden Sie es dann über den bekannten guten Management-Pfad an.
• Löschen Sie bei temporären Adressen nur genau die Adressen, die in dieser Änderung hinzugefügt wurden, und prüfen Sie anschließend die Routen und den Verbindungsstatus.
• Halten Sie den Konsolenzugang oder einen unabhängigen Management-Zugang offen, bis beide Knoten die SSH- und Routing-Prüfungen nach dem Rollback bestehen.

Ein Rollback setzt das Clusternetzwerk zurück. Planen Sie dafür ein Änderungsfenster ein, wenn jemand vom Endpunkt mit mehreren Knoten abhängt. Vergewissern Sie sich, dass der SSH-Zugang für die Verwaltung weiterhin funktioniert, bevor Sie Konfigurationsdateien löschen.

Troubleshooting-Schnelltabelle

Die folgenden Symptome stammen aus NVIDIAs Playbook:

Was Sie noch nicht tun sollten

• Starten Sie kein produktives Modell mit Tensor-Parallelität, bevor die SSH- und Verbindungsprüfungen bestanden sind.
• Vermischen Sie keine Ad-hoc-IP-Adressen mit vergessenen Netplan-Dateien über mehrere Neustarts hinweg.
• Machen Sie das CX7-Subnetz nicht für nicht vertrauenswürdige Netze zugänglich.
• Drücken Sie QSFP-Stecker nicht mit Gewalt ein und verwenden Sie keine beliebigen DAC-Kabel, ohne zuvor die Hinweise zu Geschwindigkeit und Kompatibilität im Benutzerhandbuch zu prüfen.

Minimaler Abnahmetest

Bevor Sie Agenten mit einem Endpunkt auf mehreren Knoten verbinden:

1. Beide Knoten sind im CX7-Subnetz per Ping erreichbar.
2. Passwortloses SSH funktioniert unter dem gemeinsamen Benutzerkonto in beide Richtungen.
3. Ein dokumentierter NCCL- oder Playbook-Verbindungstest ist erfolgreich.
4. Die Knotenliste des Serving-Rezepts verwendet CX7-Adressen und keine WLAN-IP-Adressen.
5. Die genauen Schritte für Sicherung und Wiederherstellung wurden in einem Wartungsfenster getestet, ohne den Management-Pfad zu verlieren.

Zwei Sparks mit einer freigegebenen QSFP-Verbindung sind ein von NVIDIA dokumentiertes Muster. Die Befehle zur Inbetriebnahme und zum Rollback in diesem Artikel folgen der Herstellerdokumentation; sie sind kein zertifiziertes Ergebnis für Ihre Hardware, Verkabelung oder Softwareversionen. Behandeln Sie jede neue Inbetriebnahme des Clusternetzes als kontrollierte Netzwerkumstellung, erfassen Sie eigene Abnahmenachweise und berücksichtigen Sie die Grenzen aus der Praxis der lokalen Inferenz erst, nachdem das Clusternetz diese Prüfungen bestanden hat.