Forbind to DGX Sparks: QSFP, SSH, RoCE og Cluster Assistant

Én DGX Spark er en stærk inferensvært med én node. To Spark-enheder forbundet via ConnectX-7 er NVIDIAs vej til modeller og agentarbejdsbelastninger, som ikke kan være i én kohærent hukommelsespulje på 128 GB, eller som kræver tensorparallel servering på tværs af noder.

Artiklen følger NVIDIAs officielle model for klyngedannelse og vejledningen connect-two-sparks. Den erstatter ikke den aktuelle dokumentation den dag, du forbinder enhederne.

Primære kilder (start her):

• Netværk og klyngedannelse med ConnectX-7 i brugervejledningen til DGX Spark
• Vejledningen connect-two-sparks
• NVIDIA Sync (Cluster Assistant)
• Produktkontekst: DGX Spark · hvad Spark er · lokal inferens i praksis

En ændret netværkskonfiguration kan isolere en node eller afbryde administrationsadgangen. Arbejd via en SSH-forbindelse, som med sikkerhed fungerer på 10 GbE- eller administrationsgrænsefladen, før ConnectX-7-netplanen ændres. Brug godkendte QSFP-kabler, og tving ikke et forkert vendt stik ind i porten. NVIDIA dokumenterer, at tvang kan beskadige porten.

Hvad du bygger

På et højt niveau:

1. Forbind fysisk de to enheder med et QSFP-kabel i ConnectX-7-portene, en vej i 200 Gbps-klassen, hvor kablet skal understøtte mindst 200 Gb/s.
2. Tildel IP-adresser til de Linux-Ethernet-grænseflader, som porten opretter. Hver QSFP-port svarer til to logiske grænseflader.
3. Brug det samme brugernavn på begge systemer.
4. Etablér SSH uden adgangskode mellem noderne.
5. Kør distribuerede arbejdsbelastninger over højhastighedsvejen med NCCL-/RoCE-orienteret trafik til inferens på flere noder eller træningsopskrifter.

NVIDIAs vejledning offentliggør egne estimater for tid og risiko. Betragt dem som leverandørens planlægningsnoter, ikke som et løfte for dit miljø. Genlæs den aktuelle README før ændringen, fordi vejledningen om grænseflader og forudsætninger kan ændre sig.

Forudsætninger

Fra den officielle vejledning:

Valgfrit, men nyttigt: En anden person kan overvåge SSH-sessionerne til administration, og du kan gemme resultatet af ip addr og ibdev2netdev før ændringen.

Sti A: NVIDIA Sync Cluster Assistant

Hvis du vil reducere det manuelle arbejde med netplan, dokumenterer NVIDIA NVIDIA Sync Cluster Assistant som en guidet vej:

• Automatisk registrering og netværksoprettelse til understøttede topologier.
• Anvender ConnectX-7-indstillinger, kontrollerer forbindelsens ydelse og konfigurerer SSH mellem noderne.
• Understøtter op til tre Spark-enheder med direkte kabelforbindelse og op til fire ved brug af en switch ifølge dokumentationen til NVIDIA Sync og klyngedannelse.

Installér Sync på en bærbar computer, tilføj Spark-enhederne, og brug derefter Cluster Assistant i stedet for at redigere YAML manuelt, hvis topologien understøttes. Læs stadig netværksvejledningen til ConnectX-7 for regler om fysisk kabling, venstre/højre portretning og navngivning af grænseflader. Cluster Assistant reducerer indtastningen, men fjerner ikke behovet for korrekte kabler og en plan for tilbagerulning.

Vej B: Manuel vejledning med connect-two-sparks

1. Samme brugernavn

whoami

Hvis navnene er forskellige, skal du oprette en bruger med samme navn på begge systemer, vejledningens eksempel bruger nvidia, give brugeren sudo og fortsætte som denne bruger. Distribuerede opskrifter og scripts til SSH-nøgler forudsætter ens brugernavne.

2. Fysisk QSFP-forbindelse

