Složitost směrování v AI sítích: ECMP, adaptivní routing, DCQCN a proč tím lidé z HPC tak žijí

Předchozí články probíraly kabely, NIC karty, switche a topologie. Tento je o tom, co se děje nad nimi: jak si pakety hledají cestu napříč fabric sítí s více switchi a co brání tomu, aby se fabric zhroutila ve chvíli, kdy se deset tisíc GPU naráz rozhodne pro all-reduce.

AI provoz vypadá zásadně jinak než provoz běžného datacentra. Webový frontend posílá miliony drobných TCP spojení. AI trénink posílá několik obrovských, dokonale synchronizovaných toků na známé protějšky a všichni čekají na ten nejpomalejší. Techniky, které fungují v prvním případě, se v tom druhém rozpadají.

Upozornění hned na úvod: většina zákazníků Kentino provozuje clustery o 1–4 uzlech. V tomto měřítku žádný z popsaných problémů reálně nekousne. Propojte čtyři uzly jedním 100GbE switchem (nebo zcela bez switche — viz N05), nechte RoCE ve výchozím nastavení a na ECMP ani DCQCN nemusíte nikdy pomyslet. Píšeme to přesto, protože (a) je to užitečné pozadí pro rozhodování o dimenzování a (b) v den, kdy přejdete ze čtyř uzlů na šestnáct, začne na tom všem najednou záležet.

Co je ECMP a proč stačilo až do příchodu AI

ECMP — Equal-Cost Multi-Path — je směrovací trik, díky kterému fungují topologie leaf-spine a fat-tree. Existuje-li z leaf A do leaf B několik cest se stejnou cenou (přes spine prvky S1..S4), switch zahashuje vybraná pole paketu a podle hashe zvolí spine. Klasický 5-tuple hash je (src IP, dst IP, src port, dst port, protokol).

U tradičních cloudových workloadů — milionů krátkých TCP spojení — ECMP funguje skvěle. Vyvažování zátěže za Vás odvede zákon velkých čísel. Při 10,000 tocích a 8 spine prvcích se dostanete na pár procent od dokonalé rovnováhy.

ECMP bylo navrženo pro mnoho malých toků. AI trénink posílá několik obrovských synchronizovaných toků — statistická rovnováha se hroutí.

Problém elephant toků

AI trénink je pravý opak webového provozu. Jeden tréninkový krok: každé GPU spočítá gradient, každé GPU pošle svůj gradient všem ostatním (allreduce), všichni počkají na nejpomalejší přenos, opakovat.

Allreduce znamená malý počet velmi velkých toků. Ring-allreduce na 8 uzlech s 200Gbps NIC kartami je 8 souběžných toků, každý o několika gigabajtech, všechny na plné rychlosti linky a všechny startující ve stejný okamžik. Studie Meta o RoCE ve velkém měřítku to doložila jasně: v AI clusterech připadá na nepatrný počet „elephant“ toků téměř veškerý objem dat a všechny chtějí síť naráz.

5-tuple hash v ECMP to nesnáší. Při N elephant tocích přes S cest je pravděpodobnost nulové kolize S! / ((S-N)! · S^N). Pro 8 toků na 8 spine prvcích: přibližně 2.4 %. Ani 32 spine prvků na 8 toků nedosáhne víc než ~33 %. Přidávání spine prvků na tomto hodu mincí nic nemění — jen Vám přibude prázdných linek, zatímco se dva toky perou o jednu.

Kolize přetíží spine linku v poměru 2:1, dotčené toky běží na poloviční rychlost, a protože krok čeká na nejpomalejší tok, běží na poloviční rychlost celá iterace. Měření na produkčních clusterech uvádějí, že kolize ECMP způsobují až 40% ztrátu výkonu u operace allreduce.

Řešení: vylepšené hashování, load balancing na úrovni paketů, adaptivní routing

Čtyři reálné odpovědi, seřazené podle rostoucí náročnosti nasazení:

