TurboQuant: claves del avance en compresión de la caché KV

Tiempo de lectura: 10 min | Cómo la compresión de 3 bits de Google abarata los LLM de contexto largo y qué nos dice sobre los próximos 18 meses de la inferencia de IA

Hay un problema silencioso dentro de cada conversación larga con un gran modelo de lenguaje, y es la razón de que esas conversaciones salgan caras. Se llama caché KV y, con contextos largos, puede consumir más memoria que el propio modelo. El 24 de marzo, un equipo de Google Research publicó TurboQuant, que comprime esa caché a tres bits por valor sin pérdida medible de precisión y sin ajuste fino. Seis veces menos memoria. Atención hasta ocho veces más rápida en una H100. Merece la pena entenderlo bien, porque la compresión de la caché KV es hoy uno de los problemas con mayor efecto palanca de la IA desplegada, y TurboQuant es la señal pública más clara hasta ahora de que el campo ha dado un giro.

Dirijo Kentino. Parte de ese trabajo consiste en leer con atención artículos como este para que nuestros clientes —mineros, constructores, europeos curiosos que siguen el stack de IA y cripto— no tengan que hacerlo. Este texto es mi intento de explicar qué hace realmente TurboQuant, cómo encaja en la ola más amplia de investigación sobre compresión de caché KV de 2025-2026 y qué debería esperar una persona razonable de los próximos dieciocho meses.

El problema de la caché KV, dicho con honestidad

Cuando un transformer genera texto, cada nuevo token atiende a todos los tokens anteriores. Para no recalcular en cada paso los tensores de clave y valor de esos tokens previos, el modelo los almacena. Ese almacén es la caché KV.

La caché crece linealmente con la longitud del contexto. Doble la conversación y doblará la caché. En un modelo de tamaño medio de 8B que trabaje con un contexto de 128k tokens en FP16, la caché KV puede alcanzar sin dificultad decenas de gigabytes en una sola sesión. Los pesos quizá ocupen dieciséis. La caché los empequeñece.

De ahí se derivan tres consecuencias prácticas.

Primera: la inferencia de contexto largo está limitada por memoria antes que por cómputo. Se queda sin VRAM mucho antes que sin FLOPS.

Segunda: el coste de servicio escala mal. Cada usuario concurrente necesita su propia caché. Una GPU que podría agrupar cincuenta conversaciones cortas quizá solo gestione cinco largas.

Tercera: la inferencia en el dispositivo y en el borde sigue fuera del alcance de los modelos que de verdad serían útiles ahí, porque lo que no cabe es la caché, no los pesos.

Comprimir bien la caché KV —es decir, de forma agresiva, barata y sin dañar la calidad de salida— no es, por tanto, una optimización menor. Cambia qué cargas de trabajo son viables y cuáles no. Ese es el problema que aborda TurboQuant.

Qué hace realmente TurboQuant

TurboQuant es un algoritmo de dos etapas. Ambas funcionan sin entrenamiento y sin depender de los datos, lo que significa que no hay ajuste fino, ni conjunto de calibración, ni ajuste por modelo. Se aplica y funciona. Eso importa más que el ratio de compresión, sinceramente, porque es lo que permite incorporar el método a un stack de inferencia existente sin fricción.

Primera etapa: PolarQuant

La primera etapa es PolarQuant, un artículo aparte del mismo grupo (Zandieh, Mirrokni et al., AISTATS 2026). La idea es estructural más que estadística.

Cuantizar vectores de alta dimensión en coordenadas cartesianas resulta incómodo. El movimiento natural —normalizar a la esfera unidad y después cuantizar la dirección— acaba siendo caro, porque calcular la norma de cada vector es justo el cuello de botella del que se intentaba escapar. Los métodos anteriores pagaban ese coste y aun así perdían precisión con anchos de bit bajos.

PolarQuant hace dos cosas para esquivar la trampa. Primero aplica una rotación aleatoria que, de forma algo contraintuitiva, vuelve más predecible y tratable la geometría de la distribución de vectores. Después convierte a coordenadas polares —un radio para la magnitud y un ángulo para la dirección— y las proyecta sobre una rejilla circular que puede cuantizarse sin el paso de normalización. El resultado es una representación limpia y de pocos bits de cada vector que conserva su geometría esencial.

Segunda etapa: QJL

PolarQuant por sí solo deja un error residual. La segunda etapa, Quantized Johnson-Lindenstrauss (QJL), lo corrige con un bit adicional por valor.

La transformada de Johnson-Lindenstrauss es un resultado clásico: se pueden proyectar vectores de alta dimensión a un espacio de dimensión mucho menor mediante una aplicación lineal aleatoria conservando de forma aproximada las distancias entre pares. QJL va más allá y guarda únicamente el bit de signo de cada coordenada proyectada: más uno, menos uno, nada más. Sin sobrecoste de almacenamiento más allá del propio bit.

