Zložitosť smerovania v AI sieťach: ECMP, adaptívne smerovanie, DCQCN a prečo sa tým ľudia z HPC tak zaoberajú

Predchádzajúce články prešli káble, sieťové karty, switche a topológie. Tento je o tom, čo sa deje nad nimi: ako si pakety hľadajú cestu cez fabric s viacerými switchmi a čo bráni tomu, aby sa fabric zložil, keď sa desaťtisíc GPU rozhodne spustiť all-reduce v rovnakom okamihu.

AI prevádzka vyzerá úplne inak než bežné dátové centrum. Webový frontend posiela milióny malých TCP spojení. Tréningový beh AI posiela niekoľko obrovských, dokonale synchronizovaných tokov na známe protistrany a všetci čakajú na ten najpomalší. Techniky, ktoré fungujú v prvom prípade, sa v druhom rozsypú.

Upozornenie hneď na úvod: väčšina zákazníkov Kentino prevádzkuje klastre s 1 – 4 uzlami. V takom rozsahu vás nič z týchto problémov reálne nezaskočí. Prepojte štyri uzly jedným 100 GbE switchom (alebo bez switchu — pozri N05), spustite štandardné RoCE s predvolenými hodnotami a na ECMP či DCQCN nikdy nemyslite. Píšeme to napriek tomu, pretože (a) je to užitočný základ pri rozhodovaní o dimenzovaní a (b) v deň, keď prejdete zo štyroch uzlov na šestnásť, začne na tom všetkom záležať.

Čo je ECMP a prečo stačilo až do príchodu AI

ECMP — Equal-Cost Multi-Path — je smerovací trik, vďaka ktorému fungujú leaf-spine a fat-tree fabricy. Keď existuje viacero ciest s rovnakou cenou z leafu A do leafu B (cez spiny S1..S4), switch zahashuje polia paketu a podľa hashu vyberie spine. Klasický 5-tuple hash je (src IP, dst IP, src port, dst port, protocol).

Pri tradičných cloudových workloadoch — milióny krátkych TCP spojení — ECMP funguje výborne. Vyvažovanie záťaže za vás urobí zákon veľkých čísel. Pri 10 000 tokoch a 8 spinoch sa dostanete na pár percent od dokonalej rovnováhy.

ECMP bolo navrhnuté pre množstvo malých tokov. Tréning AI posiela pár obrovských synchronizovaných tokov — štatistická rovnováha sa rozpadá.

Problém obrovských tokov

Tréning AI je pravý opak webovej prevádzky. Jeden tréningový krok: každé GPU vypočíta gradient, každé GPU pošle svoj gradient všetkým ostatným (allreduce), všetci čakajú na najpomalší prenos a opakuje sa to.

Allreduce je malý počet veľmi veľkých tokov. Ring-allreduce na 8 uzloch s 200 Gbps sieťovými kartami znamená 8 súbežných tokov, každý v objeme niekoľkých gigabajtov, všetky na plnej rýchlosti linky a všetky štartujú v rovnakom okamihu. Práca Meta o RoCE vo veľkom mierku to zdokumentovala jasne: v AI klastroch pripadá na nepatrný počet „sloních“ tokov takmer celý objem dát a všetky chcú sieť naraz.

5-tuple hash v ECMP to neznáša. Pri N obrovských tokoch cez S ciest je pravdepodobnosť nulovej kolízie S! / ((S-N)! · S^N). Pre 8 tokov na 8 spinoch: približne 2,4 %. Dokonca ani 32 spinov pre 8 tokov nedá viac než ~33 %. Pridávanie spinov na hode mincou nič nemení — len dostanete viac prázdnych liniek, kým sa dva toky bijú o jednu.

Kolízia preťaží spine linku v pomere 2:1, zasiahnuté toky bežia na polovičnej rýchlosti, a pretože krok čaká na najpomalší tok, na polovičnej rýchlosti beží celá iterácia. Merania z produkčných klastrov uvádzajú, že kolízie ECMP spôsobujú až 40 % stratu výkonu pri allreduce.

Riešenia: vylepšené hashovanie, vyvažovanie na úrovni paketov, adaptívne smerovanie

Štyri reálne odpovede, zoradené podľa rastúcej náročnosti nasadenia:

