Nastavení RDMA v praxi + návrh uplinku clusteru

Předchozí články v sekci N argumentovaly pro RDMA (N02) a prošel výběrem topologie (N04, N05). Toto je praktická část: nainstalujte ovladače, ověřte funkčnost cesty, zapněte GPUDirect, ověřte NCCL a poté se posuňte o úroveň výš a zamyslete se nad tím, jak se celý cluster připojuje ke světu.

Předpokládáme Ubuntu 22.04 nebo 24.04, síťové karty Mellanox/NVIDIA ConnectX-5 nebo ConnectX-6 a buď InfiniBand HDR/NDR, nebo RoCEv2 přes bezztrátovou ethernetovou síť. Použité příkazy jsou ty, které skutečně zadáváme na testovacích stolicích Kentino před dodáním 4uzlového clusteru K-AI.

Ovladače: MLNX_OFED nebo upstream rdma-core?

Pro cokoli, co v produkčním prostředí přenáší provoz NCCL, nainstalujte MLNX_OFED. mlx5 funguje, ale prohrajete mlxconfig, svázaný perftesta — co je nejdůležitější — na straně jádra nvidia-peermem testováno na stejném OFED stromu.

Čistá instalace na Ubuntu 22.04 s jádrem 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

Jedno --add-kernel-support Na příznaku záleží. Pokud ho přeskočíte na jádře mimo matici OFED, sestavení DKMS selže tiše – nakonec poběžíte na standardním jádře. mlx5 aniž by věděl. Potvrďte zásobník uživatelského prostoru pomocí dpkg -l | grep -E 'libibverbs|rdma-core|mlnx-ofed'.

Připojte se a ověřte, zda síťová karta vidí fabric.

Tři příkazy vám řeknou vše 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ý portský džus se projeví State: Active, Physical state: LinkUp, očekávané Rate: (např. 200) a vpravo Link layer: (InfiniBand nebo Ethernet). Dvě pole, která lidé přehlížejí:

• Link layer: InfiniBand vs Ethernet. Duální ConnectX se přepíná s mlxconfig -d /dev/mst/mt4125_pciconf0 set LINK_TYPE_P1=2 (1=IB, 2=Ethernet). Vyžadován restart.
• Rate: odpovídá očekávané rychlosti. Port NDR s rychlostí 200 Gb/s, který se aktivoval při rychlosti 100 Gb/s, je nejčastější tichou chybou: vadný kabel, nesprávná délka DAC převodníku nebo port přepínače s vynucenou nízkou úrovní. Před porovnáním zkontrolujte.

Na RoCE také potvrďte, že je vybrána verze v2 (v1 je ethertype 0x8915, v2 je UDP/4791 a používá ji každý moderní stack): sudo cma_roce_mode -d mlx5_0 -p 1 -m 2.

Správce podsítě (pouze InfiniBand)

InfiniBand není Ethernet – nic se na fabric nesměruje, dokud správce podsítě (SM) nepřiřadí LID. Na laboratorní fabric, sudo apt install opensm && sudo systemctl enable --now opensm na jednom uzlu. V produkčním prostředí spusťte vestavěný modul SM na přepínači. Dva softwarové moduly SM, které se vzájemně předhánějí, jsou odpoledne ladění, které nikdo nepotřebuje. RoCE nemá žádný modul SM – směrování je úkolem ethernetové struktury, a proto se konfigurace RoCE týká především QoS přepínače, nikoli hostitele.

Dokažte, že RDMA skutečně funguje: perftest

Před jakýmkoli spuštěním NCCL nebo konstrukce ověřte drát pomocí perftestDva uzly, server první:

# 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čekávané hodnoty na čisté látce:

Pokud jste o 20 % pod těmito čísly, nezačínejte se snažit o ladění NCCL. Fabric je špatně. Zkontrolujte v tomto pořadí: (1) MTU, (2) PFC na RoCE, (3) pár kabel/transceiver, (4) PCIe generátor a počet linek pro síťovou kartu, (5) umístění NUMA. Pro NDR v racku je dosažitelná submikrosekundová latence; cokoli nad 5 µs na RoCE fabric s jedním přepínačem je přerušeno.

GPUDirect RDMA: zapnutí cesty DMA

Celý smysl RDMA v clusteru AI spočívá v tom, že síťová karta čte a zapisuje do paměti GPU přímo, a obchází tak hostitele. To vyžaduje... nvidia-peermem (nebo u novějších jádrech DMA-BUF — NVIDIA nyní doporučuje DMA-BUF tam, kde jej jádro podporuje, ale většina produkčních stacků stále dodává peermem).

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

Pokud se načtení nepodaří, jádro nebylo sestaveno s využitím OFED-aware RDMA peer memory API. Pořadí instalace je důležité: nejprve OFED, poté ovladač NVIDIA a nakonec nvidia-peermem — peermem se při instalaci sestavuje s ohledem na OFED hlavičkové soubory.

