Koppla samman två DGX Spark-enheter: QSFP, SSH, RoCE och Cluster Assistant

En DGX Spark är en kraftfull inferensvärd med en enda nod. NVIDIA ser två Spark-enheter länkade via ConnectX-7 som nästa steg för modeller och agentarbetslaster som inte ryms i en koherent minnespool på 128 GB eller som kräver tensorparallell inferens över flera noder.

Den här artikeln följer NVIDIAs officiella klusterarkitektur och handboken connect-two-sparks. Den ersätter inte den aktuella dokumentationen den dag du ansluter enheterna.

Primärkällor (börja här):

• ConnectX-7 Networking / klustring (DGX Spark User Guide)
• connect-two-sparks-playbook
• NVIDIA Sync (Cluster Assistant)
• Produktkontext: DGX Spark · vad Spark är · inferensrealitet

En omkonfigurering av nätverket kan isolera en nod eller bryta administratörsåtkomsten. Arbeta via en bekräftat fungerande SSH-anslutning på 10 GbE- eller administrationsgränssnittet innan du ändrar netplan för ConnectX-7. Använd godkända QSFP-kablar. Tvinga inte in en felvänd kontakt i porten; NVIDIA varnar för att porten då kan skadas.

Vad du bygger

På hög nivå:

1. Anslut de två enheterna fysiskt med en QSFP-kabel i ConnectX-7-portarna (en väg i 200 Gbps-klassen; kabeln måste klara minst 200 Gb/s).
2. Tilldela IP:er till Linux Ethernet-gränssnitten som dyker upp för den porten (varje QSFP-port mappar till två logiska gränssnitt).
3. Använd samma användarnamn på båda systemen.
4. Etablera lösenordsfri SSH mellan noder.
5. Kör distribuerade arbetsbelastningar över höghastighetsvägen (NCCL-/RoCE-orienterad trafik för multinodinferens eller träningsrecept).

NVIDIAs handbok innehåller egna tids- och riskuppskattningar. Behandla dem som leverantörens planeringsunderlag, inte som ett löfte för din miljö. Läs den aktuella README-filen på nytt före ändringen, eftersom vägledningen om gränssnitt och förutsättningarna kan ändras.

Förutsättningar

Från den officiella handboken:

Valfritt men användbart: en andra person som bevakar SSH-sessionerna för administration samt en sparad anteckning med utdata från ip addr och ibdev2netdev före ändringen.

Väg A: NVIDIA Sync Cluster Assistant

Om du vill minska det manuella arbetet med netplan beskriver NVIDIA NVIDIA Sync Cluster Assistant som en guidad väg:

• Automatisk upptäckt och nätverksskapande för stödda topologier.
• Tillämpar ConnectX-7-inställningar, kontrollerar länkprestanda och konfigurerar SSH mellan noder.
• Stöder upp till tre Spark-enheter kopplade direkt med kablar, och upp till fyra när en switch används (enligt NVIDIA Sync-/klustringsdokumentation).

Installera Sync på din bärbara dator, lägg till Spark-enheterna och använd sedan Cluster Assistant i stället för att redigera YAML för hand, om din topologi stöds. Läs ändå ConnectX-7 Networking för regler om fysisk kabeldragning, vänster och höger port samt bakgrunden till gränssnittsnamnen. Cluster Assistant minskar skrivandet, men tar inte bort behovet av rätt kablar och en återställningsplan.

Väg B: Manuell handbok (connect-two-sparks)

1. Samma användarnamn

whoami

Om namnen skiljer sig skapar du en användare med samma namn på båda systemen (handbokens exempel använder nvidia), ger användaren sudo-behörighet och fortsätter som den användaren. Distribuerade recept och SSH-nyckelskript förutsätter att namnen är identiska.

2. Fysisk QSFP-anslutning

• Koppla en QSFP-kabel mellan de två Spark-enheterna.
• Använd helst samma fysiska portposition på båda enheterna när du följer NCCL-inriktade handböcker (NVIDIA rekommenderar konsekvent portval för att undvika testproblem).
• Vänd dragfliken uppåt och för in kontakten hela vägen utan att använda våld.
• Bekräfta länktillstånd med ibdev2netdev — förvänta dig att relevanta gränssnitt visar Up.

Varje fysisk QSFP-port syns som två Linux Ethernet-gränssnitt (och motsvarande RoCE-enheter). Exempelnamn från NVIDIAs handbok ser ut som enp1s0f1np1 och enP2p1s0f1np1 för samma fysiska port. Dina namn kan skilja sig; lita på ibdev2netdev på dina enheter.

QSFP-portar på Spark är Ethernet-konfigurerade i NVIDIAs klustringsdokumentation. Använd kablar NVIDIA listar som lämpliga för ≥200 Gb/s. Snabbare kablar höjer inte portens 200 Gb/s-tak.

3. IP-konfiguration

Handboken erbjuder:

• Alternativ 1 — netplan (/etc/netplan/40-cx7.yaml): beständigt över omstart; chmod 600; sudo netplan apply.
• Alternativ 2 — ip addr add: snabbare att prova; IP:er överlever inte omstart.

Exempel på adressmönster från handboken (anpassa gränssnittsnamnen så att de motsvarar de gränssnitt som visar Up):

Båda adresserna ovan hör till de två logiska gränssnitten på samma kabelanslutna port, så en länk med en kabel använder redan två subnät. NVIDIAs handbok anger att full bandbredd kan uppnås med en enda QSFP-kabel. I den tillhörande prestandamätningsguiden för två Spark-enheter mäts RoCE-bandbredden över en kabel och de två länkarna på porten summeras till cirka 190 Gbit/s, nära portens gräns på 200 Gbit/s. Om två kablar ansluts säger handboken endast att alla fyra gränssnitt måste få IP-adresser för att full bandbredd ska nås. NVIDIA dokumenterar inte att en andra kabel mellan samma två system ökar genomströmningen. Planera därför den andra kabeln för nätverkstopologin, till exempel en tredje nod eller ett switchat nät, inte som extra bandbredd för samma par.