• Sæt ét QSFP-kabel mellem de to Spark-enheder.
• Brug helst den samme fysiske portposition på begge enheder, når du følger NCCL-orienterede vejledninger. NVIDIA fremhæver ens portvalg for at undgå testproblemer.
• Vend træktappen opad, og sæt stikket helt i uden at bruge tvang.
• Kontrollér forbindelsestilstanden med ibdev2netdev. De relevante grænseflader bør vise Up.

Hver fysisk QSFP-port vises som to Linux-Ethernet-grænseflader samt tilsvarende RoCE-enheder. Eksempelnavne fra NVIDIAs vejledning er enp1s0f1np1 og enP2p1s0f1np1 for den samme fysiske port. Dine navne kan være anderledes; stol på resultatet fra ibdev2netdev på dine enheder.

QSFP-portene på Spark er konfigureret som Ethernet i NVIDIAs dokumentation om klyngedannelse. Brug kabler, som NVIDIA angiver som egnede til mindst 200 Gb/s. Hurtigere kabler hæver ikke portens grænse på 200 Gb/s.

3. IP-konfiguration

Vejledningen tilbyder:

• Mulighed 1 — netplan (/etc/netplan/40-cx7.yaml): bevares efter genstart; chmod 600; sudo netplan apply.
• Mulighed 2 — ip addr add: hurtigere at afprøve; IP-adresserne bevares ikke efter genstart.

Eksempel på adressering fra vejledningen, hvor navnene skal tilpasses de grænseflader, der viser Up:

Begge adresser ovenfor hører til de to logiske grænseflader på den samme tilsluttede port, så en forbindelse med ét kabel bruger allerede to undernet. NVIDIAs vejledning angiver, at fuld båndbredde kan opnås med blot ét QSFP-kabel, og NVIDIAs egen benchmarkvejledning til to Sparks måler RoCE-båndbredden over ét kabel og lægger portens to forbindelser sammen til cirka 190 Gb/s, altså portens grænse på 200 Gb/s. Vejledningens eneste udsagn om et ekstra kabel er et konfigurationskrav: er der tilsluttet to kabler, skal alle fire grænseflader have IP-adresser for at opnå fuld båndbredde. NVIDIA dokumenterer ikke et ekstra kabel mellem de samme to systemer som en forøgelse af gennemstrømningen, så planlæg et ekstra kabel som topologi, altså en tredje node eller et switchet netværk, ikke som ekstra båndbredde til det samme par.

Verificér med ip addr show <iface> på begge noder, før du fejlsøger SSH.

4. SSH uden adgangskode

Automatisk: Kør vejledningens discover-sparks-script fra én node for at finde de andre enheder og distribuere nøgler. Du kan blive bedt om adgangskoder én gang.

Manuelt: Brug ssh-copy-id til at kopiere den offentlige nøgle til begge noders ConnectX-7-IP-adresser med det fælles brugernavn.

Verificér:

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

5. Distribuerede arbejdsbelastninger og RoCE

SSH uden adgangskode og L3-forbindelse er fundamentet. Opskrifter til inferens og træning på flere noder bruger derefter ConnectX-7/RoCE til kollektiv kommunikation via NCCL og lignende. Forvent ikke, at Wi-Fi 7 eller 10 GbE RJ-45-porten kan bære dette højhastighedsnetværk.

De næste skridt efter etableret forbindelse findes normalt i andre vejledninger, for eksempel vLLM på flere noder, NCCL-tests og opskrifter til bestemte modeller. Validér den kollektive kommunikation med NVIDIAs dokumenterede NCCL- og klyngetjek for din softwareversion, før modelserveren får skylden.

Faldgruben ved navngivning af grænseflader: Læs dette før YAML redigeres

NVIDIAs vejledning om klyngedannelse forklarer, hvorfor Sparks ConnectX-7-layout kan forvirre personer, der er vant til én netværksadapter = én eth0:

• Hver QSFP-port har to PCIe-stier ind i SoC’en.
• Linux viser derfor to Ethernet-grænseflader pr. fysisk port samt tilsvarende RoCE-enheder.
• Eksemplerne i vejledningen (enp1s0f1np1, enP2p1s0f1np1, …) er kun illustrationer. Kortlæg altid ud fra ibdev2netdev på dine enheder, efter at kablet er tilsluttet.

