Disekcia latencie: Kam ide každá mikrosekunda v sieti klastrov umelej inteligencie

Ľudia, ktorí dimenzujú siete klastrov s umelou inteligenciou, zvyčajne začínajú so šírkou pásma – 100, 200, 400 GbE – a potom sú prekvapení, keď ich benchmark allreduce zobrazí číslo, ktoré sa ani zďaleka neblíži rýchlosti linky. Dôvodom je takmer vždy latencia a režim malých správ, kde sú grafy šírky pásma zbytočné.

Tento článok rozoberá jednotlivé kroky a vysvetľuje ich jednotlivé kroky. Čísla uvedené nižšie predstavujú konsenzuálny rozsah z verejných meraní, dokumentácie NVIDIA/Mellanox a našich vlastných testov. Berte ich ako rozpočet, nie ako záruku – menia sa v závislosti od sieťovej karty, prepínača ASIC, verzie jadra, nastavení systému BIOS a vašej trpezlivosti pri ladení.

Publikum: ľudia špecifikujúci alebo riešiaci problémy s klastrovými štruktúrami umelej inteligencie. Nie je to ladenie kuchárskej knihy, ale mentálny model, ktorý robí kuchársku knihu čitateľnou.

Celý spiatočný let, jedna šmýkačka

64-bajtový ping-pong medzi dvoma GPU na rôznych uzloch cez 100 GbE prepínanú sieť s RDMA vyzerá zhruba takto:

Zložka Typický príspevok Poznámky
Príspevok aplikácie / serializácia 0.1 – 1 µs memcpy, zostavenie hlavičky, zápis deskriptora
Cesta vysielania sieťovej karty (slovesá RDMA) 0.3 – 0.8 µs sub-µs na moderných ConnectX / BlueField
Oneskorenie prevodu ~5 ns/m 50 ns počas 10 m DAC, zanedbateľné <100 m
Switch hop (prestrih, moderný) 250–600 ns InfiniBand <100 ns; Ethernet 400–600 ns
Prepínanie medzi spínanými kanálmi (ukladanie a preposielanie, 64 B) 1 – 3 µs Pridajte na začiatok serializáciu po bajtoch
Za každý pridaný chmeľ +latencia prepínača Leaf-spine pridáva 2 skoky oproti jednému prepínaču
Cesta RX sieťovej karty 0.3 – 0.8 µs Symetrický s TX na RDMA
Zásobník TCP/IP jadra (jednosmerný) 10 – 30 µs Cesta k socketom; s prerušeniami, kópiami
Obídenie jadra (slovesá DPDK / RDMA, jednosmerné) <1 us Dotazovanie v používateľskom priestore, nulová kópia
Príjem / deserializácia aplikácie 0.1 – 1 µs Prebudenie spotrebiteľa, dekódovanie hlavičky

Jednoprepínací RDMA RTT na 100 GbE / NDR InfiniBand pristáva na ~2 µs pre malé správy. Dvojskokový leaf-spine pridáva ~1 µs. Rovnaká cesta cez jadro TCP/IP pristane na 20 – 60 µs, čo je o rád viac, s horším správaním chvosta. Tieto dve čísla určujú takmer každé architektonické rozhodnutie uvedené nižšie.

Aplikácia TX
memcpy, deskriptor
0.1 – 1 µs
NIC TX
Prepínač
prerezaný
250–600 ns
NIC RX
Aplikácia RX
dekódovať, prebudiť spotrebiteľa
0.1 – 1 µs

Jednosmerná cesta RDMA: dominantnou premennou je prepínací skok (250 – 600 ns na Ethernete, < 100 ns na IB); oneskorenie vodiča pri < 100 m je zanedbateľné.

Drôt nie je problém

Svetlo vo vlákne sa šíri rýchlosťou ~dve tretiny c, takže šírenie je ~5 ns/m. 30 m radové vlákno s regálmi pridáva 150 ns jednosmerne; dokonca aj 500 m rozsiahly rozvod v areáli univerzity trvá jednu mikrosekundu. Serializácia je pri moderných rýchlostiach tiež malá: 64-bajtový rámec pri 100 Gb/s je 5.12 ns; 9000-bajtový jumbo rámec je 720 ns. Pre malé riadiace správy je serializácia zanedbateľná; pre hromadný prenos prestáva byť dôležitá, keď je potrubie dostatočne široké.

