Ontwerp van Netwerktopologie voor GPU-clusters: Fat-Tree, Dragonfly en Rail-Geoptimaliseerde Architecturen

Bijgewerkt op 11 december 2025

Update december 2025: DGX SuperPOD specificeert drielaags fat-tree met Quantum-2 InfiniBand (400Gb/s). Meta-onderzoek toont aan dat netwerkconfiguratieproblemen 10,7% van significante GPU-taakfouten veroorzaken. Volledige bisectiebreedte is cruciaal voor gedistribueerde training waarbij communicatiepatronen dynamisch verschuiven. Google TPU-pods gebruiken 3D-torus; AWS Trainium gebruikt workload-geoptimaliseerde topologieën.

De DGX SuperPOD-referentiearchitectuur van NVIDIA specificeert een drielaags fat-tree netwerktopologie die tot 32 DGX-systemen verbindt met behulp van Quantum-2 InfiniBand-switches met 400 Gb/s per poort.[^1] De architectuur levert volledige bisectiebreedte, wat betekent dat de totale bandbreedte tussen twee willekeurige helften van het cluster gelijk is aan de totale bandbreedte naar beide helften. Fat-tree topologieën domineren GPU-clusterimplementaties omdat ze voorspelbare prestaties leveren ongeacht welke GPU-paren communiceren, een cruciale eigenschap voor gedistribueerde training waarbij communicatiepatronen dynamisch verschuiven.

Keuzes voor netwerktopologie beïnvloeden rechtstreeks trainingsprestaties, kosten en operationele complexiteit. Een Meta-onderzoek toonde aan dat netwerkconfiguratieproblemen 10,7% van de significante taakfouten in hun GPU-clusters veroorzaakten, waarbij topologie-afhankelijke congestie bijdroeg aan prestatievariabiliteit.[^2] Google's TPU-pods gebruiken 3D-torustopologieën die directe verbindingen tussen naburige accelerators mogelijk maken, terwijl AWS Trainium-clusters verschillende topologieën gebruiken die zijn geoptimaliseerd voor hun workloadpatronen.[^3] Het begrijpen van topologie-afwegingen stelt organisaties in staat architecturen te selecteren die aansluiten bij hun specifieke workloadvereisten en budgetbeperkingen.

Grondbeginselen van fat-tree topologie

Fat-tree topologie is ontstaan uit het werk van Charles Leiserson uit 1985, dat aantoonde dat boomstructuren volledige bisectiebreedte konden bereiken als de linkcapaciteit naar de wortel toe toenam.[^4] Moderne implementaties gebruiken overal links met gelijke capaciteit en bereiken volledige bandbreedte door meerdere parallelle paden in plaats van dikkere links.

Drielaags fat-tree architectuur

Een drielaags fat-tree bestaat uit leaf-switches die verbinding maken met servers, spine-switches die leaf-verkeer aggregeren, en core-switches die volledige connectiviteit tussen spines bieden.[^5] Elke leaf-switch maakt verbinding met elke spine-switch, en elke spine maakt verbinding met elke core-switch. Het netwerk van verbindingen creëert meerdere gelijkwaardige paden tussen twee willekeurige servers.

NVIDIA beveelt fat-tree aan voor DGX-clusters vanwege de voorspelbare latentie- en bandbreedtekarakteristieken.[^6] De topologie zorgt ervoor dat collectieve operaties zoals all-reduce consistente prestaties ervaren ongeacht GPU-plaatsing. Trainingstaken hoeven geen rekening te houden met netwerktopologie bij planning, wat clusterbeheer vereenvoudigt.

Oversubscription-verhoudingen

Volledige bisectiebreedte vereist dure switchcapaciteit op hogere lagen. Veel implementaties accepteren oversubscription, waarbij de totale uplink-bandbreedte van lagere lagen de beschikbare capaciteit op hogere lagen overschrijdt.[^7] Een 2:1 oversubscription-verhouding betekent dat slechts de helft van het verkeer gelijktijdig de hogere lagen zou kunnen passeren.

Oversubscription past bij workloads met lokaliteit, waarbij de meeste communicatie binnen racks of pods plaatsvindt. Echter, gedistribueerde training met all-to-all communicatiepatronen verzadigt oversubscribed links, wat congestie en prestatievermindering veroorzaakt. AI-trainingsclusters vereisen doorgaans niet-oversubscribed ontwerpen ondanks de hogere kosten.[^8]

Radix en schaalbaarheid

Switch-radix bepaalt hoeveel poorten elke switch biedt, wat zowel schaal als kosten beïnvloedt. Een 64-poorts switch die een drielaags fat-tree bouwt met 32 downlinks en 32 uplinks schaalt naar 32.768 eindpunten.[^9] Switches met hogere radix verminderen het aantal benodigde switches, maar verhogen de kosten per switch.