Lo que aporta QJL, matemáticamente, es un estimador insesgado de las puntuaciones de atención. Corrige el residuo de PolarQuant sin reintroducir el sesgo que sufren los esquemas ingenuos de pocos bits. Ese es el truco. Un bit de signo, bien elegido, basta para limpiar el error de la primera etapa.

Las cifras

Combinadas, las dos etapas se quedan en tres bits por valor, seis veces menos que la línea base FP16. En una NVIDIA H100, el cálculo de los logits de atención es hasta ocho veces más rápido a 4 bits frente a 32 bits. Google probó Gemma, Mistral y Llama-3.1-8B-Instruct en LongBench, Needle In A Haystack, ZeroSCROLLS, RULER y L-Eval. La precisión se mantuvo en los cinco bancos de pruebas de contexto largo. Una prueba lateral de búsqueda vectorial sobre GloVe-200 mostró además mejor recall 1@k frente a las líneas base PQ y RabbiQ, lo que sugiere que el método generaliza más allá de las cachés KV.

El artículo completo está en el blog de Google Research. TurboQuant se presentará en ICLR 2026 en Río de Janeiro.

La ola más amplia

TurboQuant no está solo. Es la aportación reciente más destacada de un área de investigación que avanza rápido, y leerla sin contexto exagera su novedad. Varios métodos más, de finales de 2025 y principios de 2026, atacan el mismo cuello de botella desde ángulos distintos.

Cada uno apunta a un nicho distinto. KVTC sirve para la reutilización sin conexión —guardar la caché de una conversación y cargarla en otra—, donde puede permitirse un trabajo de codificación más pesado a cambio de una compresión mucho mayor. ChunkKV es para los casos en que hace falta comprimir de forma agresiva preservando el significado semántico, algo que importa en tareas donde perder un token duele más que perder un dígito de precisión. PM-KVQ está afinado para las cargas de cadena de pensamiento larga que generan los modelos de razonamiento. KVPress es la fontanería que permite al resto compararlos todos con honestidad.

La aportación distintiva de TurboQuant es la combinación de funcionamiento sin entrenamiento, idoneidad para la inferencia en línea y un estimador demostrablemente insesgado. Es el candidato con más papeletas para llegar antes a los marcos de producción, precisamente porque no pide nada al operador del modelo.

Qué desbloquea esto

Si nos alejamos del artículo y pensamos hacia dónde va esto, los efectos prácticos son más fáciles de nombrar que de dimensionar.

La inferencia de contexto largo se abarata de forma apreciable. Si su caché KV es seis veces menor, puede agrupar más usuarios en la misma GPU, servir contextos más largos con el mismo presupuesto, o ambas cosas. Cualquiera que gestione un servicio de inferencia lo nota en sus márgenes en un trimestre desde la integración.

El despliegue en el borde se vuelve viable para clases de modelos antes inalcanzables. Un modelo de 8B con contexto largo en la GPU de una estación de trabajo, o uno de 3B en un portátil, pasa de «apenas posible» a «rutinario» cuando la caché se reduce en este factor. El despliegue en local para empresas que no pueden enviar datos a API en la nube —jurídico, médico, telemetría industrial— recibe un impulso parecido.

La historia del hardware se deriva directamente, y aquí es donde deja de ser abstracta. Una compresión como la de TurboQuant no cambia qué GPU existen; cambia qué cargas de trabajo caben, y ahora mismo las cargas que la gente quiere ejecutar realmente en local son los modelos frontera chinos de pesos abiertos que, discretamente, se han hecho con el puesto SOTA durante el primer trimestre de 2026.

Vale la pena nombrar explícitamente la alineación actual, porque es lo que nos preguntan los clientes. Kimi K2.5 de Moonshot AI: 1T parámetros totales, 32B activos, MoE, 256K de contexto, licencia MIT; publicado el 27 de enero, lidera los bancos de pruebas de código y matemáticas entre los pesos abiertos. GLM-5 de Z.ai: 744B totales / 40B activos, 204K de contexto, con licencia MIT; hoy encabeza el Intelligence Index de pesos abiertos y SWE-bench Verified. MiniMax M2.5 — 229B totales / 10B activos, 200K de contexto; publicado el 12 de febrero, con precio agresivo y más del 80% en SWE-bench. Qwen3-Coder-Next de Alibaba: 80B totales / 3B activos, 256K de contexto nativos, ampliables a 1M con YaRN, además de la familia Qwen3 más amplia, desde los densos 0.8B–27B hasta el MoE 397B-A17B. Todos de pesos abiertos. Todos desplegables hoy.

