KV cache

Definición

La KV cache (caché de Keys y Values) es una optimización fundamental en la inferencia de transformers decoder-only —es decir, prácticamente todos los LLMs modernos—. Consiste en almacenar en memoria las matrices Key (K) y Value (V) calculadas para cada token ya procesado, de modo que al generar el siguiente token no haya que recomputar la attention sobre toda la secuencia desde cero.

Sin KV cache, generar el token número 1.000 requeriría rehacer 1.000 cálculos de atención. Con KV cache, solo se calcula la atención del nuevo token contra los K/V ya cacheados. La diferencia: orden de magnitud en velocidad.

Es la pieza invisible que hace viable la generación token a token en LLMs grandes. Y también es el principal consumidor de VRAM durante la inferencia, lo que la convierte en el cuello de botella central de la economía de servir modelos.

Cómo funciona

En la fase de prefill (cuando el modelo procesa el prompt completo):

1. Cada capa transformer calcula Q (Query), K (Key) y V (Value) para cada token del prompt.
2. K y V se guardan en la KV cache, organizados por capa y posición.

En la fase de decode (generación token a token):

1. Para el nuevo token, solo se calcula Q (Query), K y V de ese token.
2. La atención se calcula entre el nuevo Q y todos los K cacheados (incluyendo el nuevo).
3. La salida se pondera con los V cacheados.
4. Los nuevos K y V se añaden a la cache.

Resultado: cada nuevo token cuesta O(n) (atención contra todos los anteriores) en lugar de O(n²) que costaría recomputar desde cero. Esa es la magia.

Por qué consume tanta memoria

La KV cache crece linealmente con la longitud del contexto y con el tamaño del modelo. La fórmula aproximada:

KV_size = 2 × num_layers × num_kv_heads × head_dim × context_length × precision_bytes

Para Llama 3.1 70B con contexto de 32k tokens en BF16:

2 × 80 × 8 × 128 × 32000 × 2 = ~10.5 GB

10 GB solo para la KV cache de una sola conversación. Por eso servir muchas conversaciones simultáneas requiere VRAM masiva.

Para contextos extremos (200k, 1M tokens), la KV cache puede exceder fácilmente la memoria de una GPU. Esto es el cuello de botella físico que limita ventanas de contexto larguísimas en producción.

Ejemplo práctico

Imaginemos un asistente de AE Works que mantiene conversaciones largas con clientes sobre proyectos. Una sesión típica:

• Inicio: 2.000 tokens (system prompt + contexto del cliente).
• Tras 30 turnos: 25.000 tokens acumulados.

En un Mac Studio con Llama 3.1 70B Q4:

• KV cache inicial: ~400 MB.
• KV cache tras 30 turnos: ~5 GB.
• Si tenemos 4 usuarios en paralelo: 20 GB solo en KV caches activas.
• Más el modelo cuantizado (42 GB) → estamos rozando los 64 GB.

Por eso plataformas serias usan vLLM, TensorRT-LLM, SGLang: motores de inferencia que gestionan KV cache eficientemente (paged attention, sharing, swapping).

Innovaciones modernas en KV cache

El gestión inteligente de la KV cache es uno de los campos más activos:

• Paged Attention (vLLM): gestiona la KV cache como páginas de memoria virtual estilo OS. Permite mezclar muchas conversaciones de tamaños distintos eficientemente. Tripled throughput vs naive.

• Multi-Query Attention (MQA) / Grouped-Query Attention (GQA): arquitecturas donde múltiples Q heads comparten K/V heads, reduciendo el tamaño de la KV cache 4-8×. Llama 3 usa GQA.

• Multi-head Latent Attention (MLA): introducida por DeepSeek, comprime K/V a un espacio latente más pequeño. Reduce KV cache 5-10× con mínima pérdida.

• KV cache quantization: almacenar K y V en INT8 o INT4 en lugar de BF16. Reduce 2-4× la memoria.

• Streaming attention / sliding window: solo cachear los últimos N tokens. Pierde algo de calidad pero permite contextos efectivos infinitos.

• KV cache sharing: si varios usuarios comparten el mismo system prompt, cachearlo una sola vez (prompt caching).

• Cache eviction: descartar K/V de tokens menos importantes cuando se necesita memoria.

Prompt caching

Una de las técnicas más prácticas y rentables: cachear el prefill de prompts repetidos.

Si tu system prompt + few-shot examples ocupan 5.000 tokens y se repiten en cada llamada, calcularlos cada vez es desperdicio. Anthropic, OpenAI y otros ofrecen prompt caching explícito en sus APIs:

• Marcas qué partes son cacheables.
• La primera vez se procesa normal (con coste y latencia plenos).
• Las siguientes 5 minutos (típico TTL), esa parte sale de la KV cache → coste / 10, latencia de prefill / 5.

Para chatbots con system prompts grandes, prompt caching es la optimización con mejor ROI que existe.

Speculative decoding y KV cache

Speculative decoding (mencionado en el artículo de inference) interactúa con KV cache: un modelo pequeño propone tokens, el grande verifica. Para verificar, el grande necesita actualizar su KV cache con los tokens propuestos. Si los rechaza, debe "rollback" la cache. Esto requiere gestión cuidadosa.

Errores comunes al hablar de KV cache

• Pensar que "es solo una optimización pequeña": sin KV cache, la inferencia sería 10-100× más lenta. Es fundamental.
• Subestimar su consumo de memoria: en LLMs grandes, KV cache puede ocupar más que el modelo mismo cuando hay muchos usuarios concurrentes.
• Confundir prompt caching con KV cache general: prompt caching es una forma específica de aprovechar la KV cache para prompts repetidos.
• No usar GQA/MLA cuando aplica: arquitecturas modernas reducen KV cache drásticamente. Modelos viejos con MHA tradicional son ineficientes.
• Ignorar gestión en producción: usar la implementación naive de HuggingFace para servir miles de usuarios es ingenuo. vLLM, SGLang son obligatorios a escala.
• Pensar que se puede generalizar a Mamba: arquitecturas como Mamba no tienen KV cache porque usan un estado fijo. Es una diferencia fundamental.

Cuándo importa entender KV cache

Sí, profundiza si:

• Sirves LLMs en producción a escala.
• Optimizas inferencia o eliges arquitecturas de modelo.
• Trabajas con ventanas de contexto largas.
• Comparas modelos por su perfil de coste real (no solo parámetros totales).

Es menos crítico si:

• Solo consumes APIs gestionadas (Anthropic, OpenAI, Google) sin self-host.
• Tu volumen es bajo y la latencia no es crítica.

Referencias

• vLLM · Paged Attention paper — el paper que estableció paged attention y vLLM
• Ainslie et al. · GQA paper — Grouped-Query Attention, usado por Llama y otros modernos
• DeepSeek-V2 paper — introducción de Multi-head Latent Attention (MLA)