Nvidia s'efforce d'éliminer les incertitudes liées à l'exécution de son framework d'inférence Dynamo sur Kubernetes — la plateforme d'orchestration de conteneurs devenue la couche standard pour le déploiement de logiciels dans le cloud — avec un outil conçu pour raccourcir le chemin entre une configuration de modèle et un point de terminaison d'inférence fonctionnel. Cet outil, appelé NVIDIA AI Cluster Runtime (AICR), regroupe Dynamo et ses dépendances Kubernetes dans des recettes testées que les équipes d'ingénierie peuvent déployer puis vérifier.

Fonctionnement d'AICR

AICR applique le concept de recettes à versions verrouillées aux clusters GPU, en figeant chaque composant sur une version spécifique dont Nvidia a confirmé la compatibilité avec les autres. Cette approche répond à un défi opérationnel persistant : les clusters Kubernetes accélérés par GPU contiennent de nombreux éléments interdépendants. Les pilotes doivent correspondre au matériel sous-jacent, les ressources doivent être allouées correctement, et une seule version incompatibile peut bloquer un déploiement entier.

Le runtime organise le travail en une séquence de workflows : capture instantanée, génération de recette, rendu du bundle, déploiement et validation. L'étape de capture instantanée enregistre l'état actuel d'un cluster, offrant aux équipes une trace précise de leur point de départ avant toute modification. La génération de recette et le rendu du bundle transforment ensuite ces informations en un package déployable, tandis que la validation boucle la boucle en vérifiant que le résultat fonctionne comme prévu.

Nvidia indique qu'AICR prend en charge plusieurs services cloud et accélérateurs, avec à l'appui des preuves de validation signées. Concrètement, les équipes reçoivent un enregistrement signé cryptographiquement attestant qu'une configuration donnée a été testée, plutôt qu'une simple promesse qu'elle fonctionnera probablement.

Détails sur les versions et le matériel

AICR a atteint la version 1.0 début octobre 2026, marquant sa première version stable. La documentation de déploiement de Dynamo via le runtime a suivi aux alentours des 30 et 31 octobre 2026.

Cette documentation comprend des instructions pour l'Elastic Kubernetes Service (EKS) d'Amazon, l'offre Kubernetes managée d'Amazon Web Services, sur des GPU H100 et de classe GB200. Dans les exemples EKS construits autour des GPU H100, Nvidia utilise la version 1.4.2 du chart Helm de la plateforme Dynamo — Helm étant le gestionnaire de packages de Kubernetes, où un chart regroupe les modèles et paramètres nécessaires à l'installation d'une application.

Une exigence notable s'applique : les équipes souhaitant utiliser Dynamic Resource Allocation (DRA) ont besoin de Kubernetes version 1.34 ou ultérieure. DRA est une fonctionnalité de Kubernetes permettant de distribuer plus flexiblement du matériel spécialisé comme les GPU. Les clusters exécutant des versions plus anciennes de Kubernetes ne peuvent pas utiliser cette fonctionnalité tant qu'ils n'ont pas été mis à niveau.

Des guides supplémentaires publiés en octobre 2026 présentent des guides de démarrage rapide pour divers modèles et soulignent l'importance d'intégrer le NVIDIA GPU Operator — le composant de Nvidia pour automatiser l'installation des pilotes et logiciels GPU dans Kubernetes — ainsi que la plateforme Dynamo dans un déploiement Kubernetes.

Pourquoi Dynamo a besoin de cette aide

Dynamo est le framework open source de Nvidia pour l'inférence distribuée. L'inférence est l'étape de l'IA où un modèle entraîné répond réellement aux questions, génère du texte ou produit des images pour les utilisateurs.

Le framework est conçu pour le serving désagrégé. Au lieu qu'une seule machine gère toutes les étapes de réponse à une requête, le travail est réparti et coordonné entre plusieurs workers GPU. Dynamo propose également un routage tenant compte du cache KV : le cache KV agit comme la mémoire à court terme d'un modèle du texte qu'il a déjà traité, et le routage des requêtes en tenant compte de cette mémoire évite les travaux redondants. Combinée à l'orchestration multi-nœuds, la resultante est un système capable de répartir une seule opération de serving sur de nombreuses machines.

Implications pour les équipes IA en production

Les étapes de capture instantanée et de validation ciblent directement la dérive de configuration. La capture de l'état du cluster avant le déploiement et sa vérification après coup offrent aux équipes une piste d'audit, utile pour le débogage et potentiellement pour les revues de conformité internes.

Les preuves de validation signées vont dans le même sens. Les organisations qui doivent prouver qu'une configuration a été testée, plutôt que simplement l'affirmer, obtiennent une documentation sur laquelle s'appuyer.

La prise en charge d'EKS avec des GPU H100 et de classe GB200 offre aux équipes sur le cloud d'Amazon un chemin documenté, tandis que la revendication plus large de support multi-cloud de Nvidia suggère qu'il veut qu'AICR fonctionne partout où ses GPU sont loués, et pas seulement dans l'écosystème d'un seul fournisseur.

Deux facteurs méritent d'être surveillés. Le premier est la vitesse à laquelle l'exigence de Kubernetes 1.34 pour DRA deviendra un obstacle pratique, car de nombreux clusters de production accusent du retard sur les dernières versions, et Kubernetes publie trois versions mineures par an. Le second est l'étendue : l'utilité d'AICR dépend du nombre de combinaisons cloud, accélérateur et modèle validées par Nvidia, de sorte que le rythme des nouvelles recettes après la version 1.0 en dira beaucoup sur sa pérennité.

Divulgation : le rapport original de CryptoBriefing a été édité par Diego Almada Lopez.