Zložitosť smerovania v sieťach umelej inteligencie: ECMP, adaptívne smerovanie, DCQCN a prečo sú ľudia z HPC tým posadnutí

Predchádzajúce články sa venovali káblom, sieťovým kartám, prepínačom a topológiám. Tento články sa venujú tomu, čo sa deje vyššie: ako pakety nachádzajú cestu cez multiprepínačovú štruktúru a čo zabraňuje kolapsu štruktúry, keď sa desaťtisíc grafických procesorov rozhodne pre all-reduce súčasne.

Prevádzka umelej inteligencie vyzerá zásadne inak ako v bežnom dátovom centre. Webové rozhranie odosiela milióny malých TCP pripojení. Tréningové spustenie umelej inteligencie odosiela niekoľko obrovských, dokonale synchronizovaných tokov známym uzlom a všetci čakajú na ten najpomalší. Techniky, ktoré fungujú v prvom prípade, sa v druhom rozpadajú.

Hneď na úvod: väčšina zákazníkov Kentina prevádzkuje klastre s 1 – 4 uzlami. V takomto rozsahu sa žiadny z týchto problémov v skutočnosti neprejaví. Prepojte štyri uzly s jedným 100 GbE prepínačom (alebo bez prepínača – pozri N05), spúšťajte jednoduchý RoCE s predvolenými hodnotami a nikdy nepremýšľajte o ECMP alebo DCQCN. Píšeme to aj tak, pretože (a) je to užitočný podklad pre rozhodnutia o veľkosti a (b) v deň, keď prejdete zo štyroch uzlov na šestnásť, na tom všetkom zrazu záleží.

Čo je ECMP a prečo to bolo dosť dobré pred umelou inteligenciou

ECMP — Equal-Cost Multi-Path (Viaccestný systém s rovnakými nákladmi) — je smerovací trik, ktorý umožňuje fungovať štruktúram leaf-spine a fat-tree. Keď existuje niekoľko ciest s rovnakými nákladmi z listu A do listu B (cez chrbtice S1..S4), prepínač hašuje polia paketov a použije haš na výber chrbtice. Klasický 5-tuple hash je (src IP, dst IP, src port, dst port, protocol).

Pre tradičné cloudové záťaže – milióny krátkodobých TCP pripojení – funguje ECMP skvele. Zákon veľkých čísel vyvažuje záťaž za vás. S 10 000 tokmi a 8 chrbticami sa dostanete len na niekoľko percent od dokonalej rovnováhy.

ECMP bol navrhnutý pre mnoho malých tokov. Trénovanie umelou inteligenciou odosiela niekoľko obrovských synchronizovaných tokov – štatistická rovnováha sa narúša.

Problém slonieho toku

Trénovanie AI je opakom webovej prevádzky. Krok trénovania: každá GPU vypočíta gradient, každá GPU odošle svoj gradient všetkým ostatným (allreduce), všetci čakajú na najpomalší prenos a opakujú.

Allreduce je malý počet veľmi veľkých tokov. Ring-allreduce na 8 uzloch s 200 Gbps sieťovými kartami je 8 simultánnych tokov, každý s veľkosťou niekoľkých gigabajtov, všetky s linkovou rýchlosťou a všetky začínajú v rovnakom okamihu. Meta v článku o RoCE v mierke to jasne dokumentuje: v klastroch umelej inteligencie malý počet „sloních“ tokov predstavuje takmer všetky bajty a všetky chcú sieť naraz.

5-násobný hash ECMP to neznáša. Pri N tokoch slonov cez S trás je pravdepodobnosť nulovej kolízie S! / ((S-N)! · S^N)Pre 8 tokov na 8 chrbticiach: asi 2.4%Dokonca aj 32 spinov pre 8 flowov zasiahne iba ~33 %. Pridanie spinov nemení hod mincou – získate viac prázdnych odkazov, zatiaľ čo dva flowy bojujú o jeden.

Kolízia prekročí hranicu spinálneho prepojenia v pomere 2:1, postihnuté toky bežia polovičnou rýchlosťou a pretože krok čaká na najpomalší tok, iterácia beží polovičnou rýchlosťou. Merania produkčného klastra hlásia kolízie ECMP, ktoré spôsobujú strata výkonu až 40 % na allreduce.

Riešenia: vylepšené hašovanie, vyvažovanie záťaže na úrovni paketov, adaptívne smerovanie

Štyri reálne reakcie, zoradené podľa narastajúceho počtu narušení až po nasadenie:

1. Lepšie hašovanie (E-ECMP, s ohľadom na QP). Najlacnejšie riešenie. Štandardné 5-tuple hashovanie zhlukuje prevádzku RDMA do jednej n-tice na pár QP – jeden tok allreduce je v skutočnosti jeden ECMP bucket. Hashujte aj číslo cieľového QP RoCE a nechajte aplikáciu rozložiť prevádzku medzi mnohé QP („škálovanie QP“). ​​Meta čísla: až o 40 % lepšie allreduce. Stále štatistické – kolízie sú zriedkavejšie, nie eliminované.

2. Prepínanie prietoku. Zistiť medzeru v nečinnosti a odtiaľ znova hašovať. Funguje pre TCP, zle pre RoCE back-to-back.

3. Vyvažovanie záťaže na úrovni paketov / rozprašovanie paketov. Hašovanie na paket, akceptovanie zmeny poradia, umožnenie opätovného zostavenia sieťovej karty. Eliminuje problém s tokom slonov, ale vyžaduje spoluprácu sieťovej karty a prepínača. Toto robí NVIDIA Spectrum-X – rozprašovanie na paket s hardvérovým zmenou poradia na SuperNIC.

4. Adaptívne smerovanie. Prepínač sleduje preťaženie portov a v čase prepínania vyberá najmenej zaťaženú cestu s rovnakými nákladmi namiesto slepého hašovania. V kombinácii s rozprašovaním paketov je to to, čo má InfiniBand už pätnásť rokov. Hlavnou črtou je jeho prepojenie s Ethernetom. NVIDIA Spectrum-X (ASICy Spectrum-4/5 + superNICy BlueField alebo ConnectX-8); Cisco Silicon One G200/P200; a Broadcom Tomahawk 5 / Jericho 3-AI s plánovanou tkaninou na báze buniek.

Pre klastre s 1 – 8 uzlami je adaptívne smerovanie prehnané. Pre 64+ úloh GPU škálovateľných na 1 000 GPU je to rozdiel medzi „sieť je úzkym hrdlom“ a „GPU sú úzkym hrdlom“. Preto každý seriózny dodávateľ AI Ethernetu v rokoch 2024 – 2026 vytvoril alebo licencoval kremík s adaptívnym smerovaním.

Kontrola preťaženia: prečo nie je „jednoducho nezhadzovať pakety“ zadarmo

Druhá polovica zložitosti smerovania spočíva v tom, čo sa stane, keď na jeden port prepínača príde naraz priveľa prevádzky. Dve možnosti: a stratová sieť zahadzuje pakety a koncové body sa odpájajú (otvorený internet); bezstratový Sieť sa na prepínači proti prúdu odošle späť, aby sa pozastavila – nedochádza k výpadkom, ale preťaženie sa šíri spätne.

RoCE historicky vyžadovalo bezstratovú štruktúru. Sieťové karty RDMA zle zvládajú stratu paketov – jeden stratený paket spustí opakovaný prenos celej správy go-back-N, čo na 100 GbE znamená opätovné odoslanie megabajtov. RoCEv2 s go-back-N je v podstate nepoužiteľný v stratovej sieti pri vysokom využití.

PFC — Prioritné riadenie toku (IEEE 802.1Qbb) zabezpečuje bezstratové správanie Ethernetu. Keď výstupný front prepínača s prioritou prekročí prahovú hodnotu, odošle proti prúdu rámec PAUSE so žiadosťou o zastavenie prenosu danej priority. Osem priorít, osem nezávislých signálov stop/go.

Blokovanie na začiatku fronty a toky obetí

Pauzy PFC sú hrubé. Pauza hovorí „zastaviť odosielanie priority 3 na tomto spojení“ – nevie, ktorý tok spôsobil preťaženie. Ak desať tokov zdieľa prioritu 3 a jeden je preťažený v smere toku, PFC sa pozastaví. všetkých desaťOstatných deväť „tokov obetí“ je potrestané za problém niekoho iného. Toto je blokovanie na začiatku linky, ústredný problém bezstratového Ethernetu vo veľkom meradle.

Blokovanie na začiatku linky: A→X spôsobí PFC na hlavnom kanáli. B a C komunikujúce s Y (čo je v poriadku) sú tiež pozastavené – toky obetí.