Prokažte cestu mezi konci pomocí zápisu RDMA mezi 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 jako vyrovnávací paměť RDMA. Pokud se výsledek odchyluje od situace s hostitelskou pamětí v řádu několika procent, GPUDirect funguje. Pokud je 5× pomalejší, cesta prochází hostitelskou pamětí – obvykle se jedná o problém se zátěží peermem nebo topologii PCIe, kde se síťová karta a GPU nacházejí na opačných uzlech NUMA.

MTU a PFC pro RoCE (zde se nachází systém, kde clustery RoCE žijí nebo umírají)

RoCEv2 přes bezztrátovou ethernetovou strukturu vyžaduje souhru tří věcí:

1. Velká MTU od začátku do konce. Nastavte hodnotu 9000 pro každou síťovou kartu, port přepínače a směrovač. RoCE vybírá největší MTU ve stylu IB, která se vejde do ethernetové MTU – Ethernet 9000 dává RoCE MTU 4096 bajtů, což je přesně to, co chcete.
2. PFC na prioritě RDMA. Pauza na linkové vrstvě, která zabraňuje výpadkům na určené třídě provozu. Standardní postup: RDMA na prioritě 3, vše ostatní na prioritě 0.
3. Značení ECN na přepínačích a síťových karetách. ECN je signál dlouhodobé zácpy; PFC je krátkodobá nouzová brzda. ECN vykonává většinu práce; PFC se aktivuje pouze tehdy, když ECN nedokáže držet krok.

Na straně hostitele, 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) se musí shodovat na každém úseku. Přepínací struktura musí toto odrážet: PFC povoleno na prioritě 3, značení ECN na těchto frontách, konfigurace bezztrátové vyrovnávací paměti a prostor pro každý port dimenzován pro BDP nejdelšího spoje.

Koupě přepínače od dodavatele s dokumentovanými šablonami RoCE (NVIDIA Spectrum, Arista, Cisco Nexus 9000) ušetří týden. Ruční změna konfigurace PFC na generickém bílém boxu od Broadcomu je proveditelná, ale je to projekt. My jsme to udělali. Nedoporučujeme to.

DCQCN (Data Center Quantized Congestion Notification) je řídicí smyčka, která propojuje PFC a ECN: ECN označuje pakety, když se fronta naplní, přijímač odešle zpět CNP, odesílatel zpomalí a poté zrychlí, když se fronta vyčerpá. PFC je záložní řešení, když DCQCN nedokáže reagovat dostatečně rychle. Na moderním firmwaru ConnectX-6/7 je ve výchozím nastavení zapnuto a na uzlech 4–16 jsou výchozí nastavení v pořádku. Ladění (alfa, cílová rychlost, prahové hodnoty bajtů/časovačů) je určeno pro lidi, kteří pracují ve měřítcích, kde 0.5 % na allreduce má hodnotu dvou týdnů práce.

NCCL: důležité proměnné

NCCL je vrstva, která používá RDMA pro PyTorch, JAX, DeepSpeed, vLLM tensor-parallel a podobné. Detekuje se automaticky, většinou správně. V každém skriptu pro spuštění produkčního prostředí se zobrazují čtyři proměnné prostředí:

Funkční spuštění na clusteru se 4 uzly a 4 GPU na uzel:

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

Jedno NCCL_DEBUG=INFO Výstup je povinný při prvním spuštění. Říká vám, který transportní NCCL vybral (Channel ... via NET/IB/0 GDR) na hodnost, na kanál. Viz via NET/Socket kdekoli a cesta RDMA se nepoužívá – neotestovali jste to, co si myslíte, že jste otestovali.

Ověřování pomocí nccl-tests

nccl-tests validuje celý stack – ovladač, OFED, peermem, NCCL, síť – od začátku do konce. Číslo, na kterém záleží, je šířka pásma sběrnice (busbw), nikoli šířka pásma algoritmu (algbw). Šířka pásma sběrnice se normalizuje pro velikost kruhu/stromu a porovnává se s rychlostí kabelu síťové karty.

Omezení meziuzlové rychlosti allreduce je zhruba na úrovni rychlosti linky NIC / 2 (allreduce odesílá a přijímá každý bajt jednou za každou úroveň). Strop 200 Gb/s ≈ 25 GB/s; pozorovaná hodnota 22 GB/s je v pořádku. Pokud číslo klesne 5× z 1 na 2 uzly, RDMA se pro meziuzlový přeskok nepoužívá. Přečtěte si NCCL_DEBUG=INFO výstup.

Nyní oddálení: návrh uplinku clusteru

Všechno výše uvedené se týká datová rovina — GPU v rámci fabric používají k vzájemné komunikaci. Druhou polovinou užitečného clusteru je uplink: jak se tato struktura propojuje s okolním světem. Lidé neustále staví špatný uplink.

Trénovací cluster K-AI se 4 uzly má tři externí vztahy:

1. Podniková síť / WAN — registry modelů, úložiště datových sad (S3, NFS, MinIO), Git, registry kontejnerů, telemetrie.
2. Vývojářské pracovní stanice — inženýři se přihlašují přes SSH, spouští úlohy, kopírují kontrolní body, provozují Jupyter.
3. Další klastry — druhý trénovací klastr, inferenční klastr, klastr CI/eval.

