NVIDIA Dynamo : une gestion de session pour l'inférence agentique

Les charges agentiques transforment l'architecture du serving

Les charges de travail agentiques ont radicalement changé la forme du trafic sur les serveurs d'inférence. Une session s'ouvre sur un gros prefill — souvent des dizaines de milliers de tokens de prompts système, de descriptions d'outils et de consignes spécifiques à l'utilisateur. Après le premier appel, le modèle reçoit un contexte augmenté que la session renvoie intégralement à chaque nouveau tour.

La différence avec un chatbot tient au déroulement même du travail : une seule tâche génère de multiples appels parallèles au modèle, des sous-agents parallèles à durée de vie courte ou longue, et des outils qui s'exécutent entre les tours. La majeure partie du temps d'horloge de la session n'est pas consacrée à la génération, mais à l'exécution d'outils et d'appels sortants, pendant que le contexte reste résident dans le KV cache, occupant de la place en mémoire HBM sans être utilisé. Un service optimal dépend de la quantité de contexte que le système maintient résidente et réutilise, et du nombre de sessions qu'il peut servir simultanément sans violer les SLA de latence.

L'ID de session comme primitive unique pour une infrastructure

sensible aux programmes

La plupart des stacks de serving open source sont conçus pour le chatbot standard : ils routent, admettent et mettent en cache chaque requête indépendamment, sans comprendre la session qui la relie aux tours précédents. NVIDIA Dynamo a unifié la gestion autour d'un identifiant au niveau de la session, transformant une infrastructure sensible aux requêtes en infrastructure sensible aux programmes.

Chaque requête d'une trajectoire d'agent contient :

• session_id — identifiant unique et stable d'une chaîne de raisonnement et d'appels à des outils • parent_session_id — identifiant de la session parente (pour suivre la hiérarchie des agents et sous-agents)

Prise en charge native des agents de codage (fonctionne sans configuration) :

• Claude Code transmet `x-claude-code-session-id` (racines) et `x-claude-code-agent-id` (enfants) avec `x-claude-code-parent-agent-id` • Codex utilise `thread-id` et `x-codex-parent-thread-id` • OpenCode envoie `x-opencode-session-id` et `x-opencode-parent-session-id`

Plugins pour d'autres harnesses (dépôt agent-plugins) :

• Provider Pi — pour l'endpoint compatible OpenAI de Dynamo • Middleware Hermes — mappe le `session_id` de Hermes • Provider OpenClaw — mappe le `sessionId` d'OpenClaw

Les harnesses personnalisés se contentent de transmettre `X-Dynamo-Session-ID` (et éventuellement `X-Dynamo-Parent-Session-ID`) ; Dynamo les normalise en `agent_context`, que l'ensemble de la stack peut lire.

Traçage, replay et backtesting

Avec le flag `DYN_REQUEST_TRACE=1`, Dynamo enregistre automatiquement chaque requête sans stocker les prompts ni les réponses (ces derniers peuvent être activés séparément). À la fin du flux de réponse, une entrée `request_end` est émise avec :

• Les champs de session (session_id, parent_session_id) • Le nombre de tokens de sortie et la raison de fin • Les métriques du KV cache et les noms des outils • Un bloc replay avec la longueur d'entrée et des hashes de séquences (format proche de Mooncake)

Comme chaque entrée contient des horodatages et des raisons de fin, on peut observer les distributions d'appels aux outils et leur lien avec le comportement d'éviction. Dynamo utilise ces données pour le backtesting et l'optimisation des déploiements.

La trace capturée devient un benchmark réutilisable : elle se rejoue autant de fois que nécessaire, sans solliciter à nouveau le modèle, les outils ou les API externes. Elle reste exempte de contenu grâce aux hashes de séquences, qui deviennent des block ID synthétiques, préservant le partage de préfixes entre les tours et les sessions.

AISimulate exécute le graphe de requêtes contre un scheduler, un router et un KV cache simulés pour comparer workers, topologies, politiques de routage et capacité sans consommer de GPU. AIPerf rejoue ce même graphe sur un endpoint réel pour obtenir les métriques finales de latence, de débit et de cache.

Routage sensible aux sessions et gestion du débit

Un router standard au niveau de la requête (y compris le KvRouter livré par défaut) décide du placement requête par requête : quel worker offre le meilleur overlap de cache. C'est l'unité correcte pour un seul tour, mais pas pour un agent en forte concurrence, car elle ignore deux facteurs :

• Explosion de l'occupation du cache : entre les tours, le cache de l'agent n'est pas libéré, il reste en HBM, occupant des blocs pendant que l'agent exécute un outil hors GPU. Avec N agents à l'étape k, le working set cumulé = N × context_k, mais le router au niveau requête ne voit qu'un seul tour. Dès que le working set dépasse la HBM et la DRAM, le moteur évince le cache des sessions vivantes, et chaque tour suivant paie un re-prefill complet au lieu d'un cache hit.

• Absence de backpressure : lorsqu'un worker est saturé, le router au niveau requête ne peut qu'annuler ou mettre en file d'attente les requêtes en cours — ces deux options sont pires que l'alternative : différer la session au point de pause, juste avant son prochain tour, au moment où elle est sur le point d'être inactive.

Dynamo a adapté le scheduler du paper ThunderAgent (Kang et al., 2026) au-dessus du router sensible au KV. Implémenté en Rust, il possède directement le KvRouter, suit le nombre réel de prompt_tokens + completion_tokens à partir de chaque réponse plutôt que d'estimer à partir des octets bruts. En tant que plugin natif de Dynamo, il peut être adapté à la forme de sa propre charge de travail sans modifier le router de base.