Routingkompleksitet i AI-netværk: ECMP, adaptiv routing, DCQCN og hvorfor HPC-folk er besatte af det

Tidligere artikler gennemgik kabler, netkort, switche og topologier. Denne handler om, hvad der sker ovenfor: hvordan pakker finder en vej gennem et multi-switch-stof, og hvad der forhindrer stoffet i at kollapse, når ti tusinde GPU'er beslutter sig for at reducere alt på samme tid.

AI-trafik ser fundamentalt anderledes ud end et normalt datacenter. En web-frontend sender millioner af små TCP-forbindelser. En AI-træningskørsel sender et par enorme, perfekt synkroniserede flows til kendte peers, og alle venter på den langsomste. De teknikker, der virker i det første tilfælde, falder fra hinanden i det andet.

Advarsel på forhånd: De fleste Kentino-kunder kører klynger med 1-4 noder. I den skala er der ingen af ​​disse problemer, der rent faktisk påvirker hinanden. Forbind fire noder med en enkelt 100 GbE-switch (eller ingen switch – se N05), kør vanilla RoCE med standardindstillinger, og tænk aldrig på ECMP eller DCQCN. Vi skriver dette alligevel, fordi (a) det er en nyttig baggrund for størrelsesbeslutninger, og (b) den dag du går fra fire noder til seksten, betyder det hele pludselig noget.

Hvad ECMP er, og hvorfor det var godt nok indtil AI

ECMP — Equal-Cost Multi-Path — er routing-tricket, der får blad-rygsøjle og fedttræsstrukturer til at fungere. Når der er flere stier med samme omkostninger fra blad A til blad B (gennem rygsøjler S1..S4), hasher switchen pakkefelter og bruger hashen til at vælge en rygsøjle. Den klassiske 5-tuple hash er (src IP, dst IP, src port, dst port, protocol).

For traditionelle cloud-workloads – millioner af kortlivede TCP-forbindelser – fungerer ECMP perfekt. De store tals lov klarer load-balanceringen for dig. Med 10,000 flows og 8 spines kommer du inden for et par procent af perfekt balance.

ECMP blev designet til mange små flows. AI-træning sender et par store synkroniserede flows – den statistiske balance bryder sammen.

Elefantstrømmens problem

AI-træning er det modsatte af webtrafik. Et træningstrin: hver GPU beregner en gradient, hver GPU sender sin gradient til alle de andre (allreduce), alle venter på den langsomste overførsel, gentag.

Allreduce er et lille antal meget store flows. Ring-allreduce på 8 noder med 200 Gbps NIC'er er 8 samtidige flows, hver på flere gigabytes, alle med linjehastighed, alle starter på samme tidspunkt. Metas RoCE-at-scale-artikel dokumenterede det tydeligt: ​​i AI-klynger tegner et lille antal "elefant"-flows sig for næsten alle bytes, og de vil alle have netværket på én gang.

ECMP's 5-tuple hash hader dette. Med N elefantstrømme på tværs af S stier er sandsynligheden for nul kollisioner S! / ((S-N)! · S^N)For 8 strømme på 8 rygsøjler: omkring 2.4%Selv 32 spines for 8 flows rammer kun ~33%. Tilføjelse af spines ændrer ikke coin-flip - det giver dig flere tomme links, mens to flows kæmper om ét.

En kollision overskriver rygsøjleforbindelsen 2:1, de berørte strømme kører med halv hastighed, og fordi trinnet venter på den langsomste strøm, kører iterationen med halv hastighed. Produktions-klyngemålinger rapporterer ECMP-kollisioner, der forårsager op til 40% ydeevnetab på allreduce.

Løsninger: forbedret hashing, load balancing på pakkeniveau, adaptiv routing

Fire reelle reaktioner, i stigende rækkefølge efter afbrydelse ved implementering:

1. Bedre hashing (E-ECMP, QP-bevidst). Billigste løsning. Standard 5-tuple hashing kollapser RDMA-trafik på én tuple pr. QP-par — et enkelt allreduce-flow er i virkeligheden én ECMP-bucket. Hash også på RoCE-destinationens QP-nummer, og få applikationen til at sprede trafikken på tværs af mange QP'er ("QP-skalering"). Metas tal: op til 40% bedre allreduce. Stadig statistisk — kollisioner er sjældnere, ikke elimineret.

