O Google publicou o TurboQuant em 24 de março. Em 48 horas o paper tinha 575 pontos no Hacker News, as ações da Micron caíram 900 milhões de dólares, e a TechCrunch o comparava com o algoritmo da Pied Piper de Silicon Valley.
Um mês depois, a névoa do hype se dissipou o suficiente para responder as únicas perguntas que importam: funciona? Posso usar hoje? E a que ninguém quer fazer: é realmente novo?
O que o TurboQuant promete (resumo de 30 segundos)
Se você já leu meu artigo anterior sobre a matemática, pule esta seção.
TurboQuant comprime o KV cache de LLMs — a memória de trabalho que cresce com cada token gerado — aplicando duas transformações:
- Rotação aleatória do vetor (redistribui os valores uniformemente)
- Conversão para coordenadas polares (os ângulos ficam em intervalos previsíveis → quantização sem overhead)
O resultado segundo o Google: compressão 6x do KV cache, speedup 8x em attention logits no H100, sem degradação em benchmarks. Sem retreinamento. Sem calibração. Data-oblivious.
Parece bom demais. Vamos ver o que a realidade diz.
O ecossistema real: quais implementações existem
Em um mês surgiram pelo menos dez implementações independentes. As classifico por maturidade:
Tier 1: Funcionais com benchmarks reproduzíveis
| Projeto | Linguagem | Plataforma | Compressão 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, testes vs paper |
| turboquant (0xSero) | Python | CUDA | 3-bit K, 2-bit V | Kernels Triton + vLLM |
Tier 2: Funcionais mas sem benchmarks independentes
| Projeto | Linguagem | Plataforma | Notas |
|---|---|---|---|
| SwiftLM | Swift | Apple Silicon | Servidor de inferência nativo, KV cache TurboQuant integrado |
| TurboVec (py-turboquant) | Rust + Python | CPU | Orientado a vector search, não KV cache |
| turboquant_mlx | Python/Metal | Apple Silicon | 1-3 bit, assimétrico |
Tier 3: PRs em projetos grandes
- llama.cpp: Discussion #20969 — implementação CPU com testes, MSE dentro de 1% do paper
- vLLM: PR em revisão para integração nativa
O dado que importa: a implementação em MLX do sharpner consegue compressão real de 4.7x no M4 Max com Lloyd-Max de 3-bit. Não 6x como diz o Google, mas sim uma redução substancial. Em um contexto de 16K tokens, o KV cache passa de 4.2 GB para 897 MB.
A descoberta que ninguém esperava: QJL não serve
Aqui é onde fica interessante.
TurboQuant tem duas fases: PolarQuant (rotação + polares + quantização) e QJL (correção de erro com Johnson-Lindenstrauss de 1 bit). O Google apresenta ambas como essenciais.
Mas múltiplos implementadores independentes chegaram à mesma conclusão: QJL degrada o desempenho na prática.
A equipe do turboquant-pytorch mediu com rigor. Sua descoberta: MSE-only (sem QJL) supera consistentemente MSE+QJL em token matching — a métrica que realmente importa para geração de texto. A diferença é enorme em bits baixos e ainda visível em 8 bits.
Em linguagem clara: a segunda metade do TurboQuant, a que o Google apresenta como correção de erros, introduz mais erros do que corrige. 80% do valor está apenas no PolarQuant.
Este tipo de descoberta — componentes que funcionam no paper mas não em produção — é exatamente o que separa a pesquisa da engenharia. E é o que torna valiosas as implementações independentes.
A controvérsia RaBitQ: o elefante na sala
Este é o ponto que a cobertura da TechCrunch e as threads do Twitter não mencionam.
Em 31 de março, a equipe do RaBitQ — um método de quantização vetorial publicado em maio de 2024 — acusou formalmente os autores do TurboQuant de três coisas:
1. Omissão deliberada de similitude metodológica. Tanto TurboQuant quanto RaBitQ aplicam rotações aleatórias (transformadas Johnson-Lindenstrauss) antes de quantizar. Esse é o truque central de ambos. Mas o paper do Google descreve RaBitQ como “grid-based PQ” e omite que usa rotação. O segundo autor do TurboQuant conhecia perfeitamente o RaBitQ — pediu ajuda para debugá-lo em janeiro de 2025.
2. Distorção de resultados teóricos. TurboQuant afirma que as garantias do RaBitQ são “subótimas, provavelmente por análise pouco ajustada”. Mas RaBitQ tem uma prova rigorosa (Teorema 3.2) de que alcança os limites ótimos assintóticos estabelecidos por Alon e Klartag (FOCS 2017). Os autores do RaBitQ enviaram as correções detalhadas por email em maio de 2025. O segundo autor do TurboQuant confirmou tê-las compartilhado com todos os coautores. O paper final não corrigiu nada.
3. Setup experimental tendencioso. TurboQuant comparou RaBitQ usando uma tradução degradada em Python, single-core, com multithreading desabilitado. TurboQuant rodou em GPU A100. RaBitQ tem uma implementação C++ multithreaded pública. A comparação de velocidade é, diplomaticamente falando, pouco representativa.
A equipe do RaBitQ apresentou uma queixa formal ao comitê de ética do ICLR e publicou um comentário no OpenReview. Stanford NLP amplificou a denúncia.
Isso invalida o TurboQuant? Não. PolarQuant funciona — os benchmarks das implementações independentes confirmam. Mas o paper tem um problema de integridade acadêmica que o Google Research não abordou publicamente. E para uma empresa que quer ser referência em pesquisa aberta, o silêncio é significativo.
Testar hoje: três caminhos conforme seu hardware
Caminho 1: Apple Silicon com MLX (recomendado para Mac)
git clone https://github.com/sharpner/turboquant-mlx
cd turboquant-mlx
pip install -r requirements.txt
# Benchmark com 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 no M4 Pro (48 GB):
- Compressão KV cache: ~4.6x
- Throughput: ~98% do baseline sem compressão
- Perplexity: praticamente idêntica ao FP16
Caminho 2: CUDA com PyTorch
git clone https://github.com/tonbistudio/turboquant-pytorch
cd turboquant-pytorch
pip install -r requirements.txt
# Teste de geração com Qwen2.5-3B
python tests/generation_test.py --bits 4 --model Qwen/Qwen2.5-3B-Instruct
Descoberta chave da equipe: K4/V2 (4 bits para keys, 2 para values) dá ~5x de compressão com qualidade aceitável. Assimétrico funciona melhor que simétrico porque as keys determinam os padrões de atenção.
Caminho 3: Servidor de inferência nativo em Swift
Se você quer um servidor compatível com OpenAI rodando TurboQuant no Apple Silicon sem Python:
git clone https://github.com/SharpAI/SwiftLM
cd SwiftLM
swift build -c release
# Servir Gemma 4 26B com KV cache comprimido
.build/release/SwiftLM serve --model mlx-community/gemma-4-26b-it-4bit \
--turbo-kv
SwiftLM reporta 85 tok/s com Gemma-4-26B-4bit no M5 Pro. O KV cache TurboQuant permite contextos de 100K tokens que sem compressão não caberiam na memória.
O que você NÃO pode fazer (ainda)
Aplicar TurboQuant ao modelo on-device da Apple. O framework FoundationModels do iOS 26 / macOS 26 gerencia o KV cache internamente através do LanguageModelSession. Não há API para interceptá-lo, comprimi-lo nem estendê-lo. O modelo da Apple tem contexto de 4K tokens e o TurboQuant não pode mudá-lo — pelo menos não com as APIs públicas.
Usá-lo em produção com vLLM. O PR existe, mas não foi mergeado. A integração dos kernels Triton do 0xSero funciona mas não tem o nível de testes que um framework de produção exige.
Confiar nos benchmarks do paper para vector search. Dado que a comparação com RaBitQ usa um setup tendencioso, os números de vector search do paper não são confiáveis. PolarQuant funciona; os benchmarks comparativos do paper, nem tanto.
O padrão maior: coordenação vs compressão
TurboQuant é um estudo de caso de algo que acontece cada vez mais em ML: a técnica funciona, mas a narrativa ao redor é maior que a técnica.
O que realmente funciona é PolarQuant: rotação aleatória + coordenadas polares. É elegante, é prático, e comprime KV cache 4-5x em hardware real. Não 6x como diz o Google, não 8x como os jornais manchetaram, mas o suficiente para estender contextos 4x na mesma memória.
O que não funciona tão bem: QJL (a correção de erros) e a narrativa de originalidade total (RaBitQ já fazia rotações aleatórias em 2024).
E o que é inaceitável: um paper do Google no ICLR que distorce trabalho anterior, usa benchmarks tendenciosos, e depois fica em silêncio quando apontam os erros. Isso não é um erro técnico, é um problema institucional.
Na próxima vez que um paper de um grande laboratório prometer compressão 6x sem custo, faça o que os implementadores independentes fizeram: pegue o código, meça você mesmo, e prepare-se para descobrir que a realidade está em algum ponto entre o prometido e o útil. Que costuma ser, de qualquer forma, um lugar bastante bom.
Fontes:
- TurboQuant: Redefining AI Efficiency with Extreme Compression — Google Research Blog
- TurboQuant and RaBitQ: What the Public Story Gets Wrong — Jianyang Gao (autor do RaBitQ)
- TurboQuant paper (ICLR 2026) — OpenReview
- Discussão no Hacker News (575 pontos, 166 comentários)
Este artigo foi escrito originalmente em espanhol e traduzido com a ajuda de IA.