TurboQuant: a leitura do avanço na compressão da KV cache

Tempo de leitura: 10 min | Como a compressão de 3 bits da Google torna mais baratos os LLM de contexto longo, e o que isso nos diz sobre os próximos 18 meses da inferência de IA

Há um problema silencioso dentro de todas as conversas longas que tem com um grande modelo de linguagem, e é a razão pela qual essas conversas se tornam caras. Chama-se cache KV e, com contextos longos, pode consumir mais memória do que o próprio modelo. A 24 de março, uma equipa da Google Research publicou o TurboQuant, que comprime essa cache para três bits por valor, sem perda de exatidão mensurável e sem afinação fina. Seis vezes menos memória. Atenção até oito vezes mais rápida numa H100. Vale a pena perceber isto como deve ser, porque a compressão da cache KV é um dos problemas com maior alavancagem na IA em produção neste momento, e o TurboQuant é o sinal público mais claro até hoje de que a área virou a esquina.

Eu dirijo a Kentino. Parte do que isso implica é ler com atenção artigos como este, para que os nossos clientes — mineradores, construtores, europeus curiosos que acompanham a stack de IA e cripto — não tenham de o fazer. Este texto é a minha tentativa de explicar o que o TurboQuant faz de facto, como se encaixa na vaga mais ampla de investigação em compressão de cache KV de 2025-2026 e o que uma pessoa sensata deve esperar dos próximos dezoito meses.

O problema da cache KV, dito com honestidade

Quando um transformer gera texto, cada novo token atende a todos os tokens anteriores. Para evitar recalcular os tensores de chave e valor desses tokens anteriores a cada passo, o modelo guarda-os. Esse armazenamento é a cache KV.

A cache cresce linearmente com o comprimento do contexto. Duplique a conversa e duplica a cache. Para um modelo médio de 8B a correr um contexto de 128k tokens em FP16, a cache KV pode facilmente chegar a dezenas de gigabytes numa única sessão. Os pesos talvez sejam dezasseis. A cache é muito maior.

Daqui decorrem três consequências práticas.

Primeira: a inferência de contexto longo é limitada pela memória antes de ser limitada pela computação. Fica sem VRAM muito antes de ficar sem FLOPs.

Segunda: o custo de servir escala mal. Cada utilizador em simultâneo precisa da sua própria cache. Uma GPU que poderia agrupar cinquenta conversas curtas talvez aguente cinco longas.

Terceira: a inferência no dispositivo e no edge continua fora de alcance para os modelos que aí seriam realmente úteis, porque o que se recusa a caber é a cache, e não os pesos.

Comprimir bem a cache KV — ou seja, de forma agressiva, barata e sem prejudicar a qualidade da saída — não é, portanto, uma otimização menor. Muda quais são as cargas de trabalho viáveis e quais não são. É esse o problema que o TurboQuant aborda.

O que o TurboQuant faz de facto

O TurboQuant é um algoritmo em duas fases. Ambas as fases dispensam treino e são alheias aos dados, o que significa: sem afinação fina, sem conjunto de dados de calibração, sem ajustes por modelo. Aplica-se e funciona. Honestamente, isso importa mais do que o rácio de compressão, porque é o que permite encaixar o método numa stack de inferência existente sem atritos.

Fase um: PolarQuant

A primeira fase é o PolarQuant, um artigo separado do mesmo grupo (Zandieh, Mirrokni et al., AISTATS 2026). A ideia é estrutural, e não estatística.

Quantizar vetores de dimensão elevada em coordenadas cartesianas é incómodo. O movimento natural — normalizar para a esfera unitária e depois quantizar a direção — acaba por sair caro, porque calcular a norma de cada vetor é precisamente o estrangulamento de que se queria fugir. Os métodos anteriores pagavam esse custo e ainda assim perdiam exatidão com poucos bits.

O PolarQuant faz duas coisas para evitar a armadilha. Aplica primeiro uma rotação aleatória, o que, de forma algo contraintuitiva, torna a geometria da distribuição dos vetores mais previsível e tratável. Depois converte para coordenadas polares — um raio para a magnitude, um ângulo para a direção — e mapeia-as numa grelha circular que pode ser quantizada sem o passo de normalização. O resultado é uma representação limpa e de poucos bits de cada vetor, que preserva a sua geometria essencial.

Fase dois: QJL

O PolarQuant sozinho deixa erro residual. A segunda fase, Quantized Johnson-Lindenstrauss (QJL), corrige-o com mais um bit por valor.

A transformada de Johnson-Lindenstrauss é um resultado clássico: é possível projetar vetores de dimensão elevada num espaço de dimensão muito menor com um mapa linear aleatório, preservando aproximadamente as distâncias entre pares. O QJL vai mais longe e guarda apenas o bit de sinal de cada coordenada projetada — mais um, menos um, nada mais. Sem qualquer sobrecarga de armazenamento para além do próprio bit.