Verifiera med ip addr show <iface> på båda noderna innan du felsöker SSH.

4. Lösenordsfri SSH

Automatiskt: kör handbokens discover-sparks-skript från en nod för att hitta de andra noderna och distribuera nycklar (du kan behöva ange lösenorden en gång).

Manuellt: kopiera din publika nyckel med ssh-copy-id till båda nodernas ConnectX-7-IP:er med det delade användarnamnet.

Verifiera:

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

5. Distribuerade arbetsbelastningar och RoCE

Lösenordsfri SSH och L3-nåbarhet är grunden. Multinodinferens- och träningsrecept förlitar sig sedan på ConnectX-7-/RoCE-vägen för kollektiv kommunikation (NCCL och liknande). Förvänta dig inte att Wi-Fi 7 eller 10 GbE RJ-45-porten bär den trafiken.

Nästa steg efter att anslutningen fungerar finns vanligtvis i andra handböcker (vLLM för flera noder, NCCL-tester och specifika modellrecept). Validera de kollektiva operationerna med NVIDIAs dokumenterade NCCL- och klusterkontroller för din programvaruversion innan du skyller på modellservern.

Fallgrop med gränssnittsnamn (läs innan du skriver YAML)

NVIDIAs klustringsguide förklarar varför Spark-enhetens ConnectX-7-layout förvirrar personer vana vid en NIC = en eth0:

• Varje QSFP-port har två PCIe-vägar in i SoC:n.
• Linux exponerar därför två Ethernet-gränssnitt per fysisk port, plus motsvarande RoCE-enheter.
• Exemplen i handboken (enp1s0f1np1, enP2p1s0f1np1, …) är illustrationer. Utgå alltid från ibdev2netdev på ditt par när kabeln sitter på plats.

Om netplan hänvisar till gränssnitt som visar Down medan Up-paret ignoreras kan du ägna en timme åt att felsöka en kabel som inte är trasig. Ha korrespondenstabellen från klustringsdokumentationen bredvid terminalen när du startar länken första gången.

Säkerhetsanteckningar för CX7-subnätet

Behandla ConnectX-7-länken som ett betrott internt nät, inte som gäst-Wi-Fi:

• Brygga inte ihop den slarvigt med ett användar-VLAN i företagsnätet.
• Begränsa vilka processer som binder RPC-/NCCL-/inferensportar på de IP:erna.
• Kom ihåg att lösenordsfri SSH mellan noder ger en angripare stor möjlighet att röra sig i sidled om någon av enheterna komprometteras. Skydda därför fysisk åtkomst och operativsystemkonton.
• Sköt administration och vanliga SSH-sessioner via den dokumenterade administrationsvägen, så att ett CX7-fel inte låser ute dig helt.

Risk, validering och återställning

Återställningsplan (anpassa NVIDIAs handbok till din värd):

• Ta reda på före redigeringen om /etc/netplan/40-cx7.yaml redan finns, och om någon annan netplan-fil konfigurerar samma gränssnitt. Säkerhetskopiera de berörda filerna och notera hashar, ägarskap och behörigheter.
• Ta inte bort en redan befintlig fil utan kontroll. Återställ exakt de filer som gällde före ändringen, kör sudo netplan generate, granska det genererade resultatet och tillämpa det sedan via den bekräftat fungerande administrationsvägen.
• För tillfälliga adresser: ta bara bort de adresser som uttryckligen lades till i den här ändringen, och verifiera de rutter och det länktillstånd som blir resultatet.
• Behåll konsolåtkomst eller annan oberoende administratörsåtkomst tills båda noderna klarar SSH- och routningskontrollerna efter återställningen.

Vid återställning nollställs klusternätverket. Schemalägg den i ett ändringsfönster om någon är beroende av slutpunkten med flera noder. Bekräfta att SSH för administration fortfarande fungerar innan du raderar konfigurationer.

Snabbtabell för felsökning

Sammanställd utifrån symptomen i NVIDIAs handbok:

Gör inte det här ännu

• Starta inte en tensor-parallell modell i produktion innan SSH- och länkkontrollerna är godkända.
• Blanda inte ad hoc-IP:er med glömda netplan-filer över omstarter.
• Exponera inte CX7-subnätet mot otillförlitliga nätverk.
• Tvinga inte in QSFP-kontakter och använd inte slumpvis valda DAC-kablar utan att kontrollera anteckningarna om hastighet och kompatibilitet i användarhandboken.

Minimalt acceptanstest

Innan du pekar agenter mot en multinodslutpunkt:

1. Båda noderna kan nås med ping på CX7-subnätet.
2. Lösenordsfri SSH i båda riktningarna som den delade användaren.
3. Den dokumenterade NCCL- eller länkkontrollen från handboken är godkänd.
4. Inferensreceptets nodlista använder CX7-adresser, inte Wi-Fi-IP-adresser.
5. De exakta stegen för säkerhetskopiering och återställning har testats i ett underhållsfönster utan att administratörsåtkomsten förlorats.

Två Spark-enheter och en godkänd QSFP-väg är ett dokumenterat NVIDIA-mönster. Kommandona för uppstart och återställning i den här artikeln följer leverantörens dokumentation; de är inget certifierat resultat för din hårdvara, dina kablar eller dina programversioner. Behandla varje första start av ett nytt internt nät som en förändringsstyrd nätverksomläggning, samla egna acceptansbelägg och beakta begränsningarna i inferensrealitet först när nätet har klarat testerna.