Pitva latencie: kam sa v sieti AI klastra stráca každá mikrosekunda

Kto dimenzuje siete pre AI klastre, začína zvyčajne pri šírke pásma — 100, 200, 400 GbE — a potom ho prekvapí, že jeho allreduce benchmark vypíše číslo ani zďaleka nie na úrovni linkovej rýchlosti. Dôvodom je takmer vždy latencia a režim krátkych správ, v ktorom sú grafy šírky pásma nanič.

Tento článok rozoberá jedinú obrátku na súčiastky a vyúčtuje každý krok. Čísla nižšie sú konsenzuálnym rozsahom z verejných meraní, dokumentácie NVIDIA/Mellanox a z našich vlastných testov. Berte ich ako rozpočet, nie ako záruku — menia sa s kremíkom sieťovej karty, ASIC prepínača, verziou jadra, nastaveniami BIOS a tým, ako trpezlivo ladíte.

Pre koho to je: pre tých, čo navrhujú alebo riešia problémy sieťových štruktúr AI klastrov. Nie je to kuchárka na ladenie, ale myšlienkový model, vďaka ktorému sa taká kuchárka dá čítať.

Celá obrátka na jednej snímke

Ping-pong so 64 bajtmi medzi dvoma GPU na rôznych uzloch, cez prepínanú štruktúru 100 GbE s RDMA, sa zhruba rozpadá takto:

RTT cez RDMA na jedinom prepínači pri 100 GbE / NDR InfiniBand vychádza pre krátke správy na ~2 µs. Dvojskoková leaf-spine pridá ~1 µs. Tá istá cesta cez kernelové TCP/IP vychádza na 20–60 µs, teda o rád viac, a s horším správaním v chvoste. Tieto dve čísla poháňajú takmer každé architektonické rozhodnutie nižšie.

Jednosmerná cesta cez RDMA: prechod prepínačom (250–600 ns na Ethernete, <100 ns na IB) je dominantnou premennou; oneskorenie na vedení je pod 100 m zanedbateľné.

Vedenie nie je problém

Svetlo sa vo vlákne šíri asi dvojtretinovou rýchlosťou c, takže šírenie trvá ~5 ns/m. 30 m vlákna cez rad rackov pridá 150 ns jedným smerom; aj 500 m areálový spoj je jedna mikrosekunda. Pri dnešných rýchlostiach je malá aj serializácia: 64-bajtový rámec na 100 Gb/s trvá 5,12 ns, 9000-bajtový jumbo rámec 720 ns. Pri krátkych riadiacich správach je serializácia zanedbateľná; pri hromadných prenosoch prestane hrať rolu, len čo je potrubie dosť široké.

Latencia žije v softvéri, v ASIC prepínačov a v protokole, ktorý si zvolíte.

Sieťová štruktúra: cut-through verzus store-and-forward

Cut-through prepínač začne preposielať hneď, ako prečíta cieľovú hlavičku. Store-and-forward prepínač odloží celý rámec do vyrovnávacej pamäte, voliteľne overí CRC a až potom preposiela.

Náskok InfiniBandu je reálny: kremík pre HPC sa na toto optimalizuje už dve desaťročia. Moderné ethernetové AI prepínače (Tomahawk 5, Jericho3-AI, Spectrum-X) väčšinu latenčného rozdielu dotiahli a InfiniBand prekonávajú hĺbkou vyrovnávacích pamätí, čo pri incaste v allreduce váži viac.

V leaf-spine prejde tok medzi rackmi cez leaf → spine → leaf. Návrhy, ktoré minimalizujú počet skokov (plytký fat-tree, rail-optimized topológie), sa nesnažia ušetriť šírku pásma; šetria 500 ns za každý nevykonaný skok pri každej kolektívnej operácii.

Sieťový zásobník jadra

Obyčajné TCP/IP cez linuxové jadro platí za každý paket: obsluha prerušenia sieťovej karty (alebo polling cez NAPI), alokácia skb a softirq, spracovanie TCP/IP, kopírovanie medzi vyrovnávacou pamäťou soketu v jadre a user space a prepnutie kontextu do aplikácie.