NVIDIA's Quantum-2 switches bieden 64 poorten op 400 Gb/s, wat grootschalige fat-tree implementaties met een redelijk aantal switches mogelijk maakt.[^10] De aankomende Quantum-X800 generatie verhoogt poortsnelheden naar 800 Gb/s, waardoor de totale bandbreedte verdubbelt zonder de topologiestructuur te wijzigen.

Rail-geoptimaliseerde topologie

Rail-geoptimaliseerde topologie is ontstaan uit de erkenning dat GPU-servers meerdere GPU's bevatten die hogesnelheids interne interconnects delen. In plaats van elke GPU onafhankelijk te behandelen, stemmen rail-geoptimaliseerde ontwerpen netwerkverbindingen af op GPU-plaatsing binnen servers.[^11]

GPU-rails begrijpen

Een DGX H100-systeem bevat acht GPU's verbonden via NVLink, waarbij elke GPU ook verbinding maakt met een netwerkinterfacekaart (NIC).[^12] De acht NIC's komen overeen met acht "rails" die het cluster overspannen. Rail 0 verbindt GPU 0 van elke server, rail 1 verbindt GPU 1, enzovoort. Communicatie binnen een rail passeert minder switch-hops dan cross-rail communicatie.

NVIDIA NVLink Switch verbindt GPU's binnen en tussen servers met 900 GB/s totale bandbreedte per GPU.[^13] Het NVLink-domein verwerkt de meeste GPU-naar-GPU communicatie, waarbij het InfiniBand-netwerk communicatie tussen NVLink-domeinen afhandelt. Rail-geoptimaliseerde topologie stemt InfiniBand-paden af op NVLink-domeinen om InfiniBand-verkeer te minimaliseren.

Implementatieoverwegingen

Rail-geoptimaliseerde implementaties vereisen zorgvuldige bekabeling om rail-uitlijning over racks en pods te behouden.[^14] Verkeerd aangesloten verbindingen doorbreken rail-lokaliteit, waardoor verkeer door extra switch-hops moet. Kabelbeheersdiscipline is essentieel om de voordelen van rail-optimalisatie te realiseren.

De topologie vermindert switchvereisten vergeleken met volledige fat-tree op gelijkwaardige schaal. Besparingen komen door het elimineren van cross-rail switchcapaciteit die rail-geoptimaliseerde workloads zelden gebruiken.[^15] Organisaties moeten verifiëren dat hun workloadpatronen daadwerkelijk rail-lokaliteit vertonen voordat ze zich committeren aan rail-geoptimaliseerde ontwerpen.

Dragonfly-topologie

Dragonfly-topologie organiseert switches in groepen met dichte intra-groep connectiviteit en schaarse inter-groep links.[^16] Het ontwerp vermindert het aantal switches vergeleken met fat-tree terwijl redelijke padlengtes tussen twee willekeurige eindpunten behouden blijven.

Dragonfly-structuur

Een dragonfly bestaat uit groepen, elk met meerdere switches die volledig verbonden zijn binnen de groep. Globale links verbinden elke switch met switches in andere groepen.[^17] Twee willekeurige eindpunten verbinden via maximaal drie hops: lokale switch naar groepsswitch naar externe groepsswitch naar bestemming.

Het verminderde aantal hops verlaagt de latentie voor grootschalige implementaties. Minder switches verminderen kapitaalkosten en stroomverbruik. Echter, dragonfly biedt lagere bisectiebreedte dan fat-tree, waardoor het gevoeliger is voor congestie onder bepaalde verkeerspatronen.[^18]

Vereisten voor adaptieve routing

Dragonfly-prestaties zijn sterk afhankelijk van adaptieve routing die verkeer over beschikbare paden verdeelt.[^19] Statische routing concentreert verkeer op specifieke links, wat congestie veroorzaakt terwijl andere paden onderbenut blijven. Switches moeten linkgebruik monitoren en verkeer dynamisch verschuiven naar minder belaste paden.

NVIDIA InfiniBand ondersteunt adaptieve routing geschikt voor dragonfly-implementaties.[^20] De mogelijkheid vereist configuratie en testen om te zorgen dat routing-algoritmen adequaat reageren op workload-verkeerspatronen. Verkeerd geconfigureerde adaptieve routing kan slechter presteren dan statische routing.

Workloadgevoeligheid

Dragonfly past bij workloads met gelokaliseerde communicatiepatronen die het meeste verkeer binnen groepen houden.[^21] Workloads die uniform willekeurig verkeer over alle eindpunten genereren belasten inter-groep links boven hun capaciteit. De topologie werkt goed voor inference-serving met request-affiniteit, maar kan moeite hebben met grootschalige training met globale collectives.

Organisaties die dragonfly evalueren moeten verwachte workload-communicatiepatronen karakteriseren vóór implementatie. Simulatietools kunnen verwachte prestaties modelleren onder realistisch verkeer en potentiële congestiepunten identificeren die topologie-aanpassing vereisen.[^22]

