Google publicó TurboQuant el 24 de marzo. En 48 horas el paper tenía 575 puntos en Hacker News, las acciones de Micron caían 900 millones de dólares, y TechCrunch lo comparaba con el algoritmo de Pied Piper de Silicon Valley.
Un mes después, la niebla del hype se ha disipado lo suficiente para responder las únicas preguntas que importan: ¿funciona? ¿Puedo usarlo hoy? Y la que nadie quiere hacer: ¿es realmente nuevo?
Lo que TurboQuant promete (resumen de 30 segundos)
Si ya leíste mi artículo anterior sobre la matemática, sáltate esta sección.
TurboQuant comprime el KV cache de LLMs — la memoria de trabajo que crece con cada token generado — aplicando dos transformaciones:
- Rotación aleatoria del vector (redistribuye los valores uniformemente)
- Conversión a coordenadas polares (los ángulos quedan en rangos predecibles → cuantización sin overhead)
El resultado según Google: compresión 6x del KV cache, speedup 8x en attention logits en H100, sin degradación en benchmarks. Sin reentrenamiento. Sin calibración. Data-oblivious.
Suena demasiado bien. Veamos qué dice la realidad.
El ecosistema real: qué implementaciones existen
En un mes han aparecido al menos diez implementaciones independientes. Las clasifico por madurez:
Tier 1: Funcionales con benchmarks reproducibles
| Proyecto | Lenguaje | Plataforma | Compresión real | Estado |
|---|---|---|---|---|
| turboquant-mlx | Python/Metal | Apple Silicon | 4.7x (3-bit V3) | Benchmarks publicados, M4 Max |
| turboquant-pytorch | Python | CUDA | 5x (K4/V2) | From-scratch, tests vs paper |
| turboquant (0xSero) | Python | CUDA | 3-bit K, 2-bit V | Triton kernels + vLLM |
Tier 2: Funcionales pero sin benchmarks independientes
| Proyecto | Lenguaje | Plataforma | Notas |
|---|---|---|---|
| SwiftLM | Swift | Apple Silicon | Servidor de inferencia nativo, KV cache TurboQuant integrado |
| TurboVec (py-turboquant) | Rust + Python | CPU | Orientado a vector search, no KV cache |
| turboquant_mlx | Python/Metal | Apple Silicon | 1-3 bit, asimétrico |
Tier 3: PRs en proyectos grandes
- llama.cpp: Discussion #20969 — implementación CPU con tests, MSE dentro del 1% del paper
- vLLM: PR en revisión para integración nativa
El dato que importa: la implementación en MLX de sharpner consigue 4.7x de compresión real en M4 Max con 3-bit Lloyd-Max. No 6x como dice Google, pero sí una reducción sustancial. En un contexto de 16K tokens, el KV cache pasa de 4.2 GB a 897 MB.
El hallazgo que nadie esperaba: QJL no sirve
Aquí es donde se pone interesante.
TurboQuant tiene dos fases: PolarQuant (rotación + polares + cuantización) y QJL (corrección de error con Johnson-Lindenstrauss de 1 bit). Google presenta ambas como esenciales.
Pero múltiples implementadores independientes han llegado a la misma conclusión: QJL degrada el rendimiento en la práctica.
El equipo de turboquant-pytorch lo midió con rigor. Su hallazgo: MSE-only (sin QJL) supera consistentemente a MSE+QJL en token matching — la métrica que realmente importa para generación de texto. La diferencia es enorme a bits bajos y todavía visible a 8 bits.
Dicho en cristiano: la segunda mitad de TurboQuant, la que Google presenta como corrección de errores, introduce más errores de los que corrige. El 80% del valor está en PolarQuant solo.
Este tipo de hallazgo — componentes que funcionan en el paper pero no en producción — es exactamente lo que separa la investigación de la ingeniería. Y es lo que hace valiosas las implementaciones independientes.
La controversia RaBitQ: el elefante en la sala
Este es el punto que la cobertura de TechCrunch y los threads de Twitter no mencionan.
El 31 de marzo, el equipo de RaBitQ — un método de cuantización vectorial publicado en mayo de 2024 — acusó formalmente a los autores de TurboQuant de tres cosas:
1. Omisión deliberada de similitud metodológica. Tanto TurboQuant como RaBitQ aplican rotaciones aleatorias (transformadas Johnson-Lindenstrauss) antes de cuantizar. Ese es el truco central de ambos. Pero el paper de Google describe RaBitQ como «grid-based PQ» y omite que usa rotación. El segundo autor de TurboQuant conocía perfectamente RaBitQ — le pidió ayuda para depurarlo en enero de 2025.
2. Tergiversación de resultados teóricos. TurboQuant afirma que las garantías de RaBitQ son «subóptimas, probablemente por análisis poco ajustado». Pero RaBitQ tiene una prueba rigurosa (Teorema 3.2) de que alcanza los límites óptimos asintóticos establecidos por Alon y Klartag (FOCS 2017). Los autores de RaBitQ enviaron las correcciones detalladas por email en mayo de 2025. El segundo autor de TurboQuant confirmó haberlas compartido con todos los coautores. El paper final no corrigió nada.
3. Setup experimental sesgado. TurboQuant comparó RaBitQ usando una traducción degradada en Python, single-core, con multithreading deshabilitado. TurboQuant corrió en A100 GPU. RaBitQ tiene una implementación C++ multithreaded pública. La comparación de velocidad es, dicho diplomáticamente, poco representativa.
El equipo de RaBitQ ha presentado una queja formal ante el comité de ética de ICLR y publicado un comentario en OpenReview. Stanford NLP amplificó la denuncia.
¿Invalida esto TurboQuant? No. PolarQuant funciona — los benchmarks de las implementaciones independientes lo confirman. Pero el paper tiene un problema de integridad académica que Google Research no ha abordado públicamente. Y para una empresa que quiere ser referente en investigación abierta, el silencio es significativo.
Probarlo hoy: tres caminos según tu hardware
Camino 1: Apple Silicon con MLX (recomendado para Mac)
git clone https://github.com/sharpner/turboquant-mlx
cd turboquant-mlx
pip install -r requirements.txt
# Benchmark con Llama 3.2 3B (4-bit weights)
python bench.py --model mlx-community/Llama-3.2-3B-Instruct-4bit \
--kv-bits 3 --method v3 --seq-len 8192
Resultados esperados en M4 Pro (48 GB):
- Compresión KV cache: ~4.6x
- Throughput: ~98% del baseline sin compresión
- Perplexity: prácticamente idéntica a FP16
Camino 2: CUDA con PyTorch
git clone https://github.com/tonbistudio/turboquant-pytorch
cd turboquant-pytorch
pip install -r requirements.txt
# Test de generación con Qwen2.5-3B
python tests/generation_test.py --bits 4 --model Qwen/Qwen2.5-3B-Instruct
Hallazgo clave del equipo: K4/V2 (4 bits para keys, 2 para values) da ~5x de compresión con calidad aceptable. Asimétrico funciona mejor que simétrico porque las keys determinan los patrones de atención.
Camino 3: Servidor de inferencia nativo en Swift
Si quieres un servidor OpenAI-compatible corriendo TurboQuant en Apple Silicon sin Python:
git clone https://github.com/SharpAI/SwiftLM
cd SwiftLM
swift build -c release
# Servir Gemma 4 26B con KV cache comprimido
.build/release/SwiftLM serve --model mlx-community/gemma-4-26b-it-4bit \
--turbo-kv
SwiftLM reporta 85 tok/s con Gemma-4-26B-4bit en M5 Pro. El KV cache TurboQuant permite contextos de 100K tokens que sin compresión no cabrían en memoria.
Lo que NO puedes hacer (todavía)
Aplicar TurboQuant al modelo on-device de Apple. El framework FoundationModels de iOS 26 / macOS 26 gestiona el KV cache internamente a través de LanguageModelSession. No hay API para interceptarlo, comprimirlo ni extenderlo. El modelo de Apple tiene 4K tokens de contexto y TurboQuant no puede cambiarlo — al menos no con las APIs públicas.
Usarlo en producción con vLLM. El PR existe, pero no ha sido mergeado. La integración de Triton kernels de 0xSero funciona pero no tiene el nivel de testing que exige un framework de producción.
Confiar en los benchmarks del paper para vector search. Dado que la comparación con RaBitQ usa un setup sesgado, los números de vector search del paper no son fiables. PolarQuant funciona; los benchmarks comparativos del paper, no tanto.
El patrón más grande: coordinación vs compresión
TurboQuant es un caso de estudio de algo que pasa cada vez más en ML: la técnica funciona, pero la narrativa alrededor es más grande que la técnica.
Lo que realmente funciona es PolarQuant: rotación aleatoria + coordenadas polares. Es elegante, es práctico, y comprime KV cache 4-5x en hardware real. No 6x como dice Google, no 8x como titularon los periódicos, pero sí lo suficiente para extender contextos un 4x en la misma memoria.
Lo que no funciona tan bien: QJL (la corrección de errores) y la narrativa de originalidad total (RaBitQ ya hacía rotaciones aleatorias en 2024).
Y lo que es inaceptable: un paper de Google en ICLR que tergiversa trabajo previo, usa benchmarks sesgados, y después guarda silencio cuando le señalan los errores. Eso no es un error técnico, es un problema institucional.
La próxima vez que un paper de un gran laboratorio prometa 6x de compresión sin coste, haz lo que han hecho los implementadores independientes: coge el código, mide tú mismo, y prepárate para descubrir que la realidad está en algún punto entre lo prometido y lo útil. Que suele ser, de todas formas, un sitio bastante bueno.
Fuentes:
- TurboQuant: Redefining AI Efficiency with Extreme Compression — Google Research Blog
- TurboQuant and RaBitQ: What the Public Story Gets Wrong — Jianyang Gao (autor de RaBitQ)
- TurboQuant paper (ICLR 2026) — OpenReview
- Hacker News discussion (575 points, 166 comments)
Read this article in English.
