A generatív mesterséges intelligencia gyors növekedése gyökeresen átalakította az adatközpontok tervezését. Amint az elosztott modelltréning több százezer GPU‑t átívelően skálázódik, a számítógépek közötti hálózat vált az elsőrendű teljesítmény‑szűk keresztmetszetté.
Hosszú ideje a hagyományos, kereskedelmi Ethernet a felhő és az vállalati hálózatok alapja: olcsó, szabványos és jól kezeli a magas entrópiájú, általános célú webes forgalmat. Ugyanakkor az AI‑munka terhelések rendkívül szinkronizált kommunikációja fizikailag korlátokba ütközik, amikor ezt a hagyományos Ethernetre bízzák.
NVIDIA ezért mutatta be a Spectrum‑X Etherntet, egy hardveresen gyorsított hálózati architektúrát, amelyet kifejezetten giga‑skálájú AI „gyárak” igényeire terveztek. A Spectrum‑X nem a hagyományos útválasztási és torlódásvezérlési paradigmákra épít, hanem a magas teljesítményű kapcsolók és a host‑oldali hálózati interfészek (SuperNIC-ek, például NVIDIA ConnectX) együttes tervezésével igyekszik előre jelezhető alacsony késleltetést, magas hálózati kihasználtságot és robusztus ellenálló képességet nyújtani extrém terhelés mellett.
Miért nem felel meg a hagyományos Ethernet az AI‑munka terheléseknek?
A tipikus adatközponti forgalom magas entrópiájú: sok kis, egymástól független folyamat halad különböző irányokban. Az Equal‑Cost Multi‑Path (ECMP) statikus hash‑alapú elosztással igyekszik a forgalmat párhuzamos utak közt egyenletesen elosztani. Ezzel szemben az AI tréning alacsony entrópiájú: a GPU‑k folyamatosan szinkronizálnak All‑Reduce, All‑Gather és All‑to‑All collectives segítségével, viszonylag kevés, de nagyon nagy és szinkron forgalmat generálva.
Ez három szerkezeti problémát hoz előtérbe:
- Hash ütközések és straggler‑hatás: az ECMP nem érzékeli a valós idejű torlódást, ezért nagyméretű folyamatok ütközhetnek egy linken, míg mások alulhasználtak maradnak. A szinkron collectives csak akkor fejeződnek be, ha a leglassabb flow teljesül, így egy zsúfolt út az egész műveletet lassítja.
- Vesztéses vs. veszteségmentes működés: a torlódás túlcsordíthatja a kapcsolók pufferét, csomagvesztést és újraküldést okozva, ami súlyosan rontja az AI‑teljesítményt. A RoCEv2 bevezetések gyakran Priority Flow Controlt (PFC) használnak a veszteség csökkentésére, de a pause‑frame‑ek torlódást terjeszthetnek és head‑of‑line blokkolást idézhetnek elő.
- Lassú torlódásvezérlés: olyan protokollok, mint a Data Center Quantized Congestion Notification (DCQCN) nehezen hangolhatók a szinkron AI kitörésekre; késlekedő vagy túlzott reakciók pufferépüléshez, alulhasználathoz és késleltés kiugráshoz vezethetnek.
Továbbá több bérlős környezetben a „zajos szomszéd” forgalma egy másik munkát könnyen tönkretehet: egy DeepSeek‑V3 LLM tréning‑szimulációban a hagyományos Ethernet egyedül 735 ms/tréninglépés értéket produkált, de zaj forgalom mellett 1,18 s‑re nőtt (1,6× lassulás). Spectrum‑X Ethernet ugyanakkor izolálta a torlódást repterenként és dinamikusan elkerülte a forró pontokat, így a tréninglépés ideje stabilan 668 ms maradt mind tiszta, mind erősen zajos több‑bérlős környezetben.
A Spectrum‑X architektúrája: három, egymást kiegészítő hardveres szabályozási kör
800 Gbps és afelett a késleltetés fizikai határa (a fénysebesség) változatlan, de a sávszélesség‑késleltetés szorzat hatalmas. A pufferépülés és csomagvesztés elkerüléséhez a hálózatnak mikro‑másodperces skálán kell reagálnia. Szoftveres vezérlési utak ebben az időablakban nem tudnak megfelelően működni, ezért a Spectrum‑X teljes hardveres gyorsítást alkalmaz.
A Spectrum‑X alapelve a vezérlési hurkok szétválasztása scope, jel és felelősség szerint. Három, egymást nem zavaró, hardveresen gyorsított hurkot különít el:
In‑switch Adaptive Routing (AR)
A kapcsolók per‑packet Adaptive Routinget hajtanak végre, kvantált hardverközelítéssel a Join‑Shortest‑Queue (JSQ) algoritmushoz. A switch minden kimeneti port queue‑mélységét al‑mikro másodperces mintavétellel figyeli, és beérkező csomag esetén dinamikusan a legkevésbé torlódott fizikai portra irányít. Ez stateless, flow‑független módon száznanomásodok alatt reagál a lokális egyensúlytalanságokra, kicsiben tartva a pufferelést és megelőzve a hotspotokat.
Célzott Torlódásvezérlés (Targeted Congestion Control)
Az AR kiegyenlíti az útvonalhasználatot, de nem orvosolja az endpoint‑incast helyzeteket (több küldő telíti a fogadó kimeneti portját). A Spectrum‑X hardver‑gyorsított Congestion Control mechanizmust alkalmaz: a kapcsoló ECN‑jelzéseket csak akkor ad ki, ha az AR kapacitása kimerült és a queue tovább növekszik. A küldők precíz RTT‑probeket és ECN‑jelzéseket kombinálva szabályozzák küldési sebességüket RTT‑skálán, elkerülve a hálózat túlreagálását rövid, könnyen kiegyenlíthető mikro‑kitörésekre.
NIC‑alapú Plane Load Balancing (PLB)
A host‑oldalon a Plane Load Balancer egy dedikált hardveregység a Spectrum‑X SuperNIC‑ben (például ConnectX). A PLB dinamikusan osztja el a csomagokat több, független network plane között helyi queue‑feedback és végpontok közti per‑plane torlódástelemetria alapján.
Multiplane topológia és Spectrum‑X Multiplane technológia
Giga‑skálájú AI‑klasztereknél a hagyományos hálózati rétegek növelése (például kétszintesről háromszintesre lépés) problémás: megnöveli a késleltetést, jittert, terhelési egyensúlytalanságot és az optikai költségeket. A Multiplane Topology helyett egyszerű, sekély két‑rétegű fat‑tree‑okat építenek több, fizikailag független plane‑re. Például egy 8‑lane ConnectX 800 Gbps sávszélességét négy külön 200 Gbps plane‑re bonthatják.
A host‑oldalon passzív optikai eszközök (shuffle‑boxok, trunk kábelek) kötik össze a többportos NIC‑eket az összes plane‑lal, ezzel nagy path‑diverzitást nyitva anélkül, hogy a több‑rétegű fat‑tree‑k késleltetését és jitterét importálnák. Egy ilyen két‑rétegű modell több mint 128 000 végpontig skálázható; három‑rétegű topológia esetén elméletileg akár 16 millió végpontig.
Az „oblivious spraying” gyengesége
A multiplane elméleti sávszélessége csak akkor hasznos, ha a forgalom tökéletesen kiegyensúlyozott minden plane‑on. Az ún. oblivious spraying, azaz a csomagok szállítási rétegbeli sorozatos szórása plane‑ok közt láthatóság nélkül, a valóságban megbukik: link‑degradációk, optikai csatlakozó‑romlás és fiber flappok gyakoriak. Ha egy plane kábele gyengül vagy le‑fel pattog, a róla származó kapacitás csökken; az oblivious spraying ekkor továbbra is egyenlően küldi a forgalmat, így a teljes multiplane klaszter teljesítménye a leglassabb plane teljesítményére esik vissza.
Spectrum‑X Multiplane megoldás
A Spectrum‑X Multiplane ezt a problémát a SuperNIC szilíciumba integrált hardveres Plane Load Balancerrel oldja meg. A PLB lazán átlátszatlanítja a multiplane architektúrát az alkalmazások számára: az operációs rendszer és a kollektív kommunikációs könyvtárak egyetlen, egységes RoCE eszközt látnak, míg a forgalomelosztás, terheléskiegyenlítés és meghibásodás‑átirányítás teljesen a Spectrum‑X hardverben történik.
A PLB minden kimenő csomagra egy kétlépcsős, állapotkövető kiválasztási folyamatot futtat:
- Végpontok közti torlódásszűrés: a SuperNIC minden cél GPU‑hoz külön, per‑plane torlódásvezérlési kontextust tart nyilván. Minden kontextus függetlenül figyeli az RTT‑probe‑okat és a Congestion Notification Packeteket (CNP), így valós idejű átviteli engedélyt számol minden plane‑ra. Ha egy plane végponttól végpontig torlódott vagy hibás, azt ideiglenesen kizárják.
- Lokális kimeneti sor kiválasztása: a megmaradt, egészséges plane‑ok közül a SuperNIC a legsekélyebb lokális egress queue‑val rendelkező plane‑t választja, tükrözve a kapcsolók AR‑mechanizmusát a host‑szélen.
Ezzel a per‑plane CC‑állapotok szétválasztásával és a lokális queue‑mélység figyelembevételével a Spectrum‑X izolálja a torlódást a hatott plane‑ra. Ha például Plane 2 link flappol vagy RTT timeoutot észlel, a ConnectX azonnal kiszűri Plane 2‑t és áttereli a forgalmat a megmaradt három healthy plane‑re 3 ms alatti idő alatt, így a teljes vonal‑sebességű bisection kapacitás 75%-a megmarad.
Mérések és valós hatás: ellenálló képesség, izoláció és Time‑to‑AI
NVIDIA és kutatói csoportok termelési körülmények közeli klasztereken és magas hűségű szimulációkban értékelték a Spectrum‑X‑et. Az eredmények éles kontrasztot mutatnak a hagyományos off‑the‑shelf Ethernet és a Spectrum‑X Ethernet között magas kihasználtság, hibák és bérlős terhelések esetén:
-
Multiplane ellenálló képesség: egy 8‑plane hálózatban, ha egy plane‑on 20% switch‑to‑switch kapcsolódás sérül, a hagyományos oblivious multiplane azonnal teljesítményromlást szenved — a teljes fabric a degradált plane teljesítményére zuhan (80% kapacitás). Spectrum‑X Multiplane viszont a PLB‑vel dinamikusan kikerüli a lokális szűk keresztmetszetet: a hét egészséges plane 100%‑on fut, míg a degradált plane 80%‑on; ez 1,2× magasabb All‑to‑All collective sávszélességet eredményez hibák idején.
-
Megjósolható, magas kihasználtság melletti teljesítmény: egy rosszabb eseti RDMA bisection benchmarknál a hagyományos ECMP ütközések miatt egyes GPU‑párok sávszélessége 25 Gbps‑ra zuhanhat. Spectrum‑X AR és PLB használatával szoros, kiszámítható sávszélesség‑eloszlás érhető el: a mérési eredmények szerint a Spectrum‑X 98%‑ot tartott a elméleti vonal‑sebességből minden GPU‑párra nézve. A hagyományos Ethernet P99 tail‑késleltetése 22 µs volt, míg Spectrum‑X P99 értéke szűk, 8–9 µs tartományban maradt 75% hálózati terhelés mellett.
-
Zökkenőmentes failover: egy host‑to‑leaf link flappelése esetén a hagyományos szoftveres vagy nem gyorsított load balancerek akár 1,08 másodpercet is igényelhetnek a helyreállításhoz, ami GPU collectives lefagyását okozhatja. Spectrum‑X hardveres PLB‑je a meghibásodást 2,68 ms alatt kezeli, ez több százszoros gyorsulást (kb. 400×) jelent, és átlátszóan elnyeli az átmeneti hibákat anélkül, hogy folyamatban lévő LLM tréninglépéseket zavarna.
-
Proporcionális teljesítményromlás kábelezési hibák esetén: a hagyományos Ethernet gyakran nem arányos teljesítményromlást mutat; például 10% leaf uplink kiesés a kollektív sávszélesség összeomlását okozhatja (50% vagy több). Spectrum‑X esetén a degradáció kapacitás‑arányos: 10% fabric link hiba mellett a sávszélesség csupán 11%‑kal csökken, és a tail latency mindössze 7%‑kal nő.
Ezek a tulajdonságok lehetővé teszik, hogy az üzemeltetők közel optimális hatékonysággal futtassák a tréningmunkaikat még akkor is, amikor a fizikai infrastruktúra problémái nem teljesen megoldottak — így jelentősen csökken a „Time‑to‑AI”.
Összegzés: miért fontos ez az AI‑gyárak számára
A közelmúlt általános célú felhőszámításon alapuló hálózati feltételezések (magas entrópia, statikus útválasztás, szoftver által vezérelt torlódás‑hurkok) nem felelnek meg a giga‑skálájú, szinkron AI collectives követelményeinek. A Spectrum‑X Ethernet újrarajzolja a hálózati szabályokat: a kulcsvezérlési hurkok hardveres szétválasztásával és gyorsításával (in‑switch Adaptive Routing, célzott CC és host‑oldali PLB) előre jelezhető, alacsony késleltetésű és robusztus hálózati viselkedést kínál. A Spectrum‑X Multiplane pedig operatívan skálázható, hibatűrő és izolált multiplane hálózatot ad, amely csökkenti a Time‑to‑AI‑t — ezért a giga‑skálájú AI‑t építő szervezetek számára nem pusztán optimalizáció, hanem architekturális szükséglet.
Hivatkozott források és további olvasnivaló
A Spectrum‑X és a Multiplane részleteiről, valamint a mérési eredményekről a cég fehérpapere és kapcsolódó konferencia‑publikációk adnak bővebb technikai ismertetést (Khashab et al., 2025; Bai et al., 2023; Gangidi et al., 2024; DeepSeek‑AI, 2024).
