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í.

Varování hned na začátku: 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 nevyskytuje. Propojte čtyři uzly s jedním 100GbE přepínačem (nebo žádným přepínačem – viz N05 ), spusťte základní RoCE s výchozím nastavením 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řetíží páteřní link v poměru 2:1, postiž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, které způsobují až 40% ztrátu 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 ohledem na QP). Nejlevnější řešení. Standardní hashová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. Hashujte 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 nečinné mezery a odtud opětovné hašování. 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 změnou pořadí 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 namísto slepého hašování. V kombinaci s rozprašováním paketů je to to, co InfiniBand nabízí již patnáct let. Přenesení do Ethernetu je hlavním rysem produktů NVIDIA Spectrum-X (ASICy Spectrum-4/5 + SuperNICy BlueField nebo ConnectX-8); Cisco Silicon One G200/P200; a Broadcom Tomahawk 5 / Jericho 3-AI s plánovanou strukturou založenou na buňkách.

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í spočívá v tom, co se stane, když na jeden port přepínače dorazí příliš mnoho provozu najednou. Existují dvě možnosti: ztrátová síť zahodí pakety a koncové body se odpojí (otevřený internet); bezztrátová síť se na nadřazeném přepínači pozastaví – nedojde k žádným ztrátá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 — Priority Flow Control (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í, který tok způsobil zahlcení. Pokud deset toků sdílí prioritu 3 a jeden je zahlcený v downstreamu, PFC pozastaví všech deset . Zbývajících devět „obětí“ je potrestáno za problém někoho jiného. Toto je blokování na začátku linky, což je ú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í PFC : pokud topologie a provoz tvoří cyklickou závislost pozastavených spojů – A čeká na B, B na C, C na A – celá struktura fabric se zablokuje. Pozorováno v produkčním prostředí. Moderní přepínače mají detekci zablokování; moderní topologie Close jsou konstrukčně bez zablokování; 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 (Congestion Point - bod přetížení) je přepínač, který označuje pakety pomocí ECN, když hloubka výstupní fronty překročí prahovou hodnotu (pravděpodobnostní od 0 % v Kmin do Pmax v Kmax); NP (Notification Point - bod oznámení) je síťová karta příjemce, která generuje CNP (Congestion Notification Packet - paket oznámení o přetížení) zpět odesílateli na základě značek ECN (omezených rychlostí, obvykle jeden za 50 µs na tok); RP (Reaction Point - reakční bod) je síťová karta odesílatele, která multiplikativně snižuje rychlost QP na CNP a aditivně (poté hyperaditivně) ji zvyšuje v případě 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: kolaps incastu (100 odesílatelů zasáhne jednoho příjemce, fronta se plní rychleji, než se CNP šíří zpět, PFC se aktivuje – DCQCN+ to řeší); nespravedlnost long-tailu (pozdě začínající toky jsou déle omezovány); 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 se zabývá topologií bez přepínačů – přímé připojení, síťová síť, kruhová síť, 2D/3D torus, tesseract – 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ědí v roce 2026 je FRR (FRRouting) na každém uzlu, nakonfigurovaném pro BGP unnumbered . BGP unnumbered používá pro peering lokální adresy IPv6, takže se adresy IPv4 nepřiřazují 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 vítány na adrese info@kentino.com.