Relier deux DGX Sparks : QSFP, SSH, RoCE et Cluster Assistant

Un DGX Spark est un hôte d’inférence mono-nœud solide. Deux Sparks reliés via ConnectX-7, c’est la voie prévue par NVIDIA pour passer à des modèles et à des charges d’agents qui ne tiennent pas dans un pool mémoire cohérent de 128 Go — ou qui ont besoin d’un service tensor-parallel entre nœuds.

Cet article suit le schéma de clustering officiel de NVIDIA et le playbook connect-two-sparks. Cela ne remplace pas la documentation en ligne le jour où vous câblez les machines.

Sources principales (commencez ici) :

• ConnectX-7 Networking / clustering (guide utilisateur DGX Spark)
• playbook connect-two-sparks
• NVIDIA Sync (Cluster Assistant)
• Contexte produit : DGX Spark · ce qu’est Spark · réalité de l’inférence

Une reconfiguration réseau peut isoler un nœud ou casser l’accès de gestion. Travaillez depuis un chemin SSH réputé fonctionnel sur l’interface 10 GbE / de gestion avant de changer le netplan ConnectX-7. Utilisez des câbles QSFP approuvés ; ne forcez pas un connecteur mal orienté dans le port — NVIDIA documente que forcer peut endommager le port.

Ce que vous construisez

À haut niveau :

1. Connectez physiquement les deux unités avec un câble QSFP dans les ports ConnectX-7 (chemin de classe 200 Gbit/s ; le câble doit supporter au moins 200 Gbit/s).
2. Assignez des IP aux interfaces Ethernet Linux qui apparaissent pour ce port (chaque port QSFP correspond à deux interfaces logiques).
3. Utilisez le même nom d’utilisateur sur les deux systèmes.
4. Établissez le SSH sans mot de passe entre nœuds.
5. Exécutez des charges distribuées sur le chemin haute vitesse (trafic orienté NCCL et RoCE pour les recettes d’inférence ou d’entraînement multi-nœuds).

Le playbook NVIDIA publie ses propres estimations de durée et de risque. Traitez-les comme des notes de planification du constructeur, pas comme une promesse valable pour votre environnement. Relisez le README en ligne avant l’intervention, car les conseils d’interfaces et les prérequis peuvent changer.

Prérequis

D’après le playbook officiel :

Utile mais optionnel : une seconde personne qui surveille les sessions SSH de gestion, et une trace écrite de la sortie ip addr / ibdev2netdev avant changement.

Chemin A : NVIDIA Sync Cluster Assistant

Si vous souhaitez limiter le travail manuel sur netplan, NVIDIA documente NVIDIA Sync Cluster Assistant comme chemin guidé :

• Découverte automatique et création du réseau pour les topologies prises en charge.
• Applique les réglages ConnectX-7, vérifie les performances du lien, et configure SSH entre nœuds.
• Prend en charge jusqu’à trois Sparks connectés directement par câbles, et jusqu’à quatre avec un switch (selon les documentations NVIDIA Sync et clustering).

Installez Sync sur votre ordinateur portable, ajoutez les Sparks, puis utilisez Cluster Assistant plutôt que d’éditer le YAML à la main — si votre topologie est prise en charge. Pour les règles de câblage physique, l’orientation des ports gauche/droit et les explications de fond sur le nommage des interfaces, lisez quand même ConnectX-7 Networking. Cluster Assistant vous épargne la saisie ; il ne supprime pas le besoin de câbles corrects et d’un plan de rollback.

Chemin B : playbook manuel (connect-two-sparks)

1. Même nom d’utilisateur

whoami

Si les noms diffèrent, créez un utilisateur assorti (l’exemple du playbook utilise nvidia) sur les deux systèmes, accordez sudo, et continuez comme cet utilisateur. Les recettes distribuées et les scripts de distribution de clés SSH supposent des comptes identiques.

2. Connexion QSFP physique

