NVIDIA AICR-el előkészítik a Kubernetes-t a Vera Rubin NVL72 GPU-khoz

Az új NVIDIA Vera Rubin NVL72 GPU-hardverrel történő Kubernetes-bevezetés konfigurálása és optimalizálása bonyolult és hibára hajlamos: illesztőprogramok, kernel, futtatókörnyezet, hálózat, operátorok és ütemezők mind együtt kell, hogy működjenek, és a beállításokat a hardverhez és a terheléshez kell igazítani. Apró eltérések is megakadályozhatják a munkaterhelések futását vagy rontják a teljesítményt.

Az NVIDIA AI Cluster Runtime (AICR), amely a NVIDIA DSX AI Factory Platform része, úgy egyszerűsíti ezt a folyamatot, hogy a hangolt konfigurációkat újrahasználható receptekbe rögzíti, telepítési csomagokat generál a meglévő eszközökhöz, és automatikusan ellenőrzi a futó klasztert. Az AICR célja, hogy a Kubernetes környezetek Day 1-re készen álljanak a Vera Rubin NVL72 számítási tálcák fogadására.

Mi változik a GB200 NVL72-hez képest — tervezési szempontok

A Vera Rubin NVL72 a GB200 NVL72 evolúciója az NVIDIA MGX rack-skálájú architektúráján belül, de több, a felhasználó számára látható komponens is változik. Ezek ismerete előre segít a klaszter szoftver- és konfigurációváltásainak megtervezésében:

• GPU-illesztőprogram: a Vera Rubin NVL72 új illesztőágat igényel. A validáción R615.23 host-installed, open-kernel-module alapú driverrel végezték; korai támogatás célja R610, hivatalos platformtámogatás R620. Az AICR GB200-bázisa R580.173.02. R615.23 a jelenleg tesztelt verzió, nem pedig egy hivatalos minimumkövetelmény.

• DOCA és NIC/DPU driverek: a Vera Rubin tálcák a korábbi ConnectX-7 és BlueField-3 helyett NVIDIA ConnectX-9 SuperNIC-eket és NVIDIA BlueField-4 DPU-kat használnak. A DOCA 3.3.0 az első GA kiadás, amely támogatja a ConnectX-9-et; a tesztrendszer képe DOCA-OFED 3.3.0-val lett validálva. AICR itt host-installed NIC drivereket és DraNet-et használ a pod-allokációhoz; a Network Operator kompatibilitása külön kvalifikációt igényel.

• Eszköz-topológia: a NIC/GPU/DMA topológia eltér a GB200-tól, ezért GPU–NIC affinitást és NUMA-elhelyezést érdemes ellenőrizni I/O-intenzív munkaterheléseknél (pl. RDMA, GPUDirect Storage). Mindkét referencia-tálca két CPU-t és négy GPU-t tartalmaz, de a Vera Rubin tálcák nyolc ConnectX-9 PCI eszközcsoportot és 32 funkciót mutatnak, szemben a GB200 négy ConnectX-7 adapterével. A NUMA-affinitás: GPU 0–1 -> CPU NUMA 0, GPU 2–3 -> NUMA 1. A GPU–NIC kapcsolat lehet NODE (azon belül) vagy SYS (fogaskeréken keresztül).

• IMEX: többcsomópontos NVIDIA NVLink munkaterhelésekhez, mint a GB200 esetén, itt is IMEX-et használnak. DRA-kezelt IMEX esetén le kell állítani, letiltani és maszkolni a host statikus nvidia-imex szolgáltatását, hogy elkerüljük az ownership konfliktust. A DRA v0.5.0 alfa host-managed opciót ad domain izolációval; a validációk driverManaged módban futottak.

• NVIDIA MIG-profilok: Rubin GPU-k új MIG-profilokat vezetnek be; R615.23 hirdeti ezeket a node-on. Az AICR Vera Rubin receptek teljes-GPU kiosztást használnak és nem konfigurálják a MIG-et; a MIG nem része ennek a validációnak.