En Kentino fabricamos máquinas específicamente para esta carga de trabajo, así que seré concreto con los números. Nuestro servidor de inferencia insignia es una configuración 4× NVIDIA RTX 4090: 96 GB de VRAM agrupada, AMD EPYC 7542 sobre una ASRock Rack ROMED8-2T, 256 GB de DDR4-2666 ECC RDIMM, 2 TB NVMe, dos fuentes de alimentación de 2 kW, en un rack de 24U. Por encima construimos configuraciones 4× RTX 5090 y 8× RTX 5090 (128 GB y 256 GB de VRAM agrupada) y equipos de categoría centro de datos 4× L40 / L40S (192 GB agrupada con ECC) para carga sostenida de clase empresarial y servicio en producción 24/7.

Lo que TurboQuant cambia en este cuadro es el término de la caché KV. Los modelos MoE modernos ya usan atención comprimida (MLA, atención latente de estilo MLA en Kimi, GQA en Qwen3), de modo que su caché KV por token ya parte de cifras menores que las de la antigua clase Llama. Añada TurboQuant encima y obtendrá otro ~6×. El efecto práctico es que la ventana de contexto que una máquina concreta puede servir de verdad —no la que anuncia— da un salto notable. Los pesos no se movieron. El cuello de botella sí.

Dos advertencias honestas. Primera: Kimi K2.5 y GLM-5 en FP8 (1T y 744B totales de pesos, respectivamente) siguen superando lo que admiten estas máquinas; para esos hablamos de un clúster o de aceptar una cuantización INT4 agresiva. Segunda: los límites exactos de tokens dependen del tamaño del lote, de la configuración de atención concreta del modelo y del marco (vLLM, SGLang, TensorRT-LLM implementan el KV de pocos bits de forma distinta). Pero la dirección es lo que importa: una máquina 4× RTX 4090 que hace un año tenía sentido para modelos densos de 13B es hoy la respuesta correcta para Qwen3-Coder-Next con sus 256K de contexto. Una 4× RTX 5090 gestiona con holgura el modelo de código de clase 80B activos dejando sitio para usuarios concurrentes. Una 8× RTX 5090 o una 4× L40S abre la puerta a MiniMax M2.5 y a las variantes MoE mayores de Qwen3 a escala de producción. El hardware no se hizo más grande; la carga de trabajo se hizo más pequeña.

Y cualquier carga de inferencia que se ejecute de forma continua sobre telemetría operativa se beneficia en proporción. La optimización de flotas de minería es un ejemplo real: operadores como OneMiners ejecutan sistemas de eficiencia impulsados por IA sobre miles de ASIC, y la capa de inferencia que hay debajo de esos sistemas escala directamente con cuánto contexto puede retener cada modelo de forma barata. Esta clase de investigación no transforma tales cargas de la noche a la mañana, pero desplaza la curva de lo que resulta asequible.

El pronóstico honesto es incremental. Una reducción de memoria de 6× en un cuello de botella no produce un mundo nuevo. Produce una versión algo más barata, de contexto algo más largo y algo más desplegable del mundo que ya tenemos. Aun así, es muchísimo dinero e ingeniería ahorrados, sumados en todo el sector.

Qué vigilar en 2026-2027

Unas cuantas cosas concretas, aproximadamente por orden de probabilidad.

Integración en los marcos. vLLM, TensorRT-LLM y SGLang adoptarán métodos al estilo de TurboQuant en cuestión de meses, probablemente a través de KVPress como capa de evaluación comparativa. La implementación en Triton de código abierto que publicó el equipo de Google lo vuelve casi mecánico.

Soporte a nivel de hardware. NVIDIA ha mostrado interés en primitivas de atención de pocos bits tanto con KVTC como con KVPress. Cabe esperar que las herramientas de la generación Blackwell traten los formatos KV de 3-4 bits como ciudadanos de primera y no como algo experimental.

Consolidación de los métodos. Los cinco enfoques anteriores resuelven problemas que se solapan. Un stack unificado —compresión geométrica al estilo de PolarQuant para la atención en línea, codificación entrópica al estilo de KVTC para el almacenamiento sin conexión y agrupación semántica al estilo de ChunkKV como entrada— es el punto final probable. Ningún artículo llega ahí por sí solo; el stack se forma a lo largo de un año de trabajo de integración.

Reducciones reales de coste en el servicio. A finales de 2026, los costes de servir inferencia de contexto largo deberían ser visiblemente menores que hoy, y la mayor parte de la mejora vendrá de la compresión y no de silicio nuevo. Esa es la forma más limpia de predecir que esta línea de trabajo habrá tenido éxito.

Cierre

TurboQuant es un avance real sobre un cuello de botella real, y ha llegado dentro de una ola de investigación que ataca el problema desde varios ángulos a la vez. Las cifras destacadas impresionan por sí solas —tres bits, seis veces, ocho veces—, pero la propiedad más importante es que no exige nada al operador del modelo. Lo que acaba desplegándose son los métodos sin entrenamiento y sin dependencia de los datos.

Si ejecuta inferencia de contexto largo a cualquier escala, merece la pena seguirlo de cerca. Y si no lo hace, también merece la pena entenderlo, porque la economía de los modelos que acabará usando se está fijando, en silencio, con artículos como este.