Pitva latence: kam v síti AI clusteru mizí každá mikrosekunda

Lidé, kteří dimenzují sítě pro AI clustery, obvykle začínají u propustnosti — 100, 200, 400 GbE — a pak je překvapí, že jejich allreduce benchmark vypíše číslo ani zdaleka nedosahující linkové rychlosti. Důvodem je skoro vždy latence a režim malých zpráv, ve kterém jsou grafy propustnosti k ničemu.

Tento článek rozebírá jeden round trip na součástky a vyúčtuje každý krok. Čísla níže jsou konsenzuální rozsah z veřejných měření, dokumentace NVIDIA/Mellanox a našich vlastních testů. Berte je jako rozpočet, ne jako záruku — mění se s křemíkem NIC, ASIC switche, verzí jádra, nastavením BIOSu a s tím, jak trpěliví jste při ladění.

Pro koho to je: pro ty, kdo specifikují nebo řeší problémy sítí AI clusterů. Není to kuchařka na ladění, ale myšlenkový model, díky kterému se kuchařka dá číst.

Celý round trip na jednom slidu

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

RDMA RTT přes jeden switch na 100 GbE / NDR InfiniBandu vychází u malých zpráv na ~2 µs. Dvouskoková leaf-spine přidá ~1 µs. Stejná cesta přes TCP/IP v jádře vychází na 20–60 µs, tedy o řád víc a s horším chováním v tailu. Tahle dvě čísla řídí téměř každé architektonické rozhodnutí níže.

Jednosměrná RDMA cesta: skok přes switch (250–600 ns na Ethernetu, <100 ns na IB) je dominantní proměnná; zpoždění na vedení je pod 100 m zanedbatelné.

Problém není vedení

Světlo se ve vlákně šíří rychlostí ~dvou třetin c, takže propagace je ~5 ns/m. 30m vlákno přes řadu racků přidá 150 ns jedním směrem; i 500m trasa po areálu je jedna mikrosekunda. Serializace je při dnešních rychlostech také malá: 64bajtový rámec při 100 Gb/s je 5.12 ns, 9000bajtový jumbo rámec 720 ns. U malých řídicích zpráv je serializace zanedbatelná, u hromadných přenosů přestane hrát roli, jakmile je trubka dost široká.

Latence ve skutečnosti sídlí v softwaru, v ASIC switchů a v protokolu, který si zvolíte.

Přepínaná síť: cut-through versus store-and-forward

Cut-through switch začne přeposílat, jakmile přečte cílovou hlavičku. Store-and-forward switch nabufferuje celý rámec, volitelně ověří CRC a teprve pak přeposílá.

Výhoda InfiniBandu je reálná: HPC křemík to optimalizuje už dvě dekády. Moderní Ethernet switche pro AI (Tomahawk 5, Jericho3-AI, Spectrum-X) většinu latenčního rozdílu dotahují a InfiniBand překonávají hloubkou bufferů, která u allreduce incastu váží víc.

V leaf-spine prochází tok mezi racky cestou leaf → spine → leaf. Návrhy, které minimalizují počet skoků (mělký fat-tree, rail-optimized topologie), se nesnaží šetřit propustnost; šetří 500 ns za každý ušetřený skok u každé kolektivní operace.

Síťový stack jádra

Běžné TCP/IP přes jádro Linuxu platí za každý paket: dispatch přerušení NIC (nebo NAPI polling), alokaci skb a softirq, zpracování TCP/IP, kopii socket bufferu mezi jádrem a user space a přepnutí kontextu do aplikace.

U malého paketu na moderním x86 je to 10–30 µs jedním směrem v nejlepším případě, s tailovými špičkami nad 100 µs pod zátěží. Navíc je to omezené CPU — jedno jádro vytíží na ~1 Mpps dávno před NIC. Přesně tuto cenu se zbytek článku snaží odstranit.

Obejití jádra: DPDK, RDMA, XDP, AF_XDP

Čtyři mainstreamové způsoby, jak dostat jádro z datové cesty, lišící se mírou obejití i tím, co obětují:

Pár praktických poznámek:

• DPDK a RDMA nejsou zaměnitelné. DPDK provozuje libovolné zpracování paketů v user space při linkové rychlosti; RDMA implementuje konkrétní protokol s paměťovou sémantikou a hardwarovým offloadem. AI workloady chtějí RDMA — NCCL i storage stacky jím mluví nativně. DPDK se objevuje v inference proxy, telemetrii a vlastních dataplane.
• AF_XDP je zlatá střední cesta. Napojuje se na ovladač ve vrstvě eBPF, dosahuje latence pod 10 µs a na rozdíl od DPDK nebere NIC operačnímu systému. Správná odpověď pro stroje se smíšeným využitím.
• XDP bez AF_XDP slouží pro inline zahazování/přesměrování/přeposílání (čištění DDoS, load balancery). Zpracovává pakety uvnitř jádra v hooku ovladače; nepřesouvá je do user space.

