Latenstidsdissektion: Hvor hvert mikrosekund går hen i et AI-klyngenetværk

Folk, der dimensionerer AI-klyngenetværk, starter normalt med båndbredde – 100, 200, 400 GbE – og bliver så overraskede, når deres allreduce-benchmark viser et tal, der slet ikke er i nærheden af ​​linjehastigheden. Årsagen er næsten altid latenstid og regimet med små beskeder, hvor båndbreddediagrammer er ubrugelige.

Denne artikel tager en enkelt rundvisning fra hinanden og tager højde for hvert trin. Tallene nedenfor er konsensusintervallet fra offentlige målinger, NVIDIA/Mellanox-dokumentation og vores egne tests. Betragt dem som et budget, ikke en garanti - de følger NIC-silicium, switch-ASIC, kerneversion, BIOS-indstillinger og hvor tålmodig du er med justering.

Målgruppe: folk, der specificerer eller fejlfinder AI-klyngestrukturer. Ikke en kogebog med tuning, men den mentale model, der gør kogebogen læsbar.

Den fulde rundtur, én slide

En 64-byte ping-pong mellem to GPU'er på forskellige noder, over en 100 GbE switched fabric med RDMA, opdeles omtrent sådan her:

En single-switch RDMA RTT på 100 GbE / NDR InfiniBand lander kl. ~2 µs for små beskeder. En to-hop leaf-spine tilføjer ~1 µs. Den samme sti over kernel TCP/IP lander ved 20–60 µs, en størrelsesorden mere, med dårligere haleadfærd. Disse to tal styrer næsten alle arkitektoniske beslutninger nedenfor.

RDMA envejssti: switchhop (250-600 ns på Ethernet, <100 ns på IB) er den dominerende variabel; ledningsforsinkelse ved <100 m er ubetydelig.

Tråden er ikke problemet

Lys i fiber bevæger sig med ~to tredjedele c, så udbredelsen er ~5 ns/m. En 30 m lang række-af-racks-fiber tilføjer 150 ns i én vej; selv en 500 m lang campuskørsel er et mikrosekund. Serialisering er også lille ved moderne hastigheder: en 64-byte frame ved 100 Gb/s er 5.12 ns; en 9000-byte jumbo frame er 720 ns. For små kontrolmeddelelser er serialisering ubetydelig; for bulkoverførsel holder det op med at betyde noget, når røret er bredt nok.

Latensitet findes faktisk i software, i switch ASIC'er og i den protokol, du vælger.

Skiftestof: gennemskæring vs. opbevaring og fremføring

En cut-through switch begynder at videresende, så snart den har læst destinationsheaderen. En store-and-forward switch bufferer hele framen, validerer eventuelt CRC'en og videresender derefter.

InfiniBand-fordelen er reel: HPC-silicium har optimeret dette i to årtier. Moderne Ethernet AI-switche (Tomahawk 5, Jericho3-AI, Spectrum-X) lukker det meste af latensgabet og overgår InfiniBand på bufferdybde, hvilket er vigtigere for at reducere incast.

I en bladrygsøjle gennemløber en tværgående strømning blad → rygrad → bladDesign, der minimerer antallet af hop (fladt fedttræ, skinneoptimerede topologier), forsøger ikke at spare båndbredde; de ​​sparer 500 ns pr. undgået hop på hvert kollektiv.

Kernel-netværksstakken

Almindelig TCP/IP gennem Linux-kernen betaler pr. pakke for: NIC-interrupt-afsendelse (eller NAPI-polling), skb-allokering og softirq, TCP/IP-behandling, en socket-buffer-kopi mellem kerne og brugerområde og en kontekstskifte ind i applikationen.

For en lille pakke på moderne x86 er dette 10–30 µs i én retning i bedste fald med halespidser over 100 µs under belastning. Den er også CPU-bundet — mætter en kerne med ~1 Mpps længe før netværkskortet gør. Det er den omkostning, resten af ​​artiklen forsøger at eliminere.

Kernel bypass: DPDK, RDMA, XDP, AF_XDP

Fire almindelige måder at få kernen ud af datastien på, der adskiller sig i hvor fuldstændigt de omgår og hvad de efterlader på tabellen:

Et par praktiske noter:

• DPDK og RDMA er ikke udskiftelige. DPDK kører vilkårlig pakkebehandling i brugerområdet med linjehastighed; RDMA implementerer en specifik hukommelsessemantisk protokol med hardwareoffload. AI-arbejdsbelastninger ønsker RDMA — NCCL og storage-stakke bruger det som standard. DPDK vises i inferensproxyer, telemetri og brugerdefinerede dataplaner.
• AF_XDP er mellemvejen. Kobler til driveren på eBPF-laget, får en latenstid på under 10 µs, og i modsætning til DPDK stjæler den ikke netværkskortet fra operativsystemet. Det rigtige svar for blandede bokse.
• XDP uden AF_XDP er til inline drop/redirect/videresendelse (DDoS scrubbing, load balancers). Behandler pakker inde i kernen ved driver hook'en; flytter dem ikke til brugerområdet.