• Branchez un câble QSFP entre les deux Sparks.
• Préférez la même position de port physique sur chaque appareil en suivant les playbooks orientés NCCL (NVIDIA signale que la cohérence des ports évite des problèmes lors des tests).
• Orientez la languette de retrait vers le haut ; insérez complètement sans forcer.
• Confirmez l’état du lien avec ibdev2netdev — attendez-vous à ce que les interfaces pertinentes montrent Up.

Chaque port QSFP physique apparaît comme deux interfaces Ethernet Linux (et autant de périphériques RoCE correspondants). Les noms d’exemple du playbook NVIDIA ressemblent à enp1s0f1np1 et enP2p1s0f1np1 pour le même port physique — vos noms peuvent différer ; faites confiance à ibdev2netdev sur vos unités.

Sur Spark, les ports QSFP sont configurés en Ethernet dans la documentation de clustering NVIDIA. Utilisez des câbles que NVIDIA indique comme adaptés à ≥200 Gbit/s. Des câbles plus rapides ne relèvent pas le plafond 200 Gbit/s du port.

3. Configuration IP

Le playbook propose :

• Option 1 — netplan (/etc/netplan/40-cx7.yaml) : persistant au redémarrage ; chmod 600 ; sudo netplan apply.
• Option 2 — ip addr add : plus rapide à essayer ; les IP ne survivent pas au redémarrage.

Schéma d’adressage d’exemple du playbook (ajustez les noms d’interfaces pour correspondre à vos interfaces Up) :

Les deux adresses ci-dessus appartiennent aux deux interfaces logiques du même port câblé : une liaison à un seul câble utilise donc déjà deux sous-réseaux. Le playbook de NVIDIA indique que la bande passante complète est atteignable avec un seul câble QSFP, et son propre guide d’évaluation des performances à deux Spark mesure la bande passante RoCE sur un seul câble et additionne les deux liens de ce port pour atteindre environ 190 Gb/s, soit le plafond de 200 Gb/s du port. La seule chose que le playbook indique au sujet d’un second câble est une exigence de configuration : si deux câbles sont connectés, les quatre interfaces doivent recevoir une adresse IP pour obtenir la bande passante complète. NVIDIA ne documente pas qu’un second câble entre les deux mêmes systèmes augmente le débit ; prévoyez donc un second câble comme une topologie — un troisième nœud, ou un réseau commuté — et non comme de la bande passante supplémentaire pour la même paire.

Vérifiez avec ip addr show <iface> sur les deux nœuds avant de déboguer SSH.

4. SSH sans mot de passe

Automatique : exécutez le script discover-sparks du playbook depuis un nœud pour découvrir les pairs et distribuer les clés (vous pouvez être invité une fois pour les mots de passe).

Manuel : ssh-copy-id de votre clé publique vers les IP ConnectX-7 des deux nœuds avec le nom d’utilisateur partagé.

Vérifiez :

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

5. Charges distribuées et RoCE

SSH sans mot de passe et joignabilité L3 sont le fondement. Les recettes d’inférence et d’entraînement multi-nœuds s’appuient ensuite sur le chemin ConnectX-7 / RoCE pour la communication collective (NCCL et similaires). N’attendez pas que le Wi-Fi 7 ou le port 10 GbE RJ-45 acheminent ce fabric.

Les étapes qui suivent la connectivité se trouvent généralement dans d’autres playbooks (vLLM multi-nœuds, tests NCCL, recettes modèles spécifiques). Validez les collectives avec les contrôles NCCL / clustering documentés NVIDIA pour votre version logicielle avant de mettre en cause le serveur de modèle.

Piège de nommage d’interfaces (lisez avant de taper le YAML)

Le guide de clustering NVIDIA explique pourquoi la disposition ConnectX-7 de Spark déroute les gens habitués à un NIC = un eth0 :

• Chaque port QSFP a deux chemins PCIe vers le SoC.
• Linux expose donc deux interfaces Ethernet par port physique, plus les appareils RoCE correspondants.
• Les exemples du playbook (enp1s0f1np1, enP2p1s0f1np1, …) sont des illustrations. Mappez toujours depuis ibdev2netdev sur votre paire après que le câble est en place.

