Nastavenie RDMA v praxi + návrh klastrového uplinku

Predchádzajúce články v sekcii N argumentovali za RDMA (N02) a prešiel si výberom topológie (N04, N05). Toto je praktická časť: nainštalujte ovládače, overte funkčnosť cesty, zapnite GPUDirect, overte NCCL, potom posuňte sa o úroveň vyššie a premýšľajte o tom, ako sa celý klaster pripája k svetu.

Predpokladáme Ubuntu 22.04 alebo 24.04, sieťové karty Mellanox/NVIDIA ConnectX-5 alebo ConnectX-6 a buď InfiniBand HDR/NDR, alebo RoCEv2 cez bezstratovú ethernetovú sieť. Príkazy sú tie, ktoré skutočne zadávame na testovacích stoliciach Kentino pred dodaním 4-uzlového klastra K-AI.

Ovládače: MLNX_OFED alebo nadradené rdma-core?

Pre čokoľvek, čo prenáša prevádzku NCCL v produkčnom prostredí, nainštalujte MLNX_OFED. mlx5 funguje, ale prehrávaš mlxconfig, zviazané perftesta — čo je najdôležitejšie — na strane jadra nvidia-peermem testované na rovnakom OFED strome.

Čistá inštalácia na Ubuntu 22.04 s jadrom 5.15.x:

tar xf MLNX_OFED_LINUX-*.tgz && cd MLNX_OFED_LINUX-*
sudo ./mlnxofedinstall --add-kernel-support --with-nvmf --force
sudo /etc/init.d/openibd restart && sudo systemctl enable openibd

--add-kernel-support Na príznakoch záleží. Ak ho preskočíte na jadre mimo matice OFED, zostavenie DKMS zlyhá potichu – nakoniec spustíte štandardný systém. mlx5 bez toho, aby ste vedeli. Potvrďte zásobník používateľského priestoru pomocou dpkg -l | grep -E 'libibverbs|rdma-core|mlnx-ofed'.

Pripojte sa a overte, či sieťová karta vidí sieťovú zložku (fabric).

Tri príkazy vám povedia všetko dôležité:

sudo mst start && mst status   # firmware tools
ibstat                          # port state, width, speed
ibv_devinfo -v                  # GIDs, max_qp, MTU, hw revision

Zdravý prístav sa prejavuje State: Active, Physical state: LinkUp, očakávané Rate: (napr. 200) a pravá Link layer: (InfiniBand alebo Ethernet). Dve oblasti, ktoré ľudia prehliadajú:

• Link layer: InfiniBand vs Ethernet. Dvojrežimový ConnectX sa prepína s mlxconfig -d /dev/mst/mt4125_pciconf0 set LINK_TYPE_P1=2 (1=IB, 2=Ethernet). Vyžaduje sa reštart.
• Rate: zodpovedá očakávanej rýchlosti. Najčastejšou tichou chybou je port NDR s rýchlosťou 200 Gb/s, ktorý sa objavil pri rýchlosti 100 Gb/s: chybný kábel, nesprávna dĺžka DAC alebo port prepínača s vynútenou nízkou úrovňou. Pred porovnávaním skontrolujte.

Na RoCE tiež potvrďte, že je vybratá verzia v2 (v1 je ethertype 0x8915, v2 je UDP/4791 a používa ju každý moderný stack): sudo cma_roce_mode -d mlx5_0 -p 1 -m 2.

Správca podsiete (iba InfiniBand)

InfiniBand nie je Ethernet – nič sa na fabric nesmeruje, kým správca podsiete (SM) nepriradí LID. Na laboratórnej fabric, sudo apt install opensm && sudo systemctl enable --now opensm na jednom uzle. V produkčnom režime spustite vstavaný modul SM na prepínači. Dva softvérové ​​moduly SM, ktoré sa navzájom pretekajú, sú popoludním ladením, ktoré nikto nepotrebuje. RoCE nemá žiadny modul SM – smerovanie je úlohou ethernetovej štruktúry, a preto je konfigurácia RoCE väčšinou o QoS prepínača, nie o hostiteľovi.

Dokážte, že RDMA skutočne funguje: perftest

Pred akýmkoľvek spustením NCCL alebo konštrukcie overte drôt pomocou perftestDva uzly, server ako prvý:

# server (node A)        # client (node B)
ib_send_bw -d mlx5_0 -F --report_gbits -D 10
ib_send_bw -d mlx5_0 -F --report_gbits -D 10 10.10.1.1

Očakávané čísla na čistej látke:

Ak ste o 20 % pod týmito číslami, nezačínajte sa naháňať s ladením NCCL. Fabric je nesprávny. Skontrolujte postupne: (1) MTU, (2) PFC na RoCE, (3) pár kábel/transceiver, (4) PCIe generátor a počet liniek pre sieťovú kartu, (5) umiestnenie NUMA. Pre NDR v racku je dosiahnuteľná latencia submikrosekundová; čokoľvek nad 5 µs na RoCE fabric s jedným prepínačom je poškodené.

GPUDirect RDMA: zapnutie cesty DMA

Celý zmysel RDMA v klastri s umelou inteligenciou spočíva v tom, že sieťová karta číta a zapisuje pamäť GPU priamo, obchádzajúc hostiteľa. To si vyžaduje... nvidia-peermem (alebo na novších jadrách DMA-BUF — NVIDIA teraz odporúča DMA-BUF tam, kde ho jadro podporuje, ale väčšina produkčných stackov stále dodáva peermem).

sudo modprobe nvidia-peermem
lsmod | grep nvidia_peermem
echo nvidia-peermem | sudo tee /etc/modules-load.d/nvidia-peermem.conf

Ak sa nenačíta, jadro nebolo zostavené s rozhraním API peer memory RDMA s podporou OFED. Poradie inštalácie je dôležité: najprv OFED, potom ovládač NVIDIA a nakoniec nvidia-peermem — peermem sa zostavuje s použitím OFED hlavičiek počas inštalácie.

Dokážte end-to-end cestu pomocou zápisu RDMA medzi GPU:

# server                                # client
ib_write_bw -d mlx5_0 --use_cuda=0 -F --report_gbits -D 10
ib_write_bw -d mlx5_0 --use_cuda=0 -F --report_gbits -D 10 10.10.1.1

--use_cuda=0 registruje pamäť CUDA na GPU 0 ako vyrovnávaciu pamäť RDMA. Ak sa výsledok líši o niekoľko percent od hodnoty pamäte hostiteľa, GPUDirect funguje. Ak je 5× pomalší, cesta prechádza cez pamäť hostiteľa – zvyčajne ide o problém so zaťažením peermem alebo topológiu PCIe, kde sa sieťová karta a grafická karta nachádzajú na opačných uzloch NUMA.

MTU a PFC pre RoCE (tu sa určuje, kde klastre RoCE žijú alebo zomrú)

RoCEv2 cez bezstratovú ethernetovú štruktúru vyžaduje spoluprácu troch vecí:

1. Veľká MTU od začiatku do konca. Nastavte hodnotu 9000 na každú sieťovú kartu, port prepínača a smerovač. RoCE vyberá najväčšiu MTU v štýle IB, ktorá sa zmestí do ethernetovej MTU – 9000 Ethernet dáva RoCE 4096-bajtovú MTU, čo je presne to, čo chcete.
2. PFC na priorite RDMA. Pauza na linkovej vrstve, ktorá zabraňuje výpadkom na určenej triede prevádzky. Štandardná prax: RDMA na priorite 3, všetko ostatné na priorite 0.
3. Označenie ECN na prepínačoch a sieťových kariet. ECN je signál dlhodobého preťaženia; PFC je krátkodobá núdzová brzda. ECN vykonáva prácu väčšinu času; PFC sa aktivuje iba vtedy, keď ECN nedokáže držať krok.

Na strane hostiteľa, s mlnx_qos:

sudo mlnx_qos -i enp1s0f0 --pfc 0,0,0,1,0,0,0,0   # PFC on prio 3
sudo mlnx_qos -i enp1s0f0 --trust dscp
echo 106 | sudo tee /sys/class/infiniband/mlx5_0/tc/1/traffic_class

Hodnota DSCP (26) a priorita PFC (3) sa musia zhodovať pri každom skoku. Prepínacia štruktúra musí toto odzrkadľovať: PFC povolené na priorite 3, označenie ECN na týchto frontoch, konfigurácia bezstratovej vyrovnávacej pamäte a hlavná rezerva na port dimenzovaná pre BDP najdlhšieho spojenia.

Kúpa prepínača od dodávateľa so zdokumentovanými šablónami RoCE (NVIDIA Spectrum, Arista, Cisco Nexus 9000) ušetrí týždeň. Ručná zmena konfigurácie PFC na generickom Broadcomovom whiteboxe je uskutočniteľná, ale je to projekt. My sme to urobili. Neodporúčame to.

