Google TurboQuant promete 6x menos RAM para correr IA: qué significa para los devs que ya no quieren pagar APIs

Hay un problema que cualquier wey que haya intentado correr un modelo de lenguaje en su propia máquina conoce bien: la RAM se acaba. Siempre. Sin importar cuántos gigas tengas, el modelo quiere más. Es como invitar a un primo a dormir y que de repente se instale con toda su familia.

Google Research acaba de publicar TurboQuant, un algoritmo de compresión que apunta directo a ese cuello de botella y promete achicar el consumo de memoria hasta 6 veces, sin perder precisión. No es el fin del problema, pero sí es la cosa más seria que ha salido en este frente en mucho tiempo.

Primero lo básico: ¿qué carajos es el KV Cache?

Cuando un LLM genera texto, no está procesando todo desde cero en cada token. Guarda las representaciones intermedias de los tokens anteriores en algo llamado KV cache (key-value cache). Es básicamente la memoria de trabajo del modelo durante una conversación.

El problema es que esta caché crece enorme: a mayor contexto (más tokens en la conversación), más RAM ocupa. Y cuando los modelos de hoy manejan ventanas de contexto de 1 millón de tokens, ese cache se vuelve brutalmente caro de mantener. Ya platicamos en otro momento sobre cómo la IA se está comiendo toda la RAM del mundo, y TurboQuant es directamente la respuesta de Google a ese pedo.

Cómo funciona TurboQuant (sin hacerla de académico)

El enfoque de Google combina dos técnicas:

PolarQuant: en lugar de guardar los valores del KV cache en coordenadas cartesianas normales (como todo el mundo lo hace), los convierte a coordenadas polares, los rota aleatoriamente y los cuantiza a 3 bits. Sin necesidad de datos de calibración ni de reentrenar el modelo.

QJL (Quantized Johnson-Lindenstrauss): aplica una transformación matemática para corregir los errores que introduce la compresión agresiva. El resultado: un solo bit de corrección por valor que mantiene la precisión del cálculo de atención intacta.

El efecto combinado: comprimen cada entrada del KV cache a aproximadamente 3.5 bits efectivos, cuando normalmente se guardan en 16 o 32 bits. Eso es 6 veces menos RAM. Sin fine-tuning. Sin datos de calibración extra.

Los números que importan

Según los resultados publicados por Google Research:

Métrica	Resultado
Reducción de memoria KV cache	6x
Speedup en cómputo de atención (H100)	8x vs 32-bit
Pérdida de precisión en benchmarks	0%
Modelos probados	Gemma, Mistral, Llama-3.1-8B

El 8x de speedup es en el cálculo de attention logits específicamente, no en inferencia end-to-end. O sea, el pipeline completo no va a ser 8 veces más rápido, pero esa parte del proceso sí vuela.

Lo testearon en LongBench, Needle in a Haystack, ZeroSCROLLS, RULER y L-Eval, y según InfoQ no detectaron degradación de rendimiento en ninguno.

El catch que nadie te está contando

Aquí viene la parte honesta. TurboQuant es investigación, no un producto. Y tiene limitaciones reales que vale la pena entender antes de emocionarse demasiado:

Solo probado en modelos de 8B. Nadie sabe todavía si funciona igual en modelos MoE grandes o en arquitecturas más complejas. Con los modelos que realmente cuestan, queda por verse.

No hay implementación lista para producción. No hay kernels CUDA, no hay integración con llama.cpp, Ollama, ni nada por el estilo. Por el momento es paper + resultados de laboratorio.

La paradoja de la eficiencia. The Register apunta algo que tiene mucho sentido: la historia de las mejoras de eficiencia en IA sugiere que cuando algo es más barato de correr, se usa para hacer cosas más grandes, no para gastar menos. TrendForce ya dijo que TurboQuant va a “disparar la demanda de aplicaciones de contexto largo que van a requerir más memoria, no menos”. Es la misma lógica de que las autopistas más anchas generan más tráfico, no menos.

¿Qué significa esto para los devs en México?

La neta práctica por ahora: nada inmediato. Pero el camino que abre sí importa.

Si TurboQuant llega a integrarse en herramientas como Ollama o LM Studio (que es justo lo que se usa para correr modelos locales sin pagar un peso de suscripción), el cambio sería significativo: modelos que hoy necesitan 16GB de RAM podrían funcionar en 8GB. Modelos que requieren 2 GPUs podrían funcionar en una.

Para empresas y startups mexicanas que están evaluando si pueden correr sus propios LLMs en lugar de pagar APIs de OpenAI o Anthropic, esto eventualmente podría ser la diferencia entre que sea viable o no. La ecuación de costo-beneficio cambia bastante cuando el hardware necesario se reduce a la mitad.

Lo que hay que monitorear: si algún fork de llama.cpp o un pull request en Ollama implementa TurboQuant en los próximos meses. Ahí es cuando el paper se convierte en algo que puedes usar.

La conclusión que nadie quiere dar pero hay que dar

TurboQuant es genuinamente interesante. No es hype vacío, es investigación sólida con benchmarks reproducibles publicada en Google Research y presentada en ICLR 2026. El problema del KV cache es real y este enfoque lo ataca de forma novedosa.

Pero entre “este paper existe” y “ya puedes correr Llama 4 en tu laptop con 8GB de RAM” hay un abismo que se llama implementación, integración y tiempo.

Por ahora: guarda el link, suscríbete al repo de llama.cpp en GitHub, y espera. Si esto se implementa bien, va a ser de esas cosas que cambian silenciosamente lo que es posible hacer con hardware de rango medio. Una chimba, si funciona como promete.

¿Tú ya corrías modelos localmente? ¿Cuánta RAM tienes y cuál es el modelo más grande que has podido levantar sin que tu compu muera en el intento? Cuéntame abajo.

Fuentes

• TurboQuant: Redefining AI efficiency with extreme compression - Google Research Blog
• Google’s TurboQuant Cuts LLM Memory 6x With Zero Loss - Awesome Agents
• TurboQuant is a big deal, but it won’t end the memory crunch - The Register
• Google’s TurboQuant May Support Faster Inference on Less Capable Hardware - InfoQ
• Google unveils TurboQuant - TechCrunch