TIC's en la Web

TurboQuant: Google comprime la memoria de los LLMs 6 veces sin perder calidad (y lo que significa para el coste de la IA)

Esta semana Google ha publicado algo que, la verdad, merece más atención de la que está recibiendo en los medios generalistas. Se llama TurboQuant y es un algoritmo de compresión de memoria para modelos de inteligencia artificial. Te lo cuento porque creo que tiene implicaciones prácticas bastante más concretas de lo que parece a primera vista.

El problema que resuelve TurboQuant

Para entender por qué esto importa, hay que situarse un momento. Cuando ejecutas un modelo de lenguaje grande, ya sea en producción en una empresa o en tu propio servidor, uno de los mayores cuellos de botella no es la potencia de cálculo en sí, sino la memoria. Concretamente, algo que se llama la caché KV (key-value cache): una especie de «chuleta digital» que el modelo mantiene en memoria para no tener que recalcular continuamente la misma información.

El problema es que esa caché consume una barbaridad de RAM. Y cuando hablamos de modelos grandes funcionando en tiempo real con miles de peticiones simultáneas, eso se traduce directamente en coste de infraestructura. No es un problema teórico de investigadores, es el problema que tiene cualquier empresa que despliega IA en producción.

Las técnicas de cuantización de vectores (reducir la precisión de los datos para que ocupen menos) ya existían, pero tenían un defecto: para funcionar bien necesitaban almacenar constantes adicionales que, paradójicamente, añadían entre 1 y 2 bits extra por número. Es decir, intentabas comprimir y te aparecía una sobrecarga que limitaba el beneficio real.

Qué hace TurboQuant de diferente

Google Research ha presentado TurboQuant en el ICLR 2026 junto con dos técnicas relacionadas: PolarQuant y QJL (Quantized Johnson-Lindenstrauss). La idea central es elegante: antes de comprimir los vectores, el algoritmo los rota aleatoriamente para simplificar su geometría. Ese paso previo hace que la compresión posterior sea mucho más eficiente y no necesite esas constantes de sobrecarga que lastraban los métodos anteriores.

El resultado, según los datos que ha publicado Google, es una reducción de 6 veces en el uso de memoria de la caché KV y una aceleración de 8 veces en el cálculo de atención. Y, lo que es clave: sin pérdida de precisión en las respuestas del modelo. No estamos hablando de comprimir a costa de que el modelo responda peor, sino de mantener la misma calidad con una fracción de los recursos.

En términos de coste, los análisis independientes apuntan a que esto podría reducir los costes de inferencia en producción en más de un 50% en muchos escenarios. Si tienes o gestionas infraestructura de IA, ese porcentaje te va a resultar muy llamativo.

Por qué esto importa para el sector web y tech

En mi experiencia, cuando sale una noticia así, la gente del sector se divide en dos: los que dicen «genial, pero eso es cosa de Google y los laboratorios grandes» y los que entienden que estas técnicas acaban filtrándose hacia abajo. Y en este caso, el segundo grupo tiene razón.

TurboQuant ya está publicado como algoritmo open-source y se presentará formalmente en ICLR 2026. Eso significa que en los próximos meses es muy probable que empiece a aparecer en frameworks como llama.cpp, Ollama, o en los runtimes de inferencia que utilizan las plataformas cloud. En la práctica, si dentro de seis meses ejecutas un modelo local o en un VPS propio, es bastante probable que estés beneficiándote indirectamente de este trabajo.

Para las empresas que están evaluando desplegar modelos de IA propios, esta noticia es relevante porque cambia los cálculos de hardware. Un modelo que antes necesitaba, pongamos, 80 GB de VRAM para funcionar en producción, con técnicas como esta puede bajar a un tercio o menos. Eso abre la puerta a hardware más accesible y a despliegues que antes simplemente no eran viables económicamente.

El contexto más amplio: la carrera por la eficiencia

TurboQuant llega en un momento en el que Google está apostando fuerte por la eficiencia. Es la misma semana en la que han presentado Gemini 3 Deep Think, su modelo de razonamiento que bate benchmarks en matemáticas e informática, y Lyria 3 Pro para generación musical. La estrategia parece clara: mientras la competencia sigue en la carrera de los parámetros y la escala bruta, Google está apostando por hacer más con menos.

Eso tiene sentido comercial. Los costes de inferencia son el principal freno para la adopción empresarial de la IA. Una empresa puede estar muy interesada en usar un modelo potente, pero si el coste por petición no cuadra con su modelo de negocio, simplemente no lo va a usar. Bajar ese coste a la mitad no es un detalle técnico menor, es un argumento de ventas directo.

También hay que mencionar que esta técnica aplica no solo a la caché KV sino también a la búsqueda vectorial, que es la tecnología que usa casi cualquier sistema RAG (Retrieval-Augmented Generation) moderno. Es decir, los sistemas que conectan modelos de lenguaje con bases de datos de conocimiento propias también se benefician. Y eso sí que es algo que ya están usando empresas de todos los tamaños.

Lo que no sabemos todavía

Con estas publicaciones de investigación siempre hay que ser cautos. Los números de 6x y 8x son resultados de laboratorio en condiciones controladas. La implementación en sistemas reales, con cargas variables, modelos de diferentes arquitecturas y hardware heterogéneo, casi siempre produce resultados algo más modestos. No sería la primera vez que un paper prometedor queda en mejoras reales del 20-30% en producción, que sigue siendo bueno pero no es lo mismo.

Lo que sí está claro es que la dirección es la correcta y que el enfoque teórico es sólido. PolarQuant ya tiene su propia publicación independiente en AISTATS 2026 y QJL también. No es un paper único que pueda tener errores metodológicos no detectados, hay varios trabajos convergiendo en la misma dirección.

Fuentes

Si gestionas infraestructura donde corres modelos de IA, ya sea en cloud o en servidores propios: ¿cuál es el coste de memoria que más te está limitando ahora mismo, la caché del modelo o el almacenamiento vectorial para RAG?

Salir de la versión móvil