GPU क्लस्टर नेटवर्क टोपोलॉजी डिज़ाइन: Fat-Tree, Dragonfly, और Rail-Optimized आर्किटेक्चर

11 दिसंबर, 2025 को अपडेट किया गया

दिसंबर 2025 अपडेट: DGX SuperPOD तीन-स्तरीय fat-tree को Quantum-2 InfiniBand (400Gb/s) के साथ निर्दिष्ट करता है। Meta के अध्ययन में पाया गया कि नेटवर्क कॉन्फ़िगरेशन त्रुटियाँ 10.7% महत्वपूर्ण GPU जॉब विफलताओं का कारण बनती हैं। Full bisection bandwidth distributed training के लिए महत्वपूर्ण है जहाँ communication patterns गतिशील रूप से बदलते हैं। Google TPU pods 3D torus का उपयोग करते हैं; AWS Trainium workload-optimized topologies का उपयोग करता है।

NVIDIA का DGX SuperPOD संदर्भ आर्किटेक्चर तीन-स्तरीय fat-tree नेटवर्क टोपोलॉजी निर्दिष्ट करता है जो Quantum-2 InfiniBand switches का उपयोग करके 400 Gb/s प्रति पोर्ट पर 32 DGX सिस्टम तक को जोड़ता है।[^1] यह आर्किटेक्चर full bisection bandwidth प्रदान करता है, जिसका अर्थ है कि क्लस्टर के किन्हीं दो हिस्सों के बीच कुल bandwidth दोनों में से किसी भी हिस्से में कुल bandwidth के बराबर होती है। Fat-tree topologies GPU क्लस्टर deployments में प्रभावी हैं क्योंकि वे भविष्यवाणी योग्य प्रदर्शन प्रदान करती हैं चाहे कोई भी GPU जोड़ी communicate करे, यह distributed training के लिए एक महत्वपूर्ण विशेषता है जहाँ communication patterns गतिशील रूप से बदलते हैं।

नेटवर्क टोपोलॉजी के चुनाव सीधे training प्रदर्शन, लागत और operational जटिलता को प्रभावित करते हैं। Meta के एक अध्ययन में पाया गया कि नेटवर्क कॉन्फ़िगरेशन त्रुटियाँ उनके GPU क्लस्टर में 10.7% महत्वपूर्ण जॉब विफलताओं का कारण बनीं, जिसमें topology-dependent congestion प्रदर्शन परिवर्तनशीलता में योगदान करता है।[^2] Google के TPU pods 3D torus topologies का उपयोग करते हैं जो पड़ोसी accelerators के बीच सीधे कनेक्शन सक्षम करते हैं, जबकि AWS Trainium क्लस्टर अपने workload patterns के लिए अनुकूलित विभिन्न topologies का उपयोग करते हैं।[^3] टोपोलॉजी tradeoffs को समझना संगठनों को उनकी विशिष्ट workload आवश्यकताओं और बजट बाधाओं से मेल खाने वाले आर्किटेक्चर का चयन करने में सक्षम बनाता है।

Fat-tree टोपोलॉजी की मूल बातें

Fat-tree टोपोलॉजी Charles Leiserson के 1985 के कार्य से उत्पन्न हुई जिसमें दिखाया गया था कि tree structures full bisection bandwidth प्राप्त कर सकती हैं यदि link capacity root की ओर बढ़े।[^4] आधुनिक implementations पूरे नेटवर्क में समान-क्षमता वाले links का उपयोग करते हैं, मोटे links के बजाय कई parallel paths के माध्यम से full bandwidth प्राप्त करते हैं।

तीन-स्तरीय fat-tree आर्किटेक्चर

तीन-स्तरीय fat-tree में leaf switches होते हैं जो servers से जुड़ते हैं, spine switches जो leaf traffic को aggregate करते हैं, और core switches जो spines के बीच full connectivity प्रदान करते हैं।[^5] प्रत्येक leaf switch हर spine switch से जुड़ता है, और प्रत्येक spine हर core switch से जुड़ता है। कनेक्शनों का mesh किन्हीं दो servers के बीच कई equal-cost paths बनाता है।

