NVIDIA Dynamo : La couche de service distribuée autour des moteurs d'inférence

La vidéo s'ouvre avec Ron, un ingénieur plateforme dont l'équipe exécute déjà des modèles en production avec un moteur d'inférence sain. Sa question est la bonne : si le moteur répond, quel problème Dynamo résout-il réellement ?

La réponse réside dans le positionnement : le framework open-source de NVIDIA n'est pas un autre moteur d'inférence, mais une couche de service distribuée qui les enveloppe. Tandis que SGLang, TensorRT-LLM ou vLLM continuent de générer des tokens, Dynamo achemine les requêtes, coordonne les travailleurs, réduit le travail inutile et compose une configuration multi-GPU en une seule architecture.

Les petites implémentations n'ont besoin de rien de tout cela : un client envoie une requête, le serveur exécute le préremplissage et le décodage, la réponse revient. Mais à mesure que les utilisateurs, la longueur des invites et la variété des modèles augmentent et que les objectifs de latence se resserrent, les problèmes difficiles dépassent l'exécution du modèle — décider qui exécute quoi, où, sur une capacité GPU coûteuse.

La première tâche de la couche est de coordonner le préremplissage et le décodage entre des pools de travailleurs distincts. Le préremplissage traite l'invite d'entrée et construit le cache KV, tandis que le décodage utilise ce cache pour produire des tokens de sortie. Parce que les deux phases nécessitent des ressources différentes, les exécuter dans des pools dédiés est rentable à mesure que la charge augmente.

La deuxième tâche est de réduire le gaspillage : une pile qui traite chaque requête comme isolée recalcule les préfixes d'invite partagés, manque la réutilisation du cache KV et laisse des GPU coûteux inactifs. Dynamo vise à combler cette lacune en effectuant le travail partagé une seule fois et en partageant le résultat.

Les tâches trois et quatre sont le routage et la tolérance aux pannes. Avec plus d'un travailleur, l'acheminement des requêtes nécessite un cerveau qui connaît la capacité, l'état des travailleurs et l'emplacement de chaque modèle. Et lorsque les travailleurs tombent en panne et que les nœuds redémarrent en production, la couche de service surveille la santé et dirige le trafic autour des parties défectueuses.

La cinquième tâche est la composabilité : les clients, la logique de routage, les travailleurs du moteur, les planificateurs, les éléments du plan de contrôle et les opérateurs Kubernetes se trouvent dans un seul framework au lieu d'un code de "glue" personnalisé. Les pièces sont modulaires, de sorte qu'une équipe peut commencer par le frontend, un moteur ou un routage plus intelligent et ajouter le reste à mesure que le déploiement se développe.

Le timing n'est pas un hasard : les modèles continuent de croître, les conceptions de mélange d'experts se répandent, et les systèmes à l'échelle du rack comme le GB200 NVL72 font de la vitesse de pointe d'un seul GPU la mauvaise question. La nouvelle question est de savoir si une flotte multi-GPU évolue efficacement, se récupère de manière fiable, réutilise le travail et reste compréhensible — et Dynamo 1.0 répond avec un gain de débit revendiqué de 7x sur le matériel Blackwell.