Volver a Noticias
InnovaciónAI Understanding sesión informativa

El periódico afirma que la gestión de caché basada en agentes reduce el retraso del primer token hasta en un 45 % en el servicio de múltiples agentes

Una nueva preimpresión de arXiv describe CacheScout, una capa construida en el servidor vLLM de código abierto que decide qué guardar en la caché de valores clave de un modelo en función del agente que probablemente se ejecutará a continuación. Los autores informan ganancias de latencia y rendimiento de dos dígitos; las cargas de trabajo, los modelos y el hardware no se indican en resumen.

Por 7 min read
A dimly lit data center aisle at night, lined on both sides with black server racks, bundled fiber patch cables running through overhead cable trays and rows of small status lights receding into the distance.
La versión corta

Una nueva preimpresión de arXiv describe CacheScout, una capa construida en el servidor vLLM de código abierto que decide qué guardar en la caché de valores clave de un modelo en función del agente que probablemente se ejecutará a continuación. Los autores informan ganancias de latencia y rendimiento de dos dígitos; las cargas de trabajo, los modelos y el hardware no se indican en resumen.

que paso

Una preimpresión publicada en arXiv describe CacheScout, una capa de tiempo de ejecución para servidores que alojan sistemas de modelos de lenguaje multiagente. En lugar de descartar el cálculo almacenado en caché basándose en el uso menos reciente, aprende en línea qué agente tiende a seguir a cuál y luego usa esas predicciones para decidir qué conservar y qué cargar de antemano. Construido sobre vLLM, se informa que aumenta las tasas de aciertos de caché entre 10 y 18 puntos porcentuales y reduce el tiempo medio hasta el primer token entre 18 y 45 por ciento.

Una preimpresión listada como arXiv:2608.14624, presentada el 16 de julio de 2026 y archivada bajo Inteligencia Artificial (cs.AI), describe un sistema llamado CacheScout. Se enumeran nueve autores: Rui Zhang, Chaeeun Kim, Shaoting Feng, Kuntai Du, Yuhan Liu, Yi Zhong, Cheng-Wei Ching, Junchen Jiang y Liting Hu. La página de listado que es la base de este artículo no indica sus afiliaciones institucionales, y el artículo incluye una versión única sin indicación de revisión por pares o publicación en una conferencia o revista.

El problema que describen los autores es específico de cómo se construyen los sistemas multiagente. Una solicitud de usuario se divide en una secuencia de agentes especializados, y cada uno de esos agentes se ejecuta en un bloque fijo de contexto: un mensaje del sistema, un conjunto de definiciones de herramientas y ejemplos breves. Cuando un modelo de lenguaje procesa texto, produce un estado de atención intermedio, comúnmente llamado caché de valores clave o caché KV, que un sistema de servicio puede almacenar y reutilizar para que no sea necesario procesar nuevamente el mismo texto inicial. Debido a que los contextos de los agentes se repiten, los autores argumentan que, en principio, hay una gran cantidad de reutilización disponible.

Su afirmación es que los servidores actuales no logran capturarlo. Los sistemas existentes, dice el resumen, administran el caché KV de manera reactiva, utilizando el almacenamiento en caché de prefijos combinado con el reemplazo basado en lo reciente, manteniendo lo que se usó más recientemente y desalojando el resto. En una canalización de agentes, el contexto de un agente puede permanecer sin uso mientras otros agentes se ejecutan, por lo que se desaloja poco antes de que se vuelva a invocar a ese agente y se rehaga el trabajo. La idea declarada por CacheScout es que la reutilización futura se rige por la semántica de ejecución del agente y no solo por la actualidad.

El mecanismo, como se describe, es aprender las transiciones de ejecución del agente mientras el sistema está en ejecución (qué agente tiende a seguir cuál) sin un gráfico de flujo de trabajo predefinido y sin capacitación fuera de línea, luego usar ese modelo aprendido para guiar tanto el desalojo como la captación previa proactiva de entradas de caché. Los autores dicen que la ruta crítica de servicio no se modifica, lo que significa que la maquinaria de predicción debe ubicarse junto al manejo de solicitudes en lugar de dentro de él. La implementación se basa en vLLM, un servidor de inferencia de código abierto ampliamente utilizado.

Los resultados informados, que deben leerse como afirmaciones de los autores en lugar de hechos establecidos de forma independiente, son los siguientes: en lo que el resumen llama cargas de trabajo representativas de múltiples agentes del mundo real, la tasa de aciertos de caché mejora entre 10 y 18 puntos porcentuales, el tiempo medio hasta el primer token cae entre 18 y 45 por ciento, la latencia media por turno cae entre 29 y 38 por ciento y el rendimiento máximo aumenta hasta en 57 por ciento. El resumen agrega que los beneficios se generalizan a modelos más grandes, con un tiempo hasta el primer token reducido hasta un 54 por ciento y un rendimiento un 37 por ciento mayor. No nombra las cargas de trabajo, los modelos, las GPU, los tamaños de caché o la configuración básica más allá del comportamiento descrito de almacenamiento en caché de prefijo más antigüedad, y no informa cifras de latencia absoluta.

Lea la fuente principal: arxiv.org

Por qué es importante

Los productos de agentes realizan muchas llamadas de modelo por tarea y cada llamada normalmente reenvía el mismo mensaje del sistema, definiciones de herramientas y ejemplos. Volver a calcular ese prefijo compartido representa una gran parte de la factura y de la espera que siente el usuario. Tratar el caché como algo predecible a partir de la estructura del flujo de trabajo, en lugar de lo reciente, apunta al desperdicio sin cambiar los resultados del modelo.