DCQCN (Data Center Quantized Congestion Notification) je riadiaca slučka, ktorá spája PFC a ECN: ECN označuje pakety, keď sa front naplní, prijímač odošle späť CNP, odosielateľ spomalí a potom zvýši tempo, keď sa front vyčerpá. PFC je záložná možnosť, keď DCQCN nedokáže reagovať dostatočne rýchlo. Na modernom firmvéri ConnectX-6/7 je štandardne zapnutý a pri 4–16 uzloch sú predvolené nastavenia v poriadku. Ladiaca hra (alfa, cieľová rýchlosť, prahové hodnoty bajtov/časovačov) je pre ľudí, ktorí pracujú v mierkach, kde 0.5 % na allreduce má hodnotu dvoch týždňov práce.

NCCL: premenné, na ktorých záleží

NCCL je vrstva, ktorá používa RDMA pre PyTorch, JAX, DeepSpeed, vLLM tensor-parallel a podobné. Automaticky ich detekuje, väčšinou správne. V každom skripte pre spustenie produkčného prostredia sa zobrazujú štyri premenné prostredia:

Funkčné spustenie na klastri so 4 uzlami a 4 GPU na uzol:

export NCCL_SOCKET_IFNAME=eno1            # 1 GbE management network
export NCCL_IB_HCA=mlx5_0,mlx5_1          # both RDMA NICs
export NCCL_IB_GID_INDEX=3                # RoCE v2 GID
export NCCL_NET_GDR_LEVEL=PHB
export NCCL_DEBUG=INFO                    # one-shot, then drop to WARN

mpirun -np 16 -N 4 --hostfile hosts -x NCCL_SOCKET_IFNAME \
    -x NCCL_IB_HCA -x NCCL_IB_GID_INDEX -x NCCL_NET_GDR_LEVEL \
    -x NCCL_DEBUG ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1

NCCL_DEBUG=INFO výstup je povinné čítanie pri prvom spustení. Ukazuje vám, ktorý transport NCCL vybral (Channel ... via NET/IB/0 GDR) na pozíciu, na kanál. Pozri via NET/Socket kdekoľvek a cesta RDMA sa nepoužíva – neotestovali ste to, čo si myslíte, že ste otestovali.

Overovanie pomocou nccl-tests

nccl-tests overuje celý zásobník – ovládač, OFED, peermem, NCCL, sieť – od začiatku do konca. Číslo, na ktorom záleží, je šírka pásma zbernice (busbw), nie šírka pásma algoritmu (algbw). Šírka pásma zbernice sa normalizuje pre veľkosť kruhu/stromu a porovnáva sa s rýchlosťou kábla sieťovej karty.

Obmedzenia medzi uzlami funkcie allreduce sú približne rovné rýchlosti linky NIC / 2 (funkcia allreduce odosiela a prijíma každý bajt raz za pozíciu). Strop 200 Gb/s ≈ 25 GB/s; pozorovaná hodnota 22 GB/s je v poriadku. Ak číslo klesne 5× z 1 na 2 uzly, RDMA sa nepoužíva na medziuzlový skok. Prečítajte si NCCL_DEBUG=INFO výstup.

Teraz oddiaľte: návrh klastrového uplinku

Všetko vyššie uvedené sa týka dátová rovina — grafické procesory (GPU) v rámci štruktúry (fabric) medzi sebou komunikujú. Druhá polovica užitočného klastra je uplink: ako sa táto tkanina pripája k vonkajšiemu svetu. Ľudia neustále budujú nesprávny uplink.

Štvoruzlový tréningový klaster K-AI má tri externé vzťahy:

1. Podniková sieť / WAN — registre modelov, úložisko dátových súborov (S3, NFS, MinIO), Git, registre kontajnerov, telemetria.
2. Vývojárske pracovné stanice — inžinieri sa prihlasujú cez SSH, spúšťajú úlohy, kopírujú kontrolné body, spúšťajú Jupyter.
3. Ostatné klastre — druhý trénovací klaster, inferenčný klaster, klaster CI/eval.

Matematika šírky pásma

Ak 4 uzly znížia rýchlosť na približne 22 GB/s každý, potom interný Tkanina prenáša približne 700 Gb/s agregátu z východu na západ. uplink nemusí sa s tým zhodovať. Musí sa zhodovať s rýchlosť príjmu údajov:

• 4 uzly × 4 GPU × ~1 GB/s na GPU (model obrazu/videa) = 16 GB/s ≈ 128 Gb/s trvalé čítanie z objektového úložiska.
• Predtrénovanie LLM na tokenizovanom texte je oveľa menšie – 1–4 Gb/s, pretože tokeny sú husté a jedna dávka vydrží dlho.
• Kontrolné body jemného načítania často dosiahnu vrchol 40 Gb/s na niekoľko sekúnd a potom klesnú takmer na nulu.