Pri malom pakete na modernom x86 je to v najlepšom prípade 10–30 µs jedným smerom, so špičkami v chvoste nad 100 µs pri záťaži. Je to aj limitované procesorom — jadro CPU vyťaží pri ~1 Mpps dávno pred sieťovou kartou. Práve túto réžiu sa zvyšok článku snaží odstrániť.

Obídenie jadra: DPDK, RDMA, XDP, AF_XDP

Štyri bežné spôsoby, ako dostať jadro z dátovej cesty, líšia sa mierou obídenia aj tým, čo nechávajú ležať:

Niekoľko praktických poznámok:

• DPDK a RDMA nie sú zameniteľné. DPDK spúšťa ľubovoľné spracovanie paketov v user space pri linkovej rýchlosti; RDMA implementuje konkrétny pamäťovo-sémantický protokol s hardvérovým offloadom. AI workloady chcú RDMA — NCCL aj úložné zásobníky ním hovoria natívne. DPDK sa objavuje v inferenčných proxy, telemetrii a vlastných dátových rovinách.
• AF_XDP je stredná cesta. Zavesí sa na ovládač na vrstve eBPF, dosiahne latenciu pod 10 µs a na rozdiel od DPDK neukradne sieťovú kartu operačnému systému. Správna odpoveď pre stroje so zmiešaným využitím.
• XDP bez AF_XDP slúži na inline zahadzovanie, presmerovanie a preposielanie (čistenie DDoS, load balancery). Spracúva pakety priamo v jadre na háku ovládača a nepresúva ich do user space.

Pre AI klaster: RDMA cez InfiniBand alebo RoCEv2 pre komunikáciu GPU s GPU, obyčajné TCP/IP na všetko ostatné (správa, telemetria, sťahovanie modelov). Pomalé cesty neprekombinujte.

Interrupt coalescing, GRO/LRO: pasca priepustnosti

Linux aj väčšina ovládačov sieťových kariet prichádzajú naladené na priepustnosť, nie na latenciu. Dôležité sú dva parametre:

• Interrupt coalescing. Sieťová karta pred vyvolaním prerušenia počká nastavené okno v µs (alebo určitý počet paketov). Znižuje réžiu na paket, no pridáva latenciu v dĺžke okna. rx-usecs 50 pridá na tichom spoji až 50 µs.
• GRO / LRO. Jadro (GRO) alebo karta (LRO) zlučuje prichádzajúce TCP segmenty do jedného väčšieho skb, než ich pošle vyššie. Spracovanie je lacnejšie, ale agregátor zámerne čaká na ďalšie pakety, čím pridáva mikrosekundy.

Kompromis je poctivý a nevyhnutný: špičkovú priepustnosť a špičkovú latenciu na tej istej konfigurácii mať nemôžete. Pri GPU uzle chce RDMA karta obsluhujúca allreduce rx-usecs 0 alebo 1, vypnuté adaptívne coalescing a vypnuté GRO na rozhraní na strane RDMA. Samostatná manažmentová karta si ponechá predvolené hodnoty; nie je na kritickej ceste.

Z toho plynie: karta, ktorá robí zároveň RDMA kolektívy aj TCP sťahovanie, bude mať priemerné čísla v oboch disciplínach, pokiaľ prevádzku nerozdelíte medzi fronty alebo rozhrania. Seriózne AI uzly majú jednu alebo dve vyhradené RDMA karty (ConnectX-7/8, BlueField-3) a k tomu samostatnú kartu na správu.

Ani aplikačná vrstva nie je zadarmo

Dve položky na vrchole zásobníka sa do architektonických schém dostanú len málokedy:

