Nätverksdesign för distribuerade lokala AI-kluster

Nätverket är flaskhalsen du glömde bort

När organisationer planerar lokal AI-infrastruktur får GPU:n all uppmärksamhet. Team lägger veckor på att utvärdera H100 mot H200, beräkna VRAM-krav och dimensionera lagringsarrayer. Nätverksfabriken som förbinder dessa GPU:er får ofta en enda rad i arkitekturdiagrammet: "höghastighetsinterconnect." Detta är ett kostsamt förbiseende.

För inferens på en enskild nod spelar nätverket knappt någon roll — data flödar in, prediktioner flödar ut och flaskhalsen är GPU-beräkning. Men i samma ögonblick som du skalar till flernodträning, multi-GPU-inferens med tensorparallellism eller distribuerad RAG blir nätverket den kritiska vägen. Ett träningsjobb som tar 4 timmar på en väldesignad fabric kan ta 12 timmar på samma GPU:er anslutna via en överbelastad Ethernet-switch.

InfiniBand: guldstandarden för GPU-till-GPU-kommunikation

InfiniBand (IB) förblir den dominerande interconnecten för seriösa AI-arbetsbelastningar. NVIDIAs DGX- och HGX-system levereras med ConnectX-7-adaptrar som stöder NDR (400 Gbps) InfiniBand, och den senaste generationen når XDR (800 Gbps). Fördelen är inte bara rå bandbredd — det är RDMA (Remote Direct Memory Access), som låter GPU:er läsa och skriva varandras minne utan att involvera CPU:n eller operativsystemets kärna.

För distribuerad träning med ramverk som DeepSpeed, Megatron-LM eller PyTorch FSDP eliminerar RDMA overheaden med att packa gradienter i TCP-paket, kopiera dem genom kärnans nätverksstack och packa upp dem på andra sidan. De kollektiva operationerna (AllReduce, AllGather) kan köras med nästan full linjehastighet med IB.

InfiniBand-topologier för AI-kluster använder typiskt en fat-tree-design. Lövswitchar ansluter direkt till GPU-noder och spineswitchar sammankopplar lövswitcharna. För kluster under 128 noder räcker en tvåskikts löv-spine-topologi. Bortom det, överväg en treskiktsdesign eller NVIDIAs railoptimerade topologi.

Ethernet-alternativ: när InfiniBand inte är ett val

InfiniBand kräver specialiserade switchar, kablar och operativ expertis som inte alla organisationer kan motivera. Om dina arbetsbelastningar primärt är inferens, finjustering med små batchstorlekar eller RAG-pipelines, kan höghastighets-Ethernet vara tillräckligt och betydligt billigare att driva.

Modernt 100GbE och 400GbE Ethernet med RoCE v2 (RDMA over Converged Ethernet) ger RDMA-funktioner till standard Ethernet-hårdvara. RoCE kräver förlustfritt Ethernet, vilket innebär konfiguration av Priority Flow Control (PFC) och Explicit Congestion Notification (ECN) på varje switch i vägen.

Det praktiska prestandagapet mellan NDR InfiniBand och 400GbE RoCE v2 för inferensarbetsbelastningar är mindre än många antar. För att serva en 70B-parametermodell över 4 noder med tensorparallellism levererar båda interconnecterna acceptabel inter-token-latens. Gapet vidgas märkbart för storskalig träning.

En hybridmetod fungerar väl för många lokala driftsättningar: InfiniBand för GPU-träningsklustret och 100GbE Ethernet för inferensserveringsflottan och stödjande infrastruktur.

Bandbreddsplanering: hur mycket räcker?

Att dimensionera nätverksbandbredd kräver förståelse för dina kommunikationsmönster. Tre arbetsbelastningsprofiler driver olika krav:

Distribuerad träning med dataparallellism. Varje GPU beräknar gradienter oberoende, sedan synkroniserar alla GPU:er via AllReduce. Data som överförs per steg motsvarar 2x modellstorleken. En 70B-parametermodell i FP16 innebär ungefär 280 GB överförd per synkroniseringssteg över hela ringen.

Tensorparallellism för inferens. När en modell delas över GPU:er på olika noder måste aktiveringar överföras mellan noder vid varje transformer-lager. Vid 400 Gbps överförs detta på under 1 millisekund, men vid 25 Gbps Ethernet tar det 5-8 millisekunder per lager — över 80 lager adderar det 400-640ms till varje tokengenerering.

RAG och retrieval-arbetsbelastningar. Nätverket bär inbäddningsvektorer och dokumentfragment mellan inferensservrarna och vektordatabasen. Detta är måttlig bandbredd men latenssensitivt. Standard 25GbE-anslutningar med korrekt QoS-konfiguration är tillräckliga för de flesta RAG-driftsättningar.

Lagringsnätverksöverväganden

AI-arbetsbelastningar ställer unika krav på lagringsnätverket. Träningsdata måste strömma till GPU:er utan att svälta beräkningspipelinen. Modellcheckpoints — ofta 100-500 GB vardera — måste skrivas periodiskt utan att blockera träningen.

Separera lagringsnätverket från GPU-interconnect-fabriken. Använd dedikerade nätverksgränssnitt för lagringstrafik. NVMe-oF (NVMe over Fabrics) är i allt högre grad det föredragna protokollet och erbjuder nära lokal-disk-latens över nätverket.

För träningsdata specifikt, beräkna minsta nödvändiga lagringsbandbredd som: batchstorlek x exempelstorlek x steg_per_sekund. Provisionera 2-3 gånger detta tal för att ta höjd för I/O-toppar under dataaugmentering och blandning.

Övervakning och felsökning av AI-nätverksfabriken

Nätverksproblem i AI-kluster manifesterar sig som träningsfördröjningar, inte som avbrott. En enda degraderad länk i en AllReduce-ring tvingar alla andra GPU:er att vänta, och förvandlar ett 4-timmars träningsjobb till 8 timmar. Utan nätverksnivåövervakning ser detta ut som ett GPU-prestandaproblem.

Instrumentera din fabric med tre övervakningslager. Länknivåhälsa: spåra portfelräknare på varje switchport. Trafiknivåsynlighet: övervaka per-port-utnyttjande och identifiera hot spots. UFM för InfiniBand eller sFlow/IPFIX för Ethernet tillhandahåller trafikanalys. Applikationsnivåkorrelation: korrelera nätverksmätvärden med träningsmätvärden för att identifiera när nätverket är flaskhalsen.

Etablera en baslinje under en känt bra träningskörning. Registrera kommunikationstid per steg, utnyttjande per länk och felräkningar. När framtida körningar avviker har du en referenspunkt för utredning. Nätverksfabrikproblem är enklare att diagnostisera när du vet hur normalt ser ut.

Utvald bild av Marek Piwnicki på Unsplash.