La economía de los productos de agentes depende de un contexto repetido. Un asistente de codificación, un flujo de trabajo de atención al cliente o un agente de investigación pueden realizar docenas de llamadas modelo para finalizar una tarea, y cada llamada normalmente reenvía un preámbulo largo y casi idéntico de instrucciones y esquemas de herramientas. El costo de procesar ese preámbulo (la etapa de precarga) se paga nuevamente en cada llamada, a menos que el servidor pueda reutilizar el estado almacenado en caché. A medida que crecen los inventarios de herramientas, ese bloque fijo crece con ellos, por lo que la proporción de computación gastada en releer el mismo texto tiende a aumentar en lugar de reducirse.

Las dos métricas que destaca el artículo se relacionan directamente con lo que la gente nota. El tiempo hasta el primer token es la pausa antes de que aparezca algo. La latencia por turno es la espera a que finalice un paso. En un único intercambio de chatbot, unos cientos de milisegundos son una irritación menor; en un bucle de agente que encadena muchos pasos, el mismo retraso por llamada se multiplica, y es una razón común por la que las funciones de agente se sienten lentas incluso cuando el modelo subyacente es rápido. El rendimiento importa en el otro lado de la balanza: un mayor rendimiento máximo significa que el mismo hardware sirve a más usuarios simultáneos, lo cual es una cuestión de costos para cualquiera que pague por GPU.

El movimiento conceptual es la parte que probablemente durará más que esta implementación particular. Las políticas de almacenamiento en caché tomadas de los sistemas operativos y servidores web suponen que el futuro se parece al pasado reciente. Las cargas de trabajo de los agentes violan esa suposición de una manera estructurada y fácil de aprender, porque el orden en el que se ejecutan los agentes es una propiedad de la aplicación y no aleatoria. En particular, los autores dicen que aprenden esa estructura en línea en lugar de exigir a los desarrolladores que declaren un gráfico de flujo de trabajo, una elección de diseño que se adapta a cómo se escriben realmente los marcos de agentes, con ramificaciones, enrutamiento condicional y orquestación decididos por un modelo en tiempo de ejecución.

Varios límites merecen ser señalados claramente. Reutilizar la caché KV es un atajo computacional para el trabajo que de otro modo el modelo reharía, por lo que, en principio, no debería cambiar los resultados del modelo; el resumen no informa comprobaciones de calidad o corrección de los resultados, por lo que la expectativa es una inferencia de cómo funciona la técnica y no algo que la fuente verifique. El tamaño de las ganancias depende de las cargas de trabajo que realmente repiten contextos, de que el sistema esté bajo suficiente presión de memoria para que las decisiones de desalojo importen y del hardware. Las mejoras porcentuales medidas en comparación con una configuración de referencia pueden reducirse en comparación con una mejor ajustada. La captación previa proactiva también consume ancho de banda y capacidad de memoria, y el resumen no cuantifica lo que cuesta una predicción incorrecta.

Qué ver a continuación

Las cargas de trabajo, los modelos, el hardware y las configuraciones de referencia del documento completo determinarán qué parte de la ganancia informada sobrevive al contacto con otras implementaciones. También vale la pena observar: si el código se publica o se actualiza en vLLM, si las latencias de cola mejoran junto con los promedios informados y cómo se comporta el modelo aprendido cuando el orden de los agentes es realmente impredecible.

Lo primero que hay que comprobar es el documento completo en lugar del resumen: qué cargas de trabajo de múltiples agentes se utilizaron y si son públicas, qué modelos y GPU, qué tamaño de caché tenía en relación con el conjunto de trabajo y exactamente cómo se configuró la línea base. Las comparaciones con una configuración vLLM predeterminada son una prueba más débil que las comparaciones con otros enfoques de almacenamiento en caché por niveles o con reconocimiento de caché. Sin esos detalles, los rangos informados son difíciles de comparar con el funcionamiento de los sistemas existentes.

En segundo lugar, si aparece el código. CacheScout se describe como una capa encima de vLLM, por lo que la pregunta práctica es si se lanza, si se propone para la transmisión ascendente y si los proveedores de inferencia o los mantenedores del marco de servicio recogen la idea. Los artículos sobre sistemas de este tipo influyen en las implementaciones principalmente a través de implementaciones, y una técnica que requiere cambios invasivos en un programador viaja más lentamente que una que se ajusta a un punto de extensión existente.

En tercer lugar, la robustez. El modelo de transición aprendido debería ayudar más cuando el orden de los agentes es estable y podría degradarse cuando el enrutamiento es altamente dinámico o conflictivo, y el resumen no informa el comportamiento en ese régimen, ni la sobrecarga del aprendizaje y la captación previa bajo carga. El comportamiento multiinquilino es otra cuestión abierta que la fuente no aborda: si la captación previa de una carga de trabajo desplaza a otra y cómo el uso compartido de caché interactúa con el aislamiento entre usuarios, que ha sido una preocupación recurrente para la reutilización de prefijos en general.

Cuarto, las cifras que no fueron reportadas. El resumen proporciona medios para el tiempo hasta el primer token y la latencia por turno; Las latencias de cola en el percentil 95 o 99 son contra lo que se redactan los acuerdos de nivel de servicio, y una política que mejora los promedios puede abandonar o empeorar la cola. La replicación independiente, un lugar de revisión por pares y las mediciones de las cargas de trabajo que los autores no eligieron aumentarían la confianza. Hasta entonces, esta es una dirección prometedora con resultados autoinformados, no un resultado establecido.

Guías y cuestionarios relacionados

¿Encontró esto útil?
El informe mensual

Obtenga las historias de IA que realmente importan.

Un breve correo electrónico al mes: qué cambió en la IA, por qué es importante, además de las herramientas y guías que valen la pena.

Gratis · Sin spam · Darse de baja en un clic