Torus- en mesh-topologieën

Torustopologieën verbinden nodes in regelmatige rasterpatronen met wraparound-verbindingen aan de grenzen. Google's TPU-pods gebruiken 3D-torustopologieën die directe buurverbindingen bieden zonder switching.[^23]

Directe versus geschakelde netwerken

Torusnetwerken verbinden elke node direct met buren, waardoor switches uit het communicatiepad worden geëlimineerd.[^24] De directe verbinding vermindert latentie voor buur-naar-buur communicatie die gebruikelijk is in veel parallelle algoritmen. Echter, communicatie tussen verre nodes passeert meerdere tussenliggende nodes, wat latentie verhoogt en bandbreedte bij elke hop verbruikt.

Geschakelde netwerken zoals fat-tree bieden gelijke latentie tussen twee willekeurige eindpunten ongeacht fysieke plaatsing. De uniformiteit vereenvoudigt programmeren en load balancing. Torusnetwerken vereisen topologie-bewuste plaatsing om communicatieafstanden te minimaliseren.[^25]

Dimensieselectie

Hogere-dimensionale torustopologieën verminderen diameter (maximaal aantal hops) ten koste van een verhoogd aantal verbindingen per node.[^26] Een 3D-torus met N nodes per dimensie heeft diameter 3N/2, terwijl een 2D-torus diameter N heeft. Google's keuze voor 3D-torus balanceert het aantal verbindingen tegen diameter.

Fysieke beperkingen beïnvloeden dimensieselectie. Een 2D-torus mapt natuurlijk naar rijen en kolommen in een machineruimte. Een 3D-torus vereist ofwel gestapelde racks of verbindingen die aanzienlijke afstanden overspannen. Kabellengtes in hogere-dimensionale torus kunnen problematisch worden op schaal.[^27]

Raamwerk voor topologieselectie

Het selecteren van netwerktopologie vereist evaluatie van workloadkarakteristieken, schaalvereisten, budgetbeperkingen en operationele capaciteiten.

Workloadanalyse

Verschillende workloads belasten netwerken verschillend. Het trainen van grote taalmodellen genereert all-to-all communicatiepatronen die hoge bisectiebreedte vereisen.[^28] Inference-serving met batching vertoont meer gelokaliseerde communicatie binnen GPU-groepen die verzoeken afhandelen. Datavoorbewerking kan shuffle-patronen genereren met willekeurige communicatie.

Organisaties moeten verwachte workloads profileren om communicatiepatronen te begrijpen. Monitoring van productiecluster onthult werkelijke verkeerspatronen voor bestaande workloads. Nieuwe workloadtypen kunnen schatting vereisen gebaseerd op algoritmeanalyse of leveranciersbegeleiding.

Schaaloverwegingen

Kleine clusters van tientallen GPU's vereisen mogelijk geen geavanceerde topologie-optimalisatie. Een enkele switch met hoge radix die alle GPU's verbindt biedt volledige connectiviteit zonder meerlaags complexiteit.[^29] Topologieselectie is het belangrijkst voor clusters van honderden tot duizenden GPU's waar switchkosten en kabelroutes significant worden.

Toekomstige groei beïnvloedt topologieselectie. Een fat-tree schaalt door leaf-switches en servers toe te voegen terwijl volledige bisectiebreedte behouden blijft. Een dragonfly schaalt door groepen toe te voegen, maar kan herbalancering van globale links vereisen. Plannen voor groei voorkomt topologiewijzigingen die operaties verstoren.[^30]

Economische factoren

Switch- en kabelkosten variëren significant tussen topologieën. Fat-tree vereist meer switches dan dragonfly op gelijkwaardige schaal. Rail-geoptimaliseerde ontwerpen verminderen InfiniBand-switching maar vereisen NVLink Switch-systemen.[^31] Totale kostenanalyse moet switches, kabels, optica, stroom, koeling en rackruimte omvatten.

Operationele kosten variëren ook. Complexe topologieën vereisen geavanceerdere monitoring- en probleemoplossingsmogelijkheden. Het trainen van operationeel personeel in topologie-specifieke overwegingen voegt kosten toe. Eenvoudigere topologieën kunnen bescheiden prestatiecompromissen rechtvaardigen door verminderde operationele last.

Implementatie en uitrol

Implementatie van netwerktopologie vereist zorgvuldige planning die fysieke infrastructuur, switchconfiguratie en validatietesten omvat.

Planning van fysieke infrastructuur

Hogesnelheids netwerkimplementaties vereisen gestructureerde bekabeling die duizenden verbindingen op 400 Gb/s of hoger ondersteunt.[^32] Kabelrouting moet buigradiusschendingen en signaaldegradatie minimaliseren. Hot aisle/cold aisle arrangementen moeten kabelpaden accommoderen zonder ob

[Inhoud afgekapt voor vertaling]