NVIDIA dona OpenShell alla CNCF e aggiunge strumenti open source per le fabbriche di IA

NVIDIA ha annunciato il 10 novembre 2026, in occasione di KubeCon + CloudNativeCon, che contribuirà il suo runtime per la sicurezza degli agenti OpenShell alla Sandbox della Cloud Native Computing Foundation (CNCF) e rilascerà tre componenti open source per la sua piattaforma DSX AI Factory.

Gli annunci collegano la governance degli agenti all’infrastruttura necessaria per eseguirli in modo efficiente. NVIDIA contribuisce anche al progetto Agent Substrate, nato in Google, e aggiunge a DSX Kubernetes Engine, Kubernetes Recipes e Snapshot, che si occupano rispettivamente dell’esecuzione delle sessioni, della gestione dei cluster e del ripristino dell’inferenza.

OpenShell si avvia verso una governance comunitaria

OpenShell applica controlli deterministici mentre gli agenti autonomi utilizzano strumenti, accedono ai servizi di inferenza ed eseguono carichi di lavoro. Esegue gli agenti in ambienti sandbox isolati a livello di kernel, con criteri dichiarativi YAML che regolano l’accesso al file system, alla rete, ai processi e alle credenziali dei provider. Le credenziali vengono inserite solo nelle richieste destinate a endpoint approvati; inoltre, la verifica formale controlla se una modifica proposta ai criteri concederebbe nuovi accessi rischiosi prima dell’approvazione.

Il runtime è concesso in licenza con Apache 2.0. NVIDIA riferisce che lo hanno utilizzato centinaia di organizzazioni, che in meno di un anno sono arrivati decine di migliaia di contributi e che alla governance della Sandbox parteciperanno le organizzazioni che integrano il progetto nei propri prodotti. La transizione è ancora in corso: un avviso sul progetto comunica che lo sviluppo si sta spostando nell’organizzazione ai-openshell; durante il passaggio, codice, segnalazioni e richieste di pull resteranno in NVIDIA/OpenShell.

Agent Substrate punta a ridurre le risorse inattive

Agent Substrate affronta il costo di mantenere attive le sessioni degli agenti. Spesso gli agenti attendono prompt, risultati degli strumenti o risposte dei modelli; un Pod Kubernetes dedicato e sempre attivo mantiene le risorse durante queste pause, mentre ricreare il Pod comporta la perdita dello stato e un nuovo avvio a freddo. NVIDIA e Google stanno inoltre collaborando all’integrazione di OpenShell per agenti che operano su cloud e sistemi on-premise.

La progettazione di Agent Substrate distribuisce numerose sessioni con stato su un insieme più ristretto di worker sempre attivi. Il sistema crea checkpoint delle sessioni inattive, inclusi lo stato della memoria e del file system, libera i worker e ripristina le sessioni su quelli disponibili senza ripetere la normale procedura di creazione dei Pod Kubernetes. I worker restano normali Pod Kubernetes, quindi continuano ad applicarsi le politiche di pianificazione del cluster, le quote e i criteri di collocamento. I carichi di lavoro previsti includono assistenti alla programmazione, ambienti di apprendimento per rinforzo e ambienti sandbox di ricerca su GPU di breve durata.

NVIDIA sta sviluppando l’interoperabilità con Dynamo per l’inferenza e con KAI Scheduler per le risorse condivise del cluster. Dynamo può fornire il tempo previsto fino al primo token e il livello di saturazione dei pool di GPU, consentendo ad Agent Substrate di decidere se mantenere un agente attivo, sospenderlo o riprenderlo. Le API sono ancora in evoluzione, il supporto alle GPU viene ricostruito attorno a Kubernetes Dynamic Resource Allocation e alcune parti dell’integrazione con Dynamo sono sperimentali.

DSX aggiunge la gestione dei cluster e ripristini più rapidi

