NVIDIA Dynamo: gestión de infraestructura basada en sesiones para inferencia agéntica

Las cargas agénticas están remodelando la arquitectura de serving

Las cargas de trabajo agénticas han cambiado radicalmente la forma del tráfico que llega a los servidores de inferencia. Una sesión se abre con un prefill masivo —a menudo decenas de miles de tokens de prompts del sistema, descripciones de herramientas y directrices específicas del usuario—. Tras la primera llamada, el modelo recibe contexto añadido, que la sesión vuelve a enviar completo en cada nuevo turno.

La diferencia con un chatbot está en cómo se despliega el trabajo: una sola tarea genera múltiples llamadas al modelo en paralelo, subagentes paralelos con vidas cortas y largas, y herramientas que se ejecutan entre turnos. La mayor parte del tiempo real de una sesión no se dedica a la generación, sino a la ejecución de herramientas y llamadas salientes, mientras el contexto permanece residente en la caché KV, ocupando espacio en la HBM sin ser utilizado. El servicio óptimo depende de cuánto contexto mantiene residente y reutiliza el sistema, y de cuántas sesiones puede atender simultáneamente sin romper los SLA de latencia.

El session ID como primitiva unificada para una infraestructura

orientada a programas

La mayoría de los stacks de serving de código abierto están construidos para el caso estándar del chatbot: enrutan, admiten y cachean cada petición de forma independiente, sin entender la sesión que la conecta con turnos anteriores. NVIDIA Dynamo unificó la gestión alrededor de un identificador a nivel de sesión, transformando una infraestructura orientada a peticiones en una orientada a programas.

Cada petición dentro de la trayectoria de un agente incluye:

• session_id — un identificador único y estable para una cadena de razonamiento y llamadas a herramientas • parent_session_id — el identificador de la sesión padre (para rastrear la jerarquía de agentes y subagentes)

Soporte nativo para agentes de codificación (funciona sin configuración):

• Claude Code envía `x-claude-code-session-id` (raíz) y `x-claude-code-agent-id` (hijos) junto con `x-claude-code-parent-agent-id` • Codex usa `thread-id` y `x-codex-parent-thread-id` • OpenCode envía `x-opencode-session-id` y `x-opencode-parent-session-id`

Plugins para otros harnesses (repositorio agent-plugins):

• Pi provider — para el endpoint compatible con OpenAI de Dynamo • Middleware Hermes — mapea el `session_id` de Hermes • Provider OpenClaw — mapea el `sessionId` de OpenClaw

Los harnesses personalizados simplemente envían `X-Dynamo-Session-ID` (y opcionalmente `X-Dynamo-Parent-Session-ID`), y Dynamo los normaliza en `agent_context`, que lee todo el stack.

Trazado, replay y backtesting

Con la variable `DYN_REQUEST_TRACE=1`, Dynamo registra automáticamente cada petición sin almacenar prompts ni respuestas (esto puede habilitarse por separado). Al finalizar el flujo de respuesta, emite un registro `request_end` que contiene:

• Campos de sesión (session_id, parent_session_id) • Número de tokens de salida y motivo de finalización • Métricas de la caché KV y nombres de las herramientas • Un bloque de replay con la longitud de entrada y hashes de secuencia (un formato similar al de Mooncake)

Como cada registro incluye timestamps y motivos de finalización, es posible observar la distribución de las llamadas a herramientas y su relación con el comportamiento de eviction. Dynamo usa estos datos para backtesting y para optimizar despliegues.

Una traza capturada se convierte en un benchmark reutilizable: puede reproducirse tantas veces como sea necesario sin sobrecargar el modelo, las herramientas ni las API externas. La traza permanece libre de contenido gracias a los hashes de secuencia, que se convierten en IDs de bloque sintéticos, preservando el prefix sharing entre turnos y sesiones.

AISimulate ejecuta el grafo de peticiones contra un scheduler, router y caché KV simulados para comparar workers, topologías, políticas de enrutamiento y capacidad sin consumir GPU. AIPerf reproduce el mismo grafo sobre un endpoint real para obtener métricas finales de latencia, throughput y caché.

Enrutamiento consciente de sesión y gestión del throughput

Un router estándar a nivel de petición (incluido el KvRouter de fábrica) decide la colocación petición por petición: qué worker tiene el mayor overlap de caché. Esa es la unidad correcta para un solo turno, pero no para un agente bajo alta concurrencia, porque pasa por alto dos factores:

• Explosión de ocupación de caché: entre turnos, la caché del agente no se libera; permanece en la HBM, ocupando bloques mientras el agente ejecuta una herramienta fuera de la GPU. Con N agentes en el paso k, el working set agregado es N × context_k, pero un router a nivel de petición solo ve un turno. Una vez que el working set supera la HBM y la DRAM, el motor desaloja la caché de sesiones activas, y cada turno siguiente paga un re-prefill completo en lugar de un cache hit.

• Falta de backpressure: cuando un worker está saturado, un router a nivel de petición solo puede cancelar o encolar las peticiones en curso —ambas opciones son peores que la alternativa: pausar la sesión en su punto de corte natural, justo antes de su siguiente turno, cuando está a punto de quedar inactiva.

Dynamo adaptó el scheduler del paper ThunderAgent (Kang et al., 2026) sobre el router KV-aware. Implementado en Rust, controla directamente el KvRouter y rastrea los valores reales de prompt_tokens + completion_tokens de cada respuesta, en lugar de estimarlos a partir de bytes brutos. Como plugin nativo de Dynamo, puede adaptarse a la forma de cada carga de trabajo sin modificar el router subyacente.