AI Cluster Network Design: Spine-Leaf, RoCE & NIC'er

AI-klyngenetværksdesign er processen med dimensionering af GPU-server-NIC'er, blad-spine-båndbredde, overabonnementsforhold, RoCE-indstillinger, optik og kabler, så distribueret træningstrafik forbliver forudsigelig, efterhånden som klyngen skaleres. Hvis nogen af ​​​​disse fejler, bliver netværket - ikke GPU'en - flaskehalsen.

Hvorfor AI Cluster Networking er anderledes

I et traditionelt virksomhedsdatacenter håndterer netværket en blanding af nord-syd brugertrafik, lageradgang, virtualisering og administration. Øst-vesttrafik findes, men er sjældent den dominerende belastning. I en AI-klynge vender situationen. GPU-servere, der kører distribueret træning, udveksler gradienter og synkroniserer parametre under hvert trin af jobbet. Denne kommunikation er en del af beregningen, ikke en bivirkning af den.

Hvis en GPU på 30.000 USD bruger 30 % af sin tid på at vente på netværket under alle-reducerende operationer, betaler klyngen reelt for 30 % af sin computerkapacitet for at være inaktiv. Det er den økonomiske årsag til, at AI-netværk får så meget opmærksomhed.

Tre arbejdsbelastningskarakteristika driver designet:

• Sprængfyldt øst-vesttrafik.Kollektive kommunikationsoperationer som alle-reducerer, alle-samler og reducerer-spredning producerer synkroniserede bursts på tværs af mange noder samtidigt.
• Hale-latensfølsomhed.En enkelt langsom knude forsinker hele træningstrinnet. Forudsigelig latenstid betyder mere end gennemsnitlig latenstid.
• Udskaler-vækst.Klynger, der starter ved 32 GPU'er, vokser ofte til 256 eller 1.024 inden for 18 måneder. Stoffet skal skalere uden redesign.

Hvorfor Spine-Leaf passer til AI-klynger

Spine-leaf er standardstoffet til hyperskala datacentre, fordi det giver hver server-til-serversti det samme hoptal og den samme teoretiske båndbredde. For AI-arbejdsbelastninger udmønter denne ensartethed sig direkte til mere forudsigelige træningstrintider.

I en -bladtopologi forbinder GPU-servere til bladswitche, og hvert blad forbindes til hver rygsøjle. Enhver GPU-til-GPU-kommunikation krydser præcis ét blad, én ryg og ét blad mere. Der er ingen aggregeringslag, der introducerer variabel latenstid eller chokepoints.

Forudsigelig latens

Equal-cost multi--routing (ECMP) spreder strømme på tværs af spine switches. Når det er konfigureret korrekt med adaptiv routing eller dynamisk belastningsbalancering, forhindrer dette hash-kollisioner, der får nogle flows til at være meget langsommere end andre - et kendt problem i statiske ECMP-stoffer, der bærer få men store flow, hvilket er præcis, hvad AI-træning genererer.

Høj halveringsbåndbredde

Bisektionsbåndbredde er den tilgængelige gennemstrømning mellem to lige store halvdele af klyngen. AI-træning drager fordel af ikke-blokerende eller næsten-ikke-blokerende designs, hvor blad-til-spin uplinkkapaciteten er lig med eller næsten lig med downlinkkapaciteten mod serverne. IETF definerer og diskuterer disse begreber iRFC 7938, som dækker BGP-rutede Clos-stoffer, der er meget udbredt i store-datacentre.

Nemmere udskalering-

Tilføj flere blade for at tilføje flere servere. Tilføj flere rygsøjler for at tilføje mere halveringsbåndbredde. For klynger ud over et par tusinde GPU'er udvider en super-spine (5-Clos) eller skinneoptimeret topologi det samme princip et lag længere.

Kernekomponenter i et AI-klyngenetværk

GPU-servere og NIC'er

NIC er der, hvor stoffet møder værten. I AI-klynger driver NIC-valg alt nedstrøms - switch-porthastighed, optikvalg og kabeltæthed.