O que o QJL entrega, matematicamente, é um estimador não enviesado das pontuações de atenção. Corrige o resíduo do PolarQuant sem reintroduzir o enviesamento de que sofrem os esquemas ingénuos de poucos bits. É esse o truque. Um bit de sinal, bem escolhido, basta para limpar o erro da primeira fase.

Os números

Combinadas, as duas fases ficam em três bits por valor, seis vezes menos do que a base em FP16. Numa NVIDIA H100, o cálculo dos logits de atenção corre até oito vezes mais depressa a 4 bits face a 32 bits. A Google testou Gemma, Mistral e Llama-3.1-8B-Instruct em LongBench, Needle In A Haystack, ZeroSCROLLS, RULER e L-Eval. A exatidão manteve-se nos cinco benchmarks de contexto longo. Um teste adicional de pesquisa vetorial em GloVe-200 mostrou também melhor recall 1@k face às bases PQ e RabbiQ, o que sugere que o método generaliza para além das caches KV propriamente ditas.

O texto completo está no blogue da Google Research. O TurboQuant será apresentado na ICLR 2026, no Rio de Janeiro.

A vaga mais ampla

O TurboQuant não está sozinho. É a entrada recente mais destacada numa área de investigação em rápido movimento, e lê-lo sem contexto exagera a sua novidade. Vários outros métodos do final de 2025 e do início de 2026 atacam o mesmo estrangulamento a partir de ângulos diferentes.

Cada um visa um nicho diferente. O KVTC é para reutilização offline — guardar a cache de uma conversa e carregá-la noutra, onde se pode suportar uma codificação mais pesada em troca de uma compressão muito maior. O ChunkKV serve os casos em que é preciso comprimir de forma agressiva mas preservar o sentido semântico, o que importa em tarefas onde perder um token custa mais do que perder um dígito de precisão. O PM-KVQ está afinado para as cargas de longas cadeias de raciocínio que os modelos de raciocínio produzem. O KVPress é a canalização que permite aos restantes compararem tudo isto com honestidade.

O contributo distintivo do TurboQuant é a combinação entre funcionamento sem treino, adequação a inferência online e um estimador comprovadamente não enviesado. É o que tem maior probabilidade de chegar primeiro às frameworks de produção, precisamente porque não exige nada de quem opera o modelo.

O que isto desbloqueia

Afastando-nos do artigo e pensando no que daqui decorre: os efeitos práticos são mais fáceis de nomear do que de dimensionar.

A inferência de contexto longo fica materialmente mais barata. Se a sua cache KV for seis vezes menor, pode agrupar mais utilizadores na mesma GPU, ou servir contextos mais longos com o mesmo orçamento, ou ambos. Quem opera um serviço de inferência sente isto nas margens no trimestre seguinte à integração.

A implementação no edge torna-se viável para classes de modelos que antes estavam fora de alcance. Um modelo de 8B com contexto longo numa GPU de estação de trabalho, ou um modelo de 3B num portátil, passa de "quase impossível" a "rotina" quando a cache encolhe neste fator. A implementação on-premise para empresas que não podem enviar dados para APIs na cloud — jurídico, área médica, telemetria industrial — ganha o mesmo impulso.

A história do hardware decorre diretamente daqui, e é aqui que deixa de ser abstrato. Uma compressão como a do TurboQuant não muda que GPU existem; muda que cargas de trabalho cabem — e, neste momento, as cargas que as pessoas realmente querem correr on-premise são os modelos chineses de pesos abertos que, discretamente, assumiram o lugar de SOTA ao longo do primeiro trimestre de 2026.

Vale a pena nomear explicitamente o elenco atual, porque é sobre isto que os clientes nos perguntam. Kimi K2.5, da Moonshot AI — 1T de parâmetros totais, 32B ativos, MoE, 256K de contexto, licença MIT — lançado a 27 de janeiro, lidera os benchmarks de código e de matemática entre os pesos abertos. GLM-5, da Z.ai — 744B totais / 40B ativos, 204K de contexto, licença MIT — atualmente no topo do Intelligence Index de pesos abertos e do SWE-bench Verified. MiniMax M2.5 — 229B totais / 10B ativos, 200K de contexto — lançado a 12 de fevereiro, com preço agressivo, mais de 80% no SWE-bench. Qwen3-Coder-Next, da Alibaba — 80B totais / 3B ativos, 256K de contexto nativo, extensível até 1M com YaRN — além da restante família Qwen3, de densos 0.8B–27B até ao MoE 397B-A17B. Todos de pesos abertos. Todos disponíveis hoje.

