NVIDIA Recovery az NVIDIA DSX OS részeként egy nyílt forráskódú, munkaterhelés-szintű szolgáltatás, amely automatizálja a felosztott (distributed) AI-tréning munkák körüli hibaészlelést és helyreállítást a кластер szintjén. Ahogy a párhuzamos tréningek GPU- és hálózati léptéke nő, egyedi hardver- vagy szoftverhibák — például egy leállt rank, egy NCCL-időtúllépés, egy GPU node, amely nem válaszol az ütemezőnek, vagy egy lassabb (straggler) feladat — együttesen jelentős leállást és GPU-idő pazarlást okozhatnak. Automatizált, folyamatos helyreállítás nélkül a többrétegű meghibásodások növelik a költségeket és a tréning időtartamát.
Hogyan illeszkedik az ökoszisztémába
NVIDIA Recovery a DSX OS Stack munkaterhelés-recovery rétegét adja. Kiegészíti a node-szintű egészségfigyelést és a keretrendszer-beli (framework-level) helyreállítást:
- Node- és infrastruktúra-figyeléshez Kubernetes környezetben az NVSentinel figyeli a GPU-metrikákat és XID eseményeket, automatikusan kizárhat és leüríthet (cordon and drain) hibás node-okat. Slurm-alapú telepítéseknél sok helyen egyedi prolog/epilog scripteket használnak. A slurm-operator (Slinky projekt) ezeket a scripteket injektálja, amikor Slurm Kubernetesen fut.
- In-job helyreállítást a NVRx könyvtár biztosítja (például zárolások, straggler-észlelés és újraindítás kezelése). NVIDIA Recovery ezzel szemben a klaszter-szintű koordinációt végzi: hibaattribúciót alkalmaz, dönt arról, hogy mely munkákat és hol kell újraindítani, és kezeli a node-k kizárását a későbbi újrapróbálkozások elől.
- Opcionálisan az NVIDIA Attribution mélyebb diagnosztikát ad, amely gazdagítja az audit nyomvonalat.
Ezek a komponensek modulárisak — saját megoldásokat vagy meglévő eszközöket is be lehet kötni.
A hiány költsége és miért kell automatizálni
A klaszter-szintű hatásokat szemlélteti a valószínűségi példa: ha egy GPU egy nap 99,9%-os rendelkezésre állással működik, akkor egy 10 000 GPU-t használó munka esetén a megszakítás nélküli nap valószínűsége csak 0.999^10000 ≈ 0.005%. Egy 11 hónapos vizsgálatban, amely 24 000 A100 GPU-t figyelt a Meta-nál, a hardverhibák kevesebb mint 1% munka megszakítást okoztak, ugyanakkor ezek a munkák a GPU-futásidő 19%-át tették ki — a legnagyobb, leghosszabb munkák vannak a legnagyobb kockázatnak kitéve.
NVIDIA Recovery mind kis, mind nagyméretű munkák esetén hasznos: a sok kisebb munka szintén felhalmozott megszakításokat és operációs terhet okoz, míg egyetlen nagy munka megszakítása több száz vagy több ezer GPU időveszteségét eredményezheti.
Operatív adatok és éles megfigyelés
Egy tesztkörnyezetben, 2023. július 9. és október 9. között egy NVIDIA Recovery telepítés majdnem naponta 200 munkát fedett le, és összesen körülbelül 8 550 anomália-észlelést rögzített. Az átlagos detektálási késedelem (detection latency) 69 másodperc volt, az automatikus helyreállító intézkedésig (recovery-action latency) pedig 94 másodperc. A automatizált válasz csökkenti a személyzettől való függést, de a tényleges produktív tréning visszatérését a scheduler és a checkpoint visszaállítása határozza meg.
Az automatizált recovery hurok lépései
NVIDIA Recovery négy fő lépésben működik, a konkrét műveletek a konfigurált policy-től függnek:
- Detect: az Anomaly Detector alkalmazáslogokból, scheduler-jelzésekből és GPU-metrikákból (pl. NCCL és CUDA hibák, kommunikációs zárolások, throughput romlás) ismeri fel a crash-eket, hang-eket és straggler-eket.
- Attribute: a scheduler jelzései és az alkalmazáslogok alapján a rendszer osztályozza a hibát; az NVIDIA Attribution csatlakoztatása részletesebb diagnózist ad (hardver vs. rendszer-szoftver vs. alkalmazás hiba). Az attribúció segít eldönteni a node kizárását és gazdagítja az audit nyomvonalat.
- Isolate: az Anomaly Remediator végrehajtja a javasolt lépést — például kizárja az érintett node-okat a következő újraindítási kísérletekből, vagy leállítja a további próbálkozásokat, ha azok kontraproduktívak. Egy watchdog szolgáltatás megakadályozza, hogy a munkák végtelenül várakozzanak, ha a recovery döntés elakad.
- Restart vagy Stop: a schedulerhez integrált Advisor API-n keresztül a rendszer javasolja a restartot vagy leállítást. Újraindítás esetén az alkalmazás a mentett utolsó checkpointból folytatja a munkát a saját restart logikájával. Ha a checkpoint mentése többszöri próbálkozás után sem sikerül, a további kísérletek leállíthatók. Minden döntés auditálva van; külön eseményként követik az allokáció újraindítását, a helyreállított tréning előrehaladást és a munka befejezését.
Integráció a munkaszervezőkkel (Slurm és további tervek)
NVIDIA Recovery kontroll-plane szolgáltatásként HTTP vagy gRPC API-n kommunikál a klaszter schedulerével. Jelenleg támogatott a Slurm, és a Kubernetes-támogatás a roadmap-en van. A javaslatok egy közös API-kontrakton keresztül érkeznek, amelyet a klaszter-oldali controller fordít le a helyi scheduler akcióira — így nincs szükség alkalmazáskód módosítására.
Slurm-hez a referenciaként szolgáló Advisor Controller Helm chart formában telepíthető. Két üzemmódot támogat:
- In-cluster: a controller a klaszteren belül fut.
- SSH: a control plane távolról csatlakozik Slurmhez SSH-n, anélkül, hogy a klaszterben új szolgáltatást kellene telepíteni.
A rendszer minden recovery javaslatot rögzít, így ha a controller újraindul, ellenőrzi a scheduler aktuális állapotát, hogy elkerülje az ismétléseket.
Telepítés, monitor mód és audit nyomvonal
Alapesetben új telepítés monitor (observe) módban indul: ilyenkor NVIDIA Recovery csak közzéteszi a javaslatokat és naplózza, mit tett volna, de nem hajt végre scheduler-műveletet. Ez lehetővé teszi az operátorok számára, hogy összevessék a javaslatokat saját eljárásaikkal, és csak meggyőződés után engedélyezzék az action módot.
A telepítés fő lépései:
- Telepítsd a Helm chartot: az NVIDIA Recovery egyetlen umbrella Helm chartból telepíthető, beépített MySQL al-charttal a gyorsindításhoz. Termelési környezetben érdemes egy kezelt MySQL-t használni. A repository operátor telepítési útmutatója részletezi a követelményeket (Kubernetes, Helm, Slurm verziók).
- Validáld a jelzéseket: mutass a meglévő Loki vagy Victoria Logs végpontra és a Prometheus scrape célpontra, majd futtasd a log ingest konfigurátort, amely teszteli a jelzéseket az NVIDIA Recovery szerződés szerint és feltérképezi az eltérő label neveket.
- Opt-in egy munkára: adj egy direktívát az sbatch kérésedhez, például:
#SBATCH --comment='{"nvidia-recovery":{"environment":"prod","mode":"observe"}}'
Ezután a rendszer figyeli a munkát alkalmazáslogok és scheduler-jelzések alapján; miután validáltad a javaslatokat a Recovery Console felületen, váltás action módra és acknowledgeSchedulerActions=true beállításával engedélyezheted az automatikus beavatkozásokat.
Minden végrehajtott vagy javasolt művelet felkerül egy perzisztens, lekérdezhető audit nyomvonalba: a detektált mintázat, a végrehajtott akció (kill, requeue, release, node exclusion), időbélyeg, azonosító és az NVIDIA Attribution által szolgáltatott verdikt is rögzül. A Recovery Console a kezelői műszerfal: valós időben mutatja a munkák állapotát, az anomália jelzéseket és per-munka idővonalon a detektálási és recovery eseményeket.
GitHub, licenc és partner példák
A forráskód és a issue tracker a dsx-ai-factory/NVIDIA-Recovery GitHub repositoryban található, Apache 2.0 licenccel. A gyorsindító (quickstart) végigfuttatható fizikai GPU nélkül is. IBM Research egy Slurm klaszteren először monitor módban ellenőrizte a javaslatokat, majd validálás után engedélyezte az autonóm akciót. A Verda, mint NVIDIA Cloud Partner, VictoriaLogs-ot használ és csatlakozóját (connector) már beküldte a repositoryba.
Az NVIDIA Attribution ajánlott kiegészítő telepítés: nem kötelező, de részletesebb diagnózisokat és gazdagabb audit auditfolyamot ad.
Mit várhatunk a jövőben
Jelen verzió Slurm munkákat kezel, beleértve a Slurm on Kubernetes használatát a slurm-operator révén. Következő képességek közé tartozik:
- Slurm job array recovery: hyperparameter-sweep-ek feladatainak egyedi visszaállítása és a rendszeres/ szisztémás hibák felismerése.
- Natív Kubernetes recovery: JobSet és Kubeflow PyTorchJob támogatás a Workload Map projekttel együtt.
További fejlesztési irányok: pontosabb hibaosztályozás, minden recovery döntés részletesebb nyilvántartása a dashboardon és API-n, valamint stabil kiadás felé vezető munka. A roadmap issue-kra érkező upvote-ok és kommentek befolyásolják a prioritásokat.
Összegzés
NVIDIA Recovery célja, hogy automatizálja azt a helyreállítási ciklust, amelyet ma gyakran egy mérnök kézzel végezne éjszaka. Nyílt forráskódú, Slurm-integrált megoldásként csökkenti a manuális helyreállítási terhet, felgyorsítja a detektálást és a beavatkozást, és auditálható nyomvonalat biztosít. A telepítés megkezdéséhez klónozd a GitHub repót, futtasd a konfigurátort a telemetriai stacked ellen, és jelölj ki egy munkát a monitorozásra — az első megszakítás végigmutatja a teljes hurkot end-to-end.
Elismerések
A cikk szerzői és hozzájárulói közé tartoznak: Abhishek Jha, Alex Kondratenko, Amy You, Andrew McHarg, Ashwin Poojary, Ashwini Awatiger, Bob Schatz, Collin Neale, Dave Yao, Deepak Narayanan, Dilpreet Singh, Divyansh Jain, Dong H. Ahn, Dorrin Poorkay, Evan Briones, Gargi Prasad, Haim Elisha, Hamzeh Doostie, Harmandeep Singh, Harri Lin, Himanshu Soni, Ian Gibbs, Jason Sewall, Kumar Anik, Maer Rodrigues de Melo, Megan Chao, Mike Houston, Orlando Gentil, Oscar Bejarano Ardila, Pavan Kumar Gondhi, Prateek Gera, Rajan Singh, Rakshit Sanadhya, Rajasi Purandare, Ripple Patel, Rick Izzo, Ruoxi Zhang, Satish Pasumarthi, Shelby Thomas, Stefania Alborghetti, Tony Wang, Vincent Pun és Yugal Jain.
