TurboQuant: Google comprime KV cache para 3 bits sem perder acurácia — e a comunidade já tem implementação rodando

TurboQuant: Google comprime KV cache para 3 bits sem perder acurácia — e a comunidade já tem implementação rodando

Toda semana aparece um paper novo prometendo revolucionar inference de LLMs. A maioria some em duas semanas. Mas quando o Google Research publica um método que comprime KV cache para 3 bits por valor com zero perda de acurácia, e a comunidade já tem implementação funcional antes mesmo do código oficial sair — aí vale parar e olhar com calma.

O paper é o TurboQuant: Online Vector Quantization for Quantized KV Cache in Large Language Models, anunciado em 25 de março e aceito na ICLR 2026 — que acontece em abril, aqui no Rio de Janeiro. Os números: 6x de redução no KV cache e até 8x de speedup no cálculo de attention logits em NVIDIA H100 a 4 bits.

A TechCrunch chamou de “Pied Piper da compressão de IA”. O chip stocks tremeram. Mas o que importa para quem coloca modelo em produção são os detalhes técnicos.

O problema: KV cache come sua VRAM no almoço

Se você já fez serving de LLM com contextos longos, sabe: o gargalo não é o forward pass do modelo em si — é o KV cache. Para cada token gerado, o modelo armazena os vetores de Key e Value de todas as camadas de atenção. Com modelos de 70B+ e contextos de 128K tokens, o KV cache sozinho pode consumir mais VRAM do que os pesos do modelo.

A conta é simples. Um modelo com 80 camadas, 128 heads, dimensão 128, em FP16, com contexto de 128K tokens:

KV cache = 2 × 80 × 128 × 128 × 128K × 2 bytes = ~42 GB

Quarenta e dois gigabytes. Só de cache. Isso é mais que uma A100 40GB inteira. Qualquer compressão significativa aqui tem impacto direto em throughput, batch size e custo por token.

Como o TurboQuant funciona

O TurboQuant é training-free e data-oblivious — não precisa de calibração com dados nem de retreino do modelo. Isso já é um diferencial enorme em relação a métodos como KIVI ou KVQuant, que exigem datasets de calibração.

A técnica opera em duas etapas:

1. PolarQuant

Antes de quantizar, o algoritmo aplica uma rotação aleatória nos vetores de dados. Parece contra-intuitivo, mas a ideia é brilhante: a rotação simplifica a geometria da distribuição dos vetores, tornando-os mais “uniformes” em cada sub-espaço. Depois da rotação, um quantizador padrão por sub-vetor funciona muito melhor do que aplicado diretamente nos dados originais.

Na prática, é uma multiplicação por uma matriz ortogonal aleatória — O(d) por vetor. O overhead é mínimo comparado ao custo da atenção.

2. QJL Residual

A quantização sempre introduz um viés. O truque do TurboQuant é usar 1 bit de compressão residual baseado em Johnson-Lindenstrauss para eliminar esse viés via error-checking. Com apenas 1 bit extra por valor, o erro sistemático da quantização é corrigido.

O resultado opera dentro de um fator de √(3π/2) ≈ 2.7x do limite teórico de Shannon. Em termos de teoria da informação, é difícil fazer muito melhor que isso.

Os números que importam

ConfiguraçãoMemória KV cacheSpeedup em attention (H100)Perda de acurácia
FP32 (baseline)1x1x—
FP160.5x~2xnenhuma
TurboQuant 4-bit~0.125xaté 8xnenhuma
TurboQuant 3-bit~0.09x (6x redução)~5-6xzero

Leu certo: 3 bits por valor, 6x menos memória, sem perda mensurável de acurácia. Na minha experiência com quantização, isso é excepcional. A maioria dos métodos a 4 bits já começa a mostrar degradação em tasks de raciocínio longo.

E o TurboQuant também funciona para vector search — testado no benchmark GloVe, com recall superior a métodos que dependem de codebooks grandes. Infraestrutura de busca vetorial pode se beneficiar da mesma técnica.