Pro AI cluster: RDMA přes InfiniBand nebo RoCEv2 pro komunikaci GPU–GPU, běžné TCP/IP pro všechno ostatní (management, telemetrie, stahování modelů). Pomalé cesty nepřekombinovávejte.

Interrupt coalescing, GRO/LRO: past na propustnost

Linux a většina ovladačů NIC přicházejí naladěné na propustnost, ne na latenci. Záleží na dvou parametrech:

• Interrupt coalescing. NIC čeká nastavené okno v µs (nebo počet paketů), než vyvolá přerušení. Snižuje režii na paket; přidává latenci rovnou délce okna. rx-usecs 50 přidá na klidné lince až 50 µs.
• GRO / LRO. Jádro (GRO) nebo NIC (LRO) slučuje příchozí TCP segmenty do jednoho většího skb, než je pošle výš. Zpracování je levnější, ale agregátor záměrně čeká na další pakety a přidává mikrosekundy.

Kompromis je poctivý a nesmlouvavý: na jedné konfiguraci nemůžete mít zároveň špičkovou propustnost i špičkovou latenci. Na GPU uzlu chce RDMA NIC obsluhující allreduce rx-usecs 0 nebo 1, vypnutý adaptivní coalescing a vypnuté GRO na rozhraní na straně RDMA. Oddělená management NIC si nechá výchozí hodnoty; není na kritické cestě.

Z toho plyne: NIC používaná zároveň pro RDMA kolektivy i TCP stahování bude mít průměrná čísla v obou disciplínách, pokud provoz nerozdělíte mezi fronty nebo rozhraní. Seriózní AI uzly mají jednu nebo dvě vyhrazené RDMA NIC (ConnectX-7/8, BlueField-3) plus samostatnou management NIC.

Ani aplikační vrstva není zadarmo

Dvě položky na vrcholu stacku se do architektonických diagramů dostanou jen zřídka:

• memcpy. 4MB memcpy trvá na jednom jádře při ~20 GB/s zhruba 200 µs. Pokud Vaše kolektivní operace kopíruje data tenzoru do staging bufferu, než je odešle, spálili jste víc času, než zabere celý síťový round trip. GPUDirect RDMA to přeskakuje — NIC čte přímo z paměti GPU.
• Serializace. Protobuf, JSON nebo vlastní framing přidávají u netriviálních payloadů desítky µs. V RPC na řídicí rovině v pořádku; ve vnitřní smyčce allreduce fatální. NCCL se tomu vyhýbá pevnými binárními deskriptory a předem registrovanou pamětí.

Pokud je Váš „na RDMA vyladěný“ stack stále pomalý, profilujte nejdřív user space, než začnete vinit fabriku. Viděli jsme 30µs kolektivní operace, kde 25 µs zabral reshape tenzoru v PyTorchi a jen 5 µs vedení a switch.

Kolektivní operace: latence versus propustnost a proč záleží na velikosti paketu

NCCL (a každá knihovna kolektivních operací) volí algoritmus podle velikosti zprávy:

• Malé zprávy jsou omezené latencí. NCCL používá stromové algoritmy a svůj protokol LL (4 bajty dat se 4bajtovými příznaky přes 8bajtové atomické zápisy, bez paměťových bariér). BusBw je zlomkem linkové rychlosti; měříte režii na zprávu × počet zpráv.
• Velké zprávy jsou omezené propustností. NCCL přepne na kruhové algoritmy blížící se linkové rychlosti nejpomalejší linky. Latence na zprávu se pod megabajty ztratí.

Přechod leží zhruba mezi 64 KB a 1 MB podle topologie a NIC. Pod ním dominuje latence switche a NIC a protokolový stack. Nad ním už z grafu čtete rychlost vedení.

Publikovaný strop H100 NVLink je 450 GB/s; dostat se tam u menších zpráv nebo napříč uzly je boj s laděním. U nabídky Kentino — 5090 / 4090 / RTX Pro 6000 Blackwell přes 100GbE RoCE — čekejte u velkých zpráv busbw ~10–12 GB/s na uzel, tvar algoritmu je stejný.

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ěr 30 µs, ale jeden uzel jednou za tisíc iterací vyskočí na 300 µs, každé další GPU pokaždé zahálí 270 µs. Za epochu se 100k iteracemi na 16 uzlech jsou to hodiny ztraceného výpočtu.