Zablokovanie PFCAk topológia a prevádzka tvoria cyklickú závislosť pozastavených liniek – A čaká na B, B na C, C na A – celá sieťová infraštruktúra sa uzamkne. Pozorované v produkčnom prostredí. Moderné prepínače majú detekciu deadlocku; moderné topológie Close sú konštrukčne bez deadlocku; ale každé seriózne nasadenie RoCE má aj tak plán obnovy.

Zmyslom moderného riadenia preťaženia AI je udržiavať dostatočne malé vyrovnávacie pamäte, aby sa PFC nikdy nespúšťal v ustálenom stave. PFC zostáva zapnutý ako bezpečnostná sieť pre skutočné mikrobursty. Mechanizmus, ktorý mu bráni v spustení, je DCQCN.

DCQCN — štandardné riadenie preťaženia pre RoCEv2

DCQCN (Oznámenie o kvantizovanom preťažení dátového centra) je algoritmus, na ktorom sa zamerala bezstratová technológia RoCE. Vyvinutý spoločnosťami Microsoft a Mellanox (SIGCOMM 2015). V rokoch 2025 – 2026 ho štandardne spúšťajú sieťové karty ConnectX/BlueField od spoločnosti NVIDIA a Azure ho hlási ako produkčný štandard pre „~85 % prevádzky Azure, RDMA, vo všetkých verejných oblastiach“.

DCQCN má tri úlohy: CP (Bod preťaženia) je prepínač, ktorý označuje pakety pomocou ECN, keď hĺbka výstupného frontu prekročí prahovú hodnotu (pravdepodobnostnú od 0 % pri Kmin do Pmax pri Kmax); NP (Oznamovací bod) je prijímacia sieťová karta, ktorá generuje CNP (Balík oznámení o preťažení) späť odosielateľovi na značkách ECN (s obmedzenou rýchlosťou, zvyčajne jedna na 50 µs na tok); RP (reakčný bod) je odosielateľská NIC, multiplikatívne znižujúca rýchlosť QP na CNP a aditívne (potom hyperaditívne) zvyšujúca sa v ich neprítomnosti.

Typická konfigurácia prepínača pre DCQCN na 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 je najviac vyladená trojica v RoCE. Kmin je malý (niekoľko paketov), ​​takže ECN sa aktivuje pred vyčerpaním vyrovnávacej pamäte; Kmax je oveľa väčší, takže značenie sa postupne zvyšuje; prah pauzy PFC je výrazne nad Kmax, takže PFC sa aktivuje iba vtedy, ak bol DCQCN príliš pomalý. Pôvodné nasadenie od Microsoftu: Kmin = 5 KB, Kmax = 200 KB, Pmax = 1 %.

Známe slabiny DCQCN: zrútenie odliatkov (100 odosielateľov zasiahne jedného prijímača, front sa zaplní rýchlejšie ako sa CNP šíria späť, PFC sa spustí – DCQCN+ to rieši); dlhodobá nespravodlivosť (neskoro sa začínajúce toky sa škrtia dlhšie); citlivosť parametrov (Kmin vyladený pre 4 uzly sa nezovšeobecňuje na 64). Úprimné zhrnutie: DCQCN je predvolený, pretože funguje väčšinou. HPCC, Swift, EQDS, oživený TIMELY existujú ako navrhované náhrady, ale žiadny z nich ho do roku 2026 nenahradil.

ECN, DCTCP a kde sa hodí čistý TCP

Čisté oddelenie, pretože sa tieto spájajú:

• ECN — Mechanizmus IP vrstvy (RFC 3168), kde prepínače označujú namiesto odstraňovania. A signál, nič nereaguje samo od seba.
• DCQCN — koncový bod RDMA reakciaČíta ECN cez CNP, upravuje kurz.
• DCTCP — koncový bod TCP reakciaČíta ECN v potvrdeniach ACK, škáluje okno podľa podielu označených paketov. Microsoft + Stanford, SIGCOMM 2010, dodávané v systémoch Windows Server a Linux.

Ak používate čistú štruktúru RoCE, používate DCQCN – poznajte svoje predvolené nastavenia. Ak máte na tom istom kábli aj úložisko/kontrolu TCP, oplatí sa povoliť DCTCP (net.ipv4.tcp_ecn = 1 plus prepínače s podporou ECN).

Prečo prevádzka s umelou inteligenciou toto všetko viac zaťažuje ako tradičné dátové centrá

Tri vlastnosti, pre ktoré klasické riadenie preťaženia nebolo navrhnuté:

1. Synchronizované dávky. Všetky GPU začínajú s redukciou v rovnakej nanosekunde. Využitie z nuly na 100 % v mikrosekundách. Žiadne zahrievanie pre pomalý štart na zistenie rýchlosti. DCQCN začína s linkovou rýchlosťou práve z tohto dôvodu.
2. Málo, veľké toky. Zákon veľkých čísel vás nezachráni. 8 tokov → bežné kolízie ECMP; 8 prijímačov → závažné blokovanie PFC HoL.
3. Kritická cesta je najpomalší článok. Čas kroku Allreduce = maximálny čas dokončenia toku. Žiadny „priemerný prípad“. 1 % pravdepodobnosť zlej kolízie sa počas mesiacov tréningu zvyšuje.

Preto sú ľudia zaoberajúci sa HPC a umelou inteligenciou posadnutí sieťami tak, ako to weboví operátori historicky neurobili. Web je elastický – pomalé požiadavky trvajú niektorým používateľom o niečo dlhšie. Trénovanie umelej inteligencie nie je – celá úloha beží rýchlosťou svojej najpomalšej synchronizovanej súčasti.

Bezprepínacia zložitosť (ukážka N05)

N05 Zahŕňa topológie bez prepínačov – priame pripojenie, sieťovú sieť, kruhovú, 2D/3D torusovú, tesseractovú – pre malé klastre, kde je kúpa 100 GbE prepínača prehnaná. Po odstránení prepínača sa každý uzol stane smerovačom: viacero sieťových kariet, viacero ciest, niečo si musí vybrať ďalší krok.

Štandardná odpoveď v roku 2026 je FRR (FRRouting) na každom uzle, nakonfigurovanom pre BGP bez číslaBGP unnumbered používa na peering lokálne adresy IPv6, takže adresy IPv4 nepriraďujete každému spojeniu. Každý uzol oznámi svoju slučku, naučí sa spätné slučky peerov a smerovacia tabuľka Linuxu vyberie správny ďalší krok.

# 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

Dvanásť liniek na uzol, ECMP naprieč počtom párov sieťových kariet, ktoré uzol má – s rovnakými výhradami ako ECMP prepínača. V prípade siete so 4 uzlami sa kolízie ECMP prejavujú aj na strane hostiteľa. Zmiernite ich použitím väčšieho počtu QP alebo akceptujte stratu (malá pri 4 uzloch). „Žiadny prepínač“ neznamená „žiadna zložitosť smerovania“ – premiestni sa k hostiteľom.

Keď je to pre vás dôležité

Väčšina čitateľov nebude musieť robiť nič z toho.

• 1–4 uzly, jeden prepínač, RoCE pre úložisko a občasné trénovanie viacerých GPU: Nechajte prepínač v predvolenej polohe. Štandardné prahy DCQCN a ECN sú v poriadku. PFC je povolené, pravdepodobne ho nikdy neuvidíte pozastaviť. Kolízie ECMP sú reálne, ale vplyv na beh so 4 uzlami je v jednotkách percent.
• 4–16 uzlov, vyhradený tréningový klaster: explicitne povoľte DCQCN, nastavte Kmin/Kmax/Pmax na 5 KB / 200 KB / 1 % (základná hodnota Azure), zapnite škálovanie QP v NCCL, monitorujte počítadlá pauz PFC a rýchlosti CNP. Ak sa počet pauz PFC zvyšuje, DCQCN nie je dostatočne agresívny – znížte Kmin.
• 16+ uzlov alebo 1 000+ GPU: Adaptívne smerovanie sa samo oplatí. Kúpte si Spectrum-X so zodpovedajúcimi SuperNIC kartami alebo InfiniBand a prestaňte sa starať o ECMP, prípadne sa spojte s niekým, kto už prevádzkoval fabric v tomto rozsahu. Cena za chybný postup je mesiace tréningu.
• Bezprepínací klaster, ľubovoľná veľkosť: FRR + BGP bez čísla. 1–2 dni konfigurácie a testovania na zdvojnásobenie počtu uzlov. Veľký problém je zabudnutie na ECMP na strane jadra (net.ipv4.fib_multipath_hash_policy = 1 pre hašovanie L4).

Inštinkt „kúpim si väčšiu šírku pásma, aby nikdy nedošlo k preťaženiu“ je mylný. Synchronizovaná prevádzka umelej inteligencie vytvára okamžitý dopyt pri rýchlosti linky na každej trase, bez ohľadu na počet chrbtíc. Šírka pásma rieši problémy s rýchlosťou, nie problémy s koordináciou.

---

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.