LMCache reportó un TTFT medio 13,7 veces menor con una caché KV compartida

La versión corta: LMCache reportó que el time-to-first-token (TTFT) medio bajó de 3,98 segundos a 0,29 segundos, una relación de 13,7 a 1, en un benchmark multi-turno sobre un gran modelo mixture-of-experts. El proyecto mantuvo fijos el modelo, ocho GPU H100 y la capacidad agregada de caché del host de 400 GB, pero sustituyó ocho pools aislados por rank por un pool compartido.

Es un resultado arquitectónico útil, no una promesa universal de mejora de 13,7 veces. La carga, las versiones de software, el enrutamiento, los aciertos de caché y la configuración proceden del equipo de LMCache; Wavect no reprodujo la prueba. Este artículo explica el mecanismo reportado, los límites de la afirmación y la evidencia necesaria para evaluar el patrón en tu propio servicio de LLM.

El problema del benchmark: cada rank tenía una caché aislada

Durante la inferencia autorregresiva, una caché KV almacena las claves y valores de atención intermedios de los tokens ya procesados. Si una solicitud posterior tiene un prefijo exacto reutilizable y el stack puede acceder a bloques compatibles, puede evitar parte del prefill. El beneficio depende de la longitud del prompt, el modelo, el hardware, el batching, la tasa de aciertos, la ruta de transferencia y la concurrencia.

Aquí está la trampa. En la topología del benchmark, vLLM utilizó ocho ranks de paralelismo de datos con paralelismo automático de expertos: la atención se replicó entre las GPU, mientras que las capas mixture-of-experts se distribuyeron. Cada rank se ejecutó en su propio proceso y mantuvo una caché KV privada. Las cachés no se comunicaban entre sí.

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.

Considera un turno posterior cuyo prefijo exacto reutilizable quedó en la caché del rank 3, pero que se enruta al rank 6. En la configuración aislada del benchmark, el rank 6 no podía acceder a la caché del host del rank 3. Por esa ruta no podía reutilizar el prefijo y debía repetir el trabajo de prefill correspondiente.

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 detrás de la relación reportada de 13,7 a 1 en TTFT medio es arquitectónico, no algorítmico. En la configuración en proceso, cada proceso de servicio incorporaba su propia biblioteca y los pools del host quedaban aislados. El modo Multi-Process movió la gestión a un servicio independiente que registraba los procesos de servicio contra un pool compartido del host.

Así, los mismos 400 GB agregados pasaron de ocho pools locales de 50 GB a una capa compartida. Con un acierto compatible, otro proceso registrado puede recuperar bloques KV reutilizables en vez de repetir el prefill correspondiente. El modelo y las GPU se mantuvieron fijos; cambiaron la arquitectura de caché y la configuración de servicio asociada.

Los numeros del benchmark

Estas cifras provienen del benchmark multi-turno publicado por LMCache sobre Qwen3-235B-A22B-Instruct-2507-FP8, ejecutado en ocho GPU NVIDIA H100 80GB con vLLM 0.18.1 y LMCache 0.4.3-dev. Comparan el offload en proceso con el modo Multi-Process a dos solicitudes por segundo durante 120 segundos. Son resultados de los autores para un sistema y una carga, no un benchmark independiente ni una garantía para tu tráfico.

Lee la forma y los límites, no solo el titular. La carga publicada estaba diseñada para producir reutilización de prefijos multi-turno, por lo que ejercitaba directamente el problema de fragmentación. El TTFT medio y el P99 mejoraron en esa prueba. La velocidad de decodificación reportada también cambió, pero la publicación no aporta suficientes repeticiones independientes, análisis de incertidumbre, trazas sin procesar o cargas alternativas para generalizar las relaciones.

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.

Puede aparecer un desperdicio similar en inferencia autoalojada cuando el cómputo reutilizable no es accesible entre procesos o nodos. Antes de comprar más capacidad, mide prefijos repetidos, aciertos de caché, tiempo de prefill, uso de GPU y enrutamiento. La reutilización no es gratuita: añade costes de memoria, transferencia, búsqueda, coordinación, aislamiento, corrección y operación. Aplicamos la misma disciplina de coste completo en nuestra guía para reducir los costes de tokens de LLM y en el análisis del punto de equilibrio entre modelos locales y APIs.

Si ya has agotado la reutilización y un solo modelo atiende una carga estable y crítica para la latencia, la siguiente pregunta es la especialización. Nuestro análisis del ASIC para LLM Taalas HC1 explica qué demuestran 17.000 tokens/s y qué debes validar antes de cambiar flexibilidad por velocidad.

Donde ayuda una caché KV compartida, y donde no

El solapamiento de solicitudes crea una oportunidad de reutilización, pero no determina por sí solo el resultado. Los prefijos compatibles, el enrutamiento, la expulsión, el coste de transferencia, la capacidad, la concurrencia y la implementación de referencia afectan al beneficio medido.

Un servicio de caché independiente añade una ruta de coordinación entre procesos, otro componente que proteger y monitorizar, decisiones de capacidad y expulsión, y trabajo de búsqueda o transferencia en aciertos y fallos. Cuando la reutilización compatible es baja o la transferencia es cara, el sobrecoste puede superar el prefill ahorrado. Trátalo como una opción dependiente de la carga, no como valor predeterminado para todo servicio conversacional o de contexto largo.

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 estimado = coste de cómputo y capacidad evitado - coste de infraestructura de caché, transferencia, ingeniería, seguridad y 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 topología coincide. La relación de 13,7 a 1 en TTFT medio surgió al unificar ocho cachés de ranks paralelos por datos en un nodo. Comprueba si tu enrutamiento y arquitectura producen la misma fragmentación antes de asumir que el mecanismo se aplica.
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 fragmentación de 400 GB y las cifras proceden del artículo del benchmark Multi-Process de LMCache, del repositorio de GitHub y de la documentación del proyecto. Las cifras pertenecen a los autores y a su sistema de prueba, un servidor 8x H100 con vLLM 0.18.1 y LMCache 0.4.3-dev sobre Qwen3-235B-A22B. Wavect no las reprodujo. Los hechos se revisaron de nuevo el 2 de septiembre de 2026.