WAKMan elige la política de expulsión del KV-cache y supera a LRU en 5 p. p.

El prefix caching en los servidores LLM ahorra dinero y tiempo, pero solo mientras el prefijo necesario siga en memoria. La memoria es limitada, y el resultado depende de la política de expulsión del KV-cache. Suhas Kumar Morisetty y otros tres autores, que trabajaron durante unas prácticas en Capital One, evaluaron las estrategias más populares sobre 20 mezclas de carga. La conclusión es sencilla: no existe una única política mejor. Proponen WAKMan, un gestor que elige la política de expulsión a partir del tráfico real. De media, mejora el hit rate en 5 puntos porcentuales frente a LRU.

Por qué agentes y chatbots piden cosas distintas a la caché

El prefix caching permite que el servidor reutilice los estados Key-Value de las solicitudes cuyo prefijo coincide con el de prompts anteriores. Así se acelera la fase de prefill y se reducen la latencia y el coste del servicio. Pero el tráfico real en producción es heterogéneo: solicitudes aisladas, diálogos de varios turnos, cadenas de agentes o cualquier combinación de ellos.

Estos tipos de solicitud tienen un «tiempo de retorno» distinto al prefijo. Los pasos de un agente vuelven en pocos segundos y necesitan una caché que recuerde lo reciente. Los prompts populares y los diálogos largos vuelven después de muchas otras solicitudes, y para ellos pesa más la frecuencia de acceso. El primer caso encaja bien con LRU; el segundo, con las políticas basadas en frecuencia.

Dónde gana LRU y dónde pierde

vLLM usa LRU por defecto. Los autores lo compararon con S3FIFO, orientado a la frecuencia, y obtuvieron un resultado que rompe la costumbre de elegir una política para siempre:

• en las mezclas con predominio de solicitudes de agentes, LRU logra un 12% más de aciertos de caché que S3FIFO;
• en el resto de las mezclas, LRU queda por detrás de S3FIFO hasta un 22%;
• incluso un solo parámetro de la carga puede cambiar el ganador dentro de una misma mezcla.

El último punto es el más incómodo para los ingenieros. No basta con medir el tráfico una vez, elegir una política y olvidarse. Con que se mueva un solo parámetro, el líder de ayer pasa a la cola.

Qué hace WAKMan

WAKMan elige la política de expulsión a partir del tráfico real. No necesita saber qué solicitudes concretas llegan ni leer los prompts. En producción, esta condición es importante: el contenido de las solicitudes suele ser sensible, sobre todo en una organización como la empresa financiera donde se hicieron las prácticas. Al gestor le basta con observar el comportamiento del tráfico.

Resultados finales de WAKMan:

• mejora del hit rate sobre LRU de 5 puntos porcentuales de media;
• la menor distancia media respecto a la política óptima entre todas las comparadas;
• la menor distancia en el peor caso respecto al óptimo entre todas las comparadas;
• validación sobre 20 mezclas de cargas single-turn, multi-turn y agentic.

El segundo y el tercer punto importan más que la mejora media. Hablan de previsibilidad: WAKMan no necesariamente gana en cada mezcla concreta, pero falla con menos frecuencia y por menos margen frente a la mejor opción. Para un operador de inferencia, eso vale más que una victoria llamativa en un benchmark concreto.

Qué deben hacer los equipos cuyo tráfico de agentes crece

Los escenarios con agentes ocupan rápidamente una parte cada vez mayor del tráfico. Con ellos cambia el perfil de la caché: aumentan los retornos «calientes» cortos, mientras que los prompts populares y los diálogos largos quedan de fondo. Si la política de expulsión está fijada en el servidor y nunca se revisa, se pierde parte de la ganancia del prefix caching. Esa pérdida se manifiesta en forma de prefill repetido, es decir, segundos de GPU de más y latencia añadida.

Conclusión práctica para quienes mantienen su propia inferencia sobre vLLM:

• mida el hit rate por separado según el tipo de carga, no solo como media del servidor;
• no dé por sentado que LRU es siempre la opción segura: en algunas mezclas pierde frente a S3FIFO hasta un 22%;
• revise la política cada vez que cambie la proporción de tráfico de agentes;
• evalúe las soluciones por el peor caso, no solo por la mejora media.

WAKMan demuestra que la elección de la política se puede automatizar sin acceso al contenido de las solicitudes. En despliegues grandes, una mejora de 5 puntos porcentuales de hit rate supone menos cálculos repetidos en cada prefijo y una latencia más uniforme con tráfico mixto.