Como una caché KV compartida redujo 14x la latencia de inferencia de un LLM, sin GPUs nuevas

La version corta: una capa de caché KV de codigo abierto llamada LMCache redujo el time-to-first-token medio en aproximadamente 14x en un gran modelo mixture-of-experts, y lo hizo sin una GPU mas rapida, sin un modelo mas pequeño y sin mas memoria. Lo unico que cambio fue donde vivia la caché. Ocho procesos de servicio que acaparaban cada uno una caché privada pasaron a ser ocho procesos compartiendo una sola.

Esa es toda la leccion, y es mas grande que una sola biblioteca. La mayor parte de la optimizacion de inferencia se vende como comprar hardware mas rapido. Buena parte de la latencia que pagas es tu propio sistema recalculando una respuesta que ya tiene, en una caché que pertenece al proceso equivocado. Este articulo explica que cambio, que demuestran y que no demuestran los numeros, y como saber si la misma arquitectura ayudaria a tu propio servicio de LLM.

El coste por defecto: cada rank acapara su propia caché

Cuando un modelo atiende una conversacion, no vuelve a leer todo el historial en cada turno. Almacena el estado de atencion intermedio de los tokens que ya ha visto. Ese almacen es la caché KV (caché clave-valor), y reutilizarla es la razon por la que el segundo turno de un chat es mucho mas rapido que el primero. Recalcularla se llama prefill, y el prefill es la parte cara de responder a un prompt largo.

Aqui esta la trampa. Para servir un modelo grande rapido, ejecutas varias copias de el en paralelo en un mismo servidor, una por GPU, cada una en su propio proceso. En la configuracion convencional, cada uno de esos ranks paralelos por datos mantiene su propia caché KV privada. Las cachés nunca se hablan entre si.

El propio benchmark de LMCache hace concreto el coste. Qwen3-235B-A22B se ejecuto en ocho GPUs H100. Cada rank recibio 50 GB de memoria de CPU para el offloading de la caché KV, de modo que el servidor contenia 400 GB en total. Sobre el papel eso es una caché grande. En la practica eran ocho cachés aisladas de 50 GB, no una unica caché compartida de 400 GB.

Ahora imagina una conversacion multi-turno real. El turno uno se enruta al rank 3, que calcula y cachea el contexto. El turno dos de la misma conversacion se enruta al rank 6. El rank 6 no puede ver lo que cacheo el rank 3. El estado exacto que necesita esta en la memoria del host, en el mismo servidor fisico, pero pertenece a otro proceso, asi que el modelo hace lo unico que puede: vuelve a hacer el prefill de toda la conversacion desde cero. Ya pagaste ese calculo una vez. Lo vuelves a pagar en cada turno que cae en un rank distinto.

Lo que cambio LMCache: una caché en lugar de ocho

LMCache es una capa de caché KV de codigo abierto, con licencia Apache-2.0, para motores de inferencia como vLLM y SGLang. Su trabajo es mover la caché KV fuera de la escasa memoria de GPU hacia una jerarquia por niveles de memoria de CPU, disco local y almacenes remotos, y permitir que la caché se reutilice entre solicitudes, sesiones e instancias del motor.

El cambio que produjo el numero de 14x es arquitectonico, no algoritmico. En la configuracion convencional en proceso, una biblioteca de caché separada esta embebida dentro de cada proceso de servicio, que es por lo que las cachés estan aisladas. El modo Multi-Process de LMCache saca la caché de los procesos individuales y la ejecuta como un unico servicio independiente. Cada proceso de servicio del nodo se registra en el y lee del mismo pool del lado del host.

Asi, los mismos 400 GB dejan de ser ocho cubos amurallados y se convierten en una sola capa compartida. Cuando el turno dos cae en el rank 6, el rank 6 le pregunta a la caché compartida, encuentra el estado que el rank 3 ya calculo y se salta el prefill. El modelo, el hardware y la capacidad total de caché son todos identicos. Simplemente ya no se tira el calculo a la basura.

Los numeros del benchmark

Estas cifras provienen del benchmark de conversacion multi-turno publicado por LMCache sobre Qwen3-235B-A22B-Instruct-2507-FP8, ejecutandose en ocho GPUs NVIDIA H100 80GB con vLLM 0.18.1 y LMCache 0.4.3-dev. Comparan el offload convencional en proceso frente al modo Multi-Process. Son resultados reportados por los autores en un unico hardware y carga de trabajo; tratalos como una fuerte señal direccional, no como una garantia para tu trafico.

Lee la forma, no solo el titular. La ganancia es mayor donde las cachés aisladas mas duelen: los turnos en frio que de otro modo volverian a hacer prefill de un historial largo. Que el TTFT medio caiga de unos cuatro segundos a menos de un tercio de segundo es la diferencia entre un chat que se siente lento y uno que se siente instantaneo. La mejora en el P99 importa aun mas para un producto, porque la cola es lo que experimentan de verdad tus usuarios mas lentos.

Por que esto importa aunque nunca toques LMCache

La cuestion no es que debas instalar una biblioteca concreta. La cuestion es donde se escondia el desperdicio. El servidor ya habia hecho el trabajo. Tenia la memoria para conservar el resultado. Tiro el resultado porque la caché estaba particionada por proceso en lugar de compartida por nodo.