Udvælgelseskriterier for AI-arbejdsbelastninger:

• Porthastighed:200G, 400G eller 800G pr. port. Match til GPU-generering og PCIe-båndbredde.
• PCIe generation:En 400G NIC har brug for PCIe Gen5 x16 for at undgå host-sidegasregulering. PCIe Gen4 x16 caps ved ~256 Gbps kan bruges.
• RDMA og RoCEv2 support:Påkrævet for kerne-omgå GPU-kommunikationsbiblioteker som NCCL.
• GPUDirect RDMA:Tillader direkte GPU-til-NIC DMA, fjerner værtshukommelseskopier.
• Multi-skinnekapacitet:Mange AI-servere bruger 4 eller 8 NIC'er pr. node, én pr. GPU-par, til jernbaneoptimerede-topologier.

En typisk 8-GPU-server bruger i dag enten 4× 400G NIC'er (én pr. to GPU'er) eller 8× 400G NIC'er (én pr. GPU) afhængig af arbejdsbyrde og budget. Referencearkitekturer fraNVIDIA-netværksdokumentationdække designafvejningerne i detaljer.

Blad- og Rygsøjleafbrydere

Switchudvælgelseskriterier for AI-stoffer adskiller sig fra virksomhedsvalg. Bufferstørrelse, overbelastningskontrol og telemetri betyder mere end funktionsbredden.

• Per-porthastighed og radix:En 51,2 Tbps switch ASIC leverer 64× 800G-porte eller 128× 400G-porte. Radix bestemmer, hvor fladt stoffet kan være.
• Buffer arkitektur:Dybe buffere absorberer incast bursts, men tilføjer latens. Lave buffere reducerer latenstiden, men kræver præcis overbelastningskontrol.
• RoCE funktionssæt:ECN-mærkning, PFC, DCQCN eller tilsvarende overbelastningskontrol og korrekt håndtering af prioritetskøer ende-til-ende.
• Telemetri:Inband network telemetri (INT), pr-kødybderapportering og mikrosekund-opløsningstællere for ECN-mærker og PFC-pauser.

Optik, DAC og AOC kabling

Ved 400G og 800G bliver kabelanlægget et reelt ingeniørproblem. Formfaktorer, linkbudgetter og breakout-konfigurationer kræver alle tidlig planlægning.

• DAC (Direct Attach Copper):Op til ~3 meter for 400G, laveste pris og laveste effekt. Tung og omfangsrig i skalaen.
• AOC (aktivt optisk kabel):Op til ~30 meter, tyndere end DAC, men fast-længde og forbruger optisk strøm i begge ender.
• Stikbar optik:Påkrævet ud over AOC-afstand. QSFP-DD- og OSFP-formfaktorer dominerer 400G/800G. MPO/MTP-fibersamlinger håndterer de parallelle-fiberforbindelser.

For inter-racklinks og struktureret kabling ved 400G/800G er paralleloptik over MPO-termineringer nu standard. Valget mellem trunkabler og breakout-samlinger afhænger af din switchport-allokering - se voresMPO breakout kabel guidefor den praktiske udvælgelseslogik, og den bredereMPO trunk vs breakout sammenligningnår du planlægger blad-til-rygløb.

RoCE og Lossless Ethernet i AI Fabrics

RoCEv2 (RDMA over Converged Ethernet v2) er den dominerende Ethernet-transport for AI-arbejdsbelastninger. Det giver NIC'er mulighed for at flytte data direkte mellem GPU-hukommelsesregioner uden kerne involvering i begge ender. NCCL, GPU-kommunikationsbiblioteket, der ligger til grund for næsten alle distribuerede træningsrammer, bruger RoCEv2, når InfiniBand ikke er tilgængelig.

RoCE fungerer godt, når den er konfigureret korrekt. Det fejler grimt, når det er konfigureret forkert. DeInfiniBand Trade Associationudgiver RoCE-specifikationerne, og de fleste NIC- og switch-leverandører udgiver detaljerede konfigurationsvejledninger, som bør følges fra ende -til-.