1. Lepšie hashovanie (E-ECMP, QP-aware). Najlacnejšia náprava. Štandardné 5-tuple hashovanie zlepí RDMA prevádzku do jedného tuple na pár QP — jeden allreduce tok je naozaj jeden ECMP bucket. Hashujte aj podľa čísla cieľového QP v RoCE a nechajte aplikáciu rozložiť prevádzku na viacero QP („QP scaling“). Čísla od Meta: až o 40 % lepší allreduce. Stále je to štatistika — kolízie sú zriedkavejšie, nie vylúčené.

2. Flowlet switching. Zachytí nečinnú medzeru a od nej prehashuje. Pre TCP funguje, pre nepretržité RoCE zle.

3. Vyvažovanie na úrovni paketov / packet spraying. Hashuje sa pre každý paket, akceptuje sa preusporiadanie a sieťová karta si to poskladá späť. Odstraňuje problém obrovských tokov, ale vyžaduje súčinnosť sieťovej karty a switchu. Presne to robí NVIDIA Spectrum-X — rozprašovanie po paketoch s hardvérovým preusporiadaním v SuperNIC.

4. Adaptívne smerovanie. Switch sleduje zahltenie na jednotlivých portoch a namiesto slepého hashovania vyberá najmenej zaťaženú cestu s rovnakou cenou priamo pri prepínaní. V kombinácii s packet sprayingom je to presne to, čo má InfiniBand už pätnásť rokov. Jeho prenesenie na Ethernet je hlavnou novinkou NVIDIA Spectrum-X (ASIC Spectrum-4/5 + SuperNIC BlueField alebo ConnectX-8), Cisco Silicon One G200/P200 a Broadcom Tomahawk 5 / Jericho 3-AI s bunkovo plánovaným fabricom.

Pre klastre s 1 – 8 uzlami je adaptívne smerovanie zbytočný luxus. Pri úlohách so 64+ GPU škálujúcich na 1 000 GPU je to rozdiel medzi „úzkym hrdlom je sieť“ a „úzkym hrdlom sú GPU“. Práve preto si každý seriózny dodávateľ AI Ethernetu v rokoch 2024 – 2026 postavil alebo licencoval kremík s adaptívnym smerovaním.

Riadenie zahltenia: prečo „len nezahadzovať pakety“ nie je zadarmo

Druhou polovicou zložitosti smerovania je to, čo sa stane, keď na jeden port switchu dorazí naraz príliš veľa prevádzky. Dve možnosti: stratová sieť pakety zahodí a koncové body spomalia (otvorený internet); bezstratová sieť zatlačí na nadradený switch, aby pozastavil prenos — nič sa nezahodí, ale zahltenie sa šíri dozadu.

RoCE historicky vyžadovalo bezstratový fabric. RDMA karty znášajú stratu paketov zle — jediný zahodený paket spustí go-back-N opakovaný prenos celej správy, čo na 100 GbE znamená posielať znova megabajty. RoCEv2 s go-back-N je pri vysokom vyťažení na stratovej sieti v podstate nepoužiteľné.

PFC — Priority Flow Control (IEEE 802.1Qbb) je to, vďaka čomu sa Ethernet správa bezstratovo. Keď výstupná fronta switchu pre danú prioritu prekročí prah, pošle nadradenému zariadeniu PAUSE rámec so žiadosťou, aby prestalo vysielať danú prioritu. Osem priorít, osem nezávislých signálov stoj/choď.

Blokovanie na čele fronty a obete medzi tokmi

PFC pauzy sú hrubé. Pauza hovorí „prestaň posielať prioritu 3 na tejto linke“ — nevie, ktorý tok zahltenie spôsobil. Ak si prioritu 3 delí desať tokov a jeden z nich je ďalej v ceste zahltený, PFC pozastaví všetkých desať. Zvyšných deväť „obetovaných tokov“ pyká za cudzí problém. To je blokovanie na čele fronty, hlavná bolesť bezstratového Ethernetu vo veľkom.

Blokovanie na čele fronty: tok A→X vyvolá PFC na trunku. B a C komunikujúce s Y (ktoré je v poriadku) sú pozastavené tiež — obetované toky.

Deadlock PFC: ak topológia a prevádzka vytvoria cyklickú závislosť pozastavených liniek — A čaká na B, B na C, C na A — zamkne sa celý fabric. Pozorované v produkcii. Moderné switche majú detekciu deadlocku, moderné Clos topológie sú voči nemu odolné už zo svojej konštrukcie, no každé seriózne nasadenie RoCE má aj tak plán obnovy.

