TurboQuant: cómo Google acaba de cambiar la eficiencia de los LLMs

Los modelos de lenguaje grandes tienen un problema que no suele aparecer en los titulares: la memoria. No la memoria que hace que un modelo recuerde tu nombre entre sesiones, sino la RAM de la GPU que se consume durante la inferencia.

Cuando un LLM procesa texto largo, genera internamente una estructura llamada KV cache (Key-Value cache). Cada token del contexto produce un par de vectores que el modelo guarda para no tener que recalcularlos. Con contextos de 128K tokens y modelos grandes, ese cache puede pesar varios gigabytes de memoria GPU por sesión activa.

El 25 de marzo de 2026, Google Research publicó TurboQuant. El resultado: comprimir ese cache 6 veces usando solo 3 bits, con cero pérdida de precisión medible. El paper se presenta en ICLR 2026.

Es el tipo de avance que no genera titulares de "AGI alcanzada" pero que tiene consecuencias directas sobre el coste, la velocidad y la accesibilidad de los LLMs durante los próximos dos años.

Qué es el KV cache y por qué consume tanta memoria

Para entender TurboQuant hay que entender primero qué resuelve.

La arquitectura Transformer que subyace a prácticamente todos los LLMs modernos procesa texto mediante mecanismos de atención. En cada capa del modelo, cada token mira a todos los tokens anteriores para entender el contexto. Esto requiere calcular vectores de key y value para cada token en cada capa.

En inferencia, hay una optimización fundamental: en lugar de recalcular esos vectores para todos los tokens anteriores en cada paso, el modelo los guarda en memoria. Ese almacenamiento es el KV cache.

El problema es que ese cache escala linealmente con la longitud del contexto. Un contexto de 100K tokens en un modelo con 32 capas puede requerir 40-50 GB de memoria GPU. Eso es más de lo que tiene una GPU de consumidor, y es el principal cuello de botella para ejecutar LLMs potentes en hardware asequible.

Hay dos soluciones tradicionales: usar hardware más potente (caro) o acortar el contexto (limita las aplicaciones). TurboQuant propone una tercera vía.

Cómo funciona TurboQuant

La cuantización consiste en representar valores con menos bits. En lugar de usar 16 bits (bfloat16) para cada número, usas 4 o 3 bits. La información se pierde, pero si se hace bien, esa pérdida es manejable.

El problema histórico de la cuantización extrema es que los vectores del KV cache tienen valores atípicos (outliers) que concentran información importante. Cuantizarlos agresivamente introducía errores grandes. Bajar a 3 bits con el esquema tradicional degradaba visiblemente las respuestas.

TurboQuant resuelve esto con una transformación matemática llamada QJL (Quantized Johnson-Lindenstrauss). Antes de cuantizar, aplica una rotación aleatoria a los vectores que redistribuye la información y elimina los outliers. La rotación es isométrica: preserva las distancias entre vectores, y por tanto la calidad de la atención calculada.

El proceso en cuatro pasos: generar una matriz de rotación aleatoria (fija, no cambia entre ejecuciones), rotar los vectores key y value antes de guardarlos en cache, cuantizarlos a 3 bits, y desrotarlos en el momento de calcular la atención.

No requiere ningún reentrenamiento. Es una modificación del proceso de inferencia, aplicable a cualquier modelo existente. Esa es quizá la propiedad más importante: no hay que tocar el modelo, solo el sistema de inferencia.

Los números que importan

Los benchmarks del paper son notables por ser simultáneamente buenos en tres métricas.

Memoria: 6x reducción del KV cache versus bfloat16. Para contextos largos, eso puede significar la diferencia entre que el modelo quepa en la GPU o no.

Velocidad: hasta 8x mejora de throughput en GPUs H100 con cuantización de 4 bits. El speedup viene de que leer menos datos de la memoria GPU es el cuello de botella en muchas operaciones de atención. Menos datos que leer, menos tiempo de espera.

Precisión: cero degradación medible en benchmarks de needle-in-a-haystack, la prueba estándar para verificar que el modelo recupera correctamente información de contextos largos. En benchmarks de generación como HellaSwag y MMLU, las diferencias están dentro del margen de error estadístico.

La combinación de los tres es lo que hace TurboQuant relevante. Técnicas anteriores de cuantización extrema siempre implicaban tradeoffs. TurboQuant mejora las tres métricas simultáneamente.

Por qué debería importarte como builder

Si construyes aplicaciones sobre APIs de Claude, GPT o Gemini, el impacto no es inmediato, pero la dirección es clara.

El coste de inferencia tiene dos componentes principales: el cómputo (cuánto tiempo tarda la GPU en procesar los tokens) y la memoria (cuánta RAM de GPU necesitas por sesión activa). Los costes de los contextos largos están dominados por la memoria. Si los proveedores implementan TurboQuant, pueden reducir el coste por token en llamadas de contexto largo, o escalar más sesiones simultáneas con la misma infraestructura.

Para los que hacen self-hosting con Ollama, llama.cpp o vLLM, el impacto es más directo. Modelos que hoy no caben en tu hardware pueden caber. Llama.cpp ya tiene una discusión abierta sobre la implementación, y hay una implementación PyTorch no oficial con resultados que replican el paper al 99.5% de fidelidad de atención.

Hay un tercer impacto que no está en los benchmarks pero que ocurrió de todos modos: cuando salió la noticia, las acciones de fabricantes de memoria de alto rendimiento (HBM) cayeron. Si los modelos necesitan 6 veces menos memoria para el KV cache, la demanda de hardware especializado para inferencia baja. El mercado lo interpretó como señal.

TurboQuant en el contexto de 2026

No llega solo. 2026 está siendo el año en que la industria empieza a priorizar eficiencia sobre capacidad bruta. Los modelos más potentes ya están aquí. El trabajo ahora es hacer que sean más baratos, más rápidos y accesibles en más hardware.

En este blog cubrimos cómo Google AI Studio ha evolucionado en 2026 apuntando a democratizar el acceso a modelos potentes. TurboQuant es otra pieza del mismo puzzle: si la inferencia se abarata, más builders pueden construir más cosas.

El paper original de Google Research detalla la metodología completa y los resultados de los benchmarks. Vale también la pena monitorizar PolarQuant, otra técnica relacionada que Google presenta en AISTATS 2026, que aplica principios similares a otros tipos de compresión vectorial.

La cobertura de Tom's Hardware y MarkTechPost tiene buen contexto sobre el impacto de mercado para quien quiera profundizar.

Cuándo lo verás en las herramientas que usas

El código open-source oficial se espera para Q2 2026. La implementación no oficial de PyTorch ya existe. Llama.cpp probablemente lo integre en los próximos meses, dado el ritmo habitual de adopción de la comunidad.

Para las APIs de producción (Claude, GPT, Gemini), la estimación realista es finales de 2026 o principios de 2027. Los proveedores necesitan tiempo para validar, integrar en sus sistemas de serving y hacer rollout gradual. Cuando llegue, probablemente se note en reducciones de precio en los endpoints de contexto largo, no en un anuncio explícito de implementación.

Lo que vale la pena monitorizar: los cambios de precio en los endpoints de 64K tokens o más. Cuando veamos bajadas significativas en esos endpoints, será señal de que este tipo de optimizaciones están llegando a producción.

TurboQuant no hace que los modelos sean más inteligentes ni que entiendan mejor las instrucciones. Lo que hace es reducir el coste de ejecutarlos. En la próxima generación de aplicaciones sobre LLMs, eso importa tanto como la capacidad de razonamiento misma.