Mindezek a különbségek a Vera Rubin receptcsaládba vannak kódolva, így az aicr recipe és aicr validate a validált kombinációt tükrözi, és nem kell külön-külön újrafelfedezni a változásokat.

Validáció Vera Rubin NVL72-n

A végpontok közötti Vera Rubin NVL72 támogatást az AICR runtime bundle telepítésével igazolták Vera Rubin klasztereken a hivatalos GPU Operator v26.7.0 kiadással, a DRA driver v0.5.0 kiadással és host-installed R615 driverrel.

A training és az inference receptvariánsok most mindkettőnél end-to-end validálódnak telepítésre és konformitásra. A training útvonalon az első teljesítménykapu egy cross-node NCCL all-reduce volt az NVLink hálózaton keresztül, IMEX ComputeDomainon át, busz-sávszélesség küszöbértékre tesztelve. A GPU podok tisztán futottak, és az IMEX csatornák beadódtak a podsokra több node-on keresztül.

Egy korai szilikon bring-up problémát is említenek: az egyik korai Vera Rubin klaszternél egy hardver/fabric hiba miatt egy számítási tálca ki volt zárva az NVLink fabric-ból; az alkatrész újrapozícionálása után minden GPU egy tiszta fabric clique-ba csatlakozott.

Reprodukálható receptek: az AICR szerepe

A komponensek érvényesítése csak a történet fele. Egy működő Vera Rubin klaszter felállítása során dönteni kell driver módon, container-runtime kötésen, komponensverziókon és pár platform-specifikus beállításon. Az AICR ezeket a választásokat verziózott receptként rögzíti, így a konfiguráció explicit, reprodukálható és ellenőrizhető több klaszter között.

A Vera Rubin receptcsalád (service: rke2; accelerator: Vera Rubin NVL72 (vr200); OS: Ubuntu) Preview státuszban érkezik, korai elfogadó útvonalat kínál, de még nem rendelkezik a Supported receptek teljes lifecycle támogatásával, mivel a platform pre-release állapotú. A receptbe bevont döntések között szerepelnek:

• Host-managed driver: a Vera Rubin rendszerkép előtelepíti az arm64 open-kernel-module drivert, ezért a recept a GPU Operatort driver.enabled: false módban futtatja, míg a container toolkit marad operator-managed. A recept később áttér az operator-kezelt driverre, amikor az hivatalos build-ek megérkeznek.

• DRA driver ComputeDomainokkal: IMEX-alapú ComputeDomainok engedélyezettek, miközben az eszköz pluginon teljes-GPU kiosztás marad.

• Platform küszöbök és jellegzetességek: ezek egyszer be vannak kódolva (például Kubernetes >= 1.34.1 szükséges — a GA resource.k8s.io/v1 DRA API miatt és a v1.34.1 patch az RKE2 CDI/NRI útja miatt; Ubuntu 26.04 arm64, Vera-optimalizált 64k-page kernel; valamint kisebb finomságok, mint a Node Feature Discovery topology updater alapértelmezett 60Mi memóriakorlátjának emelése, mert ez OOM-hoz vezetett multi-terabájtos NVL72 munkásokon).

Az első telepítés egy, a komponensek által még sosem közösen validált platformkombinációt (arm64, Ubuntu 26.04, 64k-page kernel, RKE2 és Vera Rubin) célozta, és a klaszter átadásától a működő runtime-ig órákon belül eljutott. Egy második klaszter másnap reprodukálta az eredményt — épp a reprodukálhatóság a recept haszna.

AICR munkafolyamat élő Vera Rubin klaszteren (AICR v1.0.0)

A valós munkafolyamat négy fő lépésből áll:

1. Receptek generálása: a recept generálása offline folyamat, amely másodpercek alatt feloldja a katalóguskritériumokat és egy YAML-receptet ír ki.

