Por qué el KV cache es el cuello de botella del serving
Ejecutar un modelo dense de 70B con una longitud de secuencia de 128K y 256 sesiones paralelas requiere más de 1 TB de HBM solo para el KV cache. Los modelos MoE (como Mixtral-8x22B o la familia DeepSeek-V3) operan de forma dispersa gracias a la selección de experts, lo que reduce el cómputo, pero el KV cache se mantiene íntegro, por lo que la presión sobre la memoria es igual o mayor que en modelos dense. En 2026, el principal problema al que los equipos de serving dedican la mayor parte de su tiempo es «¿cómo comprimir el KV para alimentar el cómputo de GPU?», y con HBM solo claramente no alcanza. Este artículo presenta como un marco de diseño unificado la cuantización FP8, el paging, el offloading a CPU y NVMe, RadixAttention y el aislamiento multi-tenant.
Compromisos de calidad del KV cache FP8
El KV en FP8 (típicamente E5M2 o E4M3) reduce a la mitad el uso de HBM respecto a FP16. En 2025 había preocupación por la degradación de la calidad de salida, pero en 2026 numerosos papers y benchmarks internos han establecido como consenso que «con el esquema de cuantización adecuado, la pérdida de calidad se mantiene dentro del 0,5%». Las recomendaciones son:
- E5M2 (5 exp, 2 mantissa): rango dinámico más amplio. Funciona bien en contextos largos y workloads multilingües. La pérdida de precisión es ligeramente mayor que E4M3, pero la tasa de fallos tipo alucinación es menor.
- E4M3 (4 exp, 3 mantissa): mayor precisión gracias a más bits de mantisa. Adecuado para generación de código y razonamiento matemático. Los valores de activación extremos pueden ser recortados.
- per-channel scale + per-token shift: cuantización activation-aware que absorbe los valores extremos. Implementado tanto en SGLang 0.4.x como en vLLM 0.7.x.
En los benchmarks de calidad internos de KGA (MT-Bench, HumanEval, JMMLU y cuatro benchmarks de RAG en japonés), bajar Llama-3.3-70B de KV FP16 a KV FP8 E5M2 produce una degradación del aggregate score de solo -0,3 %; en Qwen3-72B, de -0,6 %. El uso de HBM se reduce a la mitad, permitiendo 1,8 veces más sesiones simultáneas en la misma GPU. Para producción, E5M2 es el punto de partida recomendado, y se puede considerar E4M3 en endpoints especializados en código o matemáticas.
El perfil de memoria de los modelos MoE
Los modelos MoE se prestan a confusión por la dispersión del routing, pero el KV cache se materializa íntegramente para todos los tokens. En modelos de la familia DeepSeek-V3 (671B total, 37B activos), los parámetros de los experts ocupan la mayor parte de la HBM, pero en contextos largos el KV supera a los parámetros y se vuelve dominante.
Hay tres puntos de diseño específicos del KV en MoE. Primero, los modelos con MLA (Multi-head Latent Attention) aprenden durante el entrenamiento una representación comprimida del KV, lo que reduce la capacidad de KV en más de un 70 % respecto a un modelo dense de parámetros equivalentes. En las familias DeepSeek-V3 y Qwen3-MoE, esto reduce drásticamente el costo de serving. Segundo, mezclar la distribución de experts por GPU (expert parallelism) con la distribución del KV cache (tensor parallelism) genera desequilibrios de carga donde el KV de algunas GPUs se llena primero. Es obligatorio separar EP y TP correctamente y distribuir el KV de forma equitativa entre todas las GPUs. Tercero, la activación de experts sigue un patrón hot/cold, y ciertos experts se activan con mucha más frecuencia, por lo que el prefetch debe diseñarse asumiendo que el KV de esos experts se accede con regularidad.
Paging y offloading a CPU y NVMe
PagedAttention gestiona el KV en unidades de páginas de 16 tokens, eliminando la necesidad de alojar HBM de forma contigua. En 2026, la configuración de distribuir estas «páginas» entre HBM, memoria de CPU y NVMe ha alcanzado la etapa de uso práctico.
Offloading a CPU: las sesiones inactivas (usuario esperando, steps de agentes en pausa) se migran al KV en memoria de CPU. El costo de la transferencia por PCIe es del orden de 40 GB/s, lo que permite recuperar en la GPU en pocos cientos de milisegundos el KV de una secuencia de 128K en un modelo de 70B. Se puede usar `swap` de vLLM, el backend de `offload` de SGLang o LMCache.
Offloading a NVMe: las sesiones de muy baja frecuencia (inactivas entre minutos y horas) se bajan a NVMe. Con NVMe Gen5, la velocidad efectiva es de unos 12 GB/s; recuperar el KV de 128K lleva entre 2 y 3 segundos. La recuperación tras un largo tiempo de inactividad se canaliza en dos etapas: de NVMe a CPU, y de CPU a GPU, pipeline asíncrono.
Política de niveles: en los casos de clientes de KGA, la heurística que funciona universalmente es: KV activo en los últimos 30 segundos en HBM, de 30 segundos a 10 minutos en CPU, más de 10 minutos en NVMe. En entornos multi-tenant, cada tenant debe tener su propio TTL.
Benchmark de LMCache y SGLang RadixAttention
Benchmark elaborado internamente en KGA en el Q1 de 2026. Workload: chat RAG (system prompt de 1,5K, contexto recuperado de 8K, turn de usuario de 200 tokens en promedio, media de 6 turnos por conversación). Modelo: Qwen3-72B FP8. Hardware: 8 × H200 SXM.
- Solo prefix caching de vLLM: throughput agregado 2.100 tok/s, TTFT P50 210 ms, TTFT P99 720 ms, tasa de recómputo de prefill 38 %.
- SGLang RadixAttention: throughput 2.650 tok/s, TTFT P50 140 ms, TTFT P99 510 ms, tasa de recómputo de prefill 17 %.
- vLLM + LMCache (CPU+NVMe local): throughput 2.450 tok/s, TTFT P50 160 ms, TTFT P99 430 ms, tasa de recómputo de prefill 11 %.
- vLLM + LMCache (distribuido, NVMe compartido): throughput 2.380 tok/s, TTFT P50 180 ms, TTFT P99 480 ms, tasa de recómputo de prefill 6 %. En modo distribuido se pierde algo frente al caso con reutilización de HBM local, pero el P99 se beneficia del efecto de compartir la caché a nivel de clúster.
En conclusión: para un solo nodo, SGLang RadixAttention es la opción principal; para caché compartida multi-nodo, vLLM + LMCache. TensorRT-LLM ofrece funcionalidades equivalentes, pero en flexibilidad de configuración los dos anteriores tienen ventaja.
Aislamiento y equidad en entornos multi-tenant
Para serving multi-tenant en SaaS, la capa de KV tiene cuatro restricciones de diseño.
Riesgo de filtración: si dos tenants comparten el mismo system prompt no hay problema, pero existe la posibilidad (aunque no garantizada) de un «cache timing side channel» en el que un request de un tenant acceda al KV que contiene datos específicos de otro tenant. En sectores de alta seguridad como finanzas, salud o gobierno, la solución práctica es aislar por tenant a nivel de proceso de GPU o grupo de GPUs, separando el KV físicamente.
Equidad: con LRU simple, un tenant que envíe muchos requests monopoliza el KV y degrada el TTFT de los demás. En KGA proponemos una política híbrida: cuota de KV por tenant, con LRU dentro de esa cuota, pero sin que ningún tenant supere el 50 % del total en condiciones normales.
Calidad de servicio diferenciada por SLA: reservar espacio permanente en HBM para los tenants premium y priorizar el offloading a CPU/NVMe para los tenants básicos se está generalizando. Tanto vLLM como SGLang tienen schedulers intercambiables que permiten implementar políticas personalizadas.
Visibilidad: exportar a Prometheus métricas de hit rate de KV, tasa de eviction y uso de cuota por tenant para visualizarlas en un dashboard permite vincular facturación y planificación de capacidad. En el stack estándar de KGA esto se visualiza en Grafana.
Ejemplo de configuración: vLLM + LMCache + KV FP8
```python from vllm import LLM from lmcache.integration.vllm import LMCacheConnector
llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8_e5m2", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, kv_transfer_config={ "kv_connector": "LMCacheConnector", "kv_role": "kv_both", "kv_buffer_size": 5e9, }, ) ```
Del lado de LMCache, se asignan 256 GB al nivel de CPU y 2 TB al nivel de NVMe, y se crean namespaces lógicos por tenant para gestionar las cuotas.
Conclusión
En 2026, el KV cache ya no es algo que se gestiona de forma ingenua almacenando todo lo que cabe en HBM. La combinación es: reducir la capacidad a la mitad con KV FP8, reducirla estructuralmente con modelos MLA, eliminar la fragmentación con PagedAttention, aprovechar el prefix sharing con LMCache o RadixAttention, preservar el KV de largo plazo en niveles de CPU y NVMe, y proteger la calidad del servicio con políticas de aislamiento y equidad multi-tenant. Solo cuando estas seis capas funcionan de forma simultánea es posible lograr un throughput efectivo de miles de tok/s por nodo y cumplir con un SLO de TTFT P99 de 500 ms. Quien domine el KV cache dominará el serving de LLMs en 2026.