WAKMan: un gestor de caché para servidores de LLM que elige su propia estrategia y logra hasta 5 puntos más de aciertos

Por qué una sola regla no sirve para todo

Los servidores de modelos de lenguaje de gran tamaño dedican una parte considerable de su cómputo a reprocesar el mismo contexto una y otra vez. Si dos solicitudes comienzan con un fragmento de texto idéntico —por ejemplo, una instrucción de sistema o un historial de conversación compartido— el servidor puede calcular una sola vez las "claves" y "valores" internos del modelo para ese fragmento y luego simplemente tomar el resultado ya listo desde la memoria de la tarjeta gráfica, en lugar de recalcularlo. Esto se llama reutilización de prefijo, y acelera de forma real las respuestas y reduce los costos de servicio.

El problema es que la memoria de la tarjeta gráfica es limitada, así que constantemente hay que liberar espacio para esta caché descartando entradas antiguas. La regla que se usa para decidir qué descartar determina directamente cuántas veces el servidor podrá reutilizar datos ya calculados. Investigadores de la Universidad de Maryland y Capital One demostraron que no existe una regla universal, y propusieron un sistema llamado WAKMan que elige por sí mismo la estrategia adecuada observando el tráfico real.

El tráfico hacia servidores de LLM suele ser mixto: hay preguntas puntuales sin memoria de mensajes anteriores, conversaciones de varios turnos con historial, y escenarios de agentes donde un sistema de IA ejecuta por sí mismo una serie de pasos consecutivos en cuestión de segundos.

Estos tres tipos de solicitudes tienen patrones de reutilización de datos fundamentalmente distintos:

• Los pasos de agentes vuelven al contexto compartido casi de inmediato, en segundos, por lo que les conviene la regla de "descartar lo más antiguo" (LRU), que es el estándar actual en el popular motor vLLM.
• Las solicitudes fijas populares (como las instrucciones de sistema de servicios muy usados) y las conversaciones largas regresan a su contexto después de muchas otras solicitudes no relacionadas. Para estas, lo que importa no es la frescura sino la frecuencia de uso, y ahí gana la regla S3FIFO, que protege los bloques solicitados con frecuencia para que no sean desplazados por "ruido" de solicitudes puntuales.

Los autores probaron ambas reglas en 20 flujos de solicitudes mezclados artificialmente, con distintas proporciones de escenarios puntuales, de varios turnos y de agentes. LRU superó a S3FIFO en las mezclas orientadas a agentes, logrando hasta un 12% más de aciertos de caché, pero perdió frente a ella hasta un 22% en mezclas dominadas por conversaciones y solicitudes repetidas. Es más, incluso con una composición de tráfico fija, bastaba con cambiar un solo parámetro —por ejemplo, el número promedio de turnos en una conversación o la longitud del texto de entrada de una solicitud puntual— para que el ganador cambiara.

En la misma mezcla de solicitudes, LRU ganaba con conversaciones cortas de 2 turnos, pero con conversaciones de 8 turnos ya ganaba S3FIFO con una diferencia de 15,4 puntos porcentuales.

Cómo funciona WAKMan

La idea de WAKMan es dejar de adivinar de antemano el tipo de tráfico y, en cambio, comprobarlo constantemente en la práctica. El sistema mantiene junto al servidor real dos copias "sombra" de la caché —una con la regla LRU, otra con la regla S3FIFO— y hace pasar por ellas el registro de solicitudes recientes del último intervalo de tiempo. Gana la estrategia que, en ese mismo conjunto de solicitudes, haya logrado más coincidencias con datos ya en caché. El servidor cambia a esa estrategia hasta la siguiente verificación.

Para esto, WAKMan no necesita saber nada sobre el contenido de las solicitudes, su tipo o el número de turno en una conversación: usa únicamente los hashes de los bloques de datos que vLLM ya calcula en su funcionamiento normal. Esto es importante porque, en la práctica, el servidor muchas veces no puede determinar físicamente el tipo de solicitud: el historial de conversación se ensambla del lado del cliente, y los requisitos de privacidad y separación de datos impiden que el servidor "lea" el contenido de las solicitudes para adivinar su naturaleza.

Resultados y limitaciones

En experimentos con un modelo Gemma desplegado mediante vLLM en cuatro tarjetas gráficas NVIDIA RTX PRO 6000, WAKMan logró en promedio 5 puntos porcentuales más de aciertos de caché en comparación con la regla LRU estándar de vLLM. Entre las tres estrategias evaluadas —LRU puro, S3FIFO puro y WAKMan dinámico—, fue WAKMan el que mostró tanto la menor diferencia promedio como la menor diferencia máxima frente a una caché ideal de tamaño infinito, capaz en teoría de almacenarlo todo.

La principal debilidad del enfoque es el retraso en la reacción: la decisión de cambiar de estrategia no se toma al instante, sino al final del intervalo transcurrido, y si el carácter del tráfico cambia bruscamente justo después de un cambio, parte de las solicitudes de ese intervalo terminan siendo atendidas por una estrategia subóptima. Los autores también señalan que al sistema se le pueden agregar otras estrategias de desalojo de caché, siempre que exista una forma de simular su funcionamiento sin hardware real, por lo que el conjunto de "candidatos" no se limita solo a LRU y S3FIFO.

Para los equipos que operan productos de LLM con tráfico mixto —donde parte de los usuarios mantiene conversaciones largas, parte usa escenarios de agentes y parte simplemente hace preguntas puntuales—, la conclusión práctica es clara: una estrategia de caché fijada de forma rígida casi garantiza pérdidas de rendimiento en alguna parte del tráfico, y conviene incorporar un mecanismo de cambio adaptativo directamente en la infraestructura, en lugar de elegir "la única regla correcta" de una vez por todas.