Mesterséges intelligencia, magyarul.
Az eredeti közleményekből.

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

2026. szeptember 23.Forrás: NVIDIA Developer
NVIDIA NVCRE: GPU-klaszterek tesztelése éles AI-terhelés előtt
Kép: NVIDIA Developer

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.

A lényeg röviden
  • 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.

NVIDIANVIDIA Cluster Readiness EngineNVIDIA AI Cluster RuntimeNVSentineladatközpontokfelhővállalati AIchipek

Kapcsolódó hírek

CUDA Toolkit 13.4: Windows on Arm támogatás és Rubin előzetes
Fejlesztőknek2026. szeptember 9.

CUDA Toolkit 13.4: Windows on Arm támogatás és Rubin előzetes

Az NVIDIA 2026. szeptember 9-én jelentette be a CUDA Toolkit 13.4-et a vállalat fejlesztői blogján. A kiadás Windows on Arm támogatást, NVIDIA Rubin előzetes támogatást…

Az NVIDIA NVHBM-mel bővíti az NVLink Fusion AI-infrastruktúrát
Chipek és infrastruktúra2026. augusztus 26.

Az NVIDIA NVHBM-mel bővíti az NVLink Fusion AI-infrastruktúrát

Az NVIDIA 2026. augusztus 26-án ismertette, hogyan kapcsolódik az NVHBM memóriatechnológia az NVLink Fusion platformhoz. A vállalat szerint a megoldás a testreszabott…

BlueField-4-re épül az NVIDIA új Scale-In hálózati infrastruktúrája
Chipek és infrastruktúra2026. augusztus 24.

BlueField-4-re épül az NVIDIA új Scale-In hálózati infrastruktúrája

Az NVIDIA 2026. augusztus 24-én ismertette a Scale-In hálózati infrastruktúrát, amelyet az AI-gyárak hozzáférési, biztonsági, adattovábbítási és üzemeltetési feladataira…