Složitost směrování v sítích umělé inteligence: ECMP, adaptivní směrování, DCQCN a proč jsou lidé z HPC posedlí tím

V předchozích článcích jsme se zabývali kabely, síťovými kartami, přepínači a topologií. Tento se věnuje tomu, co se děje výše: jak pakety nacházejí cestu skrz multipřepínačovou strukturu a co brání kolapsu struktury, když se deset tisíc grafických procesorů rozhodne současně omezit přenos dat.

Provoz z umělé inteligence vypadá zásadně odlišně od běžného datového centra. Webové frontendové rozhraní odesílá miliony malých TCP spojení. Trénovací běh umělé inteligence odesílá několik obrovských, dokonale synchronizovaných toků ke známým uzlům a všichni čekají na ten nejpomalejší. Techniky, které fungují v prvním případě, se v druhém případě rozpadají.

Hned na začátku varování: většina zákazníků Kentina provozuje clustery s 1–4 uzly. V tomto měřítku se žádný z těchto problémů ve skutečnosti neobjeví. Propojte čtyři uzly s jedním 100GbE přepínačem (nebo bez přepínače – viz N05), spusťte základní RoCE s výchozími hodnotami a nikdy nepřemýšlejte o ECMP nebo DCQCN. Píšeme to i tak, protože (a) je to užitečné podkladové informace pro rozhodování o velikosti a (b) v den, kdy přejdete ze čtyř uzlů na šestnáct, na tom všem najednou záleží.

Co je ECMP a proč to bylo dost dobré, dokud se neobjevila umělá inteligence

ECMP — Equal-Cost Multi-Path — je směrovací trik, který zajišťuje fungování sítí leaf-spine a fat-tree. Pokud existuje několik cest se stejnou cenou z listu A do listu B (přes spine S1..S4), přepínač hashuje pole paketů a použije hash k výběru spine. Klasický 5-tuple hash je (src IP, dst IP, src port, dst port, protocol).

Pro tradiční cloudové úlohy – miliony krátkodobých TCP spojení – funguje ECMP skvěle. Zákon velkých čísel provádí vyvažování zátěže za vás. S 10 000 toky a 8 páteřními kanály se dostanete na několik procent dokonalé rovnováhy.

ECMP byl navržen pro mnoho malých toků. Trénování umělé inteligence odesílá několik obrovských synchronizovaných toků – statistická rovnováha se narušuje.

Problém sloního toku

Trénování umělé inteligence je opakem webového provozu. Krok trénování: každá grafická karta (GPU) vypočítá gradient, každá GPU pošle svůj gradient všem ostatním (allreduce), všechny čekají na nejpomalejší přenos a opakují se kroky.

Allreduce je malý počet velmi velkých toků. Ring-allreduce na 8 uzlech s 200 Gbps síťovými kartami je 8 simultánních toků, každý o velikosti několika gigabajtů, všechny s rychlostí linky a všechny začínají ve stejný okamžik. Metaův článek o RoCE v měřítku to jasně dokumentuje: v klastrech AI malý počet „sloních“ toků odpovídá za téměř všechny bajty a všechny chtějí síť najednou.

5-ticový hash ECMP tohle nesnáší. S N toky slonů přes S cest je pravděpodobnost nulové kolize S! / ((S-N)! · S^N)Pro 8 toků na 8 páteřích: o 2.4%Dokonce i 32 spinů pro 8 flowů zasáhne pouze ~33 %. Přidání spinů nemění hod mincí – získáte více prázdných odkazů, zatímco dva flowy bojují o jeden.

Kolize překročí povolenou hodnotu páteřního spojení v poměru 2:1, dotčené toky běží poloviční rychlostí a protože krok čeká na nejpomalejší tok, iterace běží poloviční rychlostí. Měření produkčního klastru uvádějí kolize ECMP způsobující až 40% ztráta výkonu na allreduce.

Řešení: vylepšené hashování, vyvažování zátěže na úrovni paketů, adaptivní směrování

Čtyři reálné reakce, seřazené podle rostoucího počtu narušení až po nasazení:

1. Lepší hashování (E-ECMP, s vědomím QP). Nejlevnější řešení. Standardní hašování s 5 n-ticami shlukuje provoz RDMA do jedné n-tice na pár QP – jeden tok allreduce je ve skutečnosti jeden ECMP bucket. Hašujte také číslo QP cíle RoCE a nechte aplikaci rozložit provoz mezi mnoho QP („škálování QP“). ​​Meta čísla: až o 40 % lepší allreduce. Stále statistické – kolize jsou vzácnější, nikoli eliminované.

2. Přepínání flowletů. Detekce mezery v nečinnosti a opětovné hašování odtud. Funguje pro TCP, špatně pro RoCE back-to-back.

3. Vyvažování zátěže na úrovni paketů / rozprašování paketů. Hašování na paket, akceptování změny pořadí, možnost opětovného sestavení síťové karty. Eliminuje problém sloního toku, ale vyžaduje spolupráci síťové karty a přepínače. To dělá NVIDIA Spectrum-X – rozprašování na paket s hardwarovým přeskupením na SuperNIC.

4. Adaptivní směrování. Přepínač sleduje zahlcení portů a v době přepínání vybírá nejméně zatíženou cestu se stejnou cenou, místo aby slepě hašoval. V kombinaci s rozprašováním paketů je to to, co InfiniBand nabízí již patnáct let. Přenesení této technologie do Ethernetu je hlavním rysem... NVIDIA Spectrum-X (ASICy Spectrum-4/5 + síťové karty BlueField nebo ConnectX-8 SuperNIC); Cisco Silicon One G200/P200; a Broadcom Tomahawk 5 / Jericho 3-AI s plánovanou tkaninou na bázi buněk.

Pro clustery s 1–8 uzly je adaptivní směrování zbytečné. Pro 64+ úloh GPU škálovatelných na 1 000 GPU je to rozdíl mezi „síť je úzkým hrdlem“ a „GPU jsou úzkým hrdlem“. Proto každý seriózní dodavatel AI Ethernetu v letech 2024–2026 postavil nebo licencoval křemík s adaptivním směrováním.

Řízení přetížení: proč „prostě nezahazujte pakety“ není zdarma

Druhá polovina složitosti směrování nastává, když na jeden port přepínače dorazí příliš mnoho provozu najednou. Dvě možnosti: a ztrátová síť zahazuje pakety a koncové body se odpojují (otevřený internet); bezztrátový Síť se na upstreamovém přepínači odešle zpět, aby se pozastavila – nedochází k výpadkům, ale zahlcení se šíří zpět.

RoCE historicky vyžadovalo bezztrátovou strukturu. Síťové karty RDMA špatně zvládají ztrátu paketů – jediný zahozený paket spustí opakovaný přenos celé zprávy go-back-N, což na 100 GbE znamená opětovné odeslání megabajtů. RoCEv2 s go-back-N je v podstatě nepoužitelný na ztrátové síti s vysokým využitím.

PFC — Prioritní řízení toku (IEEE 802.1Qbb) zajišťuje bezztrátové chování Ethernetu. Když výstupní fronta s prioritou přepínače překročí určitou prahovou hodnotu, odešle proti proudu rámec PAUSE s žádostí o zastavení přenosu dané priority. Osm priorit, osm nezávislých signálů stop/go.

Blokování na začátku linky a toky obětí

Pauzy PFC jsou hrubé. Pauza říká „zastavit odesílání priority 3 na tomto spoji“ – neví se, který tok způsobil zahlcení. Pokud deset toků sdílí prioritu 3 a jeden je zahlcený v downstreamu, PFC se pozastaví. všech desetDalších devět „toků obětí“ je trestáno za problém někoho jiného. Toto je blokování na začátku linky, ústřední problém bezztrátového Ethernetu ve velkém měřítku.

Blokování na začátku linky: A→X způsobí PFC na kmeni. B a C komunikující s Y (což je v pořádku) jsou také pozastaveny – toky obětí.