2. Flowlet-skift. Registrer et inaktivt gap, og gentag hashingen derfra. Fungerer for TCP, men dårligt for back-to-back RoCE.

3. Load balancing / packet spraying på pakkeniveau. Hash per pakke, accepter genbestilling, lad NIC'en samles igen. Eliminerer elefantflow-problemet, men kræver samarbejde mellem NIC og switch. Det er, hvad NVIDIA Spectrum-X gør — sprøjtning per pakke med hardwaregenbestilling ved SuperNIC'en.

4. Adaptiv ruteplanlægning. Switchen sporer overbelastning pr. port og vælger den mindst belastede lige omkostningsvej på switchtidspunktet i stedet for blindt at hashe. Kombineret med pakkespraying er dette, hvad InfiniBand har haft i femten år. At bringe det til Ethernet er hovedfunktionen hos NVIDIA Spectrum-X (Spectrum-4/5 ASIC'er + BlueField- eller ConnectX-8 SuperNIC'er); Cisco Silicon One G200/P200; og Broadcom Tomahawk 5 / Jericho 3-AI med cellebaseret planlagt stof.

For klynger med 1-8 noder er adaptiv routing overkill. For 64+ GPU-job, der skaleres til 1,000 GPU'er, er det forskellen mellem "netværket er flaskehalsen" og "GPU'erne er flaskehalsen". Derfor har alle seriøse AI Ethernet-leverandører bygget eller licenseret adaptiv routing-silicium i 2024-2026.

Bekæmpelse af trængsel: hvorfor "bare lad være med at smide pakker" ikke er gratis

Den anden halvdel af routingkompleksitet er, hvad der sker, når der ankommer for meget trafik til én switchport på én gang. To valgmuligheder: a lossy netværket dropper pakker, og endpointerne trækker sig tilbage (det åbne internet); tabsfri netværket skubber tilbage på upstream-switchen for at sætte på pause — ingen fald, men overbelastningen forplanter sig baglæns.

RoCE har historisk set krævet en tabsfri struktur. RDMA NIC'er håndterer pakketab dårligt - en enkelt mistet pakke udløser go-back-N-gentransmission af hele beskeden, hvilket på 100 GbE betyder genafsendelse af megabyte. RoCEv2 med go-back-N er stort set ubrugelig på et tabsgivende netværk ved høj udnyttelse.

PFC — Prioritetsflowkontrol (IEEE 802.1Qbb) er det, der får Ethernet til at opføre sig tabsfrit. Når en switchs udgangskø per prioritet overstiger en tærskel, sender den en PAUSE-frame upstream, der beder afsenderen om at stoppe transmissionen af ​​den prioritet. Otte prioriteter, otte uafhængige stop/go-signaler.

Blokering af hovedlinjer og offerstrømme

PFC-pauser er grove. En pause siger "stop sending af prioritet 3 på dette link" - den ved ikke, hvilken strøm der forårsagede overbelastning. Hvis ti strømme deler prioritet 3, og én er overbelastet nedstrøms, sætter PFC på pause. alle tiDe andre ni "offerstrømme" bliver straffet for en andens problem. Dette er head-of-line-blokering, den centrale smerte ved tabsfri Ethernet i stor skala.

Blokering af hovedlinjen: A→X forårsager PFC på trunk. B og C, der taler med Y (hvilket er fint), sættes også på pause — offerflow.

PFC-dødvandeHvis topologi og trafik danner en cyklisk afhængighed af pauserede links — A venter på B, B på C, C på A — låser hele strukturen. Observeret i produktion. Moderne switche har deadlock-detektion; moderne Clos-topologier er deadlock-fri per konstruktion; men enhver seriøs RoCE-implementering har alligevel en genopretningsplan.

Pointen med moderne AI-overbelastningskontrol er at holde bufferne små nok til, at PFC aldrig aktiveres i steady state. PFC forbliver aktiveret som et sikkerhedsnet for ægte mikrobursts. Mekanismen, der forhindrer den i at aktiveres, er DCQCN.