Si le netplan référence les interfaces Down alors que la paire Up est ignorée, vous chasserez pendant une heure des fantômes de « câble défectueux ». Imprimez le tableau de correspondance du doc clustering à côté de votre terminal pour le premier démarrage.

Notes de sécurité pour le sous-réseau CX7

Traitez le lien ConnectX-7 comme un fabric de confiance, pas un Wi-Fi invité :

• Ne le pontez pas à la légère sur un VLAN utilisateurs de l’entreprise.
• Limitez les processus autorisés à ouvrir des ports RPC / NCCL / d’inférence sur ces adresses IP.
• Souvenez-vous que le SSH sans mot de passe entre nœuds est un mouvement latéral puissant si l’une des machines est compromise — protégez l’accès physique et les comptes OS en conséquence.
• Gardez les habitudes de gestion et de « SSH humain » sur le chemin de gestion documenté pour qu’une erreur sur CX7 ne se traduise pas par un verrouillage total.

Risque, validation et rollback

Conception du rollback (adaptez le playbook NVIDIA à votre hôte) :

• Avant toute édition, déterminez si /etc/netplan/40-cx7.yaml existe déjà et si un autre fichier netplan configure les mêmes interfaces. Sauvegardez les fichiers concernés et notez leurs empreintes, leur propriétaire et leurs permissions.
• Ne supprimez pas aveuglément un fichier préexistant. Restaurez exactement les fichiers d’avant le changement, lancez sudo netplan generate, inspectez le résultat généré, puis appliquez-le par le chemin de gestion réputé fonctionnel.
• Pour les adresses temporaires, ne supprimez que les adresses explicitement ajoutées lors de ce changement, et vérifiez les routes et l’état de lien qui en résultent.
• Conservez un accès console ou un accès de gestion indépendant jusqu’à ce que les deux nœuds passent les contrôles SSH et de routage post-rollback.

Le rollback réinitialise le réseau du cluster. Planifiez-le comme une fenêtre de changement si quelqu’un dépend du point de terminaison multi-nœuds. Confirmez que le SSH de gestion fonctionne encore avant de supprimer les configs.

Tableau de dépannage rapide

Tiré des symptômes du playbook NVIDIA :

Ne faites pas encore ceci

• Ne démarrez pas un modèle tensor-parallel de production avant que les contrôles SSH et de lien soient au vert.
• Ne mélangez pas des IP ad hoc et des fichiers netplan oubliés d’un redémarrage à l’autre.
• N’exposez pas le sous-réseau CX7 à des réseaux non fiables.
• Ne forcez pas les connecteurs QSFP et n’utilisez pas de câbles DAC pris au hasard sans vérifier les notes de vitesse/compatibilité du guide utilisateur.

Test d’acceptation minimal

Avant de pointer des agents vers un point de terminaison multi-nœuds :

1. Les deux nœuds joignables par ping sur le sous-réseau CX7.
2. SSH sans mot de passe dans les deux sens avec l’utilisateur partagé.
3. Contrôle NCCL ou de lien documenté par le playbook au vert.
4. La liste de nœuds de la recette de service utilise les adresses CX7, pas les IP Wi-Fi.
5. Étapes exactes de sauvegarde et de restauration testées en fenêtre de maintenance sans perdre le chemin de gestion.

Deux Sparks plus un chemin QSFP approuvé forment un schéma NVIDIA documenté. Les commandes de mise en service et de rollback de cet article suivent la documentation du constructeur ; elles ne constituent pas un résultat certifié pour votre matériel, votre câblage ou vos versions logicielles. Traitez toute nouvelle mise en service de fabric comme une bascule réseau sous contrôle de changement, constituez vos propres preuves d’acceptation, et ne gardez les contraintes de réalité de l’inférence en vue qu’une fois que le fabric a passé ces tests.