• memcpy. memcpy so 4 MB trvá na jednom jadre pri ~20 GB/s zhruba 200 µs. Ak Vaša kolektívna operácia kopíruje dáta tenzora do odkladacej vyrovnávacej pamäte pred odoslaním, spálili ste viac času než celá sieťová obrátka. GPUDirect RDMA tento krok preskočí — karta číta priamo z pamäte GPU.
• Serializácia. Protobuf, JSON či vlastné rámcovanie pridá pri netriviálnych dátach desiatky µs. V riadiacom RPC je to v poriadku, vo vnútornej slučke allreduce smrteľné. NCCL sa tomu vyhýba pevnými binárnymi deskriptormi a vopred registrovanou pamäťou.

Ak je Váš „na RDMA naladený“ zásobník stále pomalý, skôr než budete viniť sieťovú štruktúru, sprofilujte user space. Videli sme 30 µs kolektívy, kde 25 µs bola zmena tvaru tenzora v PyTorchi a len 5 µs vedenie a prepínač.

Kolektívne operácie: latencia verzus šírka pásma a prečo záleží na veľkosti paketu

NCCL (a každá knižnica kolektívov) volí algoritmus podľa veľkosti správy:

• Krátke správy sú limitované latenciou. NCCL používa stromové algoritmy a svoj protokol LL (4 bajty dát so 4 bajtmi príznakov cez 8-bajtové atomické zápisy, bez pamäťových bariér). BusBw je zlomkom linkovej rýchlosti; meriate réžiu na správu × počet správ.
• Dlhé správy sú limitované šírkou pásma. NCCL prepne na kruhové algoritmy, ktoré sa blížia linkovej rýchlosti najpomalšieho spoja. Latencia na správu zmizne pod megabajtmi.

Prechod leží zhruba medzi 64 KB a 1 MB podľa topológie a sieťovej karty. Pod ním dominuje latencia prepínača a karty a protokolový zásobník. Nad ním z grafu čítate rýchlosť vedenia.

Publikovaný strop NVLinku na H100 je 450 GB/s; dostať sa k nemu pri menších správach alebo naprieč uzlami je boj o ladenie. Pri sortimente Kentino — 5090 / 4090 / RTX Pro 6000 Blackwell cez 100 GbE RoCE — čakajte pri dlhých správach busbw okolo 10–12 GB/s na uzol pri 100 GbE, s rovnakým tvarom algoritmu.

Rozptyl je horší než latencia

Ak je latencia allreduce na každom uzle 30 µs ± 1 µs, bariéra čaká 30 µs. Ak je priemer 30 µs, no jeden uzol raz za tisíc iterácií vyskočí na 300 µs, všetky ostatné GPU zakaždým stoja 270 µs. Naprieč epochou so 100k iteráciami na 16 uzloch sú to hodiny stratených výpočtov.

Preto je pri tréningu AI dôležitejšia latencia P99 / P999 než priemer. Bariérová kolektívna operácia je operácia, kde vyhráva najpomalší: klaster sa pohybuje rýchlosťou svojho najhoršieho uzla.

Zdroje rozptylu:

• Zahltenie vyrovnávacích pamätí pri incaste. AllReduce je v každej iterácii operáciou mnohí k jednému. Prepínače s plytkými vyrovnávacími pamäťami zahadzujú pakety, nastúpi pauza PFC a latencia vyskočí 10×–100×. Hlboko bufferované AI prepínače (Jericho3-AI, Spectrum-X) nápor pohltia.
• Rozptyl na CPU hostiteľa. Úloha v cron, neohraničené vlákno jadra alebo výkyv frekvencie CPU vyrobia odľahlú hodnotu 1 ms. Vyhraďte jadrá pre ISR/polling vlákno sieťovej karty, vypnite C-stavy na kritických CPU, procesy pripnite.
• Adaptívne coalescing. Ovládač „pomáha“ tým, že pri záťaži coalescing zvyšuje; latencia potichu vyskočí. Na RDMA karte ho výslovne vypnite.
• Asymetria topológie. Jeden leaf na 200 GbE, druhý na 100 GbE. Ten pomalší je Vaším stropom pre každú kolektívnu operáciu.