Častá chyba: míňanie 40 000 eur na 400 GbE uplink, pretože interná infraštruktúra je 400 GbE. Nesprávny cieľ. Správnym cieľom je rýchlosť čítania dátovej sady. Vybudovali sme 4-uzlové klastre s 25 GbE uplinkom, ktoré fungovali naplno celé týždne na dátach tokenov LLM.

Agregovaná vs. pridelená šírka pásma

Uzol so štyrmi 100 GbE sieťovými kartami má Celkom 400 Gb/s kapacita kábla. Táto kapacita je alokovaná na tok, nie zdieľaná. Jedno TCP pripojenie medzi dvoma IP adresami používa jednu sieťovú kartu – maximálne 100 Gb/s. ECMP a hašovanie na tok distribuované odlišný tečie cez štyri sieťové karty.

• Allreduce je veľa paralelných tokov – jeden na kanál na peer. NCCL sa natívne rozprestiera cez viacero sieťových kariet (NCCL_IB_HCA (uvádzajúc obe). 4× 100 GbE je funkčne blízke 400 Gb/s pre NCCL.
• Jeden stream dátových súborov (jeden HTTP GET príkaz, ktorý ťahá 1 TB shard) je jeden tok. 4× 100 GbE dáva 100 Gb/s, nie 400. Na použitie agregátu musí zavádzač dát otvoriť paralelné streamy – čo DALI, WebDataset a Streaming od MosaicML robia zámerne.

Oddelenie tkanín

Vždy spúšťajte dve siete Fabric. Rovina riadenia nesmie byť závislá od dátovej roviny, aby fungovala – v prípade poruchy siete RDMA Fabric potrebujete prístup cez SSH.

Rovina riadenia nie je voliteľná. Keď sa dátová infraštruktúra pokazí – chybný transceiver, nesprávna konfigurácia PFC, zlyhanie prepínača – potrebujete cestu SSH, ktorá nezávisí od porušenej infraštruktúry. Ladenie RoCE búrky cez búrlivú linku je typ chyby, ktorú urobíte presne raz. IPMI/BMC a NTP sú tu tiež prítomné; skreslenie hodín je neviditeľné, kým váš distribuovaný rámec nezačne produkovať nesprávne gradienty.

Nečíslovaný BGP pre smerované Clos

Nad ~8 uzlami sa L2 leaf-spine stáva problematickým – limity spanning tree, škálovanie MAC tabuľky, búrky vysielania, žiadna natívna multipath. Modernou odpoveďou je smerovaný L3 Close: každé spojenie leaf-spine je nečíslované, BGP prenáša trasy, ECMP rozdeľuje toky cez spines.

Nečíslované BGP peer-y cez IPv6 link-local adresy jadro priraďuje automaticky, takže úplne vynecháte účtovníctvo /31 pre každý link. List s FRRouting v Linuxe vyzerá zhruba takto:

router bgp 65001
 neighbor swp1 interface remote-as external
 neighbor swp2 interface remote-as external
 address-family ipv4 unicast
  network 10.1.1.0/24
  redistribute connected

Každý list a každá chrbtica je svojím vlastným AS, eBGP propaguje spätné slučky, ECMP medzi chrbticami je bezplatný. RFC 7938 dokumentuje tento vzorec; Cumulus/NVIDIA, Arista, Cisco, Juniper dnes podporujú nečíslovaný BGP. Pri 4 uzloch je jeden prepínač v poriadku. Pri 8–16 uzloch s dvoma chrbticami sa smerovaný Close začína vyplácať sám. Nad 16 uzlami je to jediné rozumné riešenie.

Pripojenie k iným klastrom

Neumiestňujte trénovací klaster a inferenčný klaster na tú istú RDMA štruktúru. Trénovanie je obrovské, impulzívne, allreduce; inferencia pozostáva z ustálených malých správ; požiadavky na QoS sa líšia; nesprávne fungujúci tréningový beh vyčerpá inferenčnú cestu. Správnou odpoveďou sú dve samostatné štruktúry, ktoré sa stretávajú na L3 routeri s normálnym IP smerovaním. Riadiaca prevádzka medzi klastrami – fronty úloh, odosielanie protokolov, prenos artefaktov – prechádza cez riadiacu rovinu alebo cez vyhradené ethernetové prepojenie medzi klastrami. Súbor s hmotnosťou 70B má ~140 GB; kontrolný bod je 2× toľko. Pri 25 GbE to trvá ~90 sekúnd; pri 100 GbE ~22 sekúnd. Plánujte s dôrazom na väčší potenciál.

---

Toto je súčasť Kentino Wiki, referenčnej série o výpočtoch s využitím umelej inteligencie a systémoch, ktoré ju prepájajú. Opravy sú vítané na info@kentino.com.