NVIDIA NVCRE: GPU-klaszterek tesztelése éles AI-terhelés előtt

Valódi elosztott AI-terhelésekkel ellenőrizné a GPU-klaszterek éles üzemre való alkalmasságát az NVIDIA Cluster Readiness Engine. A nyílt forrású Kubernetes-vezérlő célja, hogy még a produkciós futtatások előtt kiderüljön, mely csomópontok okozhatnak hibát vagy teljesítményromlást.
- Az NVCRE nyílt forrású Kubernetes-vezérlő GPU-klaszterek éles üzem előtti validálására.
- Valódi elosztott munkaterheléseket futtat topológiatudatos csomópontcsoportokon.
- A hibákat konkrét csomópontokhoz és kategóriákhoz, például NCCL-hez vagy NeMo előtanításhoz köti.
- A beépített katalógus NCCL-variánsokat, DCGM level-4 diagnosztikát és Nemotron 5 modellekkel végzett NeMo előtanítást tartalmaz.
- A diagnose mód adaptív hibaszigeteléssel szűkíti a gyanús csomópontok körét.
Miért nem elég a hagyományos egészségellenőrzés?
Az NVIDIA Developer blogján 2026. szeptember 23-án megjelent bejegyzés szerint egy GPU-klaszter akkor is elbukhat egy AI-munkaterhelésen, ha az egészségellenőrzések szerint minden GPU, hálózati kapcsolat és pod rendben van. A cég példája szerint egy 512 GPU-s tanítási feladat alulteljesíthet vagy meg is hiúsulhat egy lassú GPU, terhelés alatt romló kapcsolat vagy olyan konfiguráció miatt, amely csendben lassabb útvonalra tereli a forgalmat.
Az ilyen hibák sokszor csak órákkal a futás kezdete után, vagy ügyfélhibajegy alapján derülnek ki. Az NVIDIA szerint ilyenkor a csapatok napokat tölthetnek a klaszter feldarabolásával és a gyökérok keresésével, miközben a kapacitás kihasználatlan marad.
Erre kínál megoldást az NVIDIA Cluster Readiness Engine, röviden NVCRE. A nyílt forrású Kubernetes-vezérlő valódi elosztott munkaterheléseket futtat topológiatudatos csomópontcsoportokon, méri az eredményeket, majd jelzi, mely csomópontok buktak el az egyes teszteken. A cél, hogy az üzemeltetőknek ne kelljen kézzel NVIDIA Collective Communications Library, vagyis NCCL manifeszteket írniuk, rackeket manuálisan felezgetniük, vagy ügyfélhibajegyből értesülniük a degradált hardverről.
Réteges API és konkrét hibához kötött eredmények
Az NVCRE Kubernetesben egyéni erőforrás-definíciókra, azaz CRD-kre épül. Ezeket a felhasználók kubectl-lel vizsgálhatják, és GitOps munkafolyamatokkal is kezelhetik. Az API három erőforrást rendez hierarchiába: Certification, Workflow és Job.
A Certification az a fő erőforrás, amelyet a felhasználó létrehoz. Ez nevezi meg a tesztelendő csomópontokat és a futtatandó kategóriákat. A Workflow egy kategóriát kezel, alkalmazza a katalógus-, platform- és GPU-felülírásokat, kezeli az iterációszámot, beállítja az orkesztrációs célt, majd létrehozza a gyerek Job erőforrást. A Job futtatja a munkaterhelést a cél csomópontcsoporton, figyeli a csomópontok állapotát, és rögzíti a méréseket és hibákat.
Az eredmények alulról felfelé terjednek vissza. A Job rögzíti, mely csomópontok hibáztak és miért, a Workflow jelenti a teszt eredményét, a Certification pedig kategóriák szerint csoportosítja az eredményeket. Az NVIDIA példája szerint egy futás meg tudja mutatni, hogy a gpu-01 hardverhibát jelzett NCCL alatt, míg a gpu-02 nem érte el a sávszélességi célt.
A beépített katalógus jelenleg három területet fed le: öt NCCL kommunikációs változatot, ezek az all-reduce, all-gather, all-to-all, loopback és loopback NVIDIA NVSwitchön keresztül, az NVIDIA Data Center GPU Manager, vagyis DCGM level-4 diagnosztikai csomagját, valamint NVIDIA NeMo előtanítást NVIDIA Nemotron 5 modellekkel 8B és 56B paraméteres méretben. Minden bejegyzés platformtudatos alapbeállításokat tartalmaz.
Mérhető küszöbök, skálafüggő tesztek
Az NVCRE érzékeli a célcsomópontok GPU-architektúráját és felhőplatformját, majd ezekből vezeti le a konfiguráció többi részét, beleértve a csomópontonkénti GPU-számot, az NCCL környezetet és a platformspecifikus hálózati beállításokat.
A sikeres és sikertelen minősítés feltételei Common Expression Language, röviden CEL kifejezésekkel adhatók meg, és a mért metrikákon értékelődnek ki. Alapértelmezett küszöbértékek nem érkeznek a rendszerrel. A forrásban szereplő példák NVIDIA GB200 NVL72-osztályú rendszerekre illusztratív értékekként szerepelnek, például busBandwidthGBps esetén a value >= 900, goodputRatio esetén a value >= 0.9, avgTFLOPsPerGPU esetén a value >= 800.
Ha egy mért metrika nem éri el a célértéket, az NVCRE ValidationFailed feltételt állít be. Ezt külön kezeli attól, hogy maga a futás technikailag sikeresen lefutott-e. Így egy befejeződő, de a célt nem teljesítő munkaterhelés is hibaként jelenik meg.
A tesztelési skálát a testScale mező szabályozza. Az intra-node stratégia minden csomópontot külön tesztel. Az intra-rack topológiai tartomány szerint particionálja a csomópontokat az nvidia.com/gpu.clique címkével. A full-scale minden csomópontot egyetlen csoportba tesz. A diagnose adaptív hibaszigetelést indít.
Automatikus hibaszigetelés és WorkloadRun
A többcsomópontos validálás egyik nehéz esete az, amikor a hiba nem köthető azonnal egyetlen csomóponthoz. Az NVIDIA példája szerint egy 64 csomópontos all-reduce alacsony sávszélességet ad vissza, és a csoport minden csomópontja gyanússá válik. Kézzel ennek elszigetelése napoknyi mérnöki munkát igényelhet.
Az NVCRE ezt a folyamatot automatizálja. A testScale: diagnose beállítás topológiatudatos, hierarchikus csoporttesztelést futtat. A motor felosztja a hibás csoportokat, újrafuttatja a feleket, és addig folytatja ezt, amíg eléri a minGroupSize értéket. Azok a csoportok, amelyek ekkora méretnél is hibáznak, gyanúsként jelennek meg. A maxConcurrent korlátozza az egyszerre futó feladatok számát, hogy ne telítsék a mérés tárgyát képező hálózati fabricot.
Az NVCRE külön WorkloadRun API-t is kínál többcsomópontos GPU-munkaterhelések Kubernetes alatti futtatásához. Ez kezeli a platformfelismerést, a keretrendszer-specifikus futtatási konfigurációt, a GPU- és hálózati erőforrásigényeket, valamint a sikertelen futás utáni takarítást. A felhasználónak konténerképet, keretrendszert és csomópontszámot kell megadnia.
A forrás szerint a WorkloadRun kezeli többek között a platformdetektálást, a keretrendszer-specifikus runtime-konfigurációt és opcionálisan a gang schedulinget is, amely több pod összehangolt indítását segíti.
Mit jelent ez az üzemeltetőknek?
Az NVCRE a GPU-klaszterek élesítés előtti bizonyítására helyezi a hangsúlyt. A forrás alapján a rendszer nem pusztán állapotjelzésekre támaszkodik, hanem ugyanazokat a jellegű elosztott terheléseket futtatja, amelyek alatt a hardver- vagy konfigurációs problémák előjöhetnek.
Ez az üzemeltetők számára azt jelenti, hogy a klaszter készültsége mérhető tulajdonságként jelenhet meg. A hibaeredmények konkrét csomópontokhoz és kategóriákhoz kapcsolódnak, például NCCL kommunikációhoz vagy NeMo előtanításhoz, így a vizsgálat célzottabb lehet.
Az NVIDIA a következő lépések között az NVCRE CLI telepítését, a vezérlő inicializálását az nvcrectl setup init paranccsal, valamint egy végponttól végpontig tartó validálás futtatását említi a dokumentáció alapján. A cég arra is kéri a felhasználókat, hogy GitHubon katalógusbejegyzésekkel, workload adapterekkel vagy tesztekkel bővítsék a lefedettséget új architektúrák és inferencia-munkaterhelések irányába.
Az NVCRE az NVIDIA AI Cluster Runtime-mal és az NVSentinellel is integrálódik. A forrás szerint ezek együtt alkotják az NVIDIA DSX OS működési rétegét: az AI Cluster Runtime validált konfigurációt, az NVSentinel pedig folyamatos, telemetriaalapú egészségfigyelést ad.
NVIDIA Developer: Validate GPU Cluster Readiness Before AI Workloads Land