DCQCN — standard overbelastningskontrol for RoCEv2

DCQCN (DataCenter Quantified Congestion Notification) er den algoritme, som tabsfri RoCE er gået over til. Udviklet af Microsoft og Mellanox (SIGCOMM 2015). Fra 2025-2026 er det det, NVIDIAs ConnectX/BlueField NIC'er kører som standard, og det, Azure rapporterer som produktionsstandarden på tværs af "~85% af Azure-trafikken, RDMA, i alle offentlige regioner."

DCQCN har tre roller: CP (Tæthedspunkt) er switchen, der markerer pakker med ECN, når udgangskødybden krydser en tærskel (sandsynlighedsmæssig fra 0% ved Kmin til Pmax ved Kmax); NP (Meddelelsespunkt) er modtagerens NIC, der genererer en CNP (pakke til meddelelse om overbelastning) tilbage til afsenderen på ECN-mærker (hastighedsbegrænset, typisk én pr. 50 µs pr. flow); RP (Reaktionspunkt) er afsenderens NIC, der multiplikativt reducerer QP'ens hastighed på CNP og additivt (derefter hyperadditivt) stiger i deres fravær.

Typisk switchkonfiguration for DCQCN på 100 GbE:

# NVIDIA Cumulus-style ECN profile on the lossless RoCE priority (priority 3)
interface swp1..swp32
  qos remark dscp-to-tc 26 to 3       # DSCP 26 → TC 3
  qos congestion-mark ecn priority 3
  qos ecn-kmin       5KB              # start marking
  qos ecn-kmax     200KB              # mark at Pmax
  qos ecn-pmax       1%
  qos pfc priority 3
  qos pfc xoff     400KB              # PFC pause (well above Kmax)
  qos pfc xon      300KB

Kmin/Kmax/Pmax er den mest indstillede trippel i RoCE. Kmin er lille (et par pakker), så ECN aktiveres, før bufferen er opbrugt; Kmax er meget større, så markeringen gradvist øges; PFC-pausegrænsen er et godt stykke over Kmax, så PFC kun aktiveres, hvis DCQCN var for langsom. Microsofts oprindelige implementering: Kmin = 5 KB, Kmax = 200 KB, Pmax = 1%.