Hvorfor tabsfri adfærd betyder noget

RDMA blev designet under forudsætning af en tabsfri transport. Når pakker falder, er RDMA-gendannelse dyrt - gå-tilbage-N-gentransmission kan stoppe et træningstrin i millisekunder, hvilket er enormt i forhold til RDMA-budgettet for mikrosekunders-skala.

For at tilnærme tabsfri adfærd på Ethernet bruger stoffet to mekanismer, der arbejder sammen:

• PFC (Priority Flow Control, IEEE 802.1Qbb):En switch sætter indgående trafik på pause på en specifik prioritetskø, når dens buffer fyldes. Dette er en sidste-udvejsmekanisme.
• ECN (Explicit Congestion Notification, RFC 3168):Skifter mærkepakker, når køer nærmer sig en tærskel. NIC reducerer sin afsendelseshastighed, før buffere rent faktisk fyldes, hvilket ideelt set undgår PFC helt.

Målet er, at ECN skal klare næsten al trængselshåndtering med PFC som sikkerhedsnet. Hvis du ser hyppige PFC-pauser i konstant-trafik, er dine ECN-tærskler forkerte, eller dit stof er underdimensioneret.

Almindelige RoCE-implementeringsfejl

Sådan designes et AI Cluster Network: A Working Framework

Dette er det afsnit, de fleste "AI-netværk"-artikler springer over. De syv trin nedenfor giver dig konkrete input og output på hvert trin.

Trin 1: Definer arbejdsbyrde og skala

Indgange:Arbejdsbelastningstype (fortræning, finindstilling,-inferens, blandet), mål-GPU-antal i dag, mål-GPU-antal om 18 måneder, modelstørrelsesinterval.

Produktion:En arbejdsbelastningsprofil, der informerer NIC-hastighed og overabonnementstolerance. Stor fortræning af grænsemodeller kræver ikke-blokerende 400G+-stoffer. Finjusterende-arbejdsbelastninger kan tolerere 2:1 overabonnement. Inferensklynger har ofte brug for lavere båndbredde, men lavere halelatens.

Trin 2: Vælg NIC-hastighed og antal pr. server

Beslutningslogik:

• Fortræning af store modeller, 8-GPU-servere → 4–8× 400G NIC'er pr. server eller 4×800G
• Mid-træning, 8-GPU-servere → 2–4× 400G NIC'er pr. server
• Inferensvisning → 1–2× 200G eller 400G NIC'er pr. server, afhængig af modelparallelisme

Bekræft PCIe-båndbredden på værten. En enkelt 400G-port kræver PCIe Gen5 x16 for at køre med linjehastighed; fordobling til 800G kræver Gen6 eller opdeling på to slots.

Trin 3: Størrelse på bladlaget

Bearbejdet eksempel på - 32-node-klynge, 8 GPU'er pr. node, 4× 400G NIC'er pr. node:

• Samlet behov for server-vendte porte: 32 × 4=128 porte ved 400G
• Downlinkbåndbredde pr. node: 4 × 400=1.6 Tbps
• Samlet klynge downlink-båndbredde: 32 × 1.6=51.2 Tbps

Ved at bruge en 64-ports 400G leaf switch (25,6 Tbps total kapacitet), kan hver leaf forbinde 32 serverporte og bruge de resterende 32 porte som uplinks. Med 4 blade dækker du alle 128 serverporte. Hvert blad bidrager med 32 × 400 G=12.8 Tbps uplink mod rygsøjlen.

Trin 4: Størrelse på ryglaget

For et ikke-blokerende (1:1) design skal den samlede uplinkkapacitet svare til den samlede downlinkkapacitet. Fra trin 3:

• Samlet blad uplink påkrævet: 4 blade × 12,8 Tbps=51.2 Tbps
• Hvis hver rygrad har 32× 400G-porte=12.8 Tbps, skal du bruge 4 spines
• Hvert blad forbindes til alle 4 rygsøjler ved hjælp af 8 uplinks pr. ryg (8 × 400G × 4=12.8 Tbps pr. blad - matcher)

