La memoria del KV cache ha superado los pesos del modelo como la restricción estructural para inferencia LLM en producción a escala. Los números de una encuesta técnica de Marktechpost publicada el miércoles: un modelo de 30 mil millones de parámetros corriendo batch 128 con entradas de 1.024 tokens necesita aproximadamente 180GB solo para el estado del KV cache. Para un modelo de 7B, el KV cache (72GB) es 5x más grande que los parámetros del modelo en sí (14GB en FP16). Esa es la inversión que conduce un área de investigación activa: comprime el KV cache sin reentrenar el modelo base y recuperas margen de tamaño de batch, aumentas throughput y sirves a más usuarios concurrentes en el mismo hardware. La encuesta cubre 10 técnicas relevantes para producción a través de cuatro familias de estrategia.

Familia uno es eviction —mantén algunos tokens, descarta otros. H2O (Heavy Hitter Oracle, NeurIPS 2023) observó que una pequeña fracción de tokens lleva la mayor parte de la masa de atención y dinámicamente retiene esos más los tokens recientes, alcanzando 29x throughput sobre HuggingFace Accelerate en OPT-6.7B/30B. StreamingLLM mantiene los primeros tokens (que actúan como "sumideros de atención") más una ventana deslizante de recencia —rápido y amigable con hardware pero ciego a la importancia semántica en el contexto del medio. SnapKV usa una ventana de observación al final de prompts largos para comprimir la fase de prefill específicamente, atacando una fase que H2O deja intacta. PyramidKV / PyramidInfer asigna diferentes tamaños de cache por capa basados en patrones de atención observados, reclamando 2,2x throughput y 54 por ciento de reducción de memoria GPU. El modo de falla de la familia eviction es pérdida de información: cualquier cosa descartada se va por el resto de la generación, así que la calidad degrada en tareas que necesitan recuerdo disperso de medio contexto.

Familia dos es cuantización —mantén todos los tokens, baja los bits por token. KIVI es cuantización KV 2-bit plug-and-play sin fine-tuning, cuantizando claves por canal y valores por token; reporta 2,6x reducción de memoria pico, 4x batches más grandes y ganancias de throughput de 2,35-3,47x. KVQuant agrega precisión mixta calibrada (cuant clave por canal, cuant pre-RoPE, descomposición denso-sparse) y empuja a precisión sub-4-bit para contextos de hasta 10 millones de tokens. TurboQuant —el método reciente de Google— usa rotación ortogonal aleatoria (PolarQuant) más corrección Johnson-Lindenstrauss cuantizada 1-bit, reclamando 6-8x reducción de memoria a 3-bit sin paso de calibración offline. Familia tres es arquitectónica: Grouped-Query Attention (GQA) y Multi-Query Attention (MQA) reducen el tamaño del KV cache por diseño —múltiples cabezas de query comparten menos cabezas key/value. GQA es ahora el default de facto en Llama 3, Mistral y la mayoría de modelos open-weight. El Multi-head Latent Attention (MLA) de DeepSeek va más lejos: proyecta claves y valores en un vector latente comprimido durante inferencia y reporta 93,3 por ciento de reducción de KV cache en DeepSeek-V2 sin pérdida de calidad. Familia cuatro —la descomposición de pesos low-rank de Palu / LoRC— aplica proyección low-rank de cabeza de grupo y es ortogonal tanto a cuantización como a eviction, lo que significa que puede apilarse con las otras familias.

Para constructores, tres lecturas. Primero, la técnica correcta depende de qué fase te limita. Si la latencia de prefill es la restricción (prompts muy largos), SnapKV y métodos clase Pyramid ayudan; si el throughput de decode es la restricción (generaciones largas, muchos usuarios concurrentes), H2O, KIVI y StreamingLLM dominan. Si entrenas un nuevo modelo desde cero, el fix arquitectónico (GQA/MLA) es la primera palanca —es gratis en tiempo de inferencia y se apila con todo lo demás. Segundo, observa qué stacks de inferencia integran qué técnicas: vLLM, TensorRT-LLM, SGLang, llama.cpp y TGI tienen cada uno conjuntos soportados diferentes, y la brecha entre "el paper de investigación reclama X" y "la biblioteca de producción envía X con kernels que funcionan en tu GPU" es real. Tercero, la inversión (KV cache > pesos del modelo) es la razón arquitectónica por la que cada lanzamiento de modelo frontera en 2025-2026 ha enviado con modificaciones de atención horneadas (GQA de Llama 3, MLA de DeepSeek-V2/V3, híbrido GDN-más-atención de Qwen3). Los "pesos abiertos" que descargas ahora incluyen apuestas implícitas de compresión de KV cache; si comparas modelos entre sí, comparar el costo de inferencia requiere medir la huella del KV cache a tu tamaño de batch y longitud de secuencia específicos, no solo el conteo de parámetros. La lección para constructores: cuando la memoria es el cuello de botella, el conteo de pesos del modelo ya no es la unidad correcta de comparación.