Imagínate que Richard Hendricks de Silicon Valley aparece con su algoritmo de compresión y lo aplica al KV cache de los LLMs. Más o menos eso es lo que acaba de presentar Google Research en ICLR 2026. Se llama TurboQuant y, si corre en tu hardware, es básicamente un upgrade gratuito.
El problema que nadie te había contado bien#
Cuando ejecutas un modelo de lenguaje grande —ya sea un Llama 3.3 70B o un Qwen 2.5 32B en tu homelab— el cuello de botella no es lo que imaginas. No es la velocidad de procesamiento del transformer, ni los pesos del modelo. Es el KV cache.
El KV cache (Key-Value cache) es la memoria que el modelo usa para “recordar” el contexto de la conversación. Cada token que procesas genera vectores K y V que hay que almacenar en VRAM para que el modelo pueda atender al contexto anterior. Suena a detalle técnico menor, pero el impacto es brutal:
- Un contexto de 128K tokens con un modelo mediano puede consumir 20-30GB de VRAM solo en KV cache
- El KV cache crece linealmente con el contexto: doble de tokens = doble de memoria
- En una sesión larga, el KV cache puede superar en tamaño a los propios pesos del modelo
El resultado es que la mayoría de homelabbers corremos modelos con contextos pequeños (4K, 8K) no porque el modelo no soporte más, sino porque no tenemos VRAM suficiente para el caché. Con una RTX 3090 de 24GB tienes que elegir: modelo grande O contexto largo. Las dos cosas a la vez, imposible.
Qué es TurboQuant#
Google Research publicó TurboQuant en ICLR 2026 con un titular que levantó mucha polvareda: compresión 6x del KV cache con cero pérdida de calidad medible.
La magia está en dos técnicas combinadas:
PolarQuant — En lugar de guardar los vectores K con la precisión habitual (16 bits por valor), los transforma a coordenadas polares y cuantiza solo la magnitud y el ángulo. Los vectores K tienen una distribución muy particular que hace que esta transformación sea casi sin pérdidas. El resultado: 4 bits por valor en los K-vectors con una degradación en benchmarks de razonamiento inferior al 0.5%.
QJL (Quantized Johnson-Lindenstrauss) — Para los vectores V aplica una proyección aleatoria clásica (Johnson-Lindenstrauss lemma) antes de cuantizar a 2 bits por valor. La clave es que esta proyección preserva las distancias relativas, que es lo que al modelo realmente le importa para la atención.
Combinando ambas: los valores K pasan de 16 bits a 4, y los V pasan de 16 bits a 2. El resultado agregado son aproximadamente 3 bits por par K-V, frente a los 32 bits que usarías en FP16 completo. Eso es una compresión de ~10x en teoría, y de 6x efectiva después de los overheads del esquema.
El blog oficial de Google Research lo explica bastante bien si quieres más profundidad matemática.
Lo que esto significa para tu homelab#
Seré directo con los números:
Mac Mini M2 Pro con 16GB de RAM unificada:
- Antes: podías correr Mistral 7B con contextos de ~16K tokens
- Con TurboQuant: el mismo hardware, contextos de 100K tokens. Eso es un documento de 75 páginas en contexto completo.
RTX 4090 con 24GB:
- Antes: Llama 3.3 70B con contextos pequeños o modelos más pequeños con contextos grandes
- Con TurboQuant: 70B con 50K de contexto, o modelos de 130B que antes requerían multi-GPU
RTX 3080 con 10GB:
- Antes: modelos de 7B-13B con contextos limitados
- Con TurboQuant: modelos de 30B que antes directamente no entraban
No estamos hablando de una mejora marginal. Estamos hablando de que tu hardware actual puede hacer cosas que hace seis meses habrían requerido comprar más VRAM.
¿Hay implementaciones ahora mismo?#
Aquí viene la parte realista: TurboQuant fue publicado hace pocas semanas, pero ya hay movimiento en la comunidad:
- llama.cpp — Ya hay PRs en discusión para implementar QJL en el backend de KV cache. El proyecto tiene historial de integrar estas técnicas rápido (recuerda lo que tardó GGUF en adoptar Q4_K_M cuando salió).
- MLX (Mac) — Apple’s ML framework ya está siendo extendido por la comunidad para soportar KV cache cuantizado. Si corres modelos en Mac, esto llegará pronto via
mlx-lm. - Triton/PyTorch — El paper incluye kernels de referencia. Para los que entrenan o hacen fine-tuning, los bloques de construcción están ya disponibles.
¿Está en Ollama hoy? No todavía. Pero Ollama tiene el ciclo de integración más corto del ecosistema local. Cuando llame.cpp lo integre, Ollama lo incorporará en cuestión de semanas.
El pánico de Wall Street (y lo que revela)#
Una cosa curiosa ocurrió cuando se publicó TurboQuant: las acciones de fabricantes de memoria RAM cayeron entre un 4% y un 11% en pocas horas.
Esto es fascinante por varias razones. Primero, el paper todavía no tenía código de producción cuando se publicó. Wall Street entró en pánico por un PDF de investigación académica. Segundo, la lógica era: “si los LLMs necesitan menos memoria, los data centers van a comprar menos DRAM”. Los analistas asumieron que la demanda de memoria caería.
Esa lógica ignora una cosa: la Paradoja de Jevons.
William Stanley Jevons observó en el siglo XIX que cuando aumentamos la eficiencia en el uso de un recurso, el consumo total de ese recurso sube, no baja. Pasó con el carbón cuando mejoraron las máquinas de vapor. Pasó con la gasolina cuando mejoraron los motores. Y va a pasar con la memoria de IA.
¿Qué harán los data centers con TurboQuant? No comprar menos DRAM. Correrán modelos más grandes con la misma memoria, o el mismo modelo en más instancias paralelas. La eficiencia creará demanda adicional, no reducción de demanda.
Para los homelabbers, la paradoja aplica en nuestra escala: no usaremos menos VRAM, usaremos la misma VRAM para correr cosas que antes eran imposibles.
La diferencia con otras técnicas de compresión#
Si llevas tiempo en el ecosistema, estarás pensando: “¿no es esto lo mismo que Q4, Q5, Q8 en GGUF?”. No exactamente.
La cuantización de pesos (lo que hacen los formatos GGUF) reduce el tamaño de los pesos del modelo. Eso es estático — se carga una vez al iniciar el modelo. TurboQuant cuantiza el KV cache, que es dinámico y crece durante la inferencia.
Son técnicas complementarias. Puedes tener un modelo en Q4_K_M (pesos cuantizados) Y TurboQuant activado (caché cuantizado). El ahorro se suma. No se excluyen.
La otra diferencia clave: las técnicas de cuantización de pesos agresivas (Q2, Q3) sí degradan la calidad notablemente. TurboQuant afirma mantener la calidad de FP16 porque trabaja sobre representaciones donde los errores de redondeo tienen menos impacto en el output final del transformer.
Cuándo llegará a tu Ollama#
La hoja de ruta realista:
- Ahora mismo: el paper está disponible, los kernels de referencia también
- 1-2 meses: llama.cpp integra soporte experimental, aparecen benchmarks de la comunidad
- 3-4 meses: Ollama lo incorpora en una release, posiblemente como flag experimental (
--kv-cache-quant turbo) - 6 meses: se convierte en el default para hardware que lo soporta
Si quieres estar en la vanguardia, vale la pena seguir el repositorio de llama.cpp y los forks de MLX de la comunidad. Cuando aparezca el primer benchmark real comparando contextos con y sin TurboQuant, habrá mucho ruido.
La conclusión es simple: tu hardware ya vale más de lo que valía hace un mes. No porque hayas comprado nada nuevo, sino porque el límite ya no lo pone la VRAM que tienes, sino el ingenio de la gente que escribe estos papers.
Y eso, en el mundo del homelab, es lo más parecido a un upgrade gratuito que vas a conseguir.
Paper: TurboQuant: Redefining KV Cache Compression via Extreme Quantization — ICLR 2026, Google Research