Hvis du bruger 64-ports 400G-switche, har hver rygsøjle ledig kapacitet til at vokse klyngen, hvilket er nyttigt for 18-måneders planen fra trin 1.

Trin 5: Indstil Oversubscription Ratio

Trin 6: Adskil beregnings-, lager- og administrationstrafik

Tre muligheder, i rækkefølge for øget isolation:

• Delt stof med QoS-klasser:Beregning, lagring og administration på separate DSCP-prioriteter. Laveste omkostninger; kræver omhyggelig QoS-konfiguration.
• Logisk adskilte VLAN'er/VRF'er:Samme hardware, separate kontrolplaner. Nyttigt til klynger med flere-lejere.
• Fysisk adskilte stoffer:Dedikerede NIC'er, switche og kabler til computer vs. storage. Højeste omkostninger; almindelig i grænse-modelklynger, hvor enhver påstand er uacceptabel.

Lagertrafik til kunstig intelligens er i sig selv tung - kontrolpunktsskrivninger for en stor model kan flytte hundredvis af gigabyte i korte stød. Planlæg det eksplicit. Et struktureret kabelanlæg med høj-densitet, der brugerMPO/MTP trunk kablerforenkler at køre parallelt stof i den samme fysiske infrastruktur.

Trin 7: Valider før produktion

Tests på netværks-niveau fanger nogle problemer. Tests på arbejdsbelastningsniveau- fanger resten.

• Båndbredde:iperf3 eller ib_send_bw mellem hvert nodepar; bør nå 90%+ af NIC-linjehastigheden.
• Latency:ib_read_lat eller lignende; check distribution, ikke kun gennemsnit. P99.9 betyder mere end gennemsnittet.
• Pakketab:Kør 24-timers iblødsætningstest under belastning; ethvert ikke-nul tab i RoCE trafikklasse er et problem.
• ECN-mærkningsadfærd:Kontroller, at der vises mærker, før PFC udløses; hvis PFC-pauser er hyppige i steady state, genindstil.
• Kollektiv kommunikation:Kør NCCL-tests (all_reduce_perf, all_gather_perf) ved den fulde klyngestørrelse. Sammenlign med leverandørens referencenumre.
• Job-test:Kør et repræsentativt træningsjob i 4-6 timer. Se GPU-udnyttelse - vedvarende værdier under 50 % på en model i korrekt-størrelse indikerer normalt et netværksproblem.

Traditionelt datacenternetværk vs AI Ryg-Løvstof

Ethernet RoCE vs InfiniBand: Hurtig beslutningsvejledning

Spørgsmålet kommer op i næsten alle AI-klyngeprojekter. Begge virker. Valget kommer normalt ned til operationel pasform, ikke ren ydeevne.

• Vælg InfiniBand hvis:Dit team driver allerede InfiniBand-stoffer, du vil have den enkleste vej til tabsfri transport, eller du køber en fuldt-integreret leverandørreferencearkitektur.
• Vælg Ethernet RoCE hvis:Dit driftsteam er Ethernet-native, du vil have multi-leverandørswitchmuligheder, du skal integrere AI-strukturen med eksisterende datacenternetværk, eller du forventer skalering ud over, hvad de nuværende InfiniBand-topologier understøtter rent.

Ultra Ethernet-konsortiet, der blev dannet i 2023, arbejder aktivt på at standardisere Ethernet-forbedringer specifikt til AI-arbejdsbelastninger. For de fleste nye klynger i 2026 er Ethernet RoCE en forsvarlig standard, medmindre der er en specifik grund til at vælge andet.

Almindelige fejl at undgå

Opgradering af switche uden at tjekke NIC'er

Et 800G switch-stof gør intet for dig, hvis dine NIC'er kører ved 400G, eller din værts-PCIe løber tør for båndbredde. Design værtssiden først, derefter kontaktsiden. PCIe Gen5 x16 begrænser en enkelt port til ca. 504 Gbps i den virkelige-verdensgennemstrømning - behagelig for 400G, marginal for 800G.

