PyTorch Blog : NVIDIA Dynamo apprend à gérer les sessions d'agents IA

Les applications agentiques changent le profil de charge d'un serveur d'inférence. C'est ce qu'écrit PyTorch Blog dans un article consacré à l'inférence orientée session sur NVIDIA Dynamo. L'annonce énumère trois caractéristiques : un gros prefill initial, des appels répétés au modèle au sein d'une même session et des sous-agents qui travaillent en parallèle. Les ingénieurs connaissent chacune d'elles séparément, mais leur combinaison met à mal le modèle habituel du « requête reçue, requête traitée ».

Le fragment accessible du billet ne contient pas de benchmarks ; aucun chiffre d'accélération n'est donc cité ici. Voici ce que l'on sait du problème et de la plateforme.

Pourquoi un agent ne ressemble pas à un chat

Un tour de chat se résume à un prompt, une réponse, puis une pause pendant que l'utilisateur lit. Un agent fonctionne autrement. Il reçoit une instruction système, la description des outils, l'historique et, éventuellement, de gros morceaux de code ou de documents. Le modèle traite tout cela dès la première étape : c'est un prefill lourd. L'agent appelle ensuite un outil, récupère le résultat, l'ajoute au contexte et sollicite de nouveau le modèle. Le préfixe ne change presque pas ; seule la queue s'allonge.

Si le serveur considère chaque appel comme indépendant, il recalcule le même préfixe à chaque fois, ou envoie la requête vers un worker qui ne dispose pas du KV-cache voulu. Les sous-agents parallèles aggravent le problème : plusieurs branches partagent un contexte commun, mais divergent ensuite et se disputent la mémoire GPU.

Ce que fait Dynamo

NVIDIA Dynamo est un framework open source d'inférence distribuée, que l'entreprise a présenté comme le successeur de Triton Inference Server. Il repose sur des idées particulièrement utiles pour les agents : séparation du prefill et du decode sur des pools de GPU distincts, routage tenant compte du contenu du KV-cache, et déport du cache hors de la mémoire GPU vers des niveaux de stockage moins coûteux. Il fonctionne au-dessus de moteurs comme vLLM, SGLang et TensorRT-LLM.

L'idée du billet : ajouter à ces mécanismes la notion de session. Le planificateur sait qu'une série d'appels appartient à un même agent. Il peut donc garder son contexte à proximité du calcul, plutôt que de deviner les correspondances requête par requête.

Ce qui change pour le serveur quand on passe du chat à l'agent :

• l'unité de planification est la session, et non la requête isolée ;
• il est avantageux de calculer une seule fois le gros prefill de départ, puis de le réutiliser ;
• les appels répétés avec un contexte croissant exigent un routage orienté cache ;
• les sous-agents parallèles créent des pics de charge sur le préfixe commun ;
• la conservation du cache entre les appels devient une question de capacité et de coût de la mémoire.

Que vérifier sur votre propre stack

Si vous exécutez des agents sur vos propres modèles, commencez par mesurer. Regardez quelle part des tokens représente le préfixe répété, et à quelle fréquence l'appel suivant d'une session retombe sur le même worker. Si cette part est élevée alors que les succès de cache sont rares, vous payez un prefill superflu.

Deuxième étape : la stabilité du préfixe. Mieux vaut garder inchangés le prompt système, la liste des outils et l'ordre des messages : toute modification au début du contexte invalide le cache. Troisième étape : décider où stocker le cache entre les appels, et combien vous êtes prêt à payer pour le conserver pendant que l'agent attend la réponse d'un outil.

Pour les équipes qui achètent l'inférence en tant que service, la conclusion est plus simple. Demandez à votre fournisseur comment il facture et stocke le contexte mis en cache dans les longues sessions. Pour les agents, cette ligne du tarif pèse plus lourd sur la facture finale que le prix par million de tokens.

Les détails complets de l'implémentation et les mesures figurent dans le billet original de PyTorch Blog. Avant d'en tirer des conclusions pour votre architecture, il vaut mieux les confronter aux chiffres de la source primaire.