Phase 17 - Lesson 18

Stack de Producción vLLM con Descarga de KV LMCache

La stack de producción de vLLM (production-stack) es la implementación de referencia en Kubernetes — conectando el enrutador, los engines y la observabilidad. LMCache es la capa de descarga (offloading) de KV que extrae el caché KV de la memoria de la GPU y lo reutiliza en diferentes consultas y engines (CPU DRAM y luego disco/Ceph). El Conector de Descarga de KV de vLLM 0.11.0 (enero de 2026) hace que este proceso sea asíncrono y acoplable a través de la API de Conectores (v0.9.0+). La latencia de descarga no se muestra al usuario. LMCache es valioso incluso sin prefijos compartidos — cuando una GPU se queda sin slots de KV, las solicitudes interrumpidas (preempted) se pueden restaurar desde la CPU en lugar de recalcular el prefill. Los benchmarks publicados en 16x H100 (80GB HBM) distribuidos en 4 instancias a3-highgpu-4g demuestran que: cuando el caché KV excede la HBM, tanto la descarga nativa a CPU como LMCache mejoran sustancialmente el rendimiento (throughput); con un consumo bajo de KV, todas las configuraciones se equiparan a la línea base con un pequeño overhead.

Type: Learn Languages: Python (stdlib, simulador simple de descarte de KV/KV-spill) Prerequisites: Phase 17 · 04 (vLLM Serving Internals), Phase 17 · 06 (SGLang/RadixAttention) Time: ~60 minutos

Objetivos de Aprendizaje

• Diagramar las capas de la stack de producción de vLLM: enrutador, engines, descarga de KV, observabilidad.
• Explicar la API de Conectores para Descarga de KV (v0.9.0+) y cómo la ruta asíncrona de la versión 0.11.0 oculta la latencia de descarga.
• Cuantificar cuándo ayuda LMCache CPU-DRAM (KV > HBM) vs cuándo añade overhead (KV lo suficientemente pequeño como para caber en la HBM).
• Elegir entre la descarga de CPU nativa de vLLM y el conector LMCache dadas las restricciones de implementación.

El Problema

Su servicio vLLM muestra GPUs con un 100% de uso de HBM con eventos de interrupción (preemption) cada vez que aumenta la concurrencia. Las solicitudes se descartan, se vuelven a encolar y usted recalcula (re-prefill) el mismo prompt de 2K tokens cuatro veces en un minuto. El cómputo de la GPU se gasta en prefills redundantes; el rendimiento útil (goodput) se sitúa muy por debajo del rendimiento bruto.

Agregar más GPUs cuesta linealmente. Agregar más HBM no es posible. Sin embargo, la CPU DRAM es barata — un socket tiene más de 512 GB con latencias órdenes de magnitud peores que la HBM, pero aceptables para caché KV "temporalmente caliente".

LMCache extrae el caché KV a la CPU DRAM para que las solicitudes interrumpidas se recuperen rápidamente y los prefijos repetidos entre engines compartan el caché sin que cada engine recalcule el prefill.

El Concepto

Stack de producción vLLM

github.com/vllm-project/production-stack es la implementación de referencia en Kubernetes:

• Enrutador — consciente del caché (Fase 17 · 11). Consume eventos de KV.
• Engines — workers de vLLM. Uno por GPU o por grupo TP/PP.
• Descarga de caché KV — implementación de LMCache o conector nativo.
• Observabilidad — recolección de Prometheus, paneles de Grafana, trazas de OTel.
• Plano de control — descubrimiento de servicios, configuraciones, actualizaciones continuas (rolling updates).

Se distribuye como Helm chart + operador.

La API de Conectores para Descarga de KV (v0.9.0+)

vLLM 0.9.0 introdujo una API de Conectores para backends de caché KV acoplables. Su engine descarga bloques al conector; el conector los almacena (RAM, disco, almacenamiento de objetos, LMCache). Cuando una solicitud necesita un bloque, el conector lo recupera.

vLLM 0.11.0 (enero de 2026) añade una ruta de descarga asíncrona — la descarga puede ocurrir en segundo plano para que el engine no se bloquee en el caso común. La latencia de extremo a extremo y el rendimiento aún dependen del formato de la carga de trabajo, la tasa de aciertos del caché KV y la presión del sistema; las notas del propio vLLM advierten que la descarga con kernel personalizado puede degradar el rendimiento en tasas de aciertos bajas y que la programación asíncrona tiene problemas conocidos de interacción con la decodificación especulativa.

Descarga nativa a CPU vs LMCache

