PyTorch Blog: NVIDIA Dynamo aprende a trabajar con sesiones de agentes de IA

Las aplicaciones agénticas cambian el perfil de carga de un servidor de inferencia. Lo explica PyTorch Blog en su artículo sobre inferencia orientada a sesiones en NVIDIA Dynamo. El anuncio enumera tres rasgos: un prefill inicial grande, múltiples llamadas al modelo dentro de una misma sesión y subagentes que trabajan en paralelo. Los ingenieros conocen cada uno por separado, pero juntos rompen el modelo habitual de «llega una petición, se atiende la petición».

En el fragmento disponible del post no hay benchmarks, por lo que aquí no se citan cifras concretas de aceleración. A continuación, lo que se sabe sobre el problema y sobre la plataforma.

Por qué un agente no se parece a un chat

Un turno de chat consiste en un prompt, una respuesta y una pausa mientras el usuario lee. Un agente funciona de otra manera. Recibe una instrucción de sistema, la descripción de las herramientas, el historial y, posiblemente, grandes fragmentos de código o documentos. El modelo procesa todo eso en el primer paso, y es un prefill pesado. Después el agente llama a una herramienta, recibe el resultado, lo añade al contexto y vuelve a invocar al modelo. El prefijo apenas cambia; solo crece la cola.

Si el servidor trata cada llamada como independiente, recalcula una y otra vez el mismo prefijo o envía la petición a un worker que no tiene la KV-cache necesaria. Los subagentes paralelos agravan el problema: varias ramas comparten un contexto común, pero divergen en la continuación y compiten por la memoria de la GPU.

Qué hace Dynamo

NVIDIA Dynamo es un framework abierto de inferencia distribuida que la compañía presentó como sucesor de Triton Inference Server. Se apoya en ideas que resultan especialmente importantes para los agentes: separar prefill y decode en pools de GPU distintos, enrutar según el contenido de la KV-cache y sacar la caché de la memoria de la GPU hacia niveles de almacenamiento más baratos. Funciona sobre motores como vLLM, SGLang y TensorRT-LLM.

La idea del post es añadir a estos mecanismos el concepto de sesión. El planificador sabe que una serie de llamadas pertenece a un mismo agente y puede mantener su contexto cerca del cómputo, en lugar de adivinar coincidencias en cada petición.

Qué cambia para el servidor al pasar del chat al agente:

• la unidad de planificación es la sesión, no la petición individual;
• conviene calcular una sola vez el prefill inicial grande y reutilizarlo;
• las llamadas repetidas con un contexto creciente requieren un enrutamiento orientado a la caché;
• los subagentes paralelos generan picos de carga sobre el prefijo común;
• conservar la caché entre llamadas pasa a ser una cuestión de capacidad y de coste de memoria.

Qué comprobar en tu propio stack

Si ejecutas agentes con modelos propios, empieza por medir. Comprueba qué proporción de los tokens corresponde al prefijo repetido y con qué frecuencia la siguiente llamada de la sesión llega al mismo worker. Si la proporción es alta y los aciertos de caché son pocos, estás pagando por prefill de más.

El segundo paso es la estabilidad del prefijo. Conviene mantener sin cambios el prompt de sistema, la lista de herramientas y el orden de los mensajes: cualquier modificación al principio del contexto invalida la caché. El tercer paso es decidir dónde guardar la caché entre llamadas y cuánto estás dispuesto a pagar por conservarla mientras el agente espera la respuesta de la herramienta.

Para los equipos que compran inferencia como servicio, la conclusión es más sencilla. Pregunta al proveedor cómo tarifica y almacena el contexto cacheado en sesiones largas. En el caso de los agentes, esa línea de la tarifa influye más en la factura final que el precio por millón de tokens.

Los detalles completos de la implementación y las mediciones están publicados en el post original de PyTorch Blog. Antes de llevar estas conclusiones a la arquitectura, conviene contrastarlas con las cifras de la fuente primaria.