NVIDIA predictable latency और bandwidth विशेषताओं के कारण DGX क्लस्टर के लिए fat-tree की सिफारिश करता है।[^6] टोपोलॉजी सुनिश्चित करती है कि all-reduce जैसे collective operations GPU placement की परवाह किए बिना consistent प्रदर्शन अनुभव करें। Training jobs को scheduling करते समय नेटवर्क टोपोलॉजी पर विचार करने की आवश्यकता नहीं है, जो क्लस्टर प्रबंधन को सरल बनाता है।

Oversubscription ratios

Full bisection bandwidth के लिए upper tiers पर महंगी switch capacity की आवश्यकता होती है। कई deployments oversubscription स्वीकार करते हैं, जहाँ lower tiers से aggregate uplink bandwidth upper tiers पर उपलब्ध capacity से अधिक होती है।[^7] 2:1 oversubscription ratio का मतलब है कि केवल आधा traffic एक साथ upper tiers को traverse कर सकता है।

Oversubscription locality वाले workloads के लिए उपयुक्त है, जहाँ अधिकांश communication racks या pods के भीतर होता है। हालांकि, all-to-all communication patterns के साथ distributed training oversubscribed links को saturate करता है, जिससे congestion और प्रदर्शन में गिरावट होती है। AI training क्लस्टर को आमतौर पर उच्च लागत के बावजूद non-oversubscribed designs की आवश्यकता होती है।[^8]

Radix और scaling

Switch radix निर्धारित करता है कि प्रत्येक switch कितने ports प्रदान करता है, जो scale और cost दोनों को प्रभावित करता है। 32 downlinks और 32 uplinks के साथ तीन-स्तरीय fat-tree बनाने वाला 64-port switch 32,768 endpoints तक scale करता है।[^9] Higher-radix switches आवश्यक switches की संख्या कम करते हैं लेकिन per-switch cost बढ़ाते हैं।

NVIDIA के Quantum-2 switches 400 Gb/s पर 64 ports प्रदान करते हैं, जो उचित switch counts के साथ large-scale fat-tree deployments को सक्षम बनाते हैं।[^10] आगामी Quantum-X800 generation port speeds को 800 Gb/s तक बढ़ाती है, टोपोलॉजी structure को बदले बिना aggregate bandwidth को दोगुना करती है।

Rail-optimized टोपोलॉजी

Rail-optimized टोपोलॉजी इस मान्यता से उभरी कि GPU servers में कई GPUs होते हैं जो high-speed internal interconnects साझा करते हैं। प्रत्येक GPU को स्वतंत्र रूप से treat करने के बजाय, rail-optimized designs नेटवर्क कनेक्शनों को servers के भीतर GPU placement के साथ align करते हैं।[^11]

GPU rails को समझना

DGX H100 सिस्टम में आठ GPUs होते हैं जो NVLink के माध्यम से जुड़े होते हैं, प्रत्येक GPU network interface card (NIC) से भी जुड़ा होता है।[^12] आठ NICs क्लस्टर में फैले आठ "rails" के अनुरूप हैं। Rail 0 हर server से GPU 0 को जोड़ता है, rail 1 GPU 1 को जोड़ता है, इत्यादि। एक rail के भीतर communication cross-rail communication की तुलना में कम switch hops को traverse करता है।

NVIDIA NVLink Switch प्रति GPU 900 GB/s aggregate bandwidth पर servers के भीतर और across GPUs को जोड़ता है।[^13] NVLink domain अधिकांश GPU-to-GPU communication को handle करता है, InfiniBand network NVLink domains के बीच communication को handle करता है। Rail-optimized टोपोलॉजी InfiniBand traffic को minimize करने के लिए InfiniBand paths को NVLink domains के साथ align करती है।

Implementation संबंधी विचार

Rail-optimized deployments को racks और pods में rail alignment बनाए रखने के लिए सावधानीपूर्वक cabling की आवश्यकता होती है।[^14] गलत तरीके से wired कनेक्शन rail locality को तोड़ते हैं, traffic को अतिरिक्त switch hops के माध्यम से force करते हैं। Rail optimization लाभों को realize करने के लिए Cable management अनुशासन आवश्यक साबित होता है।