NVIDIA Kubernetes Engine e NVIDIA Kubernetes Recipes (NVKE e NVKR) sono disponibili in anteprima pubblica con licenza Apache 2.0. NVIDIA afferma che le API, la configurazione e il comportamento potrebbero cambiare e per ora non ne consiglia l’uso nei carichi di lavoro di produzione. NVKR crea immagini dei nodi e dei container, file binari e grafici Helm riproducibili a partire da sorgenti con versioni bloccate e registra gli input. NVKE usa questi artefatti per predisporre e gestire i cluster tramite un’API REST e controller, ma i progetti possono essere adottati anche separatamente.

NVKE crea cluster per i carichi di lavoro dei clienti con piani di controllo Kubernetes, istanze etcd e pool di nodi separati. Ottiene capacità bare metal tramite NVIDIA Infra Controller e il relativo provider Cluster API, CAPNICo; prima di ricevere le credenziali per unirsi al cluster, un nodo deve presentare un’identità SPIFFE attestata. Firmus e SK Telecom stanno integrando i progetti nelle proprie fabbriche di IA, mentre Mirantis, Netris, OpenNebula Systems, Rafay, Spectro Cloud e vCluster hanno in programma integrazioni che coinvolgono le loro piattaforme infrastrutturali, le offerte Kubernetes gestite o l’automazione di rete.

NVIDIA Snapshot affronta gli avvii a freddo dell’inferenza creando checkpoint della memoria CPU e GPU di un carico di lavoro completamente inizializzato. Per il ripristino sono necessari lo stesso modello di GPU e lo stesso driver; inoltre, si evitano le operazioni ripetute di caricamento dei pesi, compilazione e acquisizione dei grafi CUDA.

Sulle GPU B200 con archiviazione VAST NFS, NVIDIA riferisce tempi di ripristino compresi tra 3,6 e 42,7 secondi nelle configurazioni vLLM, SGLang e TensorRT LLM, con accelerazioni da 8x a 36x rispetto agli avvii a freddo. I test hanno riguardato un modello da 600 milioni di parametri e configurazioni con otto GPU e checkpoint prossimi a 1 TB. La creazione dei checkpoint ha richiesto da 15 secondi a 5,5 minuti; in tutte le configurazioni testate, il tempo complessivo per creare il checkpoint e ripristinarlo è stato inferiore a quello di un singolo avvio a freddo.

Questi dati non misurano l’avvio completo di una macchina: il provisioning dell’infrastruttura e il caricamento delle immagini dei container non rientrano nel tempo di ripristino misurato. Anche la cache chiave-valore viene rilasciata prima di ogni checkpoint, anziché essere conservata nell’artefatto; i risultati riguardano quindi il ripristino di un carico di lavoro inizializzato su un’infrastruttura compatibile.

Il test condotto da Crusoe sul proprio GLM-5.3 su NVIDIA HGX B300 ha utilizzato un checkpoint contenente 594 GB di stato della GPU. Crusoe ha misurato il ripristino dello stato della GPU in 15,0 secondi da NVMe locale, contro i 33,3 secondi da NFS. Con l’artefatto su NVMe, il tempo dalla creazione del pod alla disponibilità è stato di 31 secondi, rispetto a circa otto minuti per un avvio a freddo: un dato che individua nello storage un fattore determinante per le prestazioni di ripristino. Crusoe ha inoltre contribuito a integrare a monte miglioramenti delle prestazioni e della diagnostica.

Nel complesso, i progetti trasferiscono una parte maggiore del piano di controllo della fabbrica di IA e del percorso di ripristino in repository aperti, ma con livelli di maturità diversi: il passaggio alla governance di OpenShell non è completo, Agent Substrate è in evoluzione e NVKE e NVKR sono ancora versioni preliminari. I benchmark di Snapshot offrono il riscontro più chiaro di un miglioramento operativo misurato, mentre i requisiti di compatibilità e i risultati di Crusoe sullo storage mostrano che un ripristino più rapido dipende sia dal riutilizzo dello stato dei carichi di lavoro sia dall’infrastruttura circostante.