Disekce latence: Kam se v síti klastrů umělé inteligence vydává každá mikrosekunda

Lidé, kteří dimenzují sítě clusterů s umělou inteligencí, obvykle začínají s šířkou pásma – 100, 200, 400 GbE – a pak jsou překvapeni, když jejich benchmark allreduce vypíše číslo, které se ani zdaleka neblíží rychlosti linky. Důvodem je téměř vždy latence a režim malých zpráv, kde jsou grafy šířky pásma k ničemu.

Tento článek rozebírá jednotlivé kroky a popisuje každý z nich. Níže uvedená čísla představují konsensuální rozpětí z veřejných měření, dokumentace NVIDIA/Mellanox a našich vlastních testovacích lavic. Berte je jako rozpočet, nikoli jako záruku – mění se v závislosti na síťové kartě, přepínacím ASIC, verzi jádra, nastavení BIOSu a vaší trpělivosti s laděním.

Cílová skupina: lidé, kteří specifikují nebo řeší problémy s clusterovými strukturami umělé inteligence. Nejedná se o ladící kuchařku, ale o mentální model, díky kterému je kuchařka čitelná.

Celá okružní cesta, jedna skluzavka

64bajtový ping-pong mezi dvěma GPU na různých uzlech přes 100GbE přepínanou síť s RDMA se rozkládá zhruba takto:

Jednopřepínací RDMA RTT na 100 GbE / NDR InfiniBand přistává na ~2 µs pro malé zprávy. Dvouskokový leaf-spine přidává ~1 µs. Stejná cesta přes kernel TCP/IP končí na 20–60 µs, což je o řád více, s horším chováním ocasu. Tato dvě čísla určují téměř každé architektonické rozhodnutí níže.

Jednosměrná cesta RDMA: dominantní proměnnou je přepínací skok (250–600 ns na Ethernetu, <100 ns na IB); zpoždění vodiče <100 m je zanedbatelné.

Drát není problém

Světlo ve vlákně se šíří rychlostí ~dvě třetiny c, takže šíření je ~5 ns/m. 30 m dlouhé vlákno s řadou stojanů přidává jednosměrně 150 ns; i 500 m dlouhý úsek v areálu sítě trvá jednu mikrosekundu. Serializace je při moderních rychlostech také malá: 64bajtový rámec při 100 Gb/s je 5.12 ns; jumbo rámec o 9000 bajtech je 720 ns. Pro malé řídicí zprávy je serializace zanedbatelná; pro hromadný přenos přestává hrát roli, jakmile je potrubí dostatečně široké.

Latence ve skutečnosti spočívá v softwaru, v ASICech přepínačů a v protokolu, který si vyberete.

Přepínací tkanina: prořezávání vs. ukládání a předávání

Přepínač typu cut-through začne přeposílání, jakmile přečte záhlaví cíle. Přepínač typu store-and-forward ukládá celý rámec do vyrovnávací paměti, volitelně ověří CRC a poté přeposílá.

Výhoda InfiniBandu je skutečná: HPC křemík tuto optimalizaci optimalizuje již dvě desetiletí. Moderní ethernetové přepínače s umělou inteligencí (Tomahawk 5, Jericho3-AI, Spectrum-X) překonávají většinu mezer v latenci a překonávají InfiniBand v hloubce vyrovnávací paměti, což je pro incast s technologií allreduce důležitější.

V listové páteři probíhá příčný proud list → páteř → listNávrhy, které minimalizují počet skoků (mělký fat-tree, topologie optimalizované pro kolejnice), se nesnaží šetřit šířku pásma; šetří 500 ns na každý zablokovaný skok v každém kolektivu.

Síťový zásobník jádra

Prostý TCP/IP přes linuxové jádro platí za paket za: odesílání přerušení NIC (nebo dotazování NAPI), alokaci skb a softirq, zpracování TCP/IP, kopii socket-bufferu mezi jádrem a uživatelským prostorem a přepnutí kontextu do aplikace.

Pro malý paket na moderním x86 je tohle 10–30 µs jedním směrem v nejlepším případě s dobou nárůstu výkonu nad 100 µs při zátěži. Je to také vázáno na CPU – saturuje jádro rychlostí ~1 Mpps dlouho předtím, než to udělá síťová karta. To je cena, kterou se zbytek článku snaží eliminovat.

Bypass jádra: DPDK, RDMA, XDP, AF_XDP

Čtyři hlavní způsoby, jak dostat jádro z datové cesty, lišící se v tom, jak úplně je obcházejí a co ponechávají na stole:

Několik praktických poznámek:

• DPDK a RDMA nejsou zaměnitelné. DPDK zpracovává libovolné pakety v uživatelském prostoru rychlostí linky; RDMA implementuje specifický protokol pro sémantiku paměti s hardwarovým odlehčením zátěže. Úlohy umělé inteligence vyžadují RDMA – NCCL a úložné zásobníky jej používají nativně. DPDK se objevuje v inferenčních proxy, telemetrii a vlastních datových rovinách.
• AF_XDP je střední cesta. Připojuje se k ovladači na vrstvě eBPF, dosahuje latence pod 10 µs a na rozdíl od DPDK nekrade síťovou kartu z operačního systému. Správná odpověď pro zařízení se smíšeným využitím.
• XDP bez AF_XDP je určen pro inline drop/redirect/forwarding (DDoS scrubbing, load balancery). Zpracovává pakety uvnitř jádra v driver hooku; nepřesouvá je do uživatelského prostoru.

