NVIDIA AICR simplifie le déploiement de Dynamo sur Kubernetes

NVIDIA a lancé NVIDIA AI Cluster Runtime (AICR) pour simplifier le déploiement de son framework d'inférence distribué Dynamo sur Kubernetes. Intégré à la plateforme DSX AI Factory, cet outil regroupe des recettes d'infrastructure validées qui gèrent des dépendances complexes telles que les pilotes GPU, l'allocation des ressources et la supervision. Il vise à offrir aux équipes de plateforme une base reproductible et cohérente pour servir des grands modèles de langage.

Ce qui s'est passé

Le déploiement de modèles d'inférence IA sur Kubernetes va au-delà de la simple exécution de conteneurs. Les ingénieurs doivent garantir le bon fonctionnement conjoint des pilotes GPU, des signaux de santé des nœuds, de l'allocation dynamique des ressources et du routage réseau. Traditionnellement, la résolution de ces dépendances consomme beaucoup de temps et introduit des variations entre les environnements. NVIDIA répond à ce défi en intégrant Dynamo 1.4.2 et son infrastructure sous-jacente dans AICR, qui propose des configurations pré-validées pour des matériels et environnements cloud spécifiques.

L'exécution capture des exigences critiques telles que la sémantique de l'ordonnancement en groupe (gang scheduling), l'intégration des métriques Prometheus et les mécanismes de découverte des GPU. En figeant les versions des composants et en définissant des contraintes de compatibilité, AICR garantit que l'état du cluster sous-jacent correspond aux attentes de la charge de travail d'inférence. Cette approche dissocie la complexité de la configuration de l'exécution du processus de déploiement de l'application, permettant aux développeurs de se concentrer sur le comportement du modèle plutôt que sur le débogage de l'infrastructure.

AICR prend en charge deux chemins de routage principaux pour Dynamo : le routeur natif Dynamo Frontend et l'extension Gateway API Inference Extension (GAIE) avec un plugin Endpoint Picker Plugin (EPP). Le choix dépend de la gestion par l'équipe d'endpoints spécifiques aux modèles ou d'un ingress Kubernetes partagé. Les deux chemins exploitent la prise en compte du cache KV pour optimiser la génération de tokens, mais diffèrent dans la manière dont le trafic est transféré et géré au sein de la topologie du cluster.

Comment cela fonctionne

Dynamo 1.4.2 sépare le plan de requête du plan d'événements du cache KV. Il utilise TCP pour les requêtes standard et ZeroMQ (ZMQ) pour les événements du cache KV. Chaque worker vLLM publie localement des événements bruts de cache, que l'exécution Dynamo normalise et republie. Cela permet aux deux chemins de routage de prendre des décisions conscientes du cache, dirigeant les requêtes vers les workers qui détiennent déjà les préfixes de prompt pertinents en mémoire. Ce mécanisme réduit la nécessité de retraiter les tokens, améliorant ainsi la latence et le débit pour les workflows agentiques.

Le flux de déploiement AICR suit cinq étapes distinctes. Premièrement, les ingénieurs prennent un instantané de l'état actuel du cluster, capturant les labels et les taints des nœuds. Deuxièmement, AICR génère une recette d'inférence Dynamo basée sur le matériel détecté et la distribution Kubernetes. Troisièmement, il rend un bundle de déploiement avec des versions figées. Quatrièmement, l'exécution est déployée à l'aide de Helmfile ou d'outils GitOps. Enfin, le système valide l'exécution installée avant toute planification de charges de travail applicatives, garantissant que l'infrastructure est prête pour le trafic de production.

Détails clés

• AICR regroupe Dynamo 1.4.2 avec le chart dynamo-platform, remplaçant l'API v1alpha1 précédente par v1beta1.
• Le chemin de routage par défaut utilise le routeur Dynamo Frontend, tandis que le chemin GAIE/EPP s'intègre à l'ingress Kubernetes partagé via les ressources Gateway API.
• NATS n'est plus installé par défaut dans le chart dynamo-platform, bien qu'il reste disponible comme composant optionnel pour certains déploiements.
• Les composants d'infrastructure pris en charge incluent NVIDIA GPU Operator, KAI Scheduler, Grove pour l'orchestration et NVSentinel pour les vérifications de santé des nœuds.
• Dynamo 1.5 introduira un EPP natif en Rust pour remplacer le pont Go/CGO actuel, réduisant la surcharge par requête dans le chemin GAIE.
• Les recettes de validation figent des versions spécifiques, telles que NVIDIA GPU Operator v26.7.1 et Kube Prometheus Stack 84.4.0 pour les configurations Amazon EKS.

Pourquoi c'est important

Pour les ingénieurs d'infrastructure, le principal avantage est la reproductibilité. La configuration manuelle des opérateurs GPU, des ordonnanceurs et des stacks de supervision conduit souvent à des dérives et à des incompatibilités subtiles. Les recettes validées d'AICR éliminent cette incertitude en fournissant une configuration connue et fiable pour des matériels spécifiques comme le NVIDIA GB200 NVL72. Cela réduit la charge opérationnelle et accélère le passage du provisionnement du cluster au service du modèle.

Les développeurs bénéficient de caractéristiques de performance cohérentes. En garantissant que les événements du cache KV sont correctement routés et que l'ordonnancement en groupe est appliqué, l'exécution minimise les pics de latence causés par les ratés de cache ou la contention des ressources. Cette fiabilité est cruciale pour construire des applications IA réactives, en particulier celles impliquant des sessions agentiques longues où la rétention du contexte est vitale.

Ce que vous pouvez faire

• Installez NVIDIA AI Cluster Runtime pour générer des recettes validées pour votre environnement Kubernetes spécifique.
• Évaluez si votre cas d'usage nécessite la simplicité du routeur Dynamo Frontend ou les capacités d'ingress partagées de GAIE/EPP.
• Mettez à jour les déploiements Dynamo existants pour utiliser la version d'API v1beta1 afin de s'aligner sur les dernières normes des opérateurs.
• Configurez les workers vLLM pour activer la mise en cache par préfixe et les événements de cache KV basés sur ZMQ pour une performance de routage optimale.
• Utilisez la fonctionnalité d'instantané AICR pour auditer l'état actuel de votre cluster avant de générer de nouvelles recettes d'inférence.
• Surveillez la transition vers Dynamo 1.5 pour tirer parti du futur EPP natif en Rust afin de réduire la surcharge de la passerelle.