Na Kentino construímos máquinas especificamente para esta carga de trabalho, por isso deixe-me ser concreto quanto às contas. O nosso servidor de inferência de topo é uma configuração 4× NVIDIA RTX 4090 — 96 GB de VRAM agregada, AMD EPYC 7542 numa ASRock Rack ROMED8-2T, 256 GB de DDR4-2666 ECC RDIMM, 2 TB NVMe, duas fontes 2 kW PSUs, num rack 24U. Acima dela construímos configurações 4× RTX 5090 e 8× RTX 5090 (128 GB e 256 GB de VRAM agregada) e configurações de classe centro de dados 4× L40 / L40S (192 GB agregados ECC) para carga sustentada de classe empresarial e serviço em produção 24/7.

O que o TurboQuant muda neste quadro é o termo da cache KV. Os modelos MoE modernos já usam atenção comprimida (atenção latente ao estilo MLA no Kimi, GQA no Qwen3), pelo que a sua cache KV por token já parte de valores menores do que os antigos da classe Llama. Aplique o TurboQuant por cima e obtém mais ~6×. O efeito prático é que a janela de contexto que uma dada máquina consegue de facto servir — por oposição a anunciar — sobe de forma significativa. Os pesos não mudaram. O estrangulamento mudou.

Duas ressalvas honestas. Primeira: Kimi K2.5 e GLM-5 em FP8 completo (1T e 744B totais de pesos, respetivamente) continuam a exceder o que estas máquinas comportam — para esses, falamos de um cluster ou de aceitar uma quantização INT4 agressiva. Segunda: os limites exatos de tokens dependem do tamanho do lote, da configuração de atenção específica do modelo e da framework (vLLM, SGLang e TensorRT-LLM implementam KV de poucos bits de maneiras diferentes). Mas o que importa é a direção: uma máquina 4× RTX 4090 que há um ano fazia sentido para modelos densos de 13B é hoje a resposta certa para o Qwen3-Coder-Next com os seus 256K de contexto completos. Uma 4× RTX 5090 aguenta com conforto o modelo de código da classe 80B ativos, com margem para utilizadores em simultâneo. Uma 8× RTX 5090 ou uma 4× L40S abre a porta ao MiniMax M2.5 e às variantes maiores de MoE Qwen3 à escala de produção. O hardware não ficou maior; a carga de trabalho ficou menor.

E qualquer carga de inferência que corra continuamente sobre telemetria operacional beneficia na mesma proporção. A otimização de frotas de mineração é um exemplo real: operadores como a OneMiners correm sistemas de eficiência assentes em IA em milhares de ASIC, e a camada de inferência por baixo desses sistemas escala diretamente com a quantidade de contexto que cada modelo consegue manter de forma barata. Esta classe de investigação não transforma essas cargas de um dia para o outro, mas desloca a curva daquilo que é comportável.

A previsão honesta é incremental. Uma redução de memória de 6× num estrangulamento não produz um mundo novo. Produz uma versão ligeiramente mais barata, ligeiramente mais longa em contexto e ligeiramente mais implementável do mundo que já temos. Ainda assim, é muito dinheiro e muita engenharia poupados, somados à escala da indústria.

O que observar em 2026-2027

Algumas coisas específicas, por ordem aproximada de probabilidade.

Integração nas frameworks. O vLLM, o TensorRT-LLM e o SGLang vão adotar métodos ao estilo TurboQuant dentro de meses, provavelmente através do KVPress como camada de benchmarking. A implementação open-source em Triton que a equipa da Google publicou torna isto quase mecânico.

Suporte ao nível do hardware. A NVIDIA já sinalizou interesse em primitivas de atenção de poucos bits, através do KVTC e do KVPress. É de esperar que as ferramentas da geração Blackwell tratem os formatos KV de 3-4 bits como cidadãos de pleno direito, e não como experiências.

Consolidação dos métodos. As cinco abordagens acima resolvem problemas que se sobrepõem. Uma stack unificada — compressão geométrica ao estilo PolarQuant para atenção online, codificação entrópica ao estilo KVTC para armazenamento offline, agrupamento semântico ao estilo ChunkKV como frente — é o desfecho provável. Nenhum artigo isolado lá chega; a stack forma-se ao longo de um ano de trabalho de integração.

Reduções reais no custo de servir. No final de 2026, os custos de servir inferência de contexto longo deverão estar visivelmente mais baixos do que hoje, com a maior parte do ganho a vir da compressão e não de silício novo. É essa a forma mais clara de prever que esta linha de trabalho terá sido bem-sucedida.

Para terminar

O TurboQuant é um avanço real sobre um estrangulamento real e chegou dentro de uma vaga de investigação que ataca o problema por vários ângulos ao mesmo tempo. Os números de destaque impressionam por si só — três bits, seis vezes, oito vezes — mas a propriedade mais importante é não exigir nada de quem opera o modelo. Os métodos sem treino e alheios aos dados são os que acabam implementados.

Se corre inferência de contexto longo a qualquer escala, vale a pena acompanhar. Se não corre, continua a valer a pena perceber, porque a economia dos modelos que acabará por usar está a ser definida, discretamente, por artigos como este.