Az NVIDIA bemutatta az AI Factory Operations Agent rendszerét, amelyet belső NVIDIA DGX SuperPOD üzemeltetésének automatizálására és a Site Reliability Engineer (SRE) csapatok kézi munkájának csökkentésére fejlesztettek ki. A megoldás célja, hogy különböző műszaki rétegek — például számítási erőforrások, hálózat, hardver és ütemezés — között átfogó ok-okozati összefüggéseket találjon, és ezeket egyetlen chat-alapú felületen prezentálja.
Működés és architektúra
A rendszer központi eleme egy felhasználó felé forduló agent runtime, amely a chat UI-n keresztül fogadja az SRE-k kéréseit és meghívja a megfelelő domén-specifikus alagenteket és eszközöket. Az alagentek és eszközök közötti kommunikáció a Model Context Protocol (MCP) használatával történik, amelyet bármely szervezet átvehet az AI-factory rendelkezésre állásának és teljesítményének maximalizálására.
A fejlesztői példát az NVIDIA NemoClaw blueprint köré építették. Az integráció OpenClaw pluginokon és MCP szervereken keresztül csatlakozik az infrastruktúrához; minden MCP egy jóváhagyott, fókuszált eszközkészletet tesz elérhetővé. A webes felület mellett API-n keresztül meglévő kódoló-agent felületek is hozzákapcsolhatók, így új agentek és integrációk hozzáadása a meglévő agentek módosítása nélkül lehetséges.
A keretrendszer alapja az NVIDIA OpenShell, amely támogatja az on-premises telepítést, az adat-szuverenitást és a kiterjeszthetőséget. Az agent inferenciák helyben futó NVIDIA Nemotron nyílt modelleken alapulnak, míg maga a futtatókörnyezet NVIDIA DGX H100, NVIDIA DGX B200 és NVIDIA DGX GB300 gyártási klasztereken üzemel.
Telepítés és futtatás Kubernetes-ben
Az AI Factory Operations Agent Kubernetes control-plane alkalmazásként fut. Helm chartok telepítik a felületet, az OpenClaw átjárót, az MCP eszközszervereket, az inferencia végpontot és az NVIDIA OpenShell runtime-ot Kubernetes szolgáltatásokként. A chat UI minden kérést a NemoClaw-nak küld, amely a megfelelő domén agenthez továbbítja azt.
A shell-parancsok futtatása per-session Kubernetes sandboxban történik, nem a fő gateway podon belül. A sandbox megkapja az AI Factory Operations Agent munkaterületét, a kiválasztott képességeket és a parancs-politikát; életciklusa nem módosít meglévő szolgáltatásokat vagy gyártási munkaterheléseket.
A biztonság rétegzett: a Kubernetes-ellenőrzések a szerveroldali run_kubectl eszközön keresztül futnak, amely egy rögzített kubectl binárist hív olvasási jogosultságokkal. OpenShell nem kap kubectl-t vagy Kubernetes hitelesítő adatokat. A Kubernetes service accountok és a role-based access control (RBAC) határozzák meg, mely erőforrásokra kérhetnek rá az eszközök. A futtatás ugyanazon hozzáférési úton történik, amelyen keresztül az agent is látja a klasztert, így a kapott eredmények tükrözik, mit tud és mit nem tud megtenni az agent a klaszteren belül.
Példák egyes jogosultságokra a rendszerben:
(agent) $ kubectl auth can-i get pods yes (agent) $ kubectl auth can-i get configmaps yes (agent) $ kubectl auth can-i get secrets no (agent) $ kubectl auth can-i create pods no (agent) $ kubectl auth can-i update pods no
Domén-specifikus alagentek és eszközök
A belső NVIDIA telepítés több, egyre bővülő adatkörnyezet-specifikus agentet használ, amelyek javaslatokkal látják el az SRE-ket:
- Job Recovery Agent: észleli a tréningfeladatok hibáit és a goodput csökkenését, több rétegű okfeltárást végez (ütemező, alkalmazás, hardver, hálózat), és helyreállítási lépéseket ajánl, ha a gyökérok megerősítést nyer.
- Hardware Agent: eszközszintű hibakeresést végez (PCIe hibák, ECC hibák, GPU problémák, NVMe meghibásodások, hőmérsékleti anomáliák), és a tüneteket az adott komponensig vezeti vissza.
- Observability Agent: lekérdezi a történeti Prometheus, telemetria és integrált Grafana Loki logokat, dinamikusan létrehoz dashboardokat, és megjeleníti azokat a webes felületen.
- Research Agent: előre betöltött dokumentációk, köztük az NVIDIA Mission Control kézikönyvei és a DGX SuperPOD referenciaarchitektúrák keresésére szolgál; saját runbookok és helyspecifikus útmutatók feltöltését is támogatja.
- Kubernetes Agent: olvasási jogú operacionális áttekintést ad podokról, szolgáltatásokról, deploymentekről, GPU-erőforrásokról, node státuszról és az ütemezés állapotáról.
- Cluster Management Agent: az NVIDIA Base Command Manager API-kkal interfészel diagnosztikai MCP eszközökön keresztül, klaszterkezelési javaslatokhoz és hibakereséshez.
A keretrendszer továbbá keresztmetszeti MCP eszközöket egyesít, mint a webkeresés, kódvégrehajtás és Grafana dashboard integráció. Lehetőség van saját MCP szerverek és API-k csatlakoztatására is, így a rendszer alkalmazkodik meglévő ütemezőkhöz, observability platformokhoz és operációs eljárásokhoz.
Tapasztalatok és tanulságok
Az NVIDIA a rendszer finomítását a gyökérok-elemzés pontosságának mérése, az SRE-k egyetértésének nyomon követése és az agent ökoszisztéma bővítése útján végzi. A gyakorlati tapasztalatokból öt fontos tanulság emelkedik ki:
- Egyértelmű agent-határok: az átfedő felelősségek zajt okoznak a jel helyett.
- Első a read-only: pontos vizsgálatok építik az SRE-k bizalmát az automatizálás előtt.
- Rétegek közötti korreláció: a keretrendszer képes összekapcsolni a munkaterhelés, hardver és hálózat jeleit, és gyökérokokat találni, amelyeket elkülönült eszközök nem látnak.
- Precíz MCP eszközök: egyértelmű eszközdefiníciók javítják az útválasztást és csökkentik a hibás eszközválasztást.
- Átlátható érvelés: az SRE-knek látnia kell az eszközhívásokat, bizonyítékokat és következtetéseket, mielőtt lépnének.
Telepítési javaslatok nagy rendszerekhez és multi-tenant környezetekhez
Nagy léptékű AI-factoryk számára ajánlott egy dedikált, GPU-gyorsított control plane használata, amely elkülönül a gyártási klasztertől. A control plane az agent-orchestrationt és a reasoning-et kezeli, miközben a gyártási klaszter telemetriát szolgáltat anélkül, hogy képzési GPU-kat használnának vagy megzavarnák a munkaterheléseket.
A belső NVIDIA telepítések dedikált GPU kapacitáson futtatják a modell inferenciát, és a meglévő control-plane CPU Kubernetes admin térben tartják a runtime szolgáltatásokat. Kisebb vagy eltérő követelményű telepítések használhatnak helyi vagy felhő alapú inferencia végpontot az adat-szuverenitás, klaszterméret és rendelkezésre álló GPU kapacitás függvényében; kisebb telepítésekhez említésre kerül az RTX PRO Workstation vagy a DGX Spark.
Több bérlős környezeteknél a scope-olt agentek, eszközök, sandboxok és Kubernetes jogosultságok szabályozzák, hogy mely klaszteradatokhoz, eszközökhöz és node-okhoz fér hozzá egy-egy tenant. A tenant SRE-k csak saját namespace-eiket, jobjaikat és node-jukat látják, míg a központi üzemeltetés szélesebb láthatóságot tarthat fenn. OpenShell minden tenant agentjét és eszközét izolált sandboxban futtatja kernel-szintű korlátozásokkal.
Hogyan kezdjenek hozzá
Az érdeklődők az AI Factory Operations Agent fejlesztői példát és az open source keretrendszert elérhetik GitHub-on. A sorosztályozás szerint az orchestration keretrendszer kísérleti open source szoftverként érhető el; az API-k, konfigurációk és telepítési követelmények kiadások között változhatnak. NVIDIA ügyfelek a saját account managerüknél kérhetnek hozzáférést az NVIDIA által fejlesztett klaszterműveleti agentekhez.
