NVIDIA détaille la recette d’exécution de Kubernetes pour Dynamo

NVIDIA a indiqué que les équipes déployant Dynamo sur Kubernetes ont besoin de plus que le cadre de service lui-même : la pile de pilotes GPU, la planification, les couches réseau et observabilité doivent également être alignées avant qu’un point d’inférence soit fiable. Dans un article technique publié le 30 octobre 2026, la société a décrit comment son NVIDIA IA Cluster Runtime (AICR) équipe Dynamo de recettes d’infrastructure validées pour rendre ce processus reproductible.

Preuves et contexte

Le post présente Dynamo comme un cadre d’inférence distribuée qui coordonne le modèle servant entre les travailleurs GPU, mais précise que l’exécution en dessous est tout aussi importante. NVIDIA a indiqué qu’un cluster d’inférence en production doit confirmer que l’opérateur GPU et la pile de pilotes correspondent aux nœuds, que les nœuds GPU sont étiquetés et détectables, que Kubernetes expose les GPU via une allocation dynamique des ressources, que le planificateur peut placer des travailleurs avec la bonne topologie et la sémantique de group-scheduling, que les signaux de santé des nœuds sont disponibles avant que les charges de travail ne s’accumulent, que Prometheus est accessible pour les métriques, et que le chemin de l’API Gateway est configuré lors de l’utilisation de l’entrée native Kubernetes.

Selon l’article, AICR capture ces exigences dans une recette. La recette inclut des versions épinglées des composants, des contraintes de compatibilité, des sélecteurs de nœuds, des tolérances, des sommes de contrôle et des attentes de validation. NVIDIA a indiqué que la recette Dynamo propose la version 1.4.2 du graphique de la plateforme dynamo, incluant l’opérateur Dynamo, les images d’exécution et la définition personnalisée de ressource nvidia.com/v1beta1 DynamoGraphDeployment. La société a indiqué v1beta1 remplace l’ancienne version de l’API v1alpha1 .

Le post précisait également que la recette AICR n’installe plus NATS par défaut pour Dynamo 1.4; à la place, les frontends, les travailleurs et les composants optionnels de l’extension d’inférence API Gateway / Endpoint Picker Plugin découvrent un l’autre via les ressources Kubernetes. NVIDIA a indiqué que NATS reste disponible en tant qu’option pour les déploiements qui en ont encore besoin.

Chemins de routage pour Dynamo sur Kubernetes

NVIDIA a décrit deux topologies de routage. La première utilise le routeur frontend Dynamo derrière un service Kubernetes. Dans ce chemin, le frontend tokenise les requêtes, évalue les travailleurs éligibles à l’aide du chevauchement des préfixes et de la charge actuelle, sélectionne un worker et expédie la requête via le plan de requête TCP de Dynamo. L’entreprise a indiqué qu’il s’agit de la topologie la plus petite et qu’elle convient à un point de terminaison spécifique au modèle ou à un proxy edge existant qui ne transmet que le trafic vers le service frontend Dynamo.

Le second chemin intègre Dynamo avec l’API Gateway et l’extension d’inférence de l’API Gateway. Dans cette topologie, une passerelle telle que agentgateway résout un HTTPRoute vers un InferencePool, l’opérateur crée ce pool depuis le DynamoGraphDeployment, et Dynamo EPP effectue la sélection du point d’extrémité conscient du jeton. NVIDIA a indiqué que la passerelle reste le proxy HTTP, tandis qu’un sidecar Dynamo Frontend dans chaque pod ouvrier routtable fonctionne en mode direct et transmet la requête au conteneur travailleur.

Le post précisait que les deux chemins utilisent des événements KV-cache publiés par les travailleurs pour les décisions de routage. Il a également noté que Dynamo peut router en fonction de l’état du cache prédit, mais que la prédiction ne peut pas détecter les expulsions, donc la qualité du routage peut se dégrader sous la pression de la mémoire. La configuration AICR dans l’article utilise plutôt des événements en direct.

Flux de travail de déploiement et de validation

NVIDIA a présenté un flux de travail AICR en cinq étapes. Premièrement, un instantané de cluster est pris avec la commande snapshot AICR. Deuxièmement, AICR génère une recette d’inférence sur la plateforme sélectionnée. Troisièmement, le bundle d’exécution est rendu en manifestes prêts à déployer et en valeurs Helm. Quatrièmement, l’exécution est déployée via Helmfile ou d’autres déployeurs pris en charge. Cinquièmement, l’exécution installée est validée avant l’ajout de la charge de travail applicative.

Pour la recette d’inférence Amazon EKS Dynamo pour les systèmes NVIDIA GB200 NVL72 et NVIDIA GB300 NVL72 , le post listait des versions épinglées des graphiques incluant NVIDIA GPU Operator v26.7.1, Node Feature Discovery 0.19.0, Cert-Manager v1.20.2, 2.59.0 pilote AWS EBS CSI, AWS EFA v0.5.29, NVSentinel v1.25.0, NodeWright Operator v0.19.0, 0.5.0 pilote GPU NDA NVIDIA, KAI Scheduler v0.16.9, Grove v0.1.0 alpha.13, Dynamo Platform 1.4.2, Agent Gateway v1.5.0, Agent Gateway CRDs v1.5.0, Kube Prometheus Stack 84.4.0, Prometheus Operator CRDs 28.0.1, Prometheus Adapter 5.3.0 et Kubernetes Ephemeral Storage Metrics 1.19.2.

Les vérifications de validation, selon l’article, couvrent généralement la santé de base du cluster, le statut de l’opérateur GPU, l’accès à l’accélérateur, le comportement de planification en groupe et d’auto-scaling, l’observabilité via des métriques soutenues par Prometheus, ainsi que la préparation de l’API Gateway et de l’agentgateway pour l’entrée native Kubernetes. NVIDIA a indiqué que la validation des performances est distincte car elle déploie une charge de travail temporaire et consomme les GPU testés.

L’entreprise a conclu en affirmant que l’AICR et Dynamo sont des composants open source de la plateforme NVIDIA DSX IA Factory, avec des exemples de déploiement et des ressources communautaires disponibles via le NVIDIA DSX IA Factory GitHub et la communauté Slack. Elle a également évoqué une activité d’atelier pratique à KubeCon + CloudNativeCon Amérique du Nord, bien que l’article n’ait pas précisé de date future de catalyseur au-delà de cette mention de cet événement.