Descarga nativa a CPU de vLLM: local al engine. Almacena bloques KV en la RAM del host del mismo engine. Rápido de implementar, sin saltos de red. No se comparte entre engines.

Conector LMCache: a escala de cluster. Almacena bloques en un servidor LMCache compartido (CPU DRAM + capa Ceph/S3). Los bloques son accesibles para cualquier engine. Se publican benchmarks en 16x H100.

Elija el método nativo cuando un solo engine tenga presión de HBM. Elija LMCache cuando múltiples engines compartan prefijos (RAG con prompts de sistema comunes, multi-tenant con plantillas compartidas).

Comportamiento en benchmarks

La prueba con 16x H100 (80 GB HBM) distribuidos en 4 instancias a3-highgpu-4g:

• Bajo consumo de KV (prompts cortos, baja concurrencia): todas las configuraciones se equiparan a la línea base, con LMCache agregando ~3-5% de overhead.
• Consumo moderado: LMCache comienza a ayudar en la reutilización de prefijos entre engines.
• KV excede la HBM: la descarga nativa a CPU y LMCache mejoran sustancialmente el rendimiento; LMCache presenta un mayor beneficio debido al uso compartido entre engines.

Cuándo es decisivo LMCache

• Servicios multi-tenant en los que los prompts del sistema se comparten entre tenants.
• RAG en los que los fragmentos de documentos (document chunks) se repiten en las consultas.
• Variantes ajustadas (LoRA) en la misma base, donde la reutilización de KV del modelo base reduce el trabajo redundante.
• Cargas de trabajo con mucha interrupción (preemption): restaurar desde CPU es más barato que volver a calcular el prefill.

Cuándo NO activar

• Poca presión de HBM — paga el overhead sin obtener beneficios.
• Contextos cortos (<1K tokens) — tiempo de transferencia > volver a calcular el prefill.
• Cargas de trabajo de un solo inquilino con prompt único — no hay reutilización que capturar.

Integración con el servicio desagregado

El servicio desagregado de la Fase 17 · 17 se complementa con LMCache: las transferencias de KV del pool de prefill al pool de decode se envían a LMCache si no se utilizan; las consultas subsecuentes las recuperan de LMCache. El enrutador consciente del caché de la Fase 17 · 11 puede enrutar al engine cuya coincidencia de caché sea local O compartida a través de LMCache.

Números que debe recordar

Los números de los benchmarks varían — NVIDIA y la stack de inferencia publican resultados actualizados cada trimestre. Verifique antes de citar.

• vLLM 0.9.0: API de Conectores disponible.
• vLLM 0.11.0 (Ene 2026): ruta de descarga asíncrona; el impacto en la latencia de extremo a extremo depende de la carga de trabajo, la tasa de aciertos de KV y la presión del sistema (no es una garantía absoluta).
• Benchmark de 16x H100: LMCache ayuda cuando el consumo de KV supera la HBM.
• Poca presión de HBM: 3-5% de overhead sin beneficios.

Uso

code/main.py simula una carga de trabajo con mucha interrupción con y sin LMCache. Informa de los prefills evitados, la ganancia de rendimiento y la utilización de HBM mínima para compensar el uso.

Puesta en Producción

Esta lección produce outputs/skill-vllm-stack-decider.md. Dado el formato de la carga de trabajo y la implementación de vLLM, decide entre nativo, LMCache o ninguno.

Ejercicios

1. Ejecute code/main.py. ¿En qué nivel de utilización de HBM comienza a compensar LMCache?
2. Un inquilino comparte un prompt de sistema de 6K tokens en 200 consultas/hora. Calcule el ahorro esperado con LMCache por inquilino.
3. El servidor LMCache es un punto único de falla. Diseñe la estrategia de alta disponibilidad (réplicas, fallback a nativo).
4. LMCache almacena en Ceph en discos duros tradicionales. Para un KV de 4K tokens en 70B FP8 (~500 MB), ¿cuál es el tiempo de lectura versus volver a calcular el prefill?
5. Discuta si la ruta asíncrona de vLLM 0.11.0 es "gratuita" — ¿dónde se esconde el overhead?

Términos Clave

Lecturas Adicionales

• vLLM Blog — KV Offloading Connector (Jan 2026)
• vLLM Production Stack GitHub — Helm chart + operador.
• LMCache for Enterprise-Scale LLM Inference (arXiv:2510.09665)
• LMCache GitHub — Implementación del conector.
• vLLM 0.11.0 release notes — detalles de la ruta asíncrona.