TAO acelera a los agentes de IA: primer token hasta un 36% más rápido, tareas hasta un 27%

Cuando un agente de IA arregla un bug en un repositorio, no se limita a pensar. El modelo emite un comando, un compilador, unos tests o un buscador lo ejecutan en procesadores independientes, el resultado vuelve al modelo, y así decenas de veces. Investigadores de la Universidad Jiao Tong de Shanghái bautizaron este esquema como CGDC: un clúster de GPU para inferencia más CPU dispersas por la red para las herramientas.

Propusieron TAO, un planificador que decide qué agentes se ejecutan en la GPU y en qué nodo concreto, según el momento en que cada agente recibirá la respuesta de su herramienta. Frente al mejor de los competidores en cada métrica, TAO reduce la latencia de ejecución de la tarea hasta un 26,8%, el tiempo medio hasta el primer token tras reanudar la sesión (TTFT) hasta un 36,3%, y aumenta la velocidad de generación (tokens por segundo) hasta un 29,5%.

Por qué sufren la GPU y la caché mientras el agente espera a la herramienta

Mientras la herramienta trabaja, el agente no necesita la GPU. La sesión se puede pausar y ceder el sitio a otras. Pero la pausa tiene un coste. El modelo guarda en memoria una KV-cache: la representación ya calculada del historial de la conversación. Si la sesión vuelve rápido al mismo nodo, se reutiliza el prefijo y no hace falta reprocesar todo el contexto. Si tarda, la caché se desaloja y el recálculo consume capacidad.

Los autores lo demostraron con trazas de DeepSeek-V4 Flash en dos nodos H100: la proporción de caché conservada cae de forma notable con la antigüedad de la observación; la curva se construyó sobre un intervalo de hasta 1 800 segundos.

Según los autores, los sistemas existentes cometen dos errores:

• Usan el tiempo de ejecución de la herramienta solo como señal indirecta para conservar la caché o contar tokens, y no como un indicador propio de que la sesión está lista.
• Evalúan cada sesión por separado mediante heurísticas. Pero las sesiones compiten por la misma capacidad, y la elección voraz de una puede desplazar una combinación más rentable de otras.

Tres números en orden estricto y un problema de mochilas

Para cada par «sesión en espera — nodo», TAO calcula una tripleta de números que se comparan en orden, como las palabras en un diccionario:

• Crédito de caché. Cuántos tokens de esa sesión, según las observaciones, residen en ese nodo. Las observaciones antiguas decaen de forma exponencial con un periodo de semidesintegración dado. Si no hay datos del nodo, el crédito es cero.
• Disponibilidad para el retorno. Un indicador binario: si la herramienta volverá en la próxima ventana de planificación. La predicción se construye a partir de pistas de las propias herramientas (Claude Code tiene Monitor, OpenCode emite un mensaje de timeout de Bash), de comandos sleep analizados y del historial de duraciones. Si no hay nada, se toman cinco segundos por defecto. A las predicciones vencidas se les conceden oportunidades de prueba temporales, para que la sesión no se quede «lista» para siempre.
• Número de tokens. Si los dos primeros valores empatan, se prefieren los contextos largos.

El orden es fijo y los valores cambian con el tiempo. Por eso no hacen falta pesos manuales en una suma.

A continuación entra en juego un algoritmo exacto de programación dinámica. El problema se parece al clásico de las «múltiples mochilas»: cada nodo tiene una capacidad residual, cada sesión tiene un coste de admisión y hay que reunir el máximo valor total. La solución es exacta para una instantánea congelada del estado, aunque el redondeo de la capacidad puede descartar planes que eran válidos antes de redondear. El planificador se ejecuta en un proceso asíncrono independiente y, antes de aplicar el plan, lo contrasta con el estado en vivo. Según los autores, la preparación y el cálculo ocupan menos del 0,12% del tiempo de ejecución en la prueba con cuatro réplicas.

Qué mostraron las mediciones en H100

Se probaron tres modelos: DeepSeek-V4 Flash en dos nodos H100, Qwen3-32B en cuatro y GLM-4.7 en uno. Las cargas fueron estas: SWE-bench Lite (corrección de bugs reales) mediante mini-SWE-agent, Terminal-Bench 2.0 con Claude Code para tareas complejas de terminal y SWE-verified para Qwen con alta concurrencia. Cada nodo aloja una réplica del modelo.

La comparación se hizo con cuatro enfoques: el planificador de vLLM con reparto circular, el mismo con conciencia de caché, Dynamo de NVIDIA (que tiene en cuenta la KV) y ThunderAgent (por número de tokens y empaquetado «en orden decreciente»).

En SWE-bench Lite, frente al mejor competidor en cada columna:

• la latencia de la tarea es entre un 2,4 y un 26,8% menor;
• el TTFT es entre un 7,4 y un 36,3% menor;
• la velocidad de generación es entre un 5,1 y un 29,5% mayor.

En Terminal-Bench, TAO lidera en latencia y TTFT en los tres niveles de concurrencia. Con Qwen3-32B logra el TTFT mínimo con los tres números de sesiones paralelas. Los máximos se toman sobre 12 configuraciones «modelo — carga — concurrencia», así que en cada combinación concreta la mejora es más modesta.

Qué deben hacer con esto los ingenieros

La conclusión principal para quienes mantienen su propia inferencia para agentes: conviene tratar el tiempo de ejecución de las herramientas como datos para el planificador. Si ya mide la duración de las llamadas, parte de esa información puede convertirse en prioridad en la GPU y en un criterio de ubicación.

Los autores afirman que el enfoque se traslada a esquemas multiagente, a agentes cíclicos y también a cargas de chat convencionales. Es una afirmación suya; el material no deja claro si está respaldada por mediciones específicas. Todas las cifras se obtuvieron en H100 y con combinaciones concretas de modelos, por lo que con otro hardware y otro perfil de herramientas el resultado puede ser distinto.