Ese patron aparece por toda la inferencia autoalojada: computo que ya estaba pagado, descartado por como se ensamblo el sistema mas que por cuanto hardware tiene. Antes de que alguien apruebe un pedido de GPU mayor, la pregunta mas barata es si las cajas actuales estan recalculando respuestas que ya tienen. Comprar capacidad es la forma cara de resolver un problema que la reutilizacion a menudo resuelve gratis. Hacemos el mismo argumento sobre el gasto en nuestra guia para reducir los costes de tokens de LLM, y sobre el hardware en el analisis del punto de equilibrio entre modelos locales y APIs.

Donde ayuda una caché KV compartida, y donde no

La reutilizacion de la caché rinde en proporcion directa a cuanto se solapan tus solicitudes. Es una palanca, no una ley, asi que se honesto sobre tu propio trafico antes de esperar un 14x.

Compartir una caché tampoco es gratis. Un servicio de caché independiente añade un salto de red, una pieza movil que operar y monitorizar, y una busqueda que cuesta algo de latencia cuando falla. Cuando las solicitudes apenas se solapan, ese sobrecoste puede superar el prefill ahorrado. La arquitectura es un fuerte valor por defecto para el servicio conversacional y de contexto largo, no una mejora universal.

Reduce esto de verdad tu factura de inferencia?

Mas rapido no es lo mismo que mas barato. Una ganancia de latencia se convierte en ganancia de coste solo cuando elimina algo de la factura o te deja servir mas desde la misma caja. Pon precio al cambio frente a lo que realmente ejecutas:

beneficio mensual = horas de GPU ya no gastadas en volver a hacer prefill + mayor rendimiento por GPU existente + compra de hardware diferida - sobrecoste del servicio de caché y tiempo de operaciones

El prefill reutilizado libera tiempo de GPU, y el tiempo de GPU liberado es o bien un cluster mas pequeño o mas trafico servido en el actual. La ganancia limpia es cruzar un umbral: un objetivo de latencia que ahora puedes cumplir sin añadir un nodo, un nivel de concurrencia que las mismas GPUs ahora pueden sostener, o una mejora de hardware planificada que puedes posponer. Si tus solicitudes rara vez se solapan, la respuesta honesta es que el ahorro es pequeño y tu esfuerzo se aprovecha mejor en otra parte. Para el panorama completo de comprar frente a alquilar en el que esto encaja, repasa cuanto cuesta realmente autoalojar LLMs en la UE.

Una evaluacion breve antes de recablear el servicio

1. Mide tu reutilizacion. Antes de tocar la arquitectura, registra con que frecuencia las solicitudes comparten un prefijo o continuan una conversacion. El solapamiento es todo el tamaño del premio; si es bajo, para aqui.
2. Establece la linea base de la cola, no solo la media. Registra el TTFT y la velocidad de decodificacion P50 y P99 sobre tu trafico real. Las mayores ganancias del benchmark estuvieron en la cola, y la cola es lo que sienten los usuarios.
3. Confirma que la topologia coincide. El 14x vino de unificar varios ranks paralelos por datos en un nodo. Si hoy ejecutas un proceso por GPU, tienes la fragmentacion que esto arregla; si ejecutas un solo proceso, no.
4. Haz un piloto en sombra o en una porcion. Enruta una copia o una fraccion del trafico por la configuracion de caché compartida y comparala con la linea base en el mismo hardware y carga de trabajo.
5. Ponle precio, no solo lo cronometres. Convierte el cambio medido de latencia y rendimiento en horas de GPU, recuentos de nodos o compras diferidas, menos el coste de operar el servicio de caché.

Preguntas que hacer antes de adoptarlo

• Que fraccion de nuestras solicitudes comparten de verdad un prefijo o continuan una conversacion existente?
• Estamos ejecutando varios ranks paralelos por datos por nodo, de modo que las cachés aisladas sean siquiera un problema para nosotros?
• Cuales son nuestros numeros actuales de TTFT y decodificacion P50 y P99 en trafico de produccion, no en un benchmark?
• Que nos cuesta el servicio de caché independiente en latencia cuando falla, en superficie operativa y en modos de fallo?
• Se convierte la ganancia de latencia en menos GPUs, mas rendimiento o una compra diferida, y en cuanto?
• Cual es la madurez, la licencia y el estado de mantenimiento de la capa de caché, y podemos operarla o forkearla si hace falta?

Fuentes y limites de las afirmaciones

La arquitectura, el ejemplo de fragmentacion de 400 GB y todos los numeros del benchmark provienen del articulo de LMCache, "LMCache's New Architecture Boosts MoE Inference Performance by 10x", y del repositorio de GitHub y la documentacion del proyecto. Las cifras reportadas de latencia y rendimiento pertenecen a sus autores y a su sistema de prueba, un servidor 8x H100 ejecutando vLLM 0.18.1 y LMCache 0.4.3-dev sobre Qwen3-235B-A22B; Wavect no las reprodujo. Los hechos se verificaron el 23 de julio de 2026.