Zmyslom moderného riadenia zahltenia v AI je udržať buffery dosť malé na to, aby PFC v ustálenom stave nikdy nezasiahlo. PFC zostáva natiahnuté ako záchranná sieť pre skutočné mikroburstové špičky. Mechanizmus, ktorý mu bráni zasiahnuť, sa volá DCQCN.

DCQCN — štandardné riadenie zahltenia pre RoCEv2

DCQCN (DataCenter Quantized Congestion Notification) je algoritmus, na ktorom sa bezstratové RoCE ustálilo. Vyvinuli ho Microsoft a Mellanox (SIGCOMM 2015). K rokom 2025 – 2026 je to to, čo karty NVIDIA ConnectX/BlueField používajú v predvolenom nastavení, a čo Azure uvádza ako produkčný štandard naprieč „~85 % prevádzky Azure, RDMA, vo všetkých verejných regiónoch“.

DCQCN má tri roly: CP (Congestion Point) je switch, ktorý označuje pakety pomocou ECN, keď hĺbka výstupnej fronty prekročí prah (pravdepodobnostne od 0 % pri Kmin po Pmax pri Kmax); NP (Notification Point) je prijímajúca sieťová karta, ktorá pri označení ECN generuje späť odosielateľovi CNP (Congestion Notification Packet) (s obmedzenou frekvenciou, typicky jeden za 50 µs na tok); RP (Reaction Point) je odosielajúca sieťová karta, ktorá pri CNP multiplikatívne znižuje rýchlosť daného QP a v jeho neprítomnosti ju aditívne (a následne hyper-aditívne) zvyšuje.

Typická konfigurácia switchu pre DCQCN na 100 GbE:

# ECN profil v štýle NVIDIA Cumulus na bezstratovej RoCE priorite (priorita 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              # začiatok označovania
  qos ecn-kmax     200KB              # označovanie pri Pmax
  qos ecn-pmax       1%
  qos pfc priority 3
  qos pfc xoff     400KB              # PFC pauza (výrazne nad Kmax)
  qos pfc xon      300KB

Kmin/Kmax/Pmax je najčastejšie ladená trojica v RoCE. Kmin malé (pár paketov), aby ECN zabralo skôr, než sa vyčerpá buffer; Kmax oveľa väčšie, aby označovanie narastalo postupne; prah PFC pauzy výrazne nad Kmax, aby PFC zasiahlo len vtedy, keď bolo DCQCN príliš pomalé. Pôvodné nasadenie Microsoftu: Kmin = 5 KB, Kmax = 200 KB, Pmax = 1 %.

Známe slabiny DCQCN: kolaps pri incaste (100 odosielateľov zasiahne jedného príjemcu, fronta sa plní rýchlejšie, než sa CNP dostanú späť, zasiahne PFC — to rieši DCQCN+); nespravodlivosť v dlhom chvoste (neskôr začínajúce toky sú škrtené dlhšie); citlivosť na parametre (Kmin naladené na 4 uzly nefunguje na 64). Úprimné zhrnutie: DCQCN je predvolené, lebo väčšinu času funguje. HPCC, Swift, EQDS či oživené TIMELY existujú ako navrhované náhrady, ale ani jedna ho k roku 2026 nevytlačila.

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

Jasné rozlíšenie, pretože sa to často zamieňa:

• ECN — mechanizmus na IP vrstve (RFC 3168), kde switche namiesto zahodenia označujú. Je to signál, sám o sebe naň nič nereaguje.
• DCQCN — reakcia koncového bodu RDMA. Číta ECN cez CNP a upravuje rýchlosť.
• DCTCP — reakcia koncového bodu TCP. Číta ECN v ACK a škáluje okno podľa podielu označených paketov. Microsoft + Stanford, SIGCOMM 2010, dodávané vo Windows Serveri a Linuxe.

Ak prevádzkujete čistý RoCE fabric, beží vám DCQCN — poznajte svoje predvolené hodnoty. Ak máte na tom istom drôte aj TCP úložisko či riadiacu vrstvu, oplatí sa zapnúť DCTCP (net.ipv4.tcp_ecn = 1 plus switche podporujúce ECN).

Prečo AI prevádzka namáha toto všetko viac než tradičné dátové centrum

Tri vlastnosti, s ktorými klasické riadenie zahltenia nepočítalo:

1. Synchronizované špičky. Všetky GPU začnú allreduce v tej istej nanosekunde. Z nuly na 100 % vyťaženia za mikrosekundy. Žiadne zahriatie, počas ktorého by slow-start našiel správnu rýchlosť. Práve preto DCQCN štartuje na plnej rýchlosti linky.
2. Málo veľkých tokov. Zákon veľkých čísel vás nezachráni. 8 tokov → bežné kolízie ECMP; 8 príjemcov → vážne blokovanie na čele fronty cez PFC.
3. Kritickou cestou je najpomalšia linka. Čas kroku allreduce = najdlhší čas dokončenia toku. Žiadny „priemerný prípad“. Jednopercentná pravdepodobnosť zlej kolízie sa počas mesiacov tréningu nasčíta.

Preto ľudia z HPC a AI riešia siete spôsobom, aký prevádzkovatelia webu historicky nepoznali. Web je pružný — pomalé požiadavky trvajú niektorým používateľom o kúsok dlhšie. Tréning AI pružný nie je — celá úloha beží rýchlosťou svojho najpomalšieho synchronizovaného komponentu.

Zložitosť bez switchu (ochutnávka N05)

N05 sa venuje topológiám bez switchu — priame prepojenie, mesh, ring, 2D/3D torus, tesseract — pre malé klastre, kde je kúpa 100 GbE switchu zbytočná. Keď switch odstránite, routerom sa stáva každý uzol: viacero sieťových kariet, viacero ciest a niečo musí vybrať ďalší skok.

Štandardnou odpoveďou v roku 2026 je FRR (FRRouting) na každom uzle, nakonfigurovaný na BGP unnumbered. BGP unnumbered používa na peering IPv6 link-local adresy, takže na každú linku nemusíte prideľovať IPv4 adresy. Každý uzol ohlási svoj loopback, naučí sa loopbacky susedov a smerovacia tabuľka Linuxu vyberie správny ďalší skok.

# Minimálna FRR konfigurácia pre uzol v meshi bez switchu:
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         # loopback tohto uzla
    redistribute connected
  exit-address-family

Dvanásť riadkov na uzol a ECMP cez toľko párov sieťových kariet, koľko ich uzol má — s rovnakými výhradami ako pri ECMP na switchi. Pri štvoruzlovom meshi sa kolízie ECMP objavia aj na strane hostiteľa. Zmiernite ich väčším počtom QP alebo stratu akceptujte (pri štyroch uzloch je malá). „Bez switchu“ neznamená „bez zložitosti smerovania“ — len ju presuniete na hostiteľov.

Kedy to má význam pre vás

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

• 1 – 4 uzly, jeden switch, RoCE pre úložisko a občasný tréning na viacerých GPU: nechajte switch na predvolených hodnotách. Štandardné prahy DCQCN a ECN sú v poriadku. PFC je zapnuté a pauzu pravdepodobne nikdy neuvidíte. Kolízie ECMP sú reálne, ale dopad na štvoruzlový beh je v jednotkách percent.
• 4 – 16 uzlov, vyhradený tréningový klaster: zapnite DCQCN explicitne, nastavte Kmin/Kmax/Pmax na 5 KB / 200 KB / 1 % (základ podľa Azure), zapnite QP scaling v NCCL a sledujte počítadlá PFC páuz a frekvenciu CNP. Ak PFC pauzy pribúdajú, DCQCN nie je dosť agresívne — znížte Kmin.
• 16+ uzlov alebo 1 000+ GPU: adaptívne smerovanie sa vám vráti. Kúpte Spectrum-X so zodpovedajúcimi SuperNIC, alebo InfiniBand a prestaňte riešiť ECMP, prípadne sa spojte s niekým, kto už fabric v takom rozsahu prevádzkoval. Cena za chybu sú mesiace tréningového času.
• Klaster bez switchu, akejkoľvek veľkosti: FRR + BGP unnumbered. 1 – 2 dni konfigurácie a testovania na každé zdvojnásobenie počtu uzlov. Veľkým úskalím je zabudnutý ECMP na strane jadra (net.ipv4.fib_multipath_hash_policy = 1 pre hashovanie na L4).

Inštinkt „kúpim viac šírky pásma, aby zahltenie nikdy nenastalo“ je mylný. Synchronizovaná AI prevádzka vytvára okamžitý dopyt na plnej rýchlosti linky na každej ceste bez ohľadu na počet spinov. Ší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 AI výpočtoch, robotike a systémoch, ktoré ich prepájajú. Komentáre a opravy uvítame na info@kentino.com.