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 nevyskytne. Prepojte štyri uzly s jedným 100 GbE prepínačom (alebo bez prepínača – pozri N05 ), spustite jednoduchý RoCE s predvolenými nastaveniami 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čí predplatné chrbticového odkazu 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ú až 40 % stratu výkonu 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 hašovanie zhlukuje prevádzku RDMA do jednej n-tice na pár QP – jeden tok allreduce je v skutočnosti jeden ECMP bucket. Hašovanie aj na cieľové číslo RoCE QP a rozloženie prevádzky medzi mnohé QP pomocou aplikácie („škálovanie QP“). ​​Meta čísla: až o 40 % lepšie allreduce. Stále štatistické – kolízie sú zriedkavejšie, nie eliminované.

2. Prepínanie flowletov. Detekcia medzery v nečinnosti a opätovné hašovanie odtiaľ. 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, opätovné zostavenie 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 na trhu už pätnásť rokov. Prenesenie do Ethernetu je hlavnou črtou produktov 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 štruktúrou založenou na bunkách.

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 dorazí naraz príliš veľa prevádzky. Existujú dve možnosti: stratová sieť zahodí pakety a koncové body sa odpoja (otvorený internet); bezstratová sieť sa odošle späť na nadradený prepínač, aby sa pozastavila – nedochádza k stratám, 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 — Priority Flow Control (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 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, čo je ú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 PFC : ak 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 zablokuje. Pozorované v produkčnom prostredí. Moderné prepínače majú detekciu zablokovania; moderné topológie Close sú konštrukčne bez zablokovania; 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 (DataCenter Quantized Congestion Notification) je algoritmus, na ktorom sa zakladá bezstratová technológia RoCE. Vyvinutý spoločnosťami Microsoft a Mellanox (SIGCOMM 2015). V rokoch 2025 – 2026 ho štandardne používajú 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 (notifikačný bod) je sieťová karta príjemcu, ktorá generuje CNP (paket s notifikáciou o preťažení) späť odosielateľovi na základe značiek ECN (obmedzené rýchlosťou, zvyčajne jeden na 50 µs na tok); RP (reakčný bod) je sieťová karta odosielateľa, ktorá multiplikatívne znižuje rýchlosť QP na CNP a aditívne (potom hyperaditívne) ju zvyšuje v prípade 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: kolaps incastu (100 odosielateľov zasiahne jedného prijímača, front sa naplní rýchlejšie ako sa CNP šíria späť, PFC sa spustí – DCQCN+ to rieši); nespravodlivosť dlhého chvosta (toky s oneskoreným spustením sú dlhšie obmedzované); citlivosť parametrov (Kmin vyladený pre 4 uzly sa nezovšeobecní na 64). Úprimné zhrnutie: DCQCN je predvolený, pretože funguje väčšinu času. HPCC, Swift, EQDS, oživený TIMELY existujú ako navrhované náhrady, ale žiadny 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 pokrýva topológie bez prepínačov – priame pripojenie, sieť, kruh, 2D/3D torus, tesseract – 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.

Štandardnou odpoveďou v roku 2026 je FRR (FRRouting) na každom uzle, nakonfigurovanom pre BGP unnumbered . BGP 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é väzby 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ú. Pripomienky a opravy sú vítané na adrese info@kentino.com.