Matematika šířky pásma

Pokud 4 uzly sníží rychlost každého z nich na ~22 GB/s, pak interní Tkanina přenáší zhruba 700 Gb/s agregátu mezi východem a západem. uplink nemusí se s tím shodovat. Musí se shodovat s rychlost příjmu dat:

• 4 uzly × 4 GPU × ~1 GB/s na GPU (model obrazu/videa) = 16 GB/s ≈ 128 Gb/s trvalé čtení z objektového úložiště.
• Předtrénování LLM na tokenizovaném textu je mnohem menší – 1–4 Gb/s, protože tokeny jsou husté a jedna dávka vydrží dlouho.
• Kontrolní body pro jemné doladění opětovného načítání často na několik sekund dosáhnou vrcholu 40 Gb/s a poté klesnou téměř na nulu.

Častá chyba: utratit 40 000 EUR za 400 GbE uplink, protože interní fabric je 400 GbE. Špatný cíl. Správným cílem je rychlost čtení datové sady. Vytvořili jsme 4uzlové clustery s 25 GbE uplinkem, které běžely na plný výkon týdny na datech tokenů LLM.

Agregovaná vs. alokovaná šířka pásma

Uzel se čtyřmi 100GbE síťovými kartami má Celkem 400 Gb/s kapacita kabelu. Tato kapacita je alokována na tok, nikoli sdružována. Jedno TCP spojení mezi dvěma IP adresami používá jednu síťovou kartu – maximálně 100 Gb/s. ECMP a hashování na tok distribuováno odlišný protéká přes čtyři síťové karty.

• Allreduce je mnoho paralelních toků – jeden na kanál a jeden na peer. NCCL se nativně šíří přes více síťových karet (NCCL_IB_HCA (uvádíme oba). 4× 100 GbE se funkčně blíží 400 Gb/s pro NCCL.
• Jeden datový proud dat (jeden HTTP GET příkaz, který vytahuje 1TB shard) je jeden tok. 4× 100 GbE dává 100 Gb/s, nikoli 400. Aby bylo možné použít agregaci, musí zavaděč dat otevírat paralelní streamy – což DALI, WebDataset a Streaming v MosaicML dělají ze své podstaty.

Oddělení tkaniny

Vždy provozujte dvě sítě fabric. Rovina správy nesmí pro fungování záviset na datové rovině – v případě přerušení sítě fabric RDMA potřebujete přístup SSH.

Řídicí rovina není volitelná. Když dojde k přerušení datové struktury – vadný transceiver, špatná konfigurace PFC, selhání přepínače – potřebujete cestu SSH, která nezávisí na přerušené strukturě. Ladění RoCE bouře přes linku, která je v bouři, je typ chyby, kterou uděláte přesně jednou. IPMI/BMC a NTP zde také existují; zkreslení hodin je neviditelné, dokud váš distribuovaný framework nezačne produkovat nesprávné gradienty.

Nečíslovaný BGP pro směrované Clos

Nad ~8 uzly se L2 leaf-spine stává problematickou – limity spanning tree, škálování MAC tabulky, broadcast storms, absence nativní multipath technologie. Moderní odpovědí je L3 routovaný Close: každý odkaz leaf-spine je nečíslovaný, BGP přenáší trasy, ECMP rozprostírá toky napříč páteřími.

Nečíslované uzly BGP přes IPv6 link-local adresy jádro přiřazuje automaticky, takže se účetnictví /31 pro každý kanál zcela vynechá. List s FRRouting v Linuxu vypadá 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á páteř je svým vlastním AS, eBGP inzeruje zpětné smyčky, ECMP napříč páteřmi je zdarma. RFC 7938 dokumentuje tento vzorec; Cumulus/NVIDIA, Arista, Cisco, Juniper dnes všechny podporují nečíslovaný BGP. U 4 uzlů stačí jeden přepínač. U 8–16 uzlů se dvěma páteřmi se směrovaný Close začíná vyplácet. Nad 16 uzly je to jediné rozumné řešení.

Připojení k jiným clusterům

Neumisťujte trénovací cluster a inferenční cluster na stejnou RDMA fabric. Trénování je obrovské, burstní a allreduce; inference jsou ustálené malé zprávy; požadavky na QoS se liší; chybně fungující trénovací běh vyčerpá inferenční cestu. Správným řešením jsou dvě samostatné fabric, které se setkávají na routeru L3 s normálním IP směrováním. Řídicí provoz mezi clustery – fronty úloh, odesílání protokolů, přenos artefaktů – probíhá přes rovinu správy nebo přes vyhrazené ethernetové spojení mezi clustery. Soubor o hmotnosti 70B má ~140 GB; kontrolní bod je 2× větší. Při 25 GbE to trvá ~90 sekund; při 100 GbE ~22 sekund. Počítejte s větším koncem.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii umělé inteligence a systémech, které ji propojují. Opravy vítány na info@kentino.com.