Optimering af porthastighed, men ignorerer kabeltæthed

Ved 64-porte 400G kan kablerne under hver switch blive fysisk uoverskuelige uden planlægning. Brug breakout-kabler, hvor det er relevant, før fibre gennem strukturerede veje, og standardiser på konnektortyper. Stikkvalitet og afslutning betyder noget ved høje hastigheder - voresfiberoptiske stiktyper guidedækker afvejningen mellem LC, MPO og nye formfaktorer med høj-densitet.

Behandler RoCE som Plug-and-Play

Den største designfejl i rigtige AI-klynger er ikke at vælge den forkerte kontakt - det undervurderer, hvor meget ende-til-afslut RoCE-konfigurationsarbejde, der kræves. Budgettid til tuning af ECN-tærskler, PFC-prioriteter og MTU-konsistens. Planlæg en dedikeret valideringsfase, før en produktionsbelastning kører.

Blanding af al trafik på ét stof uden QoS

Lagerreplikering, overvågningsagenter og administrationstrafik kan ødelægge træningstrintider, hvis de deler buffere med computertrafik. Enten adskille dem fysisk eller håndhæve strenge QoS-klasser med separate prioriteter og ECN-konfiguration.

Bygning kun til dagens klynge

De fleste AI-klynger vokser 4-8× inden for to år efter den første implementering. Vælg omskifterradix og rygsøjlekapacitet, der tillader ikke-forstyrrende udvidelse. Det er dyrt at trække kabler i et live AI-datacenter; planlægningskanal- og patchkapacitet på implementeringstidspunktet er billig.

Hvornår skal man gå op fra 400G til 800G

800G NIC'er og switche er tilgængelige, men dyrere pr. port. Overvej at gå op, når:

• Per-GPU-båndbreddebehov overstiger, hvad 400G kan give -, for eksempel forventer H100 og nyere GPU'er med NVLink 5 højere ekstern båndbredde
• NCCL alle-reducerer tidsskalaen dårligt med klyngestørrelsen, hvilket indikerer netværksmætning
• Kabeltæthed ved 400G bliver fysisk uoverskuelig - færre 800G-porte kan erstatte flere 400G-porte
• Den næste GPU-generation i din køreplan forventes at få brug for den inden for klyngens afskrivningsvindue
• Du er ved at opbygge en grænseoverskridende-modeltræningsklynge, hvor enhver inaktiv computertid koster væsentligt mere end optikopgraderingen

For de fleste produktionsklynger i 2026 forbliver 400G den rette balance mellem omkostninger, økosystemmodenhed og kapacitet. 800G giver mening i den høje ende og som en fremadrettet investering for klynger, der bygges i dag og forventes at køre i 4-5 år.

Konklusion

Det stærkeste AI-klyngenetværk er ikke det med de hurtigste switches. Det er den, hvor NIC-valg, blad/rygsøjlestørrelse, overabonnement, RoCE-konfiguration, trafikadskillelse og fysisk kabelføring alle understøtter hinanden og den arbejdsbyrde, de blev valgt til.

Start fra arbejdsbyrden og 18-måneders vækstplan. Beregn båndbreddebehov på hvert lag ved hjælp af reelle tal, ikke kun tommelfingerregler. Konfigurer RoCE end-til-ende og valider med ægte kollektive kommunikationsbenchmarks. Budget for kabelanlægget - ved 400G og 800G er det fysiske lag ikke længere trivielt.

Klyngen, der holder sine GPU'er beskæftiget med 95 %+ udnyttelse gennem hvert træningstrin, er den, der har været opmærksom på alle disse lag. Klyngen, der leveres med en hurtigere switch og et langsommere stof, vil bruge år på at forklare, hvorfor GPU'erne er inaktive.

Yderligere læsning

• RFC 7938 - BGP i store-datacentre
• InfiniBand Trade Association - RoCE-specifikationer
• NVIDIA-netværksdokumentation
• Installationsvejledning for fiberoptisk kabel
• Insertion Tab vs Return Tab Forklaret