NVIDIA Mission Control 2.5 kiterjeszti az autonóm helyreállítási motort a Kubernetes-alapú AI-munkaterhelésekre, amelyeket az NVIDIA Run:ai kezeli. Korábban ez az automatikus helyreállítási szolgáltatás csak a Slurm-alapú, nagyteljesítményű számítási (HPC) munkaterhelésekre volt elérhető. A frissítés célja, hogy az AI-feldolgozó központok (AI factories) megbízhatóságát és rendelkezésre állását skálázható, önjavító működéssé tegye.
Miért fontos ez most?
Nagy modelltréningek ezrein GPU-n futó, több napos vagy több hetes elosztott munkameneteket igényelnek. Ebben a környezetben a hardverhibák, szoftveres hibák, hálózati időkorlátok és erőforrás-ütközések proaktív kezelése szükséges ahhoz, hogy a munkák ne veszítsenek éveket felhasználó számítási időt vagy üzleti lehetőségeket. A hagyományos, manuális beavatkozásra és reaktív monitorozásra épülő módszerek nem skálázhatók, ha több párhuzamos, többnode-os munkafolyamat fut megosztott infrastruktúrán.
Az autonóm helyreállítás alapjai
A Mission Control autonóm helyreállítási motorjának célja, hogy az AI-feldolgozó központok önjavító rendszerekké váljanak: a hibákat azonnal észlelni, a helyreállítási döntéseket a munkaterhelés kontextusa és a hiba típusa alapján intelligensen meghozni, majd a munkát automatikusan minél kisebb megszakítással újraindítani. A cél a hibák azonosítása, az anomáliák izolálása és karbantartásra megjelölése, majd a számítás termelékeny visszaállítása a lehető legkevesebb elvesztegetett idővel.
Az autonóm helyreállítási motort két szolgáltatás alkotja:
- autonomous job recovery (autonóm munkavisszaállítás)
- autonomous hardware recovery (autonóm hardver-helyreállítás)
Ezek a komponensek egy háromrétegű, integrált vezérlőhurkot alkotnak együtt a munkabeosztóval (Slurm vagy Kubernetes), ahol mindegyik szerep külön, de együttműködve működik.
A három szerep a vezérlőhurokban
-
Kubernetes-szint (munkabeosztás): az NVIDIA Run:ai a Mission Control-ban alapértelmezett Kubernetes-schedulerként kezeli a Kubernetes-alapú AI-feladatokat, a sorokat, a szabályokat és a munkák ütemezését a rendelkezésre álló kapacitásra.
-
Autonomous job recovery: ez a munkaterhelés-kontextust biztosító réteg. Figyeli a futó munkákat, követi, hogy melyik munkát melyik node vagy GPU végzi, és a hibák történetét, valamint a munkák topológiáját felhasználva dönt a helyreállítás típusáról (újraindítás, újrapróbálkozás, sorba helyezés vagy áthelyezés).
-
Autonomous hardware recovery: ez az infrastruktúra-állapot rétege. A node-okat és GPU-kat monitorozza, szükség esetén eltávolítja az anomáliákat az ütemezésből, és diagnosztikát vagy javítást indít, hogy a hardverproblémák ne terjedjenek tovább új munkákra.
E felelősségek szétválasztása hordozhatóvá és rugalmasabbá teszi a modellt: a munkavisszaállítási szolgáltatásnak nem kell hardvert javítania, a hardver-helyreállítási szolgáltatásnak nem kell minden tréning-keretrendszert ismernie, és a scheduler azonnal átirányíthatja a munkákat kész kapacitás felé anélkül, hogy megvárná a gyökérok-elemzést.
Hibautak, gyakorlati példák
A vezérlőhurok többféleképpen reagál attól függően, milyen hibajelzés érkezik:
- Hardverhiba tréning közben
Egy elosztott tréning során egy GPU hibája ECC hibákban, "fagyott" worker-ben vagy kommunikációs időkorlátban jelentkezhet. Ilyenkor a helyreállítás kettéválik: az autonomous job recovery rögzíti a munkakörnyezetet és azonosítja a gyanús node-ot vagy GPU-t, majd a Kubernetes scheduler integrációja újraindítja vagy áthelyezi a munkát más, egészséges node-okra. Ugyanakkor az autonomous hardware recovery izolálja a problémás node-ot, rögzíti az okot és diagnosztikát indít. Így a munka nem vár a gyökérok-elemzésre, és a hibás node nem kerül vissza véletlenül a következő feladat alá.
- Átmeneti szoftverhiba
Nem minden kudarc igényel hardveres beavatkozást. Ha egy worker kilép, átmeneti időkorlát lép fel, vagy a koordináció megszakad anélkül, hogy a node sérült lenne, az autonomous job recovery a munkakörnyezet ismeretében visszafogottan reagál: a rendszer a scheduler szabályai szerint újrapróbálkozik ahelyett, hogy szükségtelenül karanténba helyezne egy egész node-ot. Az autonomous hardware recovery háttérben továbbra is figyeli az állapotot, de nem avatkozik be, hacsak nem gyűlik új bizonyíték hardverproblémára.
- Korai hardverdegradáció és megelőzés
Az autonomous hardware recovery képes korán észlelni a degradációt — például ismétlődő GPU-egészségügyi figyelmeztetéseket vagy hálózati problémákat — és proaktívan eltávolítani a node-ot az ütemezhető kapacitásból, mielőtt munkát kapna. Ebben az esetben a munkavisszaállítási szolgáltatás lehet, hogy soha nem is lép közbe, mert a problémás kapacitás már körön kívül van a tényleges zavar előtt.
Működési hatás
A Mission Control autonóm helyreállítási motorának kiterjesztése az NVIDIA Run:ai által kezelt Kubernetes-munkákra előrelépés a önjavító AI-feldolgozó központok felé. A modell átalakítja a megbízhatóságot: nem egyszerűen scheduler-specifikus incidenskezelésről van szó, hanem egy scheduler-érzékeny üzemeltetési modellről.
- Platformcsapatok számára a Mission Control 2.5 egységes helyreállítási mintát biztosít Slurm és Kubernetes környezetekre: a hibás node-ok izolálva, annotálva vagy rögzítve kerülnek, diagnosztizálják őket, és csak akkor adják vissza a szolgáltatásba, amikor készen állnak.
- AI-gyakorlók számára mindkét beosztó használói egyszerűbb helyreállítási folyamattal élhetnek: a munkák újraindulhatnak, újrapróbálkozhatnak vagy visszakerülhetnek a sorba a megszokott schedulerük szabályai szerint, miközben az autonóm motor biztosítja a kontextust a felesleges ismétlődések elkerüléséhez.
- Üzleti szinten jobb kihasználtság érhető el a gyorsabb döntésekkel: kevesebb idő megy el bizonytalanságban, és több idő marad a tréningfeladatok termelékeny futtatására.
Kiadás és további újdonságok
A Mission Control 2.5 ma elérhető. A meglévő NVIDIA Mission Control felhasználók a dokumentációs központhoz fordulhatnak a frissítés részleteiért. A Kubernetes-támogatás kiterjesztésén túl a kiadás további kiemelt elemei:
- Új, AI‑vezérelt hálózati anomáliaészlelés szolgáltatás (beta)
- Javított felhasználói élmény a szolgáltatások közötti hitelesítésnél központi Keycloak használatával
- További biztonsági és Kubernetes keményítési frissítések
- Korai hozzáférés az NVIDIA Vera Rubin NVL72‑höz
A Mission Control 2.5 célja, hogy az AI‑gyártósorok számára vállalati szintű, end-to-end megoldást nyújtson munkabeosztásra, teljeskörű monitorozásra és autonóm helyreállításra.
