La KV cache y el peso de la atención: tres caminos, un problema
Llama-3.1-70B, ejecutado en precisión BF16, acumula unos 0,31 megabytes de KV cache por cada token procesado. Con un contexto de 128.000 tokens, la cuenta sube a 40 gigabytes, una cifra ya incómoda. Con un millón de tokens, el estándar hacia el cual se están impulsando los modelos más recientes, se superan los 300 gigabytes: más de los 140 gigabytes ocupados por los pesos del propio modelo. Es un detalle que anula una intuición generalizada: que la memoria crítica en un gran modelo de lenguaje es la de sus parámetros. Ya no es así, o al menos no siempre. La memoria que realmente asusta a quienes diseñan sistemas de inferencia de contexto largo es la de la KV cache, el archivo donde el modelo guarda las representaciones de clave (key) y valor (value) de cada token ya visto, para no tener que volver a calcularlo todo desde cero con cada nueva palabra generada.
El problema no es solo el tamaño. Cada token descodificado debe hacer transitar toda la caché desde la memoria de banda ancha hasta las unidades de cálculo, lo que convierte la fase de decoding en un cuello de botella de ancho de banda más que de potencia de cálculo. Es un poco como tener un almacén espacioso pero pasillos demasiado estrechos para introducir las carpetas: no importa cuánto espacio haya, si no se consigue que fluya lo suficientemente rápido, el sistema se atasca de todos modos.
En los últimos años, la investigación ha respondido a este problema siguiendo cinco directrices principales. La primera es el desalojo de tokens (eviction), del cual H2O y SnapKV son los ejemplos más citados: se decide qué tokens son menos importantes y se elimina su caché. La segunda es la cuantización, donde KIVI y GEAR han abierto camino reduciendo el número de bits utilizados para representar cada valor. La tercera es la proyección de bajo rango (low-rank projection), con Palu como líder, que ataca la redundancia oculta en las dimensiones internas de los vectores clave y valor en lugar de en el número de tokens o en los bits por valor. La cuarta es la fusión, KVMerger, que combina varias entradas de caché en una representación compartida. La quinta es el uso compartido arquitectónico, del cual la Multi-head Latent Attention de DeepSeek-V2 es el ejemplo más conocido, con una reducción de la KV cache del 93,3% incorporada directamente en el diseño del modelo desde el entrenamiento.
En los últimos meses, tres enfoques han despertado especial atención y merecen ser contados no como tres competidores que luchan por el trono, sino como tres respuestas a preguntas ligeramente diferentes planteadas al mismo problema.
TurboQuant, el antecedente
De TurboQuant ya habíamos hablado en un artículo dedicado, por lo que aquí basta con un recordatorio. El método, firmado por investigadores de Google Research y New York University y aceptado en el ICLR 2026, aplica una rotación aleatoria a los vectores clave y valor antes de cuantizarlos. La rotación no altera la longitud del vector pero redistribuye sus componentes en una forma estadísticamente conocida y predecible, eliminando la necesidad de calibrar el cuantizador con datos específicos. A esto se añade una segunda etapa, construida sobre la técnica QJL (Quantized Johnson-Lindenstrauss), que corrige el residuo de la cuantización con un solo bit adicional, garantizando que las estimaciones de los productos escalares —exactamente los cálculos que el mecanismo de atención realiza continuamente— no estén sesgadas sistemáticamente.
El resultado declarado es una compresión superior a cinco veces con neutralidad cualitativa a 3,5 bits por canal, y una aceleración de la atención de hasta ocho veces en GPUs H100. Como ya habíamos señalado, el método es sólido pero no está exento de zonas grises: la comparación con el anterior RabbitQ despertó polémica en la fase de revisión, y los benchmarks más severos en LongBench muestran que la ventaja real con respecto a métodos como KIVI es del orden de un bit, no una revolución. Para los detalles sobre rotación aleatoria, bit residual y las preguntas abiertas sobre la transferibilidad a modelos más grandes, se remite al artículo original.
OSCAR y la rotación que escucha a la atención
Si TurboQuant apuesta por la generalidad, por la capacidad de funcionar sin saber nada de la distribución de los datos, OSCAR de Together AI nace de una observación casi opuesta: ignorar la atención tiene un coste, y a 2 bits ese coste se vuelve insostenible.
El punto de partida es una distinción sutil pero decisiva. Una rotación como la de Hadamard, utilizada por muchos métodos anteriores, es eficaz porque distribuye los valores anómalos en múltiples canales, haciendo que la distribución sea más uniforme y, por tanto, más fácil de cuantizar. Pero es una rotación ciega: trata todas las direcciones del espacio vectorial como equivalentes, mientras que la atención no lo hace. Algunas direcciones importan mucho más que otras para el cálculo final de las puntuaciones de atención y para el output que se deriva de ellas. Minimizar el error de reconstrucción del vector clave o valor —el objetivo implícito de muchas técnicas de cuantización— no equivale a minimizar el error que llega realmente al output del modelo.
El equipo de Together AI ha construido, por tanto, un sistema en dos fases. En la fase offline, durante una breve calibración sobre un pequeño conjunto de datos, se estima la covarianza de las queries y la de las puntuaciones de atención, y a partir de ellas se derivan dos rotaciones distintas, una para las claves y otra para los valores, construidas específicamente para alinearse con las direcciones que la atención consume realmente. Estas rotaciones se componen después con una transformada de Hadamard y una permutación, de modo que se obtiene lo mejor de ambos mundos: la atención a la geometría del problema y la capacidad de dispersar aún más los excesos residuales. En la fase online, el sistema aplica estas transformaciones fijas durante el servicio del modelo, manteniendo en alta precisión solo una pequeña ventana de tokens recientes y los primerísimos tokens de la secuencia —que actúan como anclaje para la atención—, mientras que todo el resto de la historia conversacional se comprime a 2 bits.
La ventaja de esta elección es que la transformación es fija, calculada una sola vez en la fase de calibración, y no requiere ninguna intervención durante la inferencia propiamente dicha. Esto la hace compatible con las arquitecturas de servicio ya existentes, en particular con el paged-attention layout utilizado por frameworks como SGLang y vLLM, donde los bloques de caché se gestionan como páginas de memoria independientes. OSCAR ha sido integrado directamente en el stack de SGLang con un kernel Triton dedicado para la atención de 2 bits.
Las cifras hablan claro sobre la magnitud del problema que OSCAR resuelve. En Qwen3-4B-Thinking, la cuantización INT2 ingenua, sin ninguna rotación, colapsa prácticamente a cero de precisión en el benchmark de matemáticas AIME25. Con la sola rotación de Hadamard, sin la precaución attention-aware, la puntuación se queda por debajo de 1,5. OSCAR, en la misma tarea y con la misma cantidad de bits, alcanza una precisión comparable a la del modelo no comprimido. En Qwen3-8B, el gap con respecto a la precisión completa BF16 se reduce a 1,42 puntos, mientras que la memoria de la caché se reduce unas ocho veces y el throughput con batches grandes sube hasta siete veces, siempre con el mismo presupuesto de memoria. Incluso en modelos decididamente más grandes, como Qwen3-32B y el GLM-4.7 de 358 mil millones de parámetros, OSCAR mantiene una precisión cercana al BF16 hasta contextos de 128.000 tokens en los tests RULER-NIAH, donde la rotación ingenua, por el contrario, colapsa.
Hay que decir que el propio campo se mueve con una rapidez que hace difícil fijar un punto firme: casi al mismo tiempo que OSCAR surgió también un método con un nombre casi idéntico pero diferente en su esencia, OScaR (Omni-Scaled Canalized Rotation), que ataca el desequilibrio de norma entre tokens como causa primaria de la degradación a baja precisión, proponiendo una solución más ligera pero con objetivos similares. Una señal de lo candente que está, en este momento, el frente de la rotación attention-aware.
EpiCache, el problema que nadie miraba
Mientras TurboQuant y OSCAR compiten en el mismo terreno —el de la representación numérica más eficiente de cada vector individual—, EpiCache de Apple desplaza el foco a otra parte: no cuántos bits se necesitan para representar un token, sino qué tokens vale la pena conservar cuando la conversación se prolonga durante días o semanas.
El problema que EpiCache aborda es específico de las conversaciones de larga duración, aquellas en las que un asistente acumula sesión tras sesión de diálogo con el mismo usuario. En este escenario, la KV cache de un modelo relativamente pequeño como LLaMA3.2-3B puede superar los 7 gigabytes tras solo treinta sesiones, más que el espacio ocupado por los pesos del modelo. La respuesta más obvia —aplicar el eviction tras haber procesado todo el contexto— tiene, sin embargo, un defecto estructural: el pico de memoria crece de todos modos de forma lineal con la longitud del input, porque antes de poder descartar algo hay que procesar todo primero. Es como decidir qué libros tirar solo después de haber llenado ya todos los estantes de la casa.
EpiCache resuelve esto con un eviction por bloques: el contexto se procesa en segmentos de tamaño fijo y, después de cada segmento, se descartan inmediatamente los tokens menos relevantes, manteniendo el presupuesto de memoria constante independientemente de lo larga que sea la conversación global. El problema es que aplicar esta estrategia de forma elemental degrada enormemente la precisión, porque las técnicas más sofisticadas de selección de tokens relevantes —aquellas basadas en un prompt adicional que mide cuánto recibe cada token atención de una query— necesitan saber de antemano qué preguntará el usuario. Y en una conversación real, esa pregunta futura no está disponible en el momento de la compresión.
La solución propuesta es elegante en su sencillez conceptual. En lugar de adivinar la pregunta futura, EpiCache la aproxima usando el pasado: agrupa la historia conversacional en episodios temáticamente coherentes mediante clustering, identifica para cada episodio el segmento más representativo —aquel cuya representación semántica está más cerca del centro del clúster— y utiliza ese segmento como prompt guía para decidir qué tokens conservar en la caché específica de ese episodio. Cuando llega una nueva pregunta del usuario, el sistema la compara con los centroides de todos los episodios memorizados y recupera la caché del episodio más afín, construyendo así una respuesta basada en el contexto realmente pertinente, aunque esa parte de la conversación se remonte a días atrás.
A esto se añade un segundo recurso, tal vez menos vistoso pero igualmente útil: no todas las capas de un Transformer reaccionan de la misma manera al eviction por bloques. Al medir cuánto se desvían los estados de las claves entre el procesamiento completo y el procesamiento por bloques, los autores descubrieron que la sensibilidad varía mucho de una capa a otra, de forma consistente al variar el input pero diferente según el modelo. EpiCache distribuye, por tanto, el presupuesto de memoria asignando más espacio a las capas más sensibles y menos a las que toleran mejor la compresión, en lugar de aplicar un recorte uniforme en toda la red.
Los resultados, medidos en tres benchmarks dedicados a conversaciones de larga duración (LongMemEval, Realtalk y LoCoMo), muestran una mejora de la precisión de hasta el 30% con respecto a las técnicas de compresión anteriores aplicadas en el mismo escenario por bloques, con prestaciones cercanas a las de la caché completa incluso con una compresión de cuatro o seis veces. En cuanto a la eficiencia, el sistema reduce la latencia de descodificación hasta 2,4 veces y el pico de memoria hasta 3,7 veces con respecto a la caché no comprimida.
Tres filosofías comparadas
Puestos uno al lado del otro, los tres métodos revelan más complementariedad que competición, porque en realidad responden a tres preguntas diferentes. TurboQuant pregunta: ¿cómo comprimo un vector cualquiera, sin saber nada del modelo o de la tarea, con garantías teóricas sólidas? OSCAR pregunta: dado que conozco el modelo y puedo permitirme una breve calibración, ¿cómo alineo la compresión con lo que la atención utiliza realmente? EpiCache, por su parte, pregunta algo completamente distinto: en una conversación que dura semanas, ¿qué partes de la historia vale la pena tener a mano, independientemente de cuántos bits por token se estén utilizando?
Esto significa que, en principio, no se está obligado a elegir uno y abandonar los otros. EpiCache decide qué tokens sobreviven en la caché; OSCAR o TurboQuant deciden con cuánta precisión se representan esos tokens supervivientes. Un sistema de producción diseñado para un asistente conversacional de larga duración podría, en teoría, aplicar ambas lógicas en secuencia, aunque ninguno de los tres papers discute explícitamente esta combinación y la integración práctica sigue siendo un ejercicio por verificar sobre el terreno.
En el plano práctico, sin embargo, las diferencias importan y mucho según el escenario. Para quienes deben servir un modelo genérico en producción sin poder permitirse una fase de calibración específica para cada modelo y cada hardware, el enfoque data-oblivious de TurboQuant sigue siendo atractivo, aunque los benchmarks más severos sugieran una ventaja real más modesta de lo que la comunicación ha dejado entrever. Para quienes operan con un único modelo fijo y quieren llevar la compresión hasta el límite de 2 bits sin renuncias drásticas de calidad —especialmente en tareas de razonamiento o código donde cada error de atención se propaga y amplifica en los pasos sucesivos—, la calibración attention-aware de OSCAR ofrece un margen de seguridad que las rotaciones ciegas no garantizan. Y para quienes construyen asistentes que acompañan al usuario a lo largo del tiempo, donde el problema no es tanto la precisión bit a bit como la capacidad de recordar lo correcto en el momento adecuado, EpiCache aborda un cuello de botella que los otros dos ni siquiera tocan.
Existe además una distinción de coste operativo que vale la pena subrayar. TurboQuant no requiere calibración de ningún tipo, lo que lo hace inmediatamente aplicable a cualquier modelo pre-entrenado. OSCAR requiere una calibración offline ligera —del orden de unos pocos miles de tokens para estimar las covarianzas necesarias—, pero después permanece fijo y no conlleva costes adicionales durante la inferencia. EpiCache, finalmente, introduce un coste computacional recurrente, porque cada vez que la conversación supera un cierto presupuesto hay que repetir el clustering y reconstruir las cachés episódicas, una operación que tiene un precio pero que se amortiza con una precisión mucho más alta precisamente en el escenario para el cual ha sido diseñado.
Para quienes deseen profundizar o experimentar de forma autónoma, los autores de OSCAR han puesto a disposición tanto el código como una colección de rotaciones precalculadas en Hugging Face, mientras que para quienes trabajan más en el lado de la proyección de bajo rango, Palu pone a disposición un repositorio completo con scripts de evaluación y kernels GPU dedicados, una confirmación de que en este campo la teoría, por muy elegante que sea, vale solo en la medida en que se traduce en código ejecutable en hardware real.
Quién gana, quién espera
Queda una pregunta de fondo que ninguno de los tres papers resuelve por sí solo: ¿es realmente la compresión de la KV cache el principal vínculo de la inferencia de contexto largo, o existen otros factores —el ancho de banda de la memoria, la latencia de acceso, la paralelización del cálculo de la atención— que pesan tanto o más? Las cifras citadas en este artículo son todas reales y verificables, pero deben leerse en el contexto específico en el que se midieron: modelos de la familia Qwen3 y GLM para OSCAR, LLaMA para EpiCache, Llama-2-7B para TurboQuant. La transferibilidad a familias de modelos diferentes, a arquitecturas con atención agrupada o multi-query donde las dimensiones de los vectores clave y valor ya están reducidas de partida, queda en gran parte por verificar sobre el terreno, no por falta de confianza en la teoría subyacente, sino porque cada arquitectura trae consigo idiosincrasias que los benchmarks publicados raramente agotan.
Existe, finalmente, una consideración que vale la pena hacer en voz alta. La rapidez con la que han aparecido tres enfoques distintos en el arco de pocas semanas, y la aparición casi simultánea de un cuarto método con un nombre casi idéntico a uno de los tres, cuenta menos una carrera competitiva y más la maduración de un problema que la industria finalmente ha dejado de considerar secundario. Durante años, la conversación pública sobre la eficiencia de los grandes modelos de lenguaje se ha centrado casi exclusivamente en el tamaño de los pesos, en la cuantización del modelo, en la destilación. La KV cache ha permanecido, durante la mayor parte de este tiempo, como un detalle de implementación. Las cifras de apertura de este artículo deberían bastar para explicar por qué ese detalle se ha convertido, de hecho, en el verdadero límite de los sistemas que querríamos capaces de recordarlo todo, para siempre, sin pagar el precio en gigabytes.
Nota técnica: los benchmarks citados provienen de los papers originales y no han sido reproducidos de forma independiente por esta redacción; como siempre en este campo, las cifras de laboratorio no garantizan automáticamente las mismas prestaciones en escenarios de producción con cargas de trabajo reales.