Správnym SLO pre AI sieťovú štruktúru je latencia v chvoste, nie priemerná latencia.

Ako to merať správne

ping meria RTT ICMP cez kernelový zásobník na manažmentovej rovine. Na charakterizáciu RDMA štruktúry je nanič. Nástroje, ktoré fungujú:

• sockperf ping-pong — latencia UDP/TCP s rozlíšením pod nanosekundu. Dobré na základné hodnoty kernelového zásobníka a na odhaľovanie regresií.
• ib_send_lat, ib_write_lat (sada perftest) — priamo latencia RDMA verbs. Číslo, na ktorom Vám pri InfiniBande a RoCE naozaj záleží. Na spoji cez ten istý prepínač čakajte ~1–2 µs.
• Mikrobenchmarky OSU — osu_latency, osu_bw, osu_allreduce na úrovni MPI. Správny nástroj pre HPC aplikácie, kým do hry vstúpi NCCL.
• nccl-tests — all_reduce_perf, all_gather_perf, reduce_scatter_perf. Jediný benchmark, ktorý pri tréningu AI naozaj niečo znamená. Preveruje presne tú cestu kódu, ktorú používa Váš beh. Preveďte rozsah od 8 B po 1 GB; krivka Vám povie, kde je štruktúra pokazená.

Rýchla kontrola: ak je busbw z nccl-tests all_reduce_perf pri dlhých správach výrazne pod 80 % linkovej rýchlosti karty, máte problém v sieťovej štruktúre, nie v softvéri. Prejdite vrstvy odhora tohto článku nadol.

Užitočný zvyk: výstup z nccl-tests si uložte ako súčasť uvedenia do prevádzky a spustite ho znovu po každej zmene firmvéru, ovládača či topológie. Regresia zachytená v deň, keď vznikla, je jednoriadkový diff. Zachytená o tri týždne neskôr je forenzné cvičenie.

Kedy na latencii naozaj záleží — a kedy nie

Latencia je dôležitá:

• Synchrónny allreduce gradientov pri dátovo paralelnom tréningu. Každá iterácia, každý uzol. Latencia v chvoste = stratený výpočet.
• Jemne delený pipeline paralelizmus s malými mikrodávkami. Čas bubliny na hraniciach stupňov je zdola obmedzený latenciou medzi uzlami.
• Tenzorovo paralelné delenie vrstiev, ktoré sa rozvetví a zase zbehne v rámci jedného dopredného/spätného prechodu — reťazec krátkych kolektívov, čistá hra o latenciu.
• Komunikácia krokov s parameter serverom pri vysokej frekvencii aktualizácií.

Latencia väčšinou dôležitá nie je:

• Dávkovanie inferencie na úrovni požiadaviek. Latenciu jednej požiadavky určuje výpočet na GPU (TTFT, dekódovanie na token). 10 µs siete je šum vedľa 50 ms dekódovania.
• Hromadné načítanie modelu z objektového úložiska pri štarte úlohy. Limituje priepustnosť.
• Zápis checkpointu na sieťové úložisko. Veľké sekvenčné zápisy, ladí sa na šírku pásma.
• Premiešanie v DataLoaderi cez prednačítanie vo workeroch. Dávkované, limituje priepustnosť.

Poctivý dôsledok: jednouzlový server so 4 alebo 8 GPU (chlieb a soľ sortimentu Kentino AI) komunikuje medzi GPU cez NVLink alebo PCIe, nie cez sieť. Sieť slúži na úložiská, telemetriu a občasný viacuzlový experiment. Optimalizovať štruktúru na latenciu kolektívov sa vyplatí až pri skutočnom viacuzlovom tréningu, ktorý väčšina zákazníkov Kentina neprevádzkuje. Pre čistú inferenciu a jednouzlový tréning stačí 25 GbE s čistým kernelovým zásobníkom.

---

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich prepájajú. Pripomienky a opravy uvítame na info@kentino.com.