NVIDIA détaille le runtime Kubernetes validé d’AICR pour Dynamo, avec contrôle de l’infrastructure avant le modèle

Dans un guide du 30 octobre 2026, NVIDIA explique comment AI Cluster Runtime (AICR) construit une base Kubernetes vérifiée pour l'inférence avec Dynamo. Un DynamoGraphDeployment décrit la manière de servir un modèle, sans garantir à lui seul que pilotes GPU, ressources, ordonnancement, réseau et surveillance soient prêts. AICR traite cette couche d'infrastructure avec des recettes versionnées qui regroupent Dynamo et ses dépendances, puis contrôlent la conformité d'un cluster choisi. Le sujet est le déploiement et la validation du runtime, pas l'entraînement d'un nouveau modèle ni un gain de débit mesuré pour une application précise.

Le billet distingue deux voies de routage. Dans la première, un Dynamo Frontend se trouve derrière un Service Kubernetes. Quand le routage KV est actif, le Frontend découpe la requête en jetons, tient compte du préfixe partagé et de la charge, choisit un worker et lui transmet la requête. C'est une topologie adaptée à un point d'accès propre à un modèle ou à un proxy existant qui ne fait que transmettre au Frontend. Dans la seconde voie, Gateway API et son Inference Extension interviennent. Un HTTPRoute mène à un InferencePool créé par l'opérateur Dynamo à partir du DynamoGraphDeployment. Le Gateway appelle le Dynamo EPP, qui choisit le worker d'après les mêmes informations KV et renvoie les métadonnées de routage. C'est ensuite le Gateway qui transmet réellement la requête HTTP au Frontend sidecar du worker sélectionné. Choisir une destination et transporter la requête sont deux tâches distinctes.

Les deux voies peuvent fonctionner derrière un HTTPRoute ; la différence ne se réduit donc pas à la présence d'un Gateway. Elle porte sur le composant responsable du transport vers le worker, des délais d'attente, des relances et du fallback : le Dynamo Frontend dans la première voie, le Gateway dans la seconde. La seconde ajoute un Gateway compatible, un InferencePool, un EPP et des sidecars. NVIDIA présente la première comme la topologie la plus petite et la plus éprouvée en production. La seconde décrite ici concerne l'intégration du DynamoGraphDeployment géré par l'opérateur, pas l'accès expérimental autonome à vanilla vLLM. Dans Dynamo 1.4, l'EPP emploie un cadre Go avec un routeur KV Rust intégré via CGO. Un EPP Rust natif est annoncé comme perspective de Dynamo 1.5, non comme fonctionnalité de la recette 1.4.2 actuelle.

Les interactions avec un agent répètent souvent de longs préfixes : instructions, outils et historique. Envoyer une requête vers un worker conservant les blocs KV appropriés évite de retraiter cette partie de l'entrée. Chaque worker émet localement ses événements de cache par ZMQ ; Dynamo les normalise puis les republie sur son plan d'événements. Le plan des requêtes utilise TCP par défaut, celui des événements KV utilise ZMQ. Les deux voies peuvent se servir de l'état réel du cache et de la charge publié par les workers. Une carte prédite du cache est possible, mais NVIDIA prévient qu'elle ne voit pas les expulsions et peut diverger de la réalité. Le texte décrit aussi la séparation de prefill et decode ; le taux de défaut de cache dépend de la charge réelle et ne se déduit pas d'un schéma d'architecture.

Le déroulement AICR suit un ordre précis. aicr snapshot capture le cluster ; aicr recipe choisit une recette d'inférence Dynamo correspondant à cette capture et fixe versions, contraintes et contrôles. Dans l'exemple AICR v1.0.0 donné pour Amazon EKS sur GB200 NVL72 et GB300 NVL72, le chart Dynamo Platform est fixé à 1.4.2 parmi d'autres composants. Ce sont des versions testées pour cet exemple, pas les dernières versions universelles. Une validation hors ligne facultative compare une recette à une autre capture, mais les contrôles comportementaux sont ignorés sans cluster vivant. aicr bundle rend ensuite les valeurs Helm et les manifestes ; le runtime est déployé, puis aicr validate exécute les contrôles de déploiement et de conformité sur le cluster. Le DynamoGraphDeployment de l'application vient après.

Les contrôles typiques couvrent capacité GPU et nvidia-smi, santé de GPU Operator et Dynamo, accès DRA, ordonnancement de groupe et montée en charge, métriques Prometheus et disponibilité du Gateway si l'entrée Kubernetes native est employée. NVIDIA place la validation des performances dans une phase distincte, car elle lance un service temporaire et consomme des GPU. Un contrôle d'infrastructure réussi ne démontre donc pas le débit de l'application. Les vérifications varient selon la recette ; l'article ne prouve pas que notre cluster ou celui d'un lecteur y a satisfait. La valeur du guide est un ordre reproductible de la capture du cluster jusqu'à la configuration versionnée et aux vérifications sur l'installation réelle.