2. Telepítési csomag renderelése: a bundle komponensenként rendezett Helm chartok és egy deploy script formájában generálódik; a tesztesetben 61 fájl keletkezett és 14 komponens, 5 overlay került be.

3. Snapshot és validálás: az AICR leképezi a klaszter állapotát (snapshot), ellenőrzi a recept readiness-constraintjeit, majd in-cluster jobokként lefuttatja a validátorokat. A deployment, conformance és performance fázisok mind sikeresen lefutottak a teszt klaszteren.

4. Cross-node ComputeDomain teszt: egy két-node ComputeDomain IMEX csatornákat injektáló podokkal minden tálcán sikeresen létrejött; host-managed IMEX esetén a host statikus nvidia-imex szolgáltatását le kell tiltani és maszkolni, mert a host- és DRA-kezelt IMEX jelenleg nem osztozik egy csomóponton.

A teljes recept → bundle → snapshot → deployment+conformance validáció folyamatsor élő klaszteren körülbelül öt perc alatt lefut; a performance fázis hozzáadja az NCCL munkajának futási idejét.

Validációs eredmények és mérőszámok

A táblázatba foglalt ellenőrzések alapján a Vera Rubin training recept minden deployment, conformance és performance ellenőrzést teljesített. A legfontosabb szám: az első cross-node NCCL all-reduce az IMEX ComputeDomainon át 744.71 GB/s busz-sávszélességet mért 16 GiB-os teszten.

A inference variáns (Dynamo platform, inference gateway, gang scheduling, DCGM metrikák) ugyancsak átment a deployment és conformance ellenőrzéseken ugyanazon klaszteren.

Korai-szilikon és ökoszisztéma visszacsatolások

A bring-up során felmerült hibák segítettek javításokat bejuttatni az upstream komponensekbe. Például az AICR validáció egy ismeretlen Rubin architektúraértéket talált a go-nvlib csomagokban, ami crash-loopot okozott a DRA kubelet pluginján. A javítás (go-nvlib 0.11.0 → 0.12.0) körülbelül három nap alatt ért el validált buildet Vera Rubin hardveren, és bekerült a DRA driver v0.5.0 hivatalos kiadásába.

További kompatibilitási hatás: host-managed IMEX démon és DRA-kezelt ComputeDomain egy node-on ma még nem együttélhető meg; ez a visszajelzés formálta a DRA driver v0.5.0-ban elérhető host-managed IMEX opciót.

Egyes inference-perf témák még nyitottak: például a vLLM támogatása a Rubin (sm_107a) számára megjelent v0.27.0-ban, de a SM107 kernelút érvényes működéséhez CUDA >= 13.4 szükséges; a vLLM kiadott képei (egészen v0.28.0-ig) még CUDA 13.0.3 ellen épülnek, így a tényleges VR200 inference-perf küszöb eléréséhez publikus, CUDA >= 13.4-el épített és valós hardware-en ellenőrzött runtime kép kell.

Hozzáférés és további források

A Vera Rubin receptek nyílt forráskódú formában érhetők el az NVIDIA/aicr repozitóriumban v1.0.0-ként, amely regisztrálja az rke2 szolgáltatást és a vr200 gyorsítót a publikus katalógusban. A Preview receptek kipróbálásához elegendő egy parancs:

• Training recipe generálása: aicr recipe --service rke2 --accelerator vr200 --os ubuntu --intent training

• Dynamo inference recipe generálása: aicr recipe --service rke2 --accelerator vr200 --os ubuntu --intent inference --platform dynamo

A fejlesztés és a hibajelentések nyomon követhetők a kapcsolódó GitHub-projekteken: NVIDIA/go-nvml, NVIDIA/go-nvlib, kubernetes-sigs/dra-driver-nvidia-gpu és NVIDIA/aicr.

Az AICR célja, hogy a Vera Rubin hardverre való átállást gyorsabbá, reprodukálhatóbbá és ellenőrizhetőbbé tegye a platform- és klasztercsapatok számára.