For en AI-klynge: RDMA over InfiniBand eller RoCEv2 til GPU-til-GPU, almindelig TCP/IP til alt andet (administration, telemetri, download af model). Overkonstruer ikke de langsomme stier.

Afbrydelseskoalescer, GRO/LRO: gennemløbsfælden

Linux og de fleste NIC-drivere leveres med tuning til dataoverførsel, ikke latenstid. To knapper er vigtige:

• Afbryd koalesceringen. NIC'et venter et konfigureret µs-vindue (eller pakkeantal), før det udløser en afbrydelse. Reducerer overhead pr. pakke; tilføjer latenstid svarende til vinduet. rx-usecs 50 tilføjer op til 50 µs på et stille link.
• GRO / LRO. Kernel (GRO) eller NIC (LRO) aggregerer indgående TCP-segmenter til én større skb, før den går opad. Billigere at behandle, men aggregatoren venter bevidst på flere pakker og tilføjer mikrosekunder.

Afvejningen er ærlig og ikke til forhandling: Du kan ikke have både peak throughput og peak latency på den samme konfiguration. For en GPU-node ønsker RDMA NIC-håndteringen af ​​allreduce rx-usecs 0 eller 1, adaptiv koalescing slået fra, GRO slået fra på RDMA-sidegrænsefladen. Et separat administrations-NIC gemmer standardindstillingerne; det er ikke på den kritiske sti.

Følgeslutningen: Et NIC med dobbelt formål til RDMA-kollektiver og TCP-downloads vil levere middelmådige tal for begge. medmindre du deler trafikken på tværs af køer eller grænseflader. Seriøse AI-noder har en eller to dedikerede RDMA NIC'er (ConnectX-7/8, BlueField-3) plus en separat administrations-NIC.

Applikationslaget er heller ikke gratis

To omkostninger øverst i stakken kommer sjældent med i arkitekturdiagrammerne:

• memcpy. En 4 MB memcpy tager ~200 µs på en enkelt kerne ved ~20 GB/s. Hvis jeres kollektive data kopierer tensordata til en stagingbuffer før posting, har I brugt mere tid end hele netværkets rundtur. GPUDirect RDMA springer dette over — NIC'en læser direkte fra GPU-hukommelsen.
• Serialisering. Protobuf, JSON eller hand-rolled framing tilføjer snesevis af µs for ikke-trivielle nyttelaster. Fin i en RPC på kontrolplanet; fatal i allreduce-innerloopet. NCCL undgår det med faste binære deskriptorer og præregistreret hukommelse.

Hvis din "RDMA-tunede" stak stadig er langsom, så profilér brugerområdet, før du giver stoffet skylden. Vi har set 30 µs kollektiver, hvor 25 µs var en PyTorch tensor-omformning, og kun 5 µs var wire and switch.

Kollektiv drift: latenstid vs. båndbredde, og hvorfor pakkestørrelse er vigtig

NCCL (og ethvert kollektivt bibliotek) vælger en algoritme baseret på meddelelsesstørrelse:

• Små beskeder er latenstidsbundne. NCCL bruger træalgoritmer og sin LL-protokol (4-byte data med 4-byte flag via 8-byte atomlagre, ingen hukommelseshegn). BusBw er en brøkdel af linjehastigheden; du måler overhead pr. besked × antal beskeder.
• Store beskeder er båndbreddebundne. NCCL skifter til ringalgoritmer, der nærmer sig linjehastigheden for det langsomste link. Latens pr. besked forsvinder under megabytene.

Overgangen ligger omtrent mellem 64 KB og 1 MB afhængigt af topologi og NIC. Nedenfor dominerer switch- og NIC-latens samt protokolstakken. Ovenfor aflæser du ledningshastigheden ud fra diagrammet.

Det publicerede H100 NVLink-loft er 450 GB/s; at nå dertil ved mindre beskeder eller på tværs af noder er en kamp til at justere. For Kentinos sortiment - 5090 / 4090 / RTX Pro 6000 Blackwell over 100 GbE RoCE - kan man forvente ~10-12 GB/s busbw pr. node for store beskeder på 100 GbE, samme algoritmeform.

Jitter er værre end latenstid