1. Lepší hashování (E-ECMP, s ohledem na QP). Nejlevnější náprava. Standardní 5-tuple hashování sráží RDMA provoz na jediný tuple na pár QP — jeden allreduce tok skutečně odpovídá jedinému ECMP bucketu. Hashujte i podle cílového čísla QP v RoCE a nechte aplikaci rozprostřít provoz přes větší počet QP („QP scaling“). Čísla od Meta: až o 40 % lepší allreduce. Stále jde o statistiku — kolize jsou vzácnější, nikoli vyloučené.

2. Flowlet switching. Detekujte mezeru v provozu a od ní přehashujte. Funguje u TCP, špatně u souvislého RoCE provozu.

3. Load balancing na úrovni paketů / packet spraying. Hashujte po jednotlivých paketech, smiřte se s přeházeným pořadím a nechte NIC kartu pakety poskládat. Odstraní to problém elephant toků, vyžaduje to ale součinnost NIC karty a switche. Přesně to dělá NVIDIA Spectrum-X — spraying po paketech s hardwarovým seřazením na SuperNIC.

4. Adaptivní routing. Switch sleduje zahlcení na jednotlivých portech a místo slepého hashování vybírá v okamžiku přepnutí nejméně vytíženou cestu se stejnou cenou. V kombinaci s packet sprayingem je to přesně to, co má InfiniBand už patnáct let. Přenesení do Ethernetu je hlavní novinkou produktů NVIDIA Spectrum-X (ASICy Spectrum-4/5 + SuperNIC karty BlueField nebo ConnectX-8); Cisco Silicon One G200/P200; a Broadcom Tomahawk 5 / Jericho 3-AI s plánovanou fabric na bázi buněk.

U clusterů o 1–8 uzlech je adaptivní routing zbytečný luxus. U úloh nad 64 GPU škálujících k 1,000 GPU je to rozdíl mezi „úzkým hrdlem je síť“ a „úzkým hrdlem jsou GPU“. Proto si každý seriózní dodavatel AI Ethernetu v letech 2024–2026 postavil nebo licencoval křemík s adaptivním routingem.

Řízení zahlcení: proč „prostě nezahazujte pakety“ není zadarmo

Druhou polovinou složitosti routingu je to, co se stane, když na jeden port switche dorazí naráz příliš mnoho provozu. Jsou dvě možnosti: ztrátová síť pakety zahazuje a koncové body zpomalí (otevřený internet); bezztrátová síť požádá nadřazený switch o pozastavení — nic se nezahazuje, ale zahlcení se šíří zpětně.

RoCE historicky vyžadovalo bezztrátovou fabric. RDMA NIC karty si se ztrátou paketů poradí špatně — jediný zahozený paket spustí go-back-N retransmisi celé zprávy, což na 100GbE znamená poslat znovu megabajty dat. RoCEv2 s go-back-N je na ztrátové síti při vysokém vytížení v podstatě nepoužitelné.

PFC — Priority Flow Control (IEEE 802.1Qbb) je to, co nutí Ethernet chovat se bezztrátově. Jakmile výstupní fronta switche pro danou prioritu překročí práh, pošle proti směru rámec PAUSE s žádostí, aby odesílatel přestal tuto prioritu vysílat. Osm priorit, osm nezávislých signálů stop/jeď.

Head-of-line blocking a postižené toky

PFC pauzy jsou hrubé. Pauza říká „přestaň na této lince posílat prioritu 3“ — neví, který tok zahlcení způsobil. Pokud prioritu 3 sdílí deset toků a jeden je dál po trase zahlcený, PFC pozastaví všech deset. Zbylých devět „postižených toků“ pyká za cizí problém. To je head-of-line blocking, hlavní bolest bezztrátového Ethernetu ve velkém měřítku.

Head-of-line blocking: tok A→X vyvolá PFC na trunku. B a C komunikující s Y (které je v pořádku) jsou pozastaveny také — jde o postižené toky.

Deadlock v PFC: pokud topologie a provoz vytvoří cyklickou závislost pozastavených linek — A čeká na B, B na C a C na A — zamkne se celá fabric. V produkci to bylo pozorováno. Moderní switche mají detekci deadlocku, moderní Clos topologie jsou konstrukčně bez deadlocku, ale každé seriózní nasazení RoCE má stejně plán obnovy.