Proto u tréninku AI záleží na latenci P99 / P999 víc než na průměru. Bariérová kolektivní operace je operace typu „vyhrává nejpomalejší“: cluster se pohybuje rychlostí svého nejhoršího uzlu.

Zdroje jitteru:

• Zahlcení bufferů incastem. AllReduce je v každé iteraci many-to-one. Switche s mělkými buffery zahazují pakety, naskočí PFC pause a latence vyskočí 10×–100×. Switche pro AI s hlubokými buffery (Jericho3-AI, Spectrum-X) nárazy pohltí.
• Jitter CPU hostitele. Cron job, neohraničené jaderné vlákno nebo výkyv frekvence CPU vyrobí milisekundový odlehlý vzorek. Izolujte jádra pro ISR/poll vlákno NIC, vypněte C-stavy na kritických CPU, pinujte procesy.
• Adaptivní coalescing. Ovladač „pomůže“ tím, že pod zátěží coalescing zvýší; latence tiše vyskočí. Na RDMA NIC jej explicitně vypněte.
• Asymetrie topologie. Jeden leaf na 200 GbE, druhý na 100 GbE. Ten pomalejší je Vaší spodní hranicí pro každou kolektivní operaci.

Správným SLO pro AI fabriku je tail latency, ne průměrná latence.

Jak to měřit správně

ping měří ICMP RTT přes stack jádra na management rovině. Pro charakterizaci RDMA fabriky je nepoužitelný. Nástroje, které fungují:

• sockperf ping-pong — latence UDP/TCP se subnanosekundovým rozlišením. Dobré pro baseline stacku jádra a pro odhalení regresí.
• ib_send_lat, ib_write_lat (sada perftest) — přímo latence RDMA verbs. Číslo, na kterém u InfiniBandu a RoCE skutečně záleží. Čekejte ~1–2 µs na lince přes jeden switch.
• Mikrobenchmarky OSU — osu_latency, osu_bw, osu_allreduce na úrovni MPI. Správný nástroj pro HPC aplikace, než přijde na řadu NCCL.
• nccl-tests — all_reduce_perf, all_gather_perf, reduce_scatter_perf. Jediný benchmark, na kterém u tréninku AI záleží. Prochází přesně tu cestu kódem, kterou používá Váš běh. Proměřte 8 B až 1 GB; křivka ukáže, kde je fabrika rozbitá.

Kontrola zdravého rozumu: pokud je u nccl-tests all_reduce_perf busbw na velkých zprávách výrazně pod 80 % linkové rychlosti NIC, máte problém s fabrikou, ne se softwarem. Projděte vrstvy odshora tohoto článku dolů.

Užitečný zvyk: výstup nccl-tests si uložte jako součást uvedení do provozu a spusťte jej znovu po každé změně firmwaru, ovladače nebo topologie. Regrese odhalená v den, kdy vznikne, je jednořádkový diff. Odhalená o tři týdny později je forenzní cvičení.

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

Latence hraje roli:

• Synchronní allreduce gradientů v data-parallel tréninku. Každou iteraci, na každém uzlu. Tail latence = ztráta výpočtu.
• Jemnozrnný pipeline paralelismus s malými mikrodávkami. Čas bubliny na hranicích fází je omezen latencí mezi uzly.
• Tensor-parallel dělení vrstev, které se rozvětví a sejde v rámci jednoho forward/backward passu — řetězec malých kolektivních operací, čistá hra o latenci.
• Komunikace kroků s parameter serverem při vysoké frekvenci aktualizací.

Latence většinou nehraje roli:

• Dávkování inference na úrovni jednotlivých požadavků. Latenci požadavku dominuje výpočet na GPU (TTFT, dekódování na token). 10 µs sítě je šum vedle 50 ms dekódování.
• Hromadné načtení modelu z object storage na začátku úlohy. Omezeno propustností.
• Zápis checkpointu na síťové úložiště. Velké sekvenční zápisy, laďte na propustnost.
• Promíchávání v DataLoaderu přes prefetch ve workerech. Dávkové, omezené propustností.

Poctivý závěr: jednouzlový server se 4 nebo 8 GPU (chlebová nabídka Kentino AI) si komunikaci mezi GPU odbývá přes NVLink nebo PCIe, ne přes síť. Síť je pro úložiště, telemetrii a občasný experiment napříč uzly. Optimalizace fabriky na latenci kolektivních operací se vyplatí až u skutečného tréninku napříč uzly, který většina zákazníků Kentino neprovozuje. Pro čistou inferenci a trénink na jednom uzlu stačí 25 GbE s čistým stackem jádra.

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.