Foi uma ideia

O que é o KV Cache

Quando um modelo de linguagem como o Llama 3.1 processa um texto longo, ele precisa lembrar de tudo o que já leu para gerar a próxima palavra. Essa memória se chama KV cache (key-value cache) e cresce proporcionalmente ao tamanho do contexto. Num modelo de 70 bilhões de parâmetros processando 128 mil tokens — equivalente a um livro inteiro — o KV cache sozinho consome cerca de 40 GB de memória VRAM, segundo análise publicada pela Spheron. É o dobro do espaço restante em duas H100 depois de carregar os pesos do modelo. Em resumo: o gargalo não são mais os parâmetros do modelo, é a memória que ele precisa para “lembrar” da conversa.

O TurboQuant em números

O Google Research apresentou o TurboQuant na ICLR 2026, conferência de referência em aprendizado de máquina. Os números chamam atenção:

• 6x de compressão no KV cache em relação ao formato BF16 padrão
• 8x de aceleração na computação de atenção comparado a chaves FP32 não quantizadas
• 3,5 bits por valor — contra os 16 bits do formato original — com perda de precisão praticamente zero
• Sem necessidade de calibração: funciona com qualquer modelo, sem dados de treino adicionais

No benchmark LongBench, a versão de 3,5 bits do TurboQuant marcou 50,06 pontos — praticamente idêntico aos 50,09 do FP16, segundo dados compilados pelo site Nerd Level Tech. No teste Needle in a Haystack, que avalia a capacidade de encontrar uma informação específica num texto enorme, a precisão chegou a 0,997 com compressão de 4x em contextos de até 104 mil tokens.

Como funciona a compressão

A mágica do TurboQuant acontece em duas etapas, descritas em detalhes no blog do Google Research e no paper original (arXiv:2504.19874).

Primeira etapa — PolarQuant: os vetores de dados passam por uma rotação aleatória (transformada de Walsh-Hadamard). Isso não altera o conteúdo matemático, mas redistribui a variância de forma uniforme entre todas as coordenadas. O resultado é que cada coordenada passa a ter uma distribuição parecida com uma normal padrão — muito mais fácil de comprimir com um quantizador escalar simples. Em vez de normalizar os dados (que exige armazenar constantes em alta precisão), o PolarQuant converte para coordenadas polares, eliminando completamente o overhead de memória que aflige métodos tradicionais.

Segunda etapa — QJL (Quantized Johnson-Lindenstrauss): o pequeno erro residual da primeira etapa é corrigido com um truque de 1 bit. O algoritmo usa a transformada de Johnson-Lindenstrauss para comprimir o erro num formato que preserva as distâncias entre vetores, reduzindo cada valor a um único bit de sinal (+1 ou -1). Isso elimina o viés introduzido pela quantização sem custo adicional de memória.

O ponto crucial: tudo isso usa matrizes aleatórias, não aprendidas. Não precisa de dataset de calibração, não precisa de re-treino. Funciona em qualquer modelo, imediatamente.

O impacto prático na sua GPU

A tabela abaixo mostra o antes e depois em cenários reais, calculados com a arquitetura do Llama 3.1 em duas H100 SXM5 (160 GB totais, 140 GB para pesos do modelo de 70B, sobrando 20 GB para o KV cache):

Os dados são da Spheron. A linha de 128K tokens no modelo 70B é onde a diferença é mais dramática: sem compressão, 40 GB de KV cache não cabem nos 20 GB disponíveis — ou seja, sequer é possível servir uma única requisição com esse contexto. Com TurboQuant, os 6,7 GB cabem confortavelmente, abrindo espaço para múltiplas requisições concorrentes.

Para quem roda modelos localmente numa RTX 4090 (24 GB), a conta é igualmente impactante: um modelo de 27B parâmetros que antes comportava contextos curtos agora pode processar 3 a 4 vezes mais tokens na mesma memória, conforme discutido por usuários no r/LocalLLaMA.

Não é compressão de pesos

Uma confusão comum: TurboQuant não comprime os pesos do modelo. Os 140 GB de parâmetros do Llama 70B em FP16 continuam existindo. O que muda é exclusivamente o KV cache gerado durante a inferência. Isso significa que o TurboQuant é complementar a métodos como AWQ e GPTQ — que comprimem pesos. Você pode aplicar AWQ para reduzir o tamanho do modelo e depois TurboQuant para comprimir o cache em tempo de execução. São pools de memória diferentes, atacadas por técnicas diferentes.