Zablokování PFCPokud topologie a provoz tvoří cyklickou závislost pozastavených spojů – A čeká na B, B na C, C na A – celá struktura se zamkne. Pozorováno v produkčním prostředí. Moderní přepínače mají detekci deadlocku; moderní topologie Close jsou konstrukčně bez deadlocku; ale každé seriózní nasazení RoCE má stejně plán obnovy.

Smyslem moderního řízení zahlcení AI je udržovat dostatečně malé vyrovnávací paměti, aby se PFC nikdy nespouštěl v ustáleném stavu. PFC zůstává aktivní jako bezpečnostní síť pro skutečné mikrobursty. Mechanismus, který mu brání ve spuštění, je DCQCN.

DCQCN — standardní řízení přetížení pro RoCEv2

DCQCN (DataCenter Quantized Congestion Notification) je algoritmus, na kterém se zaměřila bezztrátová technologie RoCE. Vyvinuto společnostmi Microsoft a Mellanox (SIGCOMM 2015). V letech 2025–2026 jej standardně používají síťové karty ConnectX/BlueField od společnosti NVIDIA a Azure jej hlásí jako produkční standard pro „~85 % provozu Azure, RDMA, ve všech veřejných oblastech“.

DCQCN má tři role: CP (Bod dopravní zácpy) je přepínač, který označuje pakety pomocí ECN, když hloubka výstupní fronty překročí určitou prahovou hodnotu (pravděpodobnostní od 0 % v Kmin do Pmax v Kmax); NP (Oznamovací bod) je síťová karta přijímače, generující CNP (Paket oznámení o přetížení) zpět odesílateli na značkách ECN (s omezenou rychlostí, obvykle jedna na 50 µs na tok); RP (reakční bod) je odesílatelská síťová karta (NIC), multiplikativně snižující rychlost QP na CNP a aditivně (poté hyperaditivně) zvyšující se v jejich nepřítomnosti.

Typická konfigurace přepínače pro 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 nejvíce vyladěná trojice v RoCE. Kmin je malý (několik paketů), takže ECN se aktivuje před vyčerpáním vyrovnávací paměti; Kmax je mnohem větší, takže značení se postupně zvyšuje; prahová hodnota pauzy PFC je výrazně nad Kmax, takže PFC se aktivuje pouze tehdy, pokud byl DCQCN příliš pomalý. Původní nasazení od Microsoftu: Kmin = 5 KB, Kmax = 200 KB, Pmax = 1 %.

Známé slabiny DCQCN: zhroucení odlitku (100 odesílatelů zasáhne jednoho příjemce, fronta se plní rychleji, než se CNP šíří zpět, PFC se aktivuje – DCQCN+ to řeší); dlouhodobá nespravedlnost (pozdně začínající toky jsou déle škrceny); citlivost parametrů (Kmin vyladěný pro 4 uzly se neaplikuje na 64). Upřímné shrnutí: DCQCN je výchozí, protože funguje většinu času. HPCC, Swift, EQDS a oživený TIMELY existují jako navrhované náhrady, ale žádný z nich jej do roku 2026 nenahradil.

ECN, DCTCP a kam se hodí čistý TCP

Čisté oddělení, protože se tyto sjednocují:

• ECN — Mechanismus IP vrstvy (RFC 3168), kde přepínače označují místo odstraňování. A signál, nic nereaguje samo od sebe.
• DCQCN — koncový bod RDMA reakceČte ECN přes CNP, upravuje kurz.
• DCTCP — koncový bod TCP reakceČte ECN v potvrzeních (ACK), škáluje okno podle podílu označených paketů. Microsoft + Stanford, SIGCOMM 2010, dodáváno ve Windows Serveru a Linuxu.

Pokud používáte čistou strukturu RoCE, používáte DCQCN – znáte výchozí nastavení. Pokud máte na stejném kabelu také úložiště/řízení TCP, vyplatí se povolit DCTCP (net.ipv4.tcp_ecn = 1 plus přepínače s podporou ECN).

Proč provoz s využitím umělé inteligence toto vše zatěžuje více než tradiční datová centra

Tři vlastnosti, pro které klasické řízení přetížení nebylo navrženo:

1. Synchronizované dávky. Všechny GPU začínají s allreduce ve stejné nanosekundě. Využití z nuly na 100 % v mikrosekundách. Žádné zahřívání pro pomalý start k nalezení rychlosti. DCQCN začíná s linkovou rychlostí přesně z tohoto důvodu.
2. Málo, velké toky. Zákon velkých čísel vás nezachrání. 8 toků → běžné kolize ECMP; 8 příjemců → silné blokování HoL PFC.
3. Kritická cesta je nejpomalejším článkem. Doba kroku Allreduce = maximální doba dokončení toku. Žádný „průměrný případ“. 1% pravděpodobnost špatné kolize se v průběhu měsíců tréninku zvyšuje.

Proto se lidé zabývající se HPC a umělou inteligencí zaměřují na síťové technologie tak, jak to weboví operátoři historicky nedělali. Web je elastický – pomalé požadavky trvají některým uživatelům o něco déle. Trénování umělé inteligence nikoli – celá úloha běží rychlostí své nejpomalejší synchronizované komponenty.

Bezspínací složitost (náhled na N05)

N05 Zahrnuje bezpřepínačové topologie – přímé připojení, síťové, kruhové, 2D/3D torusové, tesseractové – pro malé clustery, kde je koupě 100GbE přepínače zbytečná. Po odstranění přepínače se každý uzel stane routerem: více síťových karet, více cest, něco si musí vybrat další směrovač.

Standardní odpověď v roce 2026 je FRR (FRRouting) na každém uzlu, nakonfigurovaném pro BGP nečíslovanýBGP unnumbered používá pro peering lokální adresy IPv6, takže adresy IPv4 nepřiřazujete každému spoji. Každý uzel oznámí svou zpětnou smyčku, naučí se zpětné smyčky peerů a směrovací tabulka Linuxu vybere správný další 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

Dvanáct linek na uzel, ECMP přes libovolný počet párů síťových karet, které uzel má – se stejnými výhradami jako u ECMP přepínačů. U sítě se 4 uzly se kolize ECMP projevují i ​​na straně hostitele. Zmírněte je pomocí více QP nebo akceptujte ztrátu (malá u 4 uzlů). „Žádný přepínač“ neznamená „žádnou složitost směrování“ – přesměruje se na hostitele.

Když je to pro vás důležité

Většina čtenářů nic z toho dělat nebude muset.

• 1–4 uzly, jeden přepínač, RoCE pro úložiště a občasné trénování více GPU: Nechte přepínač na výchozím nastavení. Prahové hodnoty DCQCN a ECN pro standardní parametry jsou v pořádku. PFC je povoleno, pravděpodobně se nikdy nepozastaví. Kolize ECMP jsou reálné, ale dopad na běh se 4 uzly je v řádu jednotek procent.
• 4–16 uzlů, vyhrazený trénovací cluster: Explicitně povolte DCQCN, nastavte Kmin/Kmax/Pmax na 5 KB / 200 KB / 1 % (základní hodnota Azure), zapněte škálování QP v NCCL, sledujte čítače pauz PFC a rychlosti CNP. Pokud se počet pauz PFC zvyšuje, DCQCN není dostatečně agresivní – snižte Kmin.
• 16+ uzlů nebo 1 000+ GPU: Adaptivní směrování se vyplatí. Kupte si Spectrum-X s odpovídajícími SuperNIC nebo InfiniBand a přestaňte se starat o ECMP, případně se spojte s někým, kdo už provozoval fabric v tomto rozsahu. Cena za chybný postup je měsíce školení.
• Bezpřepínací cluster, libovolná velikost: FRR + BGP bez čísla. 1–2 dny konfigurace a testování na zdvojnásobení počtu uzlů. Velký problém je zapomenutí ECMP na straně jádra (net.ipv4.fib_multipath_hash_policy = 1 pro L4 hashování).

Instinkt „koupím si větší šířku pásma, aby nikdy nedošlo k přetížení“ je mylný. Synchronizovaný provoz umělé inteligence vytváří okamžitou poptávku na úrovni linkové rychlosti na každé trase, bez ohledu na počet páteřních bodů. Šířka pásma řeší problémy s rychlostí, nikoli problémy s koordinací.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.