Servir des modèles IA sur Kubernetes avec Nvidia Dynamo

Un seul serveur de modèle rend tout le monde heureux dans une petite démonstration : vous ouvrez un point d'entrée, envoyez des requêtes, recevez des réponses. Quand l'équipe grandit et que le trafic devient sérieux, le tableau change ; le même point doit tourner sur une grappe, se multiplier, répartir les requêtes vers les bons agents et rester debout quand des pièces tombent. Passer un service IA en production, c'est ranger ces tâches invisibles bien plus que faire grandir le modèle. C'est exactement là que commence cette visite : une équipe à l'étroit sur un serveur, en route vers un point d'entrée compatible OpenAI sur Kubernetes.

Sur Kubernetes, Dynamo suit le modèle opérateur : l'équipe écrit l'installation voulue dans un fichier manifeste, la grappe garde cet état désiré, et l'opérateur plie le montage réel vers lui. L'image mentale tient en quatre gestes : écrire la demande de déploiement, l'appliquer à la grappe, confier les pièces à l'opérateur, puis envoyer le trafic vers le point d'entrée compatible OpenAI. L'attrait, c'est que le déploiement cesse d'être un tas de scripts faits main pour devenir une corvée de grappe répétable. Quand la conception de service change, vous mettez la demande à jour et réappliquez ; l'opérateur porte le reste. Pour un service IA au catalogue vivant, cette boucle est tout le jeu.

Dynamo offre deux voies à l'équipe. La première part d'une DGDR, une déclaration d'intention : l'équipe nomme le modèle, le moteur d'exécution, la charge, le parc d'accélérateurs et les cibles de service éventuelles, et Dynamo profile l'installation pour produire une recette prête nommée DGD. L'autre voie part directement d'un DGD : vous prenez une recette éprouvée et pliez le graphe d'inférence et la disposition de service à vos besoins. Dans les deux voies, l'opérateur change la recette DGD en pièces courantes qui servent le trafic. Le guide premier pas de la docs Nvidia raconte ce flux par les gestes appliquer, attendre et sonder avec kubectl.

Un client envoie sa requête au frontal Dynamo, qui sert un point d'entrée compatible OpenAI, si bien que la forme de requête connue côté client ne change jamais. Derrière cette frontière, Dynamo route la requête vers des agents de fond, chacun servant le modèle avec un moteur d'exécution comme SGLang, vLLM ou TensorRT-LLM, selon la recette. Cette séparation compte : le client voit toujours la même interface pendant que l'agencement de service derrière continue d'évoluer. Une équipe qui part petit mappe un modèle, un moteur et une forme d'agent dans la demande ; quand il faut plus de capacité, elle met le déploiement à jour au lieu de rebâtir tout l'édifice.

Avant Dynamo, l'équipe vit avec un seul serveur de modèle : facile à lancer, mais quand les besoins grandissent, l'équipe doit résoudre seule déploiement, découverte, mise à l'échelle, routage, exposition et observabilité. Après Dynamo, une couche de service native de la grappe prend le relais : la demande de déploiement dit ce qui est voulu, l'opérateur possède le cycle de vie, le frontal reste connu, et les agents s'ordonnent selon modèle et moteur. Le récit de déploiement automatique de la docs Nvidia montre les gestes fins de la recette produite, des passages de profilage aux cibles de service.

La démonstration en direct garde le flux DGDR volontairement simple. D'abord la demande s'écrit avec modèle, moteur, charge, accélérateurs et cibles de service. Puis le fichier part sur la grappe avec kubectl. Puis l'équipe attend pendant que l'opérateur monte les pièces. Enfin une requête touche le point d'entrée et une réponse revient. La route par la recette mène à la même porte : prenez une recette DGD prête, appliquez-la avec kubectl, et laissez l'opérateur changer le graphe d'inférence en pièces courantes. Dans les deux cas le résultat est le même : une corvée de grappe répétable au lieu d'un montage fait main.

Cette visite convient aux équipes prêtes à porter un petit point d'entrée sur une grappe : mapper réglages de modèle, de moteur et d'agent dans une seule demande de déploiement est le départ le plus net. Le dépôt ai-dynamo sur GitHub héberge le logiciel sous licence Apache 2.0 avec ses graphiques Helm ; l'opérateur et les fichiers de définition d'une première installation viennent de là. La page produit Nvidia place Dynamo comme service d'inférence à l'échelle de production et envoie les curieux vers la docs.