O InfoQ destaca que essa distinção é fundamental para entender onde o TurboQuant brilha: cenários de contexto longo (documentos grandes, bases de código inteiras, vídeos) e servidores com alta concorrência de requisições. Para inferência de contexto curto, o ganho é marginal.

Implementações open source

A comunidade não esperou. Menos de dois meses após o paper, já existem múltiplas implementações:

• TurboQuant para llama.cpp — integração direta no engine de inferência mais popular do ecossistema open source, com redução de 5,2x na memória e qualidade quase sem perdas. O repositório já conta com 82 estrelas e fork ativo do llama.cpp.
• TurboQuant com vLLM — kernels Triton otimizados para produção, integrados ao framework vLLM usado por empresas para servir modelos em escala.
• Implementação PyTorch pura — foco educacional e em pesquisa, com documentação detalhada do processo de quantização.

Todas as três são independentes e open source. O fato de a comunidade ter produzido implementações tão rapidamente — e em frameworks tão diferentes — é um sinal de que a demanda por essa otimização é real.

Por que importa agora

O custo de servir modelos de linguagem em escala é dominado por memória GPU, não por computação. A AWS cobra cerca de US$ 30 mil por mês por instância com 8 H100s. Cada GB de VRAM economizado é dinheiro direto no bolso de quem opera esses sistemas em produção. Mas o impacto vai além do custo.

A compressão eficiente do KV cache remove uma barreira técnica que impedia cenários práticos importantes: análise de documentos longos (contratos, relatórios financeiros), processamento de bases de código inteiras, e chatbots que precisam lembrar de conversas extensas. Sem compressão, essas aplicações ou eram inviáveis em hardware acessível, ou exigiam arquiteturas complexas de RAG como workaround.

O Two Minute Papers, canal de divulgação científica que analisou o paper, faz um alerta importante: os números de 6x são obtidos em condições ideais de laboratório. No mundo real, a redução prática tende a ficar entre 30% e 40% em memória total do sistema — porque os pesos do modelo continuam intocados. Mas mesmo esses ganhos mais modestos são significativos quando multiplicados por milhares de servidores.

O sinal mais relevante é metodológico. O TurboQuant mostra que ainda há muito ganho de eficiência a ser extraído sem aumentar o tamanho dos modelos. Num momento em que a indústria debate se o scaling — simplesmente fazer modelos maiores — está atingindo um platô, técnicas de compressão teoricamente fundamentadas como esta sugerem um caminho alternativo: fazer mais com a mesma infraestrutura.

Perguntas frequentes

TurboQuant comprime o modelo inteiro?

Não. Ele comprime exclusivamente o KV cache gerado durante a inferência. Os pesos do modelo permanecem inalterados. Se você precisa reduzir o tamanho do modelo em si, deve combinar TurboQuant com métodos como AWQ ou GPTQ — são complementares, não concorrentes.

Funciona com qualquer modelo?

Sim. Como o método usa matrizes aleatórias (não aprendidas), não requer calibração nem dados de treino. Funciona imediatamente com qualquer modelo baseado em transformer, seja Llama, Gemma, Mistral ou outros.

Quanto ganho real posso esperar?

Os 6x de compressão são medidos no KV cache isoladamente. O ganho total de memória do sistema depende da proporção entre pesos e cache. Para contextos longos (128K+ tokens), onde o cache domina, o ganho é substancial. Para contextos curtos, o impacto é marginal. O Two Minute Papers estima redução real de 30% a 40% na memória total do sistema.

Referências

• TurboQuant: Redefining AI efficiency with extreme compression — Google Research Blog, março de 2026
• TurboQuant: Accurate KV Cache Quantization with Rotation and Outlier-Free Quantization — arXiv:2504.19874, ICLR 2026
• Google’s TurboQuant Compression May Support Faster Inference — InfoQ, abril de 2026
• Google TurboQuant: 6x KV Cache Compression for LLM Inference — Spheron Blog
• TurboQuant KV Cache Compression for llama.cpp — GitHub
• Discussão no r/LocalLLaMA — Reddit
• Google’s TurboQuant: 6x Less Memory for LLM Inference — Nerd Level Tech