Hvis allreduce-latenstiden på hver node er 30 µs ± 1 µs, venter barrieren i 30 µs. Hvis den er 30 µs i gennemsnit med én node ved 300 µs én gang ud af tusind iterationer, sidder hver anden GPU inaktiv i 270 µs hver gang den pågældende hale aktiveres. På tværs af en epoch på 100k iterationer på 16 noder er det timer med tabt beregning.

Derfor er P99/P999 latenstid vigtigere for AI-træning end gennemsnitlig latenstid. Et barrierekollektiv er en langsomste sejre operation: klyngen bevæger sig med hastigheden af ​​dens værste node.

Kilder til jitter:

• Incast-bufferoverbelastning. AllReduce er mange-til-en i hver iteration. Shallow-buffered switches dropper pakker, PFC-pause starter, latenstiden stiger med 10×–100×. Deep-buffered AI switches (Jericho3-AI, Spectrum-X) absorberer bursten.
• Værts-CPU-jitter. Et cron-job, en ubegrænset kernetråd eller en CPU-frekvensudsving producerer en outlier på 1 ms. Isoler kerner til NIC ISR/poll-tråden, deaktiver C-tilstande på kritiske CPU'er, fastlås processer.
• Adaptiv koalescerering. Driveren "hjælper" ved at øge koalesceringen under belastning; latensen stiger lydløst. Slå den eksplicit fra på RDMA NIC'en.
• Topologisk asymmetri. En fløj på 200 GbE, en anden på 100 GbE. Den langsommere fløj er din etage for hvert kollektiv.

Haleforsinkelse, ikke gennemsnitlig latenstid, er den rigtige SLO for en AI-struktur.

Mål det rigtigt

ping måler kernel-stack ICMP RTT på administrationsplanet. Det er ubrugelig til karakterisering af et RDMA-stof. Værktøjerne der virker:

• sockperf ping-pong — UDP/TCP-latens med en opløsning på under nanosekund. God til kernel-stak-baselines og regressioner.
• ib_send_lat, ib_write_lat (perftest suite) — RDMA verb latency direkte. Det tal, du rent faktisk er interesseret i for InfiniBand og RoCE. Forvent ~1-2 µs på et link med samme switch.
• OSU mikrobenchmarks — osu_latency, osu_bw, osu_allreduce på MPI-niveau. Det rigtige værktøj til HPC-apps før NCCL er med i billedet.
• nccl-tests — all_reduce_perf, all_gather_perf, reduce_scatter_perf. Det eneste benchmark, der betyder noget for AI-træning. Den udfører præcis den kodesti, som din kørsel bruger. Scan 8 B til 1 GB; kurven fortæller dig, hvor stoffet er brudt.

Fornuftstjek: hvis nccl-tests all_reduce_perf Hvis busbw ved store beskeder er langt under 80% af NIC-linjehastigheden, har du et fabric-problem, ikke et softwareproblem. Gå lagene fra toppen af ​​denne artikel og ned.

Nyttig vane: Gem nccl-tests output som en del af idriftsættelse, og kør igen efter hver ændring af firmware, driver eller topologi. En regression fanget den dag, den sker, er en difference på én linje. Fanget tre uger senere er det en retsmedicinsk øvelse.

Når latenstid virkelig betyder noget – og når den ikke gør

Latensforhold betyder noget:

• Synkron gradient allreduce i dataparallel træning. Hver iteration, hver node. Haleforsinkelse = beregningstab.
• Finkornet pipelineparallelisme med små mikrobatcher. Bobletiden ved fasegrænser er begrænset af latenstid mellem noder.
• Tensor-parallelle lagopdelinger der spreder sig ud og tilbage i et fremad/bagud-spil — en kæde af små kollektiver, rent latenstidsspil.
• Parameter-server trinkommunikation med høj opdateringshastighed.

Latens gør for det meste ikke:

• Inferensbatching granularitet ved anmodning. Latens pr. anmodning domineres af GPU-beregning (TTFT, afkodning pr. token). 10 µs netværk er støj ved siden af ​​50 ms afkodning.
• Bulkmodelindlæsning fra objektlager ved jobstart. Gennemløbsbundet.
• Skrivning af kontrolpunkt til netværkslagring. Store sekventielle skrivninger, finjuster båndbredden.
• DataLoader-blanding via worker prefetch. Batchbaseret, gennemløbsbundet.

Den ærlige implikation: En single-node 4×- eller 8×-GPU-server (Kentinos standard K-AI-serie) udfører sin inter-GPU-kommunikation via NVLink eller PCIe, ikke netværket. Netværket er til lagring, telemetri og lejlighedsvise multi-node eksperimenter. Optimering af strukturen til kollektiv latenstid betaler sig kun med reel multi-node træning, hvilket de fleste Kentino-kunder ikke kører. Til ren inferens og single-node træning er 25 GbE med en ren kernel stak tilstrækkeligt.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.