DeepSeek, Google y Meta: 10 técnicas para comprimir la caché KV de los LLM y reducir la memoria en inferencia

La caché KV ha pasado de ser un detalle auxiliar a uno de los principales cuellos de botella de la inferencia de LLM en producción. Un nuevo estudio reúne 10 técnicas que ayudan a reducir el uso de memoria sin reentrenar por completo el modelo y, en algunos casos, aceleran notablemente la generación.

Dónde se atascan los LLM

Cuanto más largo es el contexto y más solicitudes simultáneas atiende el modelo, más rápido se infla la caché KV, el almacén intermedio de claves y valores del mecanismo de atención. El estudio ofrece un ejemplo revelador: en un modelo de 30.000 millones de parámetros con batch size de 128 y una entrada de 1024 tokens, la caché KV puede ocupar hasta 180 GB de memoria. Incluso en un modelo de 7B, los pesos ocupan unos 14 GB de memoria GPU y la caché, cerca de 72 GB, de modo que el propio mecanismo de generación empieza a costar más que almacenar los parámetros.

Por eso, optimizar la caché KV se ha convertido en una línea de trabajo propia y no en un ajuste menor. Si se comprime la caché, se puede subir el batch size, atender a más usuarios con la misma GPU y no chocar con los límites de memoria con prompts largos. Una ventaja importante es que buena parte de los métodos funciona en la fase de inferencia: no hace falta reentrenar el modelo base y el efecto se ve de inmediato en el rendimiento y el coste de servir.

Cómo se comprime

Los investigadores usan hoy varias estrategias, y difieren no solo en calidad, sino en el punto del pipeline donde actúan. Unos métodos descartan los tokens menos útiles, otros reducen la precisión de la representación de la caché y otros cambian la propia arquitectura de atención. Una clase aparte redistribuye la memoria entre capas, porque las primeras necesitan un contexto más rico y las profundas pueden trabajar con menos claves y valores. En el fondo, ya no se trata de porcentajes de ahorro, sino de poder ejecutar contexto largo en el mismo hardware.

• Descarte de tokens: H2O, StreamingLLM y SnapKV conservan solo una parte de los estados. H2O mantiene los tokens «pesados» con mayor aporte a la atención, StreamingLLM conserva los primeros tokens y una ventana reciente, y SnapKV elige las posiciones importantes según la atención al final del prompt.
• Reparto del presupuesto por capas: PyramidKV y PyramidInfer parten de que las capas profundas no necesitan un contexto tan rico como las iniciales, así que la memoria se asigna de forma desigual.
• Cuantización: KIVI, KVQuant y TurboQuant reducen la precisión de la caché KV, pero intentan no perder calidad de generación.
• Cambios de arquitectura: MQA, GQA y MLA reducen el tamaño de la caché en el propio esquema de atención, no sobre un modelo ya terminado.
• Compresión de bajo rango: Palu, LoRC y métodos afines recortan la dimensión oculta de los tensores KV, no la longitud de la secuencia.

Los más sencillos de operar son los métodos sin ajuste fino. H2O localiza los tokens que acumulan la mayor parte de la atención y descarta las posiciones débiles. StreamingLLM mantiene los primeros tokens como «anclas de atención» más una ventana reciente, por lo que sirve para conversaciones interminables, pero corre el riesgo de perder un fragmento importante del medio. SnapKV actúa en la fase de prefill y selecciona las posiciones importantes por separado en cada cabeza de atención, por lo que suele superar a esquemas más toscos con el mismo límite de caché.

La distribución de los pesos de atención suele parecerse a una ley de

potencias, por lo que eliminar tokens de bajo aporte no siempre perjudica mucho a la calidad.

Quién logra la mayor ganancia

En cuantización destacan KIVI, KVQuant y TurboQuant. KIVI pasa la caché KV a una representación de 2 bits sin fine-tuning y, según el estudio, reduce hasta 2,6 veces el pico de memoria del conjunto pesos más caché, además de permitir lotes hasta cuatro veces mayores. KVQuant va más allá: usa calibración, precisión mixta y un tratamiento separado de los valores atípicos para mantener la calidad incluso con contextos extremadamente largos.

El resultado más agresivo del texto se atribuye a TurboQuant, de Google Research. Este método primero uniformiza la distribución de los valores con una rotación ortogonal aleatoria y después corrige el error de cuantización para que la estimación de los productos escalares siga siendo insesgada. En una H100 muestra al menos una reducción de memoria de 6 veces y una atención hasta 8 veces más rápida con precisión de 3 bits. Para los equipos de infraestructura ya no es una optimización local, sino una candidatura a nuevo estándar de servicio.

Otra línea es cambiar la propia arquitectura del modelo. GQA se ha convertido de facto en la norma de los LLM open-weight actuales: si en Llama 2 solo se usaba en la versión de 70B, en Llama 3 se extendió tanto a 8B como a 70B. MLA de DeepSeek va aún más lejos: en lugar de claves y valores de tamaño completo por cada token, almacena una representación latente comprimida. El estudio indica que DeepSeek-V2 redujo con MLA la caché KV un 93,3 % respecto al anterior modelo denso de 67B.

Qué significa

El mercado de los LLM depende cada vez menos solo del tamaño de los pesos y cada vez más del precio de la memoria con contexto largo. Para los equipos que construyen servicios de inferencia, la conclusión es sencilla: la ganancia ya no viene de una técnica mágica, sino de elegir con criterio entre descarte, cuantización y arquitectura según la carga concreta, el SLA y el presupuesto de GPU.