Latencia v skutočnosti existuje v softvéri, v prepínacích ASIC čipoch a v protokole, ktorý si vyberiete.

Prepínanie tkaniny: prerezávanie vs. ukladanie a preposielanie

Prepínač typu cut-through začne preposielať hneď po prečítaní cieľovej hlavičky. Prepínač typu store-and-forward ukladá celý rámec do vyrovnávacej pamäte, voliteľne overuje CRC a potom preposiela.

Prepnúť triedu Latencia na skok
Prepínač InfiniBand NDR/HDR (prerušenie) <100 ns
Prerušenie Ethernetu (trieda Tomahawk, AI fab) 400–600 ns
Prerušenie Ethernetu (staršie / generické) 600–900 ns
Ethernetové ukladanie a preposielanie, 64 B 1 – 3 µs
Ethernetové ukladanie a preposielanie, 1500 B 1.5 – 4 µs

Výhoda InfiniBandu je skutočná: kremík HPC to optimalizuje už dve desaťročia. Moderné ethernetové prepínače s umelou inteligenciou (Tomahawk 5, Jericho3-AI, Spectrum-X) prekonávajú väčšinu medzery v latencii a prekonávajú InfiniBand v hĺbke vyrovnávacej pamäte, čo je dôležitejšie pre incast allreduce.

V listovej chrbtici prechádza priečny prúd list → chrbtica → listNávrhy, ktoré minimalizujú počet skokov (plytký fat-tree, topológie optimalizované pre koľajnice), sa nesnažia šetriť šírku pásma; šetria 500 ns na každý zablokovaný skok v každom kolektíve.

Sieťový zásobník jadra

Obyčajný TCP/IP cez jadro Linuxu platí za paket za: odoslanie prerušení sieťovej karty (alebo polling NAPI), alokáciu skb a softirq, spracovanie TCP/IP, kópiu socket-buffera medzi jadrom a používateľským priestorom a prepínanie kontextu do aplikácie.

Pre malý paket na modernom x86 je to 10–30 µs jedným smerom v najlepšom prípade s dobou nárastu napätia nad 100 µs pri zaťažení. Je to tiež viazané na CPU – saturuje jadro rýchlosťou ~1 Mpps dávno predtým, ako to urobí sieťová karta. To sú náklady, ktoré sa zvyšok článku snaží eliminovať.

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

Štyri hlavné spôsoby, ako dostať jadro z dátovej cesty, ktoré sa líšia v tom, ako úplne ich obchádzajú a čo nechávajú na stole:

Cesta Minimálna latencia Model CPU kompatibilita Typické použitie
Jadrový TCP/IP 10–30 µs/cesta prerušenie Univerzálny Čokoľvek, čo nie je kritické z hľadiska latencie
AF_XDP 6–10 µs/cesta hybridný Nástroje Linuxu stále fungujú Stredná cesta; programy eBPF
DPDK 1–3 µs/cesta Zaneprázdnený prieskum Jadro nič nevidí Telco, HFT, NFV, vlastné paketové kanály
Slovesá RDMA <1 µs/cesta Dvojica frontu / CQE Vyžaduje RDMA NIC + fabric HPC, školenia pre umelú inteligenciu, siete úložísk

Niekoľko praktických poznámok:

  • DPDK a RDMA nie sú zameniteľné. DPDK spúšťa ľubovoľné spracovanie paketov v používateľskom priestore rýchlosťou linky; RDMA implementuje špecifický pamäťovo-sémantický protokol s hardvérovým odľahčením. Zaťaženia umelej inteligencie vyžadujú RDMA – NCCL a úložné zásobníky ho ovládajú natívne. DPDK sa zobrazuje v inferenčných proxy, telemetrii a vlastných dátových rovinách.
  • AF_XDP je stredná cesta. Pripája sa k ovládaču na vrstve eBPF, dosahuje latenciu pod 10 µs a na rozdiel od DPDK nekradne sieťovú kartu z operačného systému. Správna odpoveď pre zariadenia so zmiešaným použitím.
  • XDP bez AF_XDP slúži na inline presmerovanie/presmerovanie/odstraňovanie (DDoS scrubbing, vyrovnávače záťaže). Spracováva pakety v jadre na strane ovládača; nepresúva ich do používateľského priestoru.

Pre klaster umelej inteligencie: RDMA cez InfiniBand alebo RoCEv2 pre GPU-to-GPU, obyčajný TCP/IP pre všetko ostatné (správa, telemetria, sťahovanie modelu). Nepreháňajte s pomalými cestami.

Zlúčenie prerušení, GRO/LRO: pasca na priepustnosť

Linux a väčšina ovládačov sieťových kariet sú dodávané s optimalizovaným priepustnosťou, nie latenciou. Dôležité sú dva ovládače:

  • Prerušenie zlúčenia. Sieťová karta čaká nakonfigurovaný časový úsek (alebo počet paketov) pred vyvolaním prerušenia. Znižuje réžiu na paket; pridáva latenciu rovnú dĺžke okna. rx-usecs 50 na tichom spoji sčíta až 50 µs.
  • GRO / LRO. Jadro (GRO) alebo sieťová karta (LRO) agreguje prichádzajúce segmenty TCP do jedného väčšieho bloku SKB pred odoslaním. Spracovanie je lacnejšie, ale agregátor zámerne čaká na viac paketov, čím pridáva mikrosekundy.

Kompromis je čestný a nevyjednávateľný: V tej istej konfigurácii nemôžete mať súčasne maximálnu priepustnosť aj maximálnu latenciu. Pre uzol GPU vyžaduje sieťová karta RDMA NIC, ktorá spracováva allreduce rx-usecs 0 alebo 1, adaptívne zlúčenie vypnuté, GRO vypnuté na rozhraní na strane RDMA. Samostatná riadiaca sieťová karta udržiava predvolené hodnoty; nenachádza sa na kritickej ceste.

Dôsledok: Sieťová karta s dvojitým účelom pre kolektívne úlohy RDMA a sťahovanie TCP bude mať priemerné čísla pre obe pokiaľ nerozdelíte prevádzku medzi fronty alebo rozhrania. Vážne uzly AI majú jednu alebo dve vyhradené sieťové karty RDMA (ConnectX-7/8, BlueField-3) a samostatnú sieťovú kartu pre správu.

Ani aplikačná vrstva nie je bezplatná.

Dva náklady na vrchole zásobníka sa zriedkakedy dostanú do architektonických diagramov:

  • memcpy. 4 MB memcpy trvá ~200 µs na jednom jadre pri ~20 GB/s. Ak váš kolektív skopíruje tenzorové dáta do vyrovnávacej pamäte pred odoslaním, spotrebovali ste viac času ako celá sieťová cesta späť. GPUDirect RDMA to preskočí – sieťová karta číta priamo z pamäte GPU.
  • Serializácia. Protobuf, JSON alebo ručne generované rámcovanie pridáva desiatky µs pre netriviálne užitočné zaťaženia. Je to v poriadku v RPC riadiacej roviny; fatálne vo vnútornej slučke allreduce. NCCL sa tomu vyhýba pomocou pevných binárnych deskriptorov a predregistrovanej pamäte.

Ak je váš „RDMA-vyladený“ stack stále pomalý, profilujte používateľský priestor predtým, ako obviňujete fabric. Videli sme 30 µs kolektívy, kde 25 µs bolo pretvorenie tenzora PyTorch a iba 5 µs bolo prepojenie a spínač.

Kolektívne operácie: latencia vs. šírka pásma a prečo je dôležitá veľkosť paketu

NCCL (a akákoľvek kolektívna knižnica) vyberá algoritmus na základe veľkosti správy:

  • Malé správy sú ohraničené latenciou. NCCL používa stromové algoritmy a svoj protokol LL (4-bajtové dáta so 4-bajtovými príznakmi cez 8-bajtové atomické úložiská, žiadne pamäťové ploty). BusBw je zlomok rýchlosti linky; meriate réžiu na správu × počet správ.
  • Veľké správy sú obmedzené šírkou pásma. NCCL prepína na algoritmy zvonenia, ktoré sa približujú rýchlosti linky najpomalšieho spojenia. Latencia na správu mizne pod hranicou megabajtov.

Prechod trvá približne medzi 64 KB a 1 MB v závislosti od topológie a sieťovej karty. Pod ňou dominuje latencia prepínačov a sieťových kariet a zásobník protokolov. Hore odčítavate rýchlosť kábla z grafu.

Allreduce busbw — H100 / NDR InfiniBand klastre s jedným rackom
Veľkosť správy Algoritmus BusBw (jeden uzol, 8× NVLink) BusBw (8 uzlov, NDR IB)
1 KB Strom / LL ~ 5 GB / s ~ 2 GB / s
64 KB strom ~ 80 GB / s ~ 20 GB / s
1 MB krúžok ~ 250 GB / s ~ 40 GB / s
64 MB krúžok ~ 370 GB / s ~ 45 GB / s
1 GB krúžok ~ 450 GB / s ~ 48 GB / s

Zverejnený strop H100 NVLink je 450 GB/s; dosiahnutie tohto limitu pri menších správach alebo medzi uzlami je náročné. Pre zostavu Kentino – 5090 / 4090 / RTX Pro 6000 Blackwell nad 100 GbE RoCE – sa očakáva ~10–12 GB/s zbernicovej šírky pásma na uzol pre veľké správy na 100 GbE, pričom algoritmus je rovnaký.

Jitter je horší ako latencia

Ak je latencia allreduce na každom uzle 30 µs ± 1 µs, bariéra čaká 30 µs. Ak je to priemer 30 µs, pričom jeden uzol má 300 µs raz za tisíc iterácií, každá ostatná GPU je nečinná 270 µs pri každom spustení tohto chvosta. Počas epochy 100 000 iteracií na 16 uzloch to predstavuje hodiny stratených výpočtov.

Preto je latencia P99 / P999 pre trénovanie AI dôležitejšia ako priemerná latencia. Bariérový kolektív je najpomalšie víťazstvá operácia: klaster sa pohybuje rýchlosťou svojho najhoršieho uzla.

Zdroje chvenia:

  • Preťaženie vyrovnávacej pamäte incast. AllReduce je v každej iterácii many-to-one (mnohé k jednej). Prepínače s plytkou vyrovnávacou pamäťou zahadzujú pakety, aktivuje sa pauza PFC, latencia prudko stúpa o 10× – 100×. Prepínače umelej inteligencie s hlbokou vyrovnávacou pamäťou (Jericho3-AI, Spectrum-X) absorbujú tento burst.
  • Jitter hostiteľského procesora. Úloha cron, neohraničené vlákno jadra alebo odchýlka frekvencie CPU spôsobí odchýlku 1 ms. Izolujte jadrá pre vlákno ISR/poll sieťovej karty, vypnite stavy C na kritických CPU, pripnite procesy.
  • Adaptívne zlúčenie. Ovládač „pomáha“ zvýšením koalescencie pri záťaži; latencia prudko stúpa. Vypnite ho explicitne na sieťovej karte RDMA.
  • Topologická asymetria. Jeden list s rýchlosťou 200 GbE, druhý s rýchlosťou 100 GbE. Pomalší list je vaším poschodím pre každý kolektív.

Správna hodnota SLO pre AI fabric je chvostová latencia, nie stredná latencia.

Správne meranie

ping meria RTT protokolu ICMP jadra na úrovni riadenia. Je to zbytočný na charakterizáciu RDMA tkaniny. Nástroje, ktoré fungujú:

  • sockperf ping-pong — latencia UDP/TCP s rozlíšením sub nanosekundy. Vhodné pre základné línie a regresie kernelu.
  • ib_send_lat, ib_write_lat (perftest suite) – priama latencia slovesa RDMA. Číslo, ktoré vás skutočne zaujíma pre InfiniBand a RoCE. Na spojení s rovnakým prepínačom očakávajte ~1–2 µs.
  • Mikro-benchmarky OSU - osu_latency, osu_bw, osu_allreduce na úrovni MPI. Správny nástroj pre HPC aplikácie pred NCCL je na obrázku.
  • nccl-tests - all_reduce_perf, all_gather_perf, reduce_scatter_perf. Jediný benchmark, ktorý je dôležitý pre tréning umelej inteligencie. Cvičí sa presná cesta kódu, ktorú používa váš beh. Zmena rozsahu 8 B na 1 GB; krivka vám ukáže, kde je štruktúra prerušená.

Kontrola príčetnosti: ak nccl-tests all_reduce_perf Ak je rýchlosť zbernice pri veľkých správach výrazne nižšia ako 80 % rýchlosti linky sieťovej karty, máte problém s fabric, nie so softvérom. Prejdite si vrstvy od začiatku článku nadol.

Užitočný zvyk: uložiť výstup nccl-tests ako súčasť uvedenia do prevádzky a znova spustiť po každej zmene firmvéru, ovládača alebo topológie. Regresia zachytená v deň, keď sa stane, je rozdiel v jednom riadku. Zachytená o tri týždne neskôr je to forenzné cvičenie.

Kedy na latencii skutočne záleží – a kedy nie

Latencia je dôležitá:

  • Synchrónny gradient allreduce pri paralelnom trénovaní dát. Každá iterácia, každý uzol. Latencia chvosta = strata výpočtov.
  • Jemnozrnný paralelizmus potrubia s malými mikrodávkami. Čas bublín na hraniciach etáp je obmedzený latenciou medzi uzlami.
  • Rozdelenie tenzorovo paralelných vrstiev ktoré sa rozprestierajú a dozadu v rámci prihrávky dopredu/dozadu – reťazec malých kolektívov, čistá hra s latenciou.
  • Komunikácia medzi parametrami a serverom krok za krokom pri vysokej rýchlosti aktualizácie.

Latencia väčšinou neznamená:

  • Dávkovanie inferencie pri granularite požiadaviek. Latencia na požiadavku je dominantne ovplyvnená výpočtami GPU (TTFT, dekódovanie na token). 10 µs siete je šum v porovnaní s 50 ms dekódovania.
  • Hromadné načítanie modelu z úložiska objektov na začiatku úlohy. Obmedzené na priepustnosť.
  • Zápis kontrolného bodu do sieťového úložiska. Veľké sekvenčné zápisy, ladenie s ohľadom na šírku pásma.
  • Náhodné prehrávanie dátového zavádzača prostredníctvom predbežného načítania pracovníkov. Dávkované, viazané na priepustnosť.

Úprimný dôsledok: Jednouzlový server so 4× alebo 8× grafickými procesormi (základná zostava K-AI od spoločnosti Kentino) vykonáva komunikáciu medzi grafickými procesormi cez NVLink alebo PCIe, nie cez sieť. Sieť slúži na úložisko, telemetriu a občasný experiment s viacerými uzlami. Optimalizácia štruktúry pre kolektívnu latenciu sa vyplatí iba pri skutočnom tréningu s viacerými uzlami, ktorý väčšina zákazníkov Kentina nespúšťa. Pre čistú inferenciu a tréning s jedným uzlom stačí 25 GbE s čistým jadrom.

Čo urobiť ďalej

Ak zadávate novú látku, spustite túto postupnosť:

  1. ib_send_lat medzi každým párom uzlov. Čokoľvek viac ako 1.5-násobok mediánu je signál – zlý kábel, znečistená optika, nesprávne smerovaná topológia.
  2. nccl-tests all_reduce_perf cez 8 B → 1 GB. Uložte krivku. Porovnajte ju s publikovanou referenciou pre vašu sieťovú kartu a triedu prepínača.
  3. Porovnajte TCP sockperf ping-pong proti RDMA ib_send_lat. Medzera by mala byť 10–30×. Ak je 2×, váš kernel stack je nezvyčajne rýchly (nepravdepodobné) alebo je vaša RDMA cesta poškodená (pravdepodobne — nesprávna konfigurácia PFC, nesprávne nastavenie DCQCN, RDMA sa vracia k mäkkej ceste).
  4. Znovu spustite nccl-testy pod záťažou. Súbežne prenášajte dáta z úložiska a sledujte degradáciu zbernice. Zdravé klastre degradujú o <20 % pri realistickom zmiešanom zaťažení; choré klastre sa zrútia.
  5. Laďte jednu premennú naraz. Zlúčenie, adaptívne smerovanie, prahy PFC, značenie ECN. Zdokumentujte každú zmenu. Zmeňte tri veci a jedna pomôže – neviete ktorú.
  6. Upozornenie na kolektívnu latenciu P99, nie zlý. Zlý problém skrýva; P99 je to, čo tréning skutočne cíti.

Následné opatrenia — N07 o smerovaní a riadení preťaženia (ECMP, DCQCN, ECN), N08 o nastavení RDMA v praxi a K02 o výbere distribuovaného tréningového algoritmu – hlbšie sa venujeme konkrétnym rozhodnutiam, ktoré tento článok iba načrtáva.

Latencia v AI fabric nie je samotný drôt, ale všetko, čo je okolo drôtu omotané – a riešením je takmer vždy skrátiť cestu softvéru skôr, ako miniete viac peňazí na hardvér.


Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.