The Pulse

NVIDIA aggiunge l’inventario dei carichi di lavoro IA al runtime della piattaforma GPU

NVIDIA AI Cluster Runtime include ora un componente per l’inventario dei carichi di lavoro IA supportati su Kubernetes. Il componente è selezionato per impostazione predefinita in due ricette di Google Kubernetes Engine, ma i suoi registri non dimostrano che un carico di lavoro sia stato eseguito.

AI.info Team · · verificato · su 1 fonte ↓ · Pubblicato 11 nov 2026

NVIDIA AI Cluster Runtime include ora un componente che censisce i carichi di lavoro IA supportati su Kubernetes insieme alle configurazioni utilizzate per distribuire le piattaforme GPU. In un articolo tecnico dell’11 novembre, l’azienda ha dichiarato che l’integrazione utilizza k8s-aibom, un progetto open source creato da Google.

Il componente è selezionato per impostazione predefinita in due ricette di Google Kubernetes Engine per l’inferenza. Altre ricette GKE possono attivarlo tramite il flag runtime-inventory, mentre quelle che lo selezionano per impostazione predefinita possono disattivarlo.

Dalle ricette all’inventario

AI Cluster Runtime, o AICR, è un componente open source di NVIDIA DSX AI Factory Platform. Genera ricette e pacchetti di distribuzione con versioni bloccate per Kubernetes accelerato tramite GPU, registrando componenti, versioni fissate, vincoli, ordine di distribuzione e criteri di validazione previsti per una specifica configurazione.

Il componente di inventario esamina un livello diverso: i carichi di lavoro e i pod Kubernetes. Produce una distinta dei materiali dell’IA, o AIBOM, per ogni carico di lavoro riconosciuto, utilizzando il formato CycloneDX 1.6. I carichi di lavoro subordinati tracciati vengono aggregati nel registro del carico di lavoro di appartenenza.

La copertura è limitata ai tipi di carico di lavoro supportati che presentano un segnale IA riconosciuto. Tra questi figurano i grafi Dynamo nativi e le risorse NIMService, LeaderWorkerSet, DisaggregatedSet e CronJob.

Le ricette predefinite si chiamano h100-gke-cos-inference e h100-gke-cos-inference-dynamo. Gli esempi nell’articolo usano AICR v1.2.0 con un catalogo che fissa k8s-aibom alla versione 1.6.2. NVIDIA afferma che il suo processo di qualificazione associa il codice sorgente upstream, il chart, le definizioni delle risorse personalizzate e l’immagine del controller come un insieme testato e verifica la provenienza, le impostazioni di sicurezza predefinite e le operazioni di distribuzione.

Che cosa mostrano i registri

La produzione dei registri di inventario viene abilitata separatamente per ogni namespace. Questa impostazione controlla dove vengono emessi i registri AIBOM, ma non limita ciò che il controller legge: le specifiche dei carichi di lavoro e dei pod vengono memorizzate nella cache in tutto il cluster, compresi gli argomenti dei container e i valori delle variabili d’ambiente definiti in linea.

Per impostazione predefinita non sono configurati né una destinazione esterna né l’accesso ai segreti. L’esempio dell’articolo utilizza una distribuzione vLLM che serve un modello Qwen; il controller classifica il carico di lavoro come inferenza e ne identifica il runtime di serving.

Un registro di inventario viene creato a partire dalla specifica del carico di lavoro e può comparire prima che un pod sia in esecuzione. Un registro contrassegnato come pronto non dimostra quindi che il carico di lavoro sia stato pianificato o eseguito con successo. Una volta che un pod esiste, il registro può anche indicare a quali elementi sono stati risolti gli artefatti dichiarati.

Gli attributi riportano livelli di attendibilità — dichiarato, inferito, non risolto o verificato — insieme ai riferimenti alle evidenze. Un documento abbastanza piccolo da rientrare nello spazio disponibile viene memorizzato in linea sulla sua risorsa Kubernetes, con un hash SHA-256 pubblicato dei suoi byte canonici.

Risultati dei test e lavoro ancora da fare

Il progetto upstream ha misurato k8s-aibom versione 1.6.1 su GKE utilizzando NVIDIA Dynamo e la configurazione di AICR, ha dichiarato l’azienda. Il test ha utilizzato nodi con sole CPU, con i pod dei carichi di lavoro rimasti in attesa, quindi i dati descrivono il sovraccarico del controller dovuto all’inventario, anziché carichi di lavoro GPU in esecuzione.

Durante una finestra di osservazione di 15 minuti a regime, il test ha registrato circa quattro richieste al minuto all’API server, un utilizzo medio della CPU da parte del controller di 2,2 millicore e un working set di memoria compreso tra 28 e 34 MiB. Ha anche registrato una rigenerazione dell’AIBOM quando è cambiato il tag dell’immagine del carico di lavoro testato.

Le osservazioni a runtime non sono attualmente firmate. Sebbene k8s-aibom possa verificare le firme sulle dichiarazioni relative ai modelli rispetto alle radici di fiducia configurate dall’operatore, AICR lascia tale verifica disabilitata per impostazione predefinita. Il collegamento della provenienza della piattaforma all’inventario a runtime e il confronto tra ciò che la ricetta prevede e le specifiche dei carichi di lavoro osservate restano attività di integrazione future.