टोपोलॉजी समान scale पर full fat-tree की तुलना में switch आवश्यकताओं को कम करती है। बचत cross-rail switching capacity को eliminate करने से आती है जिसका rail-optimized workloads शायद ही कभी उपयोग करते हैं।[^15] संगठनों को rail-optimized designs के लिए commit करने से पहले verify करना चाहिए कि उनके workload patterns वास्तव में rail locality प्रदर्शित करते हैं।

Dragonfly टोपोलॉजी

Dragonfly टोपोलॉजी switches को dense intra-group connectivity और sparse inter-group links के साथ groups में organize करती है।[^16] यह design किन्हीं दो endpoints के बीच उचित path lengths बनाए रखते हुए fat-tree की तुलना में switch count को कम करता है।

Dragonfly structure

एक dragonfly groups से बनी होती है, प्रत्येक में कई switches होते हैं जो group के भीतर fully connected होते हैं। Global links प्रत्येक switch को अन्य groups में switches से जोड़ते हैं।[^17] कोई भी दो endpoints अधिकतम तीन hops के माध्यम से जुड़ते हैं: local switch से group switch से remote group switch से destination तक।

कम hop count large-scale deployments के लिए latency कम करता है। कम switches capital cost और power consumption कम करते हैं। हालांकि, dragonfly fat-tree की तुलना में कम bisection bandwidth प्रदान करती है, जिससे यह कुछ traffic patterns के तहत congestion के प्रति अधिक susceptible हो जाती है।[^18]

Adaptive routing आवश्यकताएं

Dragonfly प्रदर्शन adaptive routing पर बहुत निर्भर करता है जो traffic को उपलब्ध paths में distribute करता है।[^19] Static routing traffic को specific links पर concentrate करता है, जिससे congestion होती है जबकि अन्य paths underutilized रहते हैं। Switches को link utilization monitor करना चाहिए और dynamically traffic को कम loaded paths पर shift करना चाहिए।

NVIDIA InfiniBand dragonfly deployments के लिए उपयुक्त adaptive routing को support करता है।[^20] इस capability के लिए configuration और testing की आवश्यकता होती है यह सुनिश्चित करने के लिए कि routing algorithms workload traffic patterns के लिए उचित रूप से respond करें। गलत configured adaptive routing static routing से भी खराब perform कर सकती है।

Workload sensitivity

Dragonfly localized communication patterns वाले workloads के लिए उपयुक्त है जो अधिकांश traffic को groups के भीतर रखते हैं।[^21] सभी endpoints में uniform random traffic generate करने वाले workloads inter-group links को उनकी capacity से अधिक stress करते हैं। टोपोलॉजी request affinity के साथ inference serving के लिए अच्छी तरह काम करती है लेकिन global collectives का उपयोग करने वाली large-scale training के साथ संघर्ष कर सकती है।

Dragonfly का मूल्यांकन करने वाले संगठनों को deployment से पहले expected workload communication patterns को characterize करना चाहिए। Simulation tools realistic traffic के तहत expected performance को model कर सकते हैं, संभावित congestion points की पहचान कर सकते हैं जिनके लिए टोपोलॉजी adjustment की आवश्यकता होती है।[^22]

Torus और mesh topologies

Torus topologies nodes को boundaries पर wraparound connections के साथ regular grid patterns में connect करती हैं। Google के TPU pods 3D torus topologies का उपयोग करते हैं जो switching के बिना direct neighbor connections प्रदान करती हैं।[^23]

Direct versus switched networks

Torus networks प्रत्येक node को सीधे neighbors से connect करते हैं, communication path से switches को eliminate करते हैं।[^24] Direct connection कई parallel algorithms में common neighbor-to-neighbor communication के लिए latency कम करता है। हालांकि, distant nodes के बीच communication कई intermediate nodes को traverse करता है, latency बढ़ाता है और प्रत्येक hop पर bandwidth consume करता है।

