Multiplicar es difícil. Sumar es fácil.
Eso lo sabe cualquier chaval de primaria. Lo que no sabe es que los logaritmos existen precisamente para explotar esa asimetría: conviertes una multiplicación en una suma, operas en el mundo sencillo, y luego deshaces la transformación. El resultado es correcto. El esfuerzo, una fracción.
Este patrón — transformar el problema a un espacio donde resolverlo es trivial, resolver, y volver — es uno de los más poderosos de toda la ingeniería. La FFT lo hace con señales. Los logaritmos lo hacen con productos. Y ahora Google acaba de publicar un paper que lo hace con la compresión de modelos de lenguaje.
Se llama TurboQuant, y la idea es tan elegante que merece un artículo.
El problema: comprimir sin destrozar
Los LLMs modernos tienen un cuello de botella que no es el modelo en sí, sino su memoria de trabajo. Cada vez que un modelo genera texto, mantiene en memoria unas estructuras llamadas key-value cache (KV cache) — básicamente, el «contexto» que el modelo necesita recordar para generar la siguiente palabra.
En un modelo grande con contexto largo, el KV cache puede ocupar decenas de gigabytes de VRAM. Eso es un problema serio: la VRAM de una GPU es cara, finita, y compartida con todo lo demás.
La solución obvia es cuantizar: reducir la precisión de cada número. En vez de guardar cada valor en 32 bits (float32), lo guardas en 4 bits o incluso 3. Pasas de un rango continuo a una escala discreta con pocos peldaños. Funciona razonablemente bien.
Hasta que te topas con la trampa.
La trampa de las constantes de normalización
Para cuantizar un bloque de números, necesitas saber su rango: el mínimo y el máximo. Esos valores se llaman constantes de normalización, y tienes que guardarlos a precisión completa (16 bits) para poder reconstruir los valores originales.
Aquí está la ñapa: si cuantizas a 3 bits por número pero necesitas guardar una constante de 16 bits cada, digamos, 8 números, esas constantes ocupan 2 bits extra por número. Tu compresión «a 3 bits» en realidad ocupa 5 bits efectivos. Has perdido casi la mitad de la ganancia.
Es como hacer una mudanza a un piso más pequeño y descubrir que las cajas de la mudanza ocupan la mitad del piso nuevo.
Y no puedes simplemente hacer los bloques más grandes para amortizar las constantes, porque bloques más grandes significan peor aproximación — el rango se amplía y pierdes precisión. Estás atrapado entre dos fuerzas opuestas.
Este problema lleva años abierto. Todo el mundo ha intentado resolverlo inventando mejores compresores. Bloques adaptativos, cuantización no uniforme, esquemas mixtos. Más complejidad, más parámetros, resultados marginales.
Google hizo algo diferente. No inventó un compresor mejor. Cambió de coordenadas.
El cambio de coordenadas: de cartesianas a polares
La idea central de TurboQuant es aplicar una rotación aleatoria al vector antes de cuantizarlo, y luego convertir el resultado a coordenadas polares.
Vamos por partes.
Paso 1: Rotar aleatoriamente
Imagina que tienes un vector en un espacio de alta dimensión. Sus componentes están distribuidas de forma irregular — algunas dimensiones tienen valores enormes, otras son casi cero. Ese desequilibrio es exactamente lo que hace que necesites constantes de normalización por bloque: cada bloque tiene un rango diferente.
¿Qué pasa si multiplicas el vector por una matriz de rotación aleatoria? Geométricamente, estás girando el vector a una orientación arbitraria. El vector sigue siendo el mismo (misma longitud, misma relación con otros vectores), pero sus componentes se redistribuyen.
Y aquí entra un resultado de matemáticas que parece magia: en espacios de alta dimensión, una rotación aleatoria hace que las componentes del vector se vuelvan casi uniformes. Es un fenómeno llamado concentración de medida — en dimensiones altas, casi toda la masa de una distribución se concentra cerca de su media. Rota aleatoriamente y todo se aplana.
En román paladino: la rotación destruye los picos y los valles. Después de rotar, todos los bloques tienen rangos parecidos. Y si todos los bloques tienen rangos parecidos… no necesitas guardar el rango de cada uno.
Paso 2: Convertir a coordenadas polares
Después de la rotación, TurboQuant convierte los vectores de coordenadas cartesianas (x, y, z…) a coordenadas polares (un radio y un montón de ángulos).
¿Por qué? Porque la rotación aleatoria ha hecho que los ángulos sean altamente predecibles — están concentrados en rangos estrechos y conocidos de antemano. Los límites de cuantización son fijos. No dependen de los datos.
Eso significa: cero constantes de normalización para los ángulos. El overhead que se comía 1-2 bits por número desaparece. Solo necesitas guardar el radio (un número por vector) y los ángulos cuantizados con límites fijos.
flowchart LR
subgraph antes[" Cuantización clásica "]
direction LR
V1[" Vector original "] --> B1[" Dividir en bloques "]
B1 --> N1[" Calcular min/max <br/>por bloque "]
N1 --> Q1[" Cuantizar <br/>3 bits + 2 bits overhead "]
end
subgraph despues[" TurboQuant "]
direction LR
V2[" Vector original "] --> R2[" Rotación <br/>aleatoria "]
R2 --> P2[" Coordenadas <br/>polares "]
P2 --> Q2[" Cuantizar <br/>3 bits, overhead ≈ 0 "]
end
antes ~~~ despues
La gracia es que la rotación es invertible. Para recuperar el vector original, descuantizas, vuelves a cartesianas y aplicas la rotación inversa. El resultado es una compresión 6x del KV cache sin pérdida de precisión medible.
Por qué funciona: añadir aleatoriedad reduce incertidumbre
Esto es lo más contraintuitivo del paper. Añadir ruido (la rotación aleatoria) reduce la incertidumbre. Parece una contradicción, pero tiene una explicación elegante.
Sin la rotación, cada vector tiene su propia distribución interna. Unas dimensiones dominan, otras son ruido. No sabes de antemano qué rango tendrá cada bloque. Esa incertidumbre te obliga a medir y almacenar los rangos.
Con la rotación, fuerzas a todos los vectores a tener la misma distribución estadística (concentración de medida en acción). Ya no necesitas medir nada porque sabes de antemano cómo van a estar distribuidos los valores. La aleatoriedad destruye la información específica de cada vector (que no te servía para nada) y la reemplaza por una regularidad predecible (que te sirve para todo).
Es como barajar una baraja de cartas. Antes de barajar, no sabes en qué orden están — necesitas mirar cada carta. Después de barajar bien, sabes exactamente en qué orden están: en un orden aleatorio uniforme. Paradójicamente, sabes más sobre el sistema barajado que sobre el ordenado si lo que necesitas es predecir propiedades estadísticas.
TurboQuant en números
Google evaluó TurboQuant en varios benchmarks con modelos Gemma y Mistral. Los resultados:
| Métrica | Valor |
|---|---|
| Compresión del KV cache | 6x (de 32 bits a ~5 bits efectivos con 3 bits de cuantización) |
| Speedup en atención (H100) | hasta 8x en cómputo de attention logits |
| Precisión | Sin degradación medible en LongBench, RULER, ZeroSCROLLS |
| Requiere entrenamiento | No — funciona sin fine-tuning ni calibración |
| Dependencia de datos | Ninguna — data-oblivious |
Ese último punto es clave. La mayoría de técnicas de cuantización necesitan un dataset de calibración para ajustar los parámetros. TurboQuant no necesita nada. La rotación aleatoria funciona igual de bien con cualquier dato porque la concentración de medida es una propiedad del espacio, no del contenido.
El patrón que todo programador debería reconocer
TurboQuant es un caso particular de un patrón mucho más amplio que merece un nombre: transforma y vencerás.
La idea: cuando un problema te resiste, pregúntate si estás trabajando en el espacio correcto. A veces la solución no es un algoritmo más listo, sino una representación diferente del mismo problema.
Ejemplos que ya conoces:
| Problema | Espacio original | Transformación | Espacio fácil |
|---|---|---|---|
| Multiplicar números grandes | Aritmética | Logaritmos | Sumas |
| Filtrar señales | Tiempo | FFT | Frecuencia |
| Resolver ecuaciones diferenciales | Tiempo | Laplace | Álgebra |
| Comprimir KV cache | Cartesianas | Rotación + polares | Ángulos uniformes |
| Encontrar patrones en texto | Caracteres | Regex → autómata | Transiciones de estado |
En todos los casos, la dificultad no estaba en el problema sino en la representación. Cambias de coordenadas y lo que era intratable se vuelve trivial.
Lo que puedes aplicar hoy
No necesitas estar comprimiendo LLMs para usar este patrón. La próxima vez que te encuentres peleando con un problema que «debería ser fácil pero no lo es», hazte estas preguntas:
1. ¿Estoy en el espacio correcto? Si comparar dos cosas es difícil, quizá necesitas normalizar antes de comparar. Si buscar algo es lento, quizá necesitas un índice (que no es más que una representación alternativa optimizada para búsqueda).
2. ¿Hay una transformación conocida para mi dominio? La FFT existe desde 1965. Las transformadas wavelet, desde los 80. Los embeddings vectoriales, desde 2013. Muchos problemas «difíciles» ya tienen transformaciones estándar que los resuelven. Antes de inventar algo, busca si alguien ya encontró las coordenadas correctas.
3. ¿Puedo añadir aleatoriedad para simplificar? Hashing, random projections, sketches probabilísticos — todos funcionan porque añadir aleatoriedad controlada destruye complejidad innecesaria. Si tu problema tiene estructura irregular que te complica la vida, a veces la mejor estrategia es destruir esa estructura a propósito.
La próxima vez que fuerces una solución
La lección de TurboQuant no es sobre compresión de modelos. Es sobre resistir la tentación de inventar un compresor mejor cuando lo que necesitas es cambiar de perspectiva.
Durante años, la comunidad de ML intentó resolver el overhead de las constantes de normalización con esquemas de cuantización más sofisticados. Más bloques, más niveles, más heurísticas. Todo dentro del mismo marco de coordenadas cartesianas. Y todo con mejoras incrementales.
Google no hizo nada de eso. Rotó los datos, cambió de coordenadas, y el problema desapareció. No lo resolvieron. Lo disolvieron.
La próxima vez que lleves dos horas dándole leña al mono con una solución que no termina de encajar, para un momento y pregúntate: ¿estoy peleando con el problema o con la representación? Porque si estás en las coordenadas equivocadas, el mejor algoritmo del mundo no te va a salvar.
Fuente: TurboQuant: Redefining AI Efficiency with Extreme Compression — Google Research Blog.
Read this article in English.