DCQCNs kendte svagheder: incast kollaps (100 afsendere rammer én modtager, køen fyldes hurtigere end CNP'er forplanter sig tilbage, PFC aktiveres — DCQCN+ løser dette); langhale urimelighed (sent startede strømninger bliver droslet længere); parameterfølsomhed (Kmin indstillet til 4 noder generaliserer ikke til 64). Ærlig opsummering: DCQCN er standard, fordi den fungerer det meste af tiden. HPCC, Swift, EQDS og den genoplivede TIMELY findes som foreslåede erstatninger, men ingen har erstattet den fra 2026.

ECN, DCTCP, og hvor ren TCP passer ind

Ren adskillelse, fordi disse blandes sammen:

• ECN — IP-lagsmekanisme (RFC 3168), hvor kontakter markerer i stedet for at slippe. A signal, intet reagerer af sig selv.
• DCQCN — RDMA-slutpunktet reaktionLæser ECN via CNP'er, justerer hastigheden.
• DCTCP — TCP-slutpunktet reaktionLæser ECN i ACK'er, skalerer vinduet efter den markerede pakkefraktion. Microsoft + Stanford, SIGCOMM 2010, leveret i Windows Server og Linux.

Hvis du kører en ren RoCE-struktur, kører du DCQCN — kend dine standardindstillinger. Hvis du også har TCP-lagring/kontrol på samme ledning, er DCTCP værd at aktivere (net.ipv4.tcp_ecn = 1 plus ECN-bevidste kontakter).

Hvorfor AI-trafik understreger alt dette mere end traditionelle datacentre

Tre egenskaber, som klassisk overbelastningskontrol ikke var designet til:

1. Synkroniserede bursts. Alle GPU'er starter med allreduce ved samme nanosekund. Nul til 100% udnyttelse i mikrosekunder. Ingen opvarmning ved langsom opstart for at finde hastigheden. DCQCN starter ved linjehastighed af netop denne grund.
2. Få, store strømme. De store tals lov redder dig ikke. 8 strømme → almindelige ECMP-kollisioner; 8 modtagere → alvorlig PFC HoL-blokering.
3. Den kritiske sti er det langsomste led. Allreduce-trintid = maks. flow-fuldførelsestid. Intet "gennemsnitligt tilfælde". En sandsynlighed på 1% for en dårlig kollision forøges over måneders træning.

Derfor er HPC- og AI-folk besatte af netværk på en måde, som weboperatører historisk set ikke har gjort. Internettet er elastisk – langsomme anmodninger tager lidt længere tid for nogle brugere. AI-træning er ikke – hele jobbet kører med hastigheden af ​​dens langsomst synkroniserede komponent.

Den kontaktløse kompleksitet (forhåndsvisning af N05)

N05 Dækker switchløse topologier — direct-connect, mesh, ring, 2D/3D torus, tesseract — til små klynger, hvor det er overkill at købe en 100 GbE switch. Når du fjerner switchen, bliver hver node til en router: flere NIC'er, flere stier, noget skal vælge det næste hop.

Standardsvaret i 2026 er FRR (FRRouting) på hver node, konfigureret til BGP unummereretBGP uden nummerering bruger IPv6 link-lokale adresser til peering, så du tildeler ikke IPv4 adresser på hvert link. Hver node annoncerer sin loopback, lærer peers' loopbacks at kende, og Linux routingtabellen vælger det næste hop.

# Minimal FRR config for a node in a switchless mesh:
router bgp 65001
  bgp router-id 10.0.0.1
  neighbor enp1s0 interface remote-as external
  neighbor enp2s0 interface remote-as external
  neighbor enp3s0 interface remote-as external
  address-family ipv4 unicast
    network 10.0.0.1/32         # this node's loopback
    redistribute connected
  exit-address-family

Tolv linjer pr. node, ECMP på tværs af uanset hvor mange NIC-par noden har — med de samme forbehold som switch ECMP. For et 4-node mesh opstår ECMP-kollisioner også på værtssiden. Reducer med flere QP'er eller accepter tabet (lille ved 4 noder). "Ingen switch" betyder ikke "ingen routingkompleksitet" — det flytter det til værterne.

Når dette er vigtigt for dig

De fleste læsere behøver ikke at gøre noget af dette.

• 1-4 noder, enkelt switch, RoCE til lagring og lejlighedsvis multi-GPU-træning: Lad knappen være på standardindstillingerne. Standard DCQCN- og ECN-tærskler er fine. Hvis PFC er aktiveret, vil du sandsynligvis aldrig se den sætte på pause. ECMP-kollisioner er reelle, men virkningen på en kørsel med 4 noder er et encifret procenttal.
• 4–16 noder, dedikeret træningsklynge: Aktiver DCQCN eksplicit, indstil Kmin/Kmax/Pmax til 5 KB / 200 KB / 1% (Azure-baseline), aktivér QP-skalering i NCCL, overvåg PFC-pausetællere og CNP-hastigheder. Hvis PFC-pauser stiger, er DCQCN ikke aggressiv nok — sænk Kmin.
• 16+ noder eller 1,000+ GPU'er: Adaptiv routing betaler sig selv. Køb Spectrum-X med matchende SuperNIC'er eller InfiniBand, og stop med at bekymre dig om ECMP, eller slå dig sammen med en, der har kørt en fabric i denne skala. Omkostningerne ved at gøre det forkert er måneders træningstid.
• Kontaktløs klynge, alle størrelser: FRR + BGP unummereret. 1-2 dages konfiguration og test pr. fordobling af nodeantal. Den store fejl er at glemme ECMP på kernelsiden (net.ipv4.fib_multipath_hash_policy = 1 til L4-hashing).

Instinktet "jeg køber mere båndbredde, så der aldrig opstår overbelastning" er forkert. Synkroniseret AI-trafik skaber øjeblikkelig efterspørgsel med linjehastighed på alle stier, uanset hvor mange spines der er. Båndbredde løser hastighedsproblemer, ikke koordinationsproblemer.

---

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.