Nvidia lavora per eliminare l'incertezza nell'esecuzione del suo framework di inferenza Dynamo su Kubernetes — la piattaforma di orchestrazione di container diventata lo standard per il deployment di software cloud — con uno strumento pensato per accorciare il percorso da una configurazione di modello a un endpoint di inferenza funzionante. Lo strumento, chiamato NVIDIA AI Cluster Runtime (AICR), confeziona Dynamo e le sue dipendenze Kubernetes in ricette testate che i team di ingegneria possono deployare e poi verificare.

Come funziona AICR

AICR applica il concetto di ricette version-locked ai cluster GPU, fissando ogni componente a una release specifica che Nvidia ha confermato essere compatibile con le altre. L'approccio affronta una sfida operativa persistente: i cluster Kubernetes accelerati via GPU contengono molte parti interdipendenti. I driver devono corrispondere all'hardware sottostante, le risorse devono essere allocate correttamente, e una singola versione non coerente può bloccare un intero deployment.

Il runtime organizza il lavoro in una sequenza di workflow: snapshot, generazione della ricetta, rendering del bundle, deployment e validazione. Il passaggio di snapshot cattura lo stato attuale di un cluster, fornendo ai team una registrazione precisa del punto di partenza prima di qualsiasi modifica. La generazione della ricetta e il rendering del bundle trasformano poi queste informazioni in un pacchetto deployabile, mentre la validazione chiude il ciclo verificando che il risultato funzioni come previsto.

Nvidia dichiara che AICR supporta più servizi cloud e acceleratori, con il supporto di evidenze di validazione firmate. In termini pratici, i team ricevono una registrazione firmata crittograficamente che dimostra che una data configurazione è stata testata, anziché una promessa che probabilmente funzionerà.

Dettagli su versioni e hardware

AICR ha raggiunto la versione 1.0 all'inizio di ottobre 2026, segnando la sua prima release stabile. La documentazione per il deployment di Dynamo attraverso il runtime è seguita verso il 30-31 ottobre 2026.

Quella documentazione include indicazioni per l'Elastic Kubernetes Service (EKS) di Amazon, l'offerta Kubernetes gestita di Amazon Web Services, in esecuzione su GPU H100 e di classe GB200. Negli esempi EKS basati su GPU H100, Nvidia usa la versione 1.4.2 del Dynamo Platform Helm chart — Helm essendo il package manager di Kubernetes, dove un chart raggruppa i template e le impostazioni necessarie per installare un'applicazione.

Si applica un requisito rilevante: i team che vogliono usare la Dynamic Resource Allocation (DRA) necessitano di Kubernetes versione 1.34 o successive. DRA è una funzionalità di Kubernetes per distribuire in modo più flessibile hardware specializzato come le GPU. I cluster che eseguono release Kubernetes più datate non possono usare la funzionalità finché non effettuano l'aggiornamento.

Guide aggiuntive pubblicate a ottobre 2026 illustrano quickstart per vari modelli e sottolineano l'importanza di integrare l'NVIDIA GPU Operator — il componente di Nvidia per automatizzare la configurazione di driver e software GPU all'interno di Kubernetes — e la Dynamo Platform come parte di un deployment Kubernetes.

Perché Dynamo ha bisogno di questo aiuto

Dynamo è il framework open-source di Nvidia per l'inferenza distribuita. L'inferenza è la fase dell'AI in cui un modello addestrato risponde effettivamente a domande, genera testo o produce immagini per gli utenti.

Il framework è progettato per il disaggregated serving. Invece di far gestire a una singola macchina ogni fase della risposta a una richiesta, il lavoro viene suddiviso e coordinato tra più worker GPU. Dynamo offre anche il routing consapevole della KV cache: la KV cache funge da memoria a breve termine di un modello riguardo al testo già elaborato, e instradare le richieste tenendo conto di quella memoria evita lavoro ridondante. Combinata con l'orchestrazione multi-nodo, il risultato è un sistema in grado di distribuire una singola operazione di serving su molte macchine.

Implicazioni per i team AI in produzione

I passaggi di snapshot e validazione affrontano direttamente il drift di configurazione. Catturare lo stato del cluster prima del deployment e verificarlo dopo fornisce ai team una traccia di audit, utile per il debugging e potenzialmente per revisioni di conformità interne.

Le evidenze di validazione firmate vanno nella stessa direzione. Le organizzazioni che devono dimostrare che una configurazione è stata testata, anziché semplicemente affermarlo, ottengono una documentazione a cui poter fare riferimento.

Il supporto per EKS con GPU H100 e di classe GB200 offre ai team sul cloud di Amazon un percorso documentato, mentre l'affermazione più ampia di Nvidia riguardo al supporto multi-cloud suggerisce che l'azienda voglia che AICR funzioni ovunque le sue GPU siano noleggiate, non solo nell'ecosistema di un singolo provider.

Due fattori meritano attenzione da qui in avanti. Il primo è la velocità con cui il requisito di Kubernetes 1.34 per la DRA diventerà un ostacolo pratico, poiché molti cluster di produzione restano indietro rispetto alle release più recenti, e Kubernetes rilascia tre versioni minori all'anno. Il secondo è l'ampiezza: l'utilità di AICR cresce con il numero di combinazioni cloud, acceleratori e modelli validate da Nvidia, quindi il ritmo delle nuove ricette dopo la release 1.0 dirà molto sulla sua capacità di affermarsi nel tempo.

Disclosure: Il report originale di CryptoBriefing è stato curato da Diego Almada Lopez.