Smyslem moderního řízení zahlcení pro AI je udržet buffery natolik malé, aby PFC v ustáleném stavu vůbec nespustilo. PFC zůstává nataženo jako záchranná síť pro skutečné mikrošpičky. Mechanismem, který mu v sepnutí brání, je DCQCN.

DCQCN — standardní řízení zahlcení pro RoCEv2

DCQCN (DataCenter Quantized Congestion Notification) je algoritmus, na kterém se bezztrátové RoCE ustálilo. Vyvinuly jej Microsoft a Mellanox (SIGCOMM 2015). V letech 2025–2026 je to to, co NIC karty NVIDIA ConnectX/BlueField spouštějí ve výchozím stavu, a co Azure uvádí jako produkční standard pro „~85 % provozu Azure, RDMA, ve všech veřejných regionech“.

DCQCN má tři role: CP (Congestion Point) je switch, který značí pakety pomocí ECN, jakmile hloubka výstupní fronty překročí práh (pravděpodobnostně od 0 % na Kmin po Pmax na Kmax); NP (Notification Point) je NIC karta příjemce, která při ECN značkách generuje zpět odesílateli CNP (Congestion Notification Packet) (s omezenou frekvencí, typicky jeden za 50 µs na tok); RP (Reaction Point) je NIC karta odesílatele, která při příchodu CNP multiplikativně snižuje rychlost daného QP a v jejich nepřítomnosti ji aditivně (a následně hyper-aditivně) zvyšuje.

Typická konfigurace switche pro DCQCN na 100GbE:

# ECN profil ve stylu NVIDIA Cumulus na bezztrátové RoCE prioritě (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čátek značkování
  qos ecn-kmax     200KB              # značkování na Pmax
  qos ecn-pmax       1%
  qos pfc priority 3
  qos pfc xoff     400KB              # PFC pauza (výrazně nad Kmax)
  qos pfc xon      300KB

Kmin/Kmax/Pmax je nejčastěji laděná trojice v RoCE. Kmin malý (pár paketů), aby se ECN zapojilo dřív, než dojde buffer; Kmax výrazně větší, aby značkování narůstalo postupně; práh PFC pauzy hodně nad Kmax, aby PFC sepnulo jen tehdy, když bylo DCQCN příliš pomalé. Původní nasazení u Microsoftu: Kmin = 5 KB, Kmax = 200 KB, Pmax = 1 %.

Známé slabiny DCQCN: incast kolaps (100 odesílatelů zasáhne jednoho příjemce, fronta se plní rychleji, než se stihnou vrátit CNP pakety, a sepne PFC — řeší to DCQCN+); nespravedlnost vůči pozdním tokům (později startující toky jsou škrceny déle); citlivost na parametry (Kmin vyladěný pro 4 uzly se nepřenese na 64). Poctivé shrnutí: DCQCN je výchozí volbou, protože většinu času funguje. Jako navrhované náhrady existují HPCC, Swift, EQDS i oživené TIMELY, ale k roku 2026 jej žádná z nich nevytlačila.

ECN, DCTCP a kam patří čisté TCP

Jasné rozlišení, protože se tyto pojmy často pletou:

• ECN — mechanismus na IP vrstvě (RFC 3168), kde switche místo zahazování značkují. Jde o signál, sám o sobě na nic nereaguje.
• DCQCN — to je reakcekoncového bodu RDMA. Čte ECN přes CNP pakety a upravuje rychlost.
• DCTCP — to je reakcekoncového bodu TCP. Čte ECN v ACK paketech a škáluje okno podle podílu označkovaných paketů. Microsoft + Stanford, SIGCOMM 2010, součást Windows Serveru i Linuxu.

Provozujete-li čistou RoCE fabric, provozujete DCQCN — znejte své výchozí hodnoty. Máte-li na stejném vodiči i TCP úložiště a řízení, vyplatí se zapnout DCTCP (net.ipv4.tcp_ecn = 1 plus switche podporující ECN).

Proč AI provoz namáhá tohle všechno víc než tradiční datacentrum

Tři vlastnosti, se kterými klasické řízení zahlcení nepočítalo:

1. Synchronizované špičky. Všechna GPU zahájí allreduce ve stejné nanosekundě. Z nuly na 100% vytížení během mikrosekund. Žádné zahřívání, během kterého by slow-start našel správnou rychlost. Právě proto DCQCN startuje na plné rychlosti linky.
2. Málo velkých toků. Zákon velkých čísel Vás nezachrání. 8 toků → běžné kolize ECMP; 8 příjemců → silný HoL blocking kvůli PFC.
3. Kritickou cestou je nejpomalejší článek. Doba kroku allreduce = nejdelší doba dokončení toku. Žádný „průměrný případ“. 1% pravděpodobnost nepříjemné kolize se za měsíce tréninku nasčítá.

Proto jsou lidé kolem HPC a AI sítěmi posedlí způsobem, jaký provozovatelé webových služeb historicky neznali. Web je pružný — pomalé požadavky prostě pár uživatelům chvíli trvají déle. AI trénink pružný není — celá úloha běží rychlostí své nejpomalejší synchronizované části.

Složitost řešení bez switche (ochutnávka N05)

N05 se věnuje topologiím bez switche — direct-connect, mesh, ring, 2D/3D torus, tesseract — pro malé clustery, kde je nákup 100GbE switche zbytečný. Jakmile switch odstraníte, stává se routerem každý uzel: více NIC karet, více cest a něco musí vybírat další skok.

Standardní odpovědí roku 2026 je FRR (FRRouting) na každém uzlu, nakonfigurované pro BGP unnumbered. BGP unnumbered používá k peeringu link-local adresy IPv6, takže nemusíte přidělovat IPv4 adresy každé lince. Každý uzel ohlásí svůj loopback, naučí se loopbacky protějšků a směrovací tabulka Linuxu vybere správný další skok.

# Minimální konfigurace FRR pro uzel v mesh síti bez switche:
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 tohoto uzlu
    redistribute connected
  exit-address-family

Dvanáct řádků na uzel a ECMP přes tolik párů NIC karet, kolik jich uzel má — se stejnými výhradami jako u ECMP na switchi. U mesh sítě o 4 uzlech se kolize ECMP objeví i na straně hostů. Zmírněte je větším počtem QP, nebo ztrátu přijměte (u 4 uzlů je malá). „Bez switche“ neznamená „bez složitého routingu“ — jen jej přesouvá na hosty.

Kdy na tom pro Vás záleží

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

• 1–4 uzly, jeden switch, RoCE pro úložiště a občasný trénink na více GPU: nechte switch ve výchozím nastavení. Tovární prahy DCQCN a ECN stačí. PFC je zapnuté a pravděpodobně jej nikdy neuvidíte pozastavit provoz. Kolize ECMP jsou reálné, ale dopad na běh o 4 uzlech je v jednotkách procent.
• 4–16 uzlů, dedikovaný tréninkový cluster: zapněte DCQCN explicitně, nastavte Kmin/Kmax/Pmax na 5 KB / 200 KB / 1 % (základ podle Azure), zapněte QP scaling v NCCL a sledujte čítače PFC pauz a frekvenci CNP. Pokud počet PFC pauz roste, není DCQCN dost agresivní — snižte Kmin.
• 16+ uzlů nebo 1,000+ GPU: adaptivní routing se zaplatí sám. Pořiďte si Spectrum-X s odpovídajícími SuperNIC kartami, nebo InfiniBand a přestaňte ECMP řešit, případně se spojte s někým, kdo fabric tohoto rozsahu už provozoval. Cenou za chybu jsou měsíce tréninkového času.
• Cluster bez switche, jakékoli velikosti: FRR + BGP unnumbered. 1–2 dny konfigurace a testování na každé zdvojnásobení počtu uzlů. Velkým úskalím je zapomenout na ECMP na straně jádra (net.ipv4.fib_multipath_hash_policy = 1 pro hashování na L4).

Instinkt „koupím víc propustnosti, aby zahlcení nikdy nenastalo“ je chybný. Synchronizovaný AI provoz vytváří okamžitou poptávku na plné rychlosti linky na každé cestě bez ohledu na počet spine prvků. Propustnost řeší problémy s rychlostí, ne problémy s koordinací.

---

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Připomínky a opravy uvítáme na info@kentino.com.