Hvis netplan henviser til grænseflader, der viser Down, mens parret med Up ignoreres, kan du bruge lang tid på en ikke-eksisterende kabelfejl. Hav korrespondancetabellen fra dokumentationen om klyngedannelse ved siden af terminalen under den første idriftsættelse.

Sikkerhedsnoter til CX7-undernettet

Behandl ConnectX-7-forbindelsen som et betroet højhastighedsnetværk, ikke som gæste-Wi-Fi:

• Forbind det ikke uden videre til et virksomheds-VLAN for brugere.
• Begræns, hvilke processer der binder RPC-, NCCL- og inferensporte på de IP-adresser.
• Husk, at SSH uden adgangskode mellem noderne giver omfattende mulighed for lateral bevægelse, hvis én af maskinerne kompromitteres. Beskyt derfor fysisk adgang og operativsystemkonti tilsvarende.
• Bevar administrationsarbejde og menneskelig SSH på den dokumenterede administrationsvej, så en CX7-fejl ikke medfører fuldstændig udelukkelse.

Risiko, validering og tilbagerulning

Plan for tilbagerulning (tilpas NVIDIAs vejledning til værten):

• Før du redigerer noget, skal du fastslå, om /etc/netplan/40-cx7.yaml allerede findes, og om andre netplan-filer konfigurerer de samme grænseflader. Sikkerhedskopiér de relevante filer, og notér kontrolsummer, ejerskab og adgangsrettigheder.
• Slet ikke en eksisterende fil uden at kende dens formål. Gendan præcis de filer, der fandtes før ændringen, kør sudo netplan generate, gennemgå resultatet, og anvend det derefter via den administrationsvej, som du ved fungerer.
• Ved midlertidige adresser skal du kun slette de adresser, som udtrykkeligt blev tilføjet under denne ændring, og derefter kontrollere ruter og forbindelsestilstand.
• Bevar adgang via konsollen eller en uafhængig administrationsvej, indtil begge noder består SSH- og routingkontrollerne efter tilbagerulningen.

En tilbagerulning nulstiller klyngens netværkskonfiguration. Planlæg den i et ændringsvindue, hvis nogen er afhængige af endepunktet med flere noder. Bekræft, at SSH via administrationsvejen stadig fungerer, før du sletter konfigurationsfiler.

Hurtig tabel til fejlfinding

Tabellen bygger på symptomerne i NVIDIAs vejledning:

Gør ikke dette endnu

• Start ikke en tensorparallel model i produktion, før SSH- og forbindelseskontrollerne består.
• Bland ikke midlertidige IP-adresser med glemte netplan-filer på tværs af genstarter.
• Eksponér ikke CX7-undernettet for upålidelige netværk.
• Tving ikke QSFP-stik på plads, og brug ikke tilfældige DAC-kabler uden at kontrollere oplysningerne om hastighed og kompatibilitet i brugervejledningen.

Minimal acceptance test

Før du sender agenter til et endepunkt med flere noder:

1. Begge noder kan nås med ping på CX7-undernettet.
2. SSH uden adgangskode fungerer i begge retninger som den fælles bruger.
3. Den dokumenterede NCCL- eller forbindelseskontrol fra vejledningen består.
4. Nodelisten i serveringsopskriften bruger CX7-adresser, ikke Wi-Fi-adresser.
5. De præcise trin til sikkerhedskopiering og gendannelse er afprøvet i et vedligeholdelsesvindue uden at miste administrationsadgangen.

To Spark-enheder og en godkendt QSFP-forbindelse er et mønster, som NVIDIA dokumenterer. Kommandoerne til idriftsættelse og tilbagerulning i denne artikel følger leverandørens dokumentation, men udgør ikke en certificering af resultatet for din hardware, dine kabler eller softwareversioner. Behandl en ny højhastighedsforbindelse som en ændringsstyret netværksomlægning, indsaml din egen dokumentation for accepttesten, og tag først højde for begrænsningerne ved lokal inferens i praksis, når forbindelsen har bestået disse test.