Hands-on: o que já dá para rodar hoje

O Google não liberou código oficial ainda (esperado para Q2 2026). Mas o ecossistema open-source não espera — e isso diz muito sobre a saúde da comunidade.

PyTorch from-scratch

O repositório tonbistudio/turboquant-pytorch traz uma implementação limpa da ICLR 2026. Segundo o README: 5x de compressão a 3 bits com 99.5% de attention fidelity.

git clone https://github.com/tonbistudio/turboquant-pytorch.git
cd turboquant-pytorch
pip install -r requirements.txt
python demo.py --model meta-llama/Llama-3-8B --bits 3

llama.cpp

A thread mais interessante está no ggml-org/llama.cpp/discussions/20969. A comunidade está discutindo integração, e já existe uma implementação funcional em C no fork ikawrakow/ik_llama.cpp — rodando em CPU. Para quem faz inference local, isso é relevante: TurboQuant no KV cache + modelo GGUF quantizado = contextos muito mais longos na mesma RAM.

Triton kernel custom

Alguém já testou um kernel Triton custom com Gemma 3 4B numa RTX 4090. O resultado: output character-identical ao modelo não-quantizado — a 2 bits de precisão. Dois bits. Isso é território que eu achava impossível sem degradação visível.

Limitações e trade-offs

Preciso ser honesto sobre o que o TurboQuant não resolve:

  • Só comprime KV cache: os pesos do modelo continuam no mesmo tamanho. Se sua VRAM está apertada por causa do modelo em si (não do cache), TurboQuant não ajuda. É complementar a GPTQ/AWQ/GGUF, não substituto.
  • Sem código oficial do Google: as implementações da comunidade são baseadas no paper. Pode haver diferenças de performance vs. a implementação original quando sair.
  • Overhead de rotação: a multiplicação pela matriz ortogonal no PolarQuant tem custo. Para contextos curtos (< 2K tokens), o overhead pode não compensar a economia. O ganho escala com o tamanho do contexto.
  • Compatibilidade com arquiteturas: testado primariamente em modelos com Multi-Head Attention padrão. GQA (Grouped Query Attention) e MQA (Multi-Query Attention) podem precisar de adaptações — ainda não está claro nos benchmarks do paper.
  • Não é plug-and-play (ainda): integrar no seu pipeline de serving atual (vLLM, TGI, SGLang) vai exigir trabalho. Nenhum framework major integrou TurboQuant nativamente até agora.

Por que isso importa de verdade

Eu gosto de separar papers que são “legal, mas e daí?” de papers que mudam o que dá para fazer na prática. TurboQuant é do segundo tipo.

Com 6x menos KV cache, um modelo de 70B com contexto de 128K que precisava de 2x A100 80GB para o cache agora cabe numa única GPU. Isso muda o cálculo de custo de serving para todo mundo que roda LLMs em produção. Mais batch size, mais contexto, menos máquinas.

E o fato de que a ICLR 2026 acontece no Rio de Janeiro (23-25 de abril) torna isso especialmente relevante para a comunidade brasileira. Se você vai estar lá, o paper é de leitura obrigatória.

Veredito

TurboQuant é o tipo de breakthrough “chato” que realmente importa. Não é um modelo novo com nome bonito — é infraestrutura. Compressão training-free, data-oblivious, que opera perto do limite teórico e já tem implementações da comunidade funcionando antes do Google soltar o código oficial.

Se você faz serving de LLMs e KV cache é seu gargalo (spoiler: provavelmente é), acompanhe o paper e as implementações. Quando a integração com vLLM ou llama.cpp chegar de forma nativa, a adoção vai ser imediata.

Paper: arXiv:2504.19874. Blog do Google: research.google/blog/turboquant-redefining-ai-efficiency-with-extreme-compression. Implementação PyTorch: tonbistudio/turboquant-pytorch. Vai lá, lê o paper, roda o demo. Depois me conta se o output realmente bate.