Capítulo 2 — El desafío de la caché KV

Segunda entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que nombra la estructura de datos que se come la VRAM de todo sistema de serving antes de que los pesos siquiera tengan oportunidad.

Por qué existe este capítulo

El bucle autorregresivo del Capítulo 1 evita trabajo cuadrático recordando. En cada paso de decoding, el modelo tiene que atender a cada token anterior, y hacerlo desde cero volvería a ejecutar el prefill entero en cada iteración — un multiplicador de N veces sobre la longitud de la completación. La caché clave-valor es el espacio de trabajo que ahorra esa aritmética. Guarda las proyecciones K y V por token en cada capa, de modo que los tokens posteriores solo calculan sus propias K y V y leen las anteriores. La caché es la razón por la que el decoding se mantiene aproximadamente O(N) en vez de O(N²). También es, en todos los sistemas de producción que he mirado, el mayor consumidor único de VRAM. El Capítulo 2 recorre la fórmula que gobierna su tamaño, las variantes arquitectónicas que la reducen y el problema de fragmentación que arruina la forma ingenua de asignarla.

2.1 La fórmula que gobierna el tamaño de la caché

La memoria KV para una secuencia es 2 × L × H_kv × D × S × bytes: dos tensores (K y V), L capas, H_kv cabezas de clave/valor, dimensión de cabeza D, longitud de secuencia S y bytes de precisión por elemento. Multiplícalo por el batch para el número a nivel de flota. Cada eje es multiplicativo. Llama-3-70B con L=80, H_kv=8 (GQA), D=128, con S=8.192 y BF16, retiene unos 40 GB de caché por secuencia — antes de aplicar el batch. Con batch 32, solo la caché se acerca a 1,3 TB, varias veces los propios pesos y varias veces la VRAM de un H100. Llama-2-70B, el último gran modelo con MHA, tiene H_kv=64 en lugar de 8 y su caché es ocho veces mayor para la misma configuración. La fórmula no es una curiosidad; es el número que determina cuántos usuarios concurrentes puede sostener un chip. Cualquier otro presupuesto de memoria en la caja — activaciones, overhead del framework, buffers temporales — tiene que caber a su alrededor.

2.2 MHA, GQA y MQA son decisiones de diseño sobre el tamaño de la caché

El término H_kv es el término que las arquitecturas modernas han ido rebajando por ingeniería. La atención multi-cabeza (MHA) usa una cabeza K y V por cada cabeza de consulta; la caché es gruesa, la calidad es la más alta y cada cabeza puede especializar su noción de a qué atender. La atención multi-consulta (MQA) colapsa a una única cabeza K y V compartida; la caché se reduce por un factor de H, pero las cabezas pierden especialización y se pierde calidad medible en contextos largos. La atención de consulta agrupada (GQA), introducida en 2023 y hoy la elección dominante en Llama-3, Mistral, Mixtral, Qwen y DeepSeek, particiona las cabezas de consulta en G grupos que comparten K y V; un G = H/8 típico da una reducción de caché de ocho veces con un coste de calidad tan pequeño que los suites de evaluación no lo detectan de forma fiable. GQA no es gratis — reduce también el número de parámetros de la proyección K/V, y ese presupuesto se redistribuye en otra parte del modelo — pero empíricamente la redistribución rara vez perjudica. MLA (multi-latent attention, DeepSeek-V2) empuja más lejos con una caché latente de bajo rango; es la dirección de investigación, pero los despliegues de producción en 2026 son mayoritariamente GQA.

2.3 La asignación ingenua desperdicia la mayor parte del presupuesto

La forma obvia de asignar memoria KV — reservar una losa contigua por secuencia, dimensionada a la longitud máxima posible — falla en cuanto entra en contacto con tráfico real. La mayoría de las peticiones terminan muy por debajo del máximo; la cola reservada es memoria muerta. En Llama-3-70B con un límite de 32K, una completación de 1.000 tokens desperdicia 31 losas de caché KV. Un batch de 32 con límite de 8K y longitud media 800 deja en cualquier momento sin usar aproximadamente el 90 por ciento de la caché KV reservada. Peor aún, la disposición es inflexible: una nueva llegada no puede usar la cola sin usar de otra secuencia, porque esa cola ya está comprometida. La concurrencia colapsa a lo que permita el peor caso presupuestado, no a lo que soportaría el tráfico medio. El problema es fragmentación interna — el mismo modo de fallo que los sistemas operativos resolvieron con paginación en los años 1960. El Capítulo 8 muestra cómo PagedAttention trae al lado del LLM esa misma solución.

Lo que prepara el Capítulo 2

La fórmula de la caché y sus ejes reaparecerán cada vez que capítulos posteriores tengan que razonar sobre cuántos usuarios caben en una GPU. El Capítulo 3 la usa para explicar por qué la capacidad de VRAM importa más que los FLOPs al elegir una GPU de serving. El Capítulo 7 la usa para explicar por qué el batching continuo está acotado por la caché KV y no por el modelo. El Capítulo 8 la usa para justificar PagedAttention, la eviction H2O y el caché de prefijos — tres técnicas cuyo propósito íntegro es hacer que la caché se comporte más como memoria virtual paginada y menos como una losa de bytes reservados. La fórmula es la gramática del resto de argumentos de memoria del libro.

Próximamente — Capítulo 3: GPUs de centro de datos para IA generativa. El silicio que tiene que sostener tanto los pesos como la caché KV, leído por mecanismo en vez de por hoja de especificaciones.