Fat-tree जैसे switched networks physical placement की परवाह किए बिना किन्हीं दो endpoints के बीच equal latency प्रदान करते हैं। यह uniformity programming और load balancing को simplify करती है। Torus networks को communication distances minimize करने के लिए topology-aware placement की आवश्यकता होती है।[^25]

Dimension selection

Higher-dimensional torus topologies प्रति-node connection count बढ़ाने की कीमत पर diameter (maximum hop count) को कम करती हैं।[^26] प्रति dimension N nodes वाली 3D torus का diameter 3N/2 होता है, जबकि 2D torus का diameter N होता है। Google की 3D torus की पसंद connection count को diameter के विरुद्ध balance करती है।

Physical constraints dimension selection को प्रभावित करती हैं। 2D torus naturally machine room में rows और columns पर map होती है। 3D torus के लिए या तो stacked racks या substantial distances spanning connections की आवश्यकता होती है। High-dimensional torus में cable lengths scale पर problematic हो सकती हैं।[^27]

Topology selection framework

नेटवर्क टोपोलॉजी का चयन करने के लिए workload characteristics, scale requirements, budget constraints, और operational capabilities का मूल्यांकन करना आवश्यक है।

Workload analysis

विभिन्न workloads networks को अलग-अलग तरीके से stress करते हैं। Large language models को train करना all-to-all communication patterns generate करता है जिसके लिए high bisection bandwidth की आवश्यकता होती है।[^28] Batching के साथ inference serving requests serve करने वाले GPU groups के भीतर अधिक localized communication प्रदर्शित करती है। Data preprocessing random communication के साथ shuffle patterns generate कर सकती है।

संगठनों को communication patterns समझने के लिए expected workloads को profile करना चाहिए। Production cluster monitoring मौजूदा workloads के लिए actual traffic patterns reveal करती है। नए workload types के लिए algorithm analysis या vendor guidance के आधार पर estimation की आवश्यकता हो सकती है।

Scale संबंधी विचार

दसियों GPUs के छोटे clusters को sophisticated topology optimization की आवश्यकता नहीं हो सकती है। सभी GPUs को connect करने वाला single high-radix switch multi-tier complexity के बिना full connectivity प्रदान करता है।[^29] Topology selection सैकड़ों से हजारों GPUs spanning clusters के लिए सबसे अधिक मायने रखता है जहाँ switching costs और cable runs significant हो जाते हैं।

भविष्य की growth topology selection को प्रभावित करती है। Fat-tree full bisection bandwidth बनाए रखते हुए leaf switches और servers जोड़कर scale करती है। Dragonfly groups जोड़कर scale करती है लेकिन global links को rebalancing की आवश्यकता हो सकती है। Growth के लिए planning topology changes से बचाती है जो operations को disrupt करते हैं।[^30]

Economic factors

Switch और cable costs topologies के बीच significantly vary करती हैं। Fat-tree को समान scale पर dragonfly से अधिक switches की आवश्यकता होती है। Rail-optimized designs InfiniBand switching को कम करते हैं लेकिन NVLink Switch systems की आवश्यकता होती है।[^31] Total cost analysis में switches, cables, optics, power, cooling, और rack space शामिल होना चाहिए।

Operational costs भी vary करती हैं। Complex topologies को अधिक sophisticated monitoring और troubleshooting capabilities की आवश्यकता होती है। Staff को topology-specific considerations पर training देना cost जोड़ता है। Simpler topologies reduced operational burden के माध्यम से modest performance tradeoffs को justify कर सकती हैं।

Implementation और deployment

Network topology implementation के लिए physical infrastructure, switching configuration, और validation testing spanning careful planning की आवश्यकता होती है।

Physical infrastructure planning

High-speed network deployments को 400 Gb/s या higher पर हजारों connections को support करने वाली structured cabling की आवश्यकता होती है।[^32] Cable routing को bend radius violations और signal degradation को minimize करना चाहिए। Hot aisle/cold aisle arrangements को cable pathways को बिना ob

[अनुवाद के लिए सामग्री छोटी की गई]