Pro cluster umělé inteligence: RDMA přes InfiniBand nebo RoCEv2 pro komunikaci mezi GPU, pro všechno ostatní (správa, telemetrie, stahování modelu) prostý TCP/IP. Nepřetěžujte pomalé cesty.

Slučování přerušení, GRO/LRO: past na propustnost

Linux a většina ovladačů síťových karet jsou dodávány s optimalizací propustnosti, nikoli latence. Důležité jsou dva knoflíky:

• Slučování přerušení. Síťová karta čeká po nastavenou dobu (v µs) před vyvoláním přerušení. Snižuje režii na paket; přidává latenci odpovídající délce okna. rx-usecs 50 na klidném spoji se sčítá až 50 µs.
• GRO / LRO. Jádro (GRO) nebo síťová karta (LRO) agreguje příchozí TCP segmenty do jednoho většího bloku paketů (skb) před jejich odesláním. Je to sice levnější na zpracování, ale agregátor záměrně čeká na více paketů a přidává tak mikrosekundy.

Kompromis je čestný a nevyjednávatelný: Nemůžete mít ve stejné konfiguraci zároveň špičkovou propustnost i špičkovou latenci. Pro uzel GPU vyžaduje síťová karta RDMA zpracovávající allreduce rx-usecs 0 nebo 1, adaptivní slučování vypnuto, GRO vypnuto na rozhraní na straně RDMA. Samostatná síťová karta pro správu udržuje výchozí nastavení; nenachází se na kritické cestě.

Důsledek: Síťová karta s dvojitým účelem pro RDMA kolektivy a TCP stahování bude v obou případech poskytovat průměrná čísla. pokud nerozdělíte provoz mezi fronty nebo rozhraní. Vážné uzly umělé inteligence mají jednu nebo dvě dedikované síťové karty RDMA (ConnectX-7/8, BlueField-3) a samostatnou síťovou kartu pro správu.

Aplikační vrstva také není zdarma

Dva náklady na vrcholu zásobníku se do architektonických diagramů jen zřídka dostanou:

• memcpy. 4 MB memcpy trvá ~200 µs na jednom jádru rychlostí ~20 GB/s. Pokud váš kolektiv zkopíruje tenzorová data do staging bufferu před odesláním, spálili jste více času, než kolik trvá celá síťová cesta. GPUDirect RDMA to přeskočí – síťová karta čte přímo z paměti GPU.
• Serializace. Protobuf, JSON nebo ručně generované rámce přidávají desítky µs pro netriviální datové zátěže. Je to v pořádku v RPC v řídicí rovině, ale fatální ve vnitřní smyčce allreduce. NCCL se tomu vyhýbá pomocí pevných binárních deskriptorů a předregistrované paměti.

Pokud je váš stack „vyladěný na RDMA“ stále pomalý, profilujte uživatelský prostor, než z toho viníte fabric. Viděli jsme kolektivy za 30 µs, kde 25 µs tvořilo přetvoření tenzoru PyTorch a pouze 5 µs tvořilo spojení a přepínání.

Kolektivní operace: latence vs. šířka pásma a proč je důležitá velikost paketu

NCCL (a jakákoli kolektivní knihovna) vybírá algoritmus na základě velikosti zprávy:

• Malé zprávy jsou omezeny latencí. NCCL používá stromové algoritmy a svůj protokol LL (4bajtová data se 4bajtovými příznaky přes 8bajtové atomické úložiště, žádné paměťové ploty). BusBw je zlomek rychlosti linky; měříte režii na zprávu × počet zpráv.
• Velké zprávy jsou omezeny šířkou pásma. NCCL přepíná na algoritmy vyzvánění, které se blíží rychlosti linky nejpomalejšího spojení. Latence na zprávu mizí pod hranicí megabajtů.

Přechod trvá zhruba mezi 64 KB a 1 MB v závislosti na topologii a síťové kartě. Pod ní dominuje latence přepínačů a síťových karet a protokolový stack. Nahoře odečítáte rychlost kabelu z grafu.

Publikovaný strop pro H100 NVLink je 450 GB/s; dosáhnout ho u menších zpráv nebo mezi uzly je náročný úkol. U řady Kentino – 5090 / 4090 / RTX Pro 6000 Blackwell přes 100 GbE RoCE – se očekává ~10–12 GB/s na uzel pro velké zprávy na 100 GbE, přičemž algoritmus má stejný tvar.

Jitter je horší než latence

Pokud je latence allreduce na každém uzlu 30 µs ± 1 µs, bariéra čeká 30 µs. Pokud je průměrně 30 µs, přičemž jeden uzel čeká 300 µs jednou za tisíc iterací, každá další GPU je nečinná 270 µs pokaždé, když se tento ocas aktivuje. Během epochy 100 000 iterací na 16 uzlech to představuje hodiny ztracených výpočetních prostředků.

Proto je pro trénování umělé inteligence latence P99 / P999 důležitější než průměrná latence. Bariérový kolektiv je nejpomalejší výhry operace: cluster se pohybuje rychlostí svého nejhoršího uzlu.

Zdroje chvění:

• Zahlcení vyrovnávací paměti incast. AllReduce je v každé iteraci více než jedna. Přepínače s mělkou vyrovnávací pamětí zahazují pakety, aktivuje se pauza PFC, latence se zvyšuje 10×–100×. Přepínače s hlubokou vyrovnávací pamětí a umělou inteligencí (Jericho3-AI, Spectrum-X) absorbují tento burst.
• Jitter hostitelského procesoru. Úloha cron, neohraničené vlákno jádra nebo odchylka frekvence CPU způsobí odchylku 1 ms. Izolujte jádra pro vlákno ISR/poll síťové karty, zakažte stavy C na kritických CPU a zapněte procesy.
• Adaptivní koalescence. Ovladač „pomáhá“ tím, že zvyšuje koalescenci při zátěži; latence se nenápadně zvyšuje. Vypněte jej explicitně na síťové kartě RDMA.
• Topologická asymetrie. Jeden list na 200 GbE, druhý na 100 GbE. Ten pomalejší je vaším patrem pro každý kolektiv.

Správnou hodnotou SLO pro AI fabric je latence ocasu, nikoli střední latence.

Správné měření

ping měří ICMP RTT protokolu kernel-stack na úrovni správy. Je to zbytečný pro charakterizaci RDMA tkaniny. Nástroje, které fungují:

• sockperf ping-pong — latence UDP/TCP s rozlišením pod nanosekundy. Vhodné pro základní linie a regrese kernel-stacku.
• ib_send_lat, ib_write_lat (perftest suite) — Přímá latence sloves RDMA. Číslo, které vás skutečně zajímá pro InfiniBand a RoCE. Na propojení se stejným přepínačem očekávejte ~1–2 µs.
• Mikro-benchmarky OSU - osu_latency, osu_bw, osu_allreduce na úrovni MPI. Správný nástroj pro HPC aplikace před NCCL je na obrázku.
• nccl-tests - all_reduce_perf, all_gather_perf, reduce_scatter_perf. Jediný benchmark, který je důležitý pro trénink umělé inteligence. Procvičuje přesnou cestu kódu, kterou používá váš běh. Rozsah 8 B až 1 GB; křivka vám ukazuje, kde je struktura přerušena.

Kontrola příčetnosti: pokud nccl-tests all_reduce_perf Pokud je rychlost sběrnice Busbw při velkých zprávách výrazně nižší než 80 % rychlosti síťové linky, máte problém s fabric, nikoli se softwarem. Projděte si vrstvy od začátku článku dolů.

Užitečný zvyk: ukládat výstup nccl-testů jako součást uvádění do provozu a znovu spouštět po každé změně firmwaru, ovladače nebo topologie. Regrese zachycená v den, kdy k ní dojde, je rozdíl o jednom řádku. Zachycená o tři týdny později je to forenzní cvičení.

Kdy na latenci skutečně záleží – a kdy ne

Latence je důležitá:

• Synchronní gradient allreduce v paralelním datovém trénování. Každá iterace, každý uzel. Latence ocasu = výpočetní ztráta.
• Jemnozrnný paralelismus potrubí s malými mikrodávkami. Doba bublin na hranicích fází je omezena latencí mezi uzly.
• Tenzorově paralelní vrstvení se rozděluje které se rozbíhají v rámci přihrávky vpřed/vzad – řetězec malých kolektivů, čistá hra s latencí.
• Komunikace mezi parametry a serverem krok za krokem při vysoké frekvenci aktualizací.

Latence většinou ne:

• Dávkování inference při granularitě požadavků. Latence na požadavek je dominantně ovlivněna výpočetními prostředky GPU (TTFT, dekódování na token). 10 µs sítě je šum ve srovnání s 50 ms dekódování.
• Hromadné načtení modelu z úložiště objektů při spuštění úlohy. Omezeno na propustnost.
• Zápis kontrolního bodu k síťovému úložišti. Velké sekvenční zápisy, ladění s ohledem na šířku pásma.
• Náhodné přehrávání datového zavaděče prostřednictvím předběžného načítání pracovníků. Dávkované, omezené propustností.

Upřímný důsledek: Jednouzlový server se 4× nebo 8 GPU (základní řada K-AI od Kentina) provádí komunikaci mezi GPU přes NVLink nebo PCIe, nikoli přes síť. Síť slouží pro úložiště, telemetrii a občasné experimenty s více uzly. Optimalizace fabric pro kolektivní latenci se vyplatí pouze při skutečném trénování s více uzly, které většina zákazníků Kentina nespustí. Pro čistou inferenci a trénování s jedním uzlem stačí 25 GbE s čistým kernel stackem.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.