O TurboQuant da Google acabou de encolher um índice de IA de 31GB para 4GB — Eis o que isso significa realmente

O TurboQuant da Google acabou de encolher um índice de IA de 31GB para 4GB — Eis o que isso significa realmente

De 31GB para 4GB. Foi esse o número que tirou alguns por cento às ações da Micron em junho de 2026, e foi o que lançou metade do Twitter dos developers em pânico, a perguntar se as suas faturas de RAG tinham acabado de colapsar. A matemática por baixo é real: o TurboQuant da Google (arXiv 2504.19874, aceite no ICLR 2026) comprime a memória de um LLM cerca de 6x, para aproximadamente 3 bits por valor, com perda de precisão quase nula. Mas a maioria dos artigos errou numa coisa, e isso muda a forma como deves ler toda a história.

A história da compressão de memória de IA do Google TurboQuant é, na verdade, duas histórias a vestir o mesmo capuz. Vamos desembaraçá-las.

Pontos-chave

• O TurboQuant é o algoritmo de compressão sem treino da Google: redução de ~6x da KV-cache para ~3 bits, com perda de precisão quase nula (ICLR 2026).
• O TurboVec é uma biblioteca Rust separada, de terceiros, que implementa o TurboQuant. A Google não a lançou.
• A demonstração viral "31GB → 4GB, supera o FAISS" é do TurboVec, não do TurboQuant puro.
• O verdadeiro ganho para os developers é inferência de contexto longo mais barata e índices de RAG mais pequenos, mas o lançamento oficial da Google é um artigo científico, não um produto.

O que é o TurboQuant da Google, em linguagem simples?

O TurboQuant é o algoritmo de quantização vetorial da Google Research, sem treino e independente dos dados. Comprime a KV cache de um LLM cerca de 6x, para cerca de 3 bits por valor, com perda de precisão quase nula. Está publicado no arXiv 2504.19874 e foi aceite no ICLR 2026. "Sem treino" significa que funciona em modelos já existentes, prontos a usar, sem precisar de fine-tuning.

Então, o que está realmente a ser comprimido? Duas coisas, principalmente.

Primeiro, a KV cache. Quando um modelo lê a tua conversa, guarda um resumo contínuo de tudo até ao momento, chamado cache chave-valor (key-value cache). Pensa nela como a memória de curto prazo do modelo. Quanto maior for a tua janela de contexto, mais desta memória ele retém, e mais RAM da GPU consome. Uma conversa de 128k tokens pode inflacionar a KV cache para muitos gigabytes. É por isso que servir contexto longo fica caro rapidamente, e é por isso que a cache de prompts para reduzir custos de API se tornou relevante em primeiro lugar.

Segundo, os índices vetoriais. Os embeddings que alimentam a pesquisa semântica e o RAG são grandes arrays de números de vírgula flutuante. Guarda milhões deles em precisão total e estás a olhar para dezenas de gigabytes de RAM.

O TurboQuant encolhe ambos. Eis a parte fixe: não precisa de nenhuns dos teus dados para o fazer. A maioria dos esquemas de quantização estuda primeiro uma amostra dos teus vetores e depois constrói um codebook afinado para eles. O TurboQuant salta essa etapa. É independente dos dados, o que significa que atinge a sua taxa de compressão sem nunca olhar para a tua distribuição.

O verdadeiro truque do TurboQuant não é a taxa de compressão. É que precisa de zero dados de treino para a atingir.

Esse é o verdadeiro desbloqueio. Podes apontá-lo a um modelo que já tens em execução e obter as poupanças de imediato.

TurboQuant vs TurboVec: a confusão que toda a gente está a interpretar mal

O TurboQuant é o algoritmo de compressão da Google (arXiv 2504.19874, ICLR 2026). O TurboVec é uma biblioteca separada de Rust e Python, de terceiros (RyanCodrai/turbovec), que implementa o TurboQuant para pesquisa vetorial. A Google não lançou o TurboVec. O resultado viral "31GB → 4GB, supera o FAISS" pertence ao TurboVec, não ao TurboQuant puro. Se só te lembrares de uma coisa deste artigo, que seja isso.

Foi aqui que a coisa ficou confusa. Quando o benchmark de 31GB→4GB se tornou viral no início de junho de 2026, alguns meios (incluindo o Tech Startups) publicaram títulos a dizer que a Google tinha "lançado o TurboVec". Não foi isso que aconteceu. Verifica a fonte: o TurboVec está em RyanCodrai/turbovec no GitHub e no PyPI. É uma biblioteca open-source criada por um developer chamado Ryan Codrai. O MarkTechPost acertou no enquadramento, descrevendo-o como "um índice vetorial em Rust com bindings para Python, construído sobre o algoritmo TurboQuant da Google".

Por isso, a relação é simples: a Google publicou a matemática, e a comunidade construiu ferramentas com ela. O TurboVec é a mais visível dessas ferramentas.

A Google construiu o algoritmo. Um developer chamado Ryan Codrai construiu a biblioteca que toda a gente anda a capturar em screenshots. Não são a mesma coisa.

Se estás a ponderar onde é que um índice baseado em TurboQuant se encaixa ao lado da tua configuração atual, o nosso resumo das melhores bases de dados vetoriais em 2026 coloca o FAISS, o Qdrant e os novos índices comprimidos lado a lado.

Como é que o TurboQuant comprime a memória sem arruinar a precisão?

O TurboQuant usa uma rotação aleatória mais um esquema de quantização em coordenadas polares (PolarQuant) e uma projeção ao estilo Johnson-Lindenstrauss (QJL, Quantized Johnson-Lindenstrauss) para distribuir os valores uniformemente antes de quantizar. Esta distorção quase ótima é o que lhe permite descer para cerca de 3 bits por valor, mantendo a precisão quase intacta, sem necessidade de retreinar o modelo.

Deixa-me desmontar isto, porque o jargão esconde uma ideia bastante intuitiva.

Quando quantizas, estás a arredondar números para menos bits. O perigo é que algumas dimensões de um vetor têm muito mais peso do que outras, por isso arredondá-las de forma desajeitada arruína o resultado. A solução do TurboQuant é rodar o vetor aleatoriamente primeiro. Imagina baralhar um baralho uniformemente antes de dar as cartas, para que nenhuma mão fique desequilibrada. Após a rotação, os valores ficam distribuídos de forma que nenhuma dimensão domina, e o arredondamento custa muito menos.

Essa é a parte do QJL: uma projeção aleatória que mistura tudo, preservando as distâncias. O PolarQuant (apresentado no AISTATS 2026) quantiza depois os valores rodados em coordenadas polares, o que se ajusta melhor à sua distribuição do que o simples arredondamento em grelha.

O resultado é aquilo a que o artigo chama distorção quase ótima, ou seja, aproxima-se do limite teórico de Shannon para a mínima qualidade que se pode perder com um dado orçamento de bits. Em termos simples: para 3 bits por valor, basicamente não se consegue fazer muito melhor, e o TurboQuant chega lá sem estudar os teus dados.

Para o mecanismo completo, o blog da Google Research e o artigo no arXiv são as fontes primárias. O InfoQ tem também uma análise limpa e orientada para developers sobre o ângulo da KV-cache, se quiseres o enquadramento prático.

O que significa realmente 31GB → 4GB para a tua fatura de RAM?

Um índice de RAG de 10M de vetores que precisa de ~31GB de RAM em precisão total desce para cerca de ~4GB com a compressão baseada em TurboQuant do TurboVec, pequeno o suficiente para caber numa instância comum em vez de um escalão pesado em memória. Para a KV cache, a redução de ~6x significa aproximadamente 6x mais sessões simultâneas de contexto longo na mesma GPU. Essa é a parte que realmente aparece numa fatura.

Fizemos as contas que os concorrentes não fazem. Primeiro, uma nota rápida de honestidade: tudo o que se segue é estimado e modelado (junho de 2026) a partir dos preços públicos da cloud e dos rácios declarados no artigo. Não executámos o TurboVec em produção, por isso trata isto como a matemática, não como um benchmark que medimos fisicamente. Os escalões de preços seguem a mesma base que usamos no nosso guia para reduzir custos de API de LLM.

Eis um índice de embeddings de 10M de documentos, precisão total vs comprimido com TurboVec, mapeado para o escalão de RAM da cloud de que realmente precisarias:

O salto de uma máquina otimizada para memória para uma pequena de uso geral é a história toda. Para um índice auto-hospedado, é muitas vezes a diferença entre uma fatura que te faz estremecer e uma que mal notas. Se estás a construir o pipeline que assenta por cima disto, o nosso guia passo a passo sobre como construir uma aplicação RAG cobre onde vive este índice.

Agora o lado da KV-cache, modelado para uma GPU fixa de 24GB a servir sessões de contexto de 128k:

Um corte de 6x na KV-cache não poupa apenas RAM. Pode transformar uma GPU em seis para servir contexto longo.

É por isso que isto importa mais para cargas de trabalho de contexto longo do que qualquer outra coisa. Se serves muitos chats curtos, a tua KV cache nunca foi o estrangulamento. Se corres agentes de 128k tokens ou análise de documentos, um corte de 6x muda a tua economia por GPU da noite para o dia. A reportagem da VentureBeat coloca o ganho máximo de throughput até 8x numa H100 com poupanças de custos de 50%+, o que bate certo com a nossa matemática de concorrência modelada.

Porque é que as ações dos chips de memória caíram, e terá Wall Street reagido de forma exagerada?

Após a revelação do TurboQuant, as ações da Micron, Western Digital e Seagate caíram com o receio de que uma memória de IA radicalmente mais barata reduza a futura procura de DRAM e HBM — o chamado enquadramento de "momento DeepSeek". Analistas, incluindo o Wells Fargo, argumentaram o contrário: memória mais barata gera mais utilização total, não menos, através do paradoxo de Jevons.

A narrativa escreveu-se sozinha. A IA é o maior comprador de memória de alta largura de banda neste momento, por isso, se um algoritmo da Google corta as necessidades de memória 6x, segundo a lógica, a procura de chips cai e os fabricantes também. O TechCrunch recorreu até à comparação com a "Pied Piper", a startup fictícia de compressão da série Silicon Valley da HBO que prometia encolher os dados do mundo. As ações caíram com esse receio.

Eis a visão mais calma, e é uma que o ciclo noticioso praticamente ignorou. O Wells Fargo apontou para o paradoxo de Jevons: quando algo fica mais barato e mais eficiente, geralmente consumimos mais disso no total, não menos. Memória de IA mais barata significa que mais apps lançam funcionalidades de contexto longo, mais equipas auto-hospedam índices de RAG maiores, e acontece mais inferência, ponto final. Os ganhos de eficiência têm um longo histórico de fazer crescer a procura total em vez de a matar.

O mercado avaliou o TurboQuant como um assassino da procura. A história diz que computação mais barata geralmente significa que simplesmente usamos mais dela.

Então, terá a queda sido uma leitura exagerada? Provavelmente, pelo menos no curto prazo. Um artigo científico não é uma reconversão instantânea de toda a indústria. O mercado reagiu a um título; a implementação real levará trimestres, e o efeito de indução de procura pode muito bem superar as poupanças.

Podes realmente usar o TurboQuant hoje?

Sim, parcialmente. O lançamento oficial da Google do TurboQuant é o artigo e o algoritmo, não um produto pronto a usar. Mas já existem implementações da comunidade: o TurboVec (RyanCodrai/turbovec, no PyPI) para índices vetoriais, e o AmesianX/TurboQuant para llama.cpp (cerca de 5.2x, com suporte para DeepSeek-V2/V3 e GLM-4.7-Flash via MLA). O ecossistema é jovem, mas utilizável.

Se quiseres experimentar o lado do índice vetorial, o TurboVec está a um pip de distância:

pip install turbovec
# Rust + Python bindings, implements Google's TurboQuant for vector search
# llama.cpp KV-cache impl (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python reference impl: github.com/yashkc2025/turboquant

Para o lado da KV-cache em modelos locais, a implementação llama.cpp do AmesianX/TurboQuant é a que deves acompanhar, especialmente se corres modelos DeepSeek ou GLM com atenção latente multi-cabeça (multi-head latent attention). Combina bem com uma configuração de LLM local, já que uma KV cache mais pequena significa que podes empurrar um contexto maior na mesma placa. E se estás a escolher que modelo aberto correr, os nossos benchmarks dos melhores LLM open-source cobrem diretamente as famílias DeepSeek e GLM.

A ressalva honesta: isto é um artigo agora, com o ecossistema a amadurecer. O entregável oficial da Google é investigação, não um produto suportado com um SLA.

A resposta honesta: o TurboQuant é matemática pronta a expedir, não um botão de download. Pelo menos por agora.

O TurboQuant é hype ou é a sério? Um veredito honesto

O TurboQuant é real e genuinamente inteligente. O seu design sem treino é o verdadeiro desbloqueio, e a vitória da KV-cache importa mais para cargas de trabalho de contexto longo. Mas não é magia: é um avanço de quantização entre muitos, o título de 31GB→4GB pertence ao TurboVec e não à Google, e o pânico das ações sobreinterpretou um resultado de investigação.

Na nossa experiência a afinar a inferência e o custo de RAM para clientes, o que decide se uma técnica como esta vale a pena adotar é o atrito. O "sem treino" ganha em grande aqui, porque não há ciclo de fine-tuning, nem codebook para manter, nem cirurgia ao modelo. Podes encaixá-lo em algo que já tens em execução.

O que muda:

• Inferência de contexto longo mais barata, que é onde o custo de memória realmente dói.
• Índices de RAG auto-hospedados mais pequenos que cabem em hardware mais barato.
• Uma opção de compressão que podes adotar sem retreinar nada.

O que não muda:

• Não fará muito por cargas de trabalho de contexto curto e modelos pequenos, onde a KV cache nunca foi o estrangulamento.
• Não torna a tua quantização existente obsoleta da noite para o dia; é um acrescento, não uma substituição.
• O lançamento oficial da Google continua a ser um artigo, por isso as ferramentas de nível de produção ficam a cargo da comunidade, por agora.

Se estás a tentar perceber o que isto significa para a tua própria fatura de inferência ou de RAM, é exatamente esse o tipo de modelação de custos que fazemos para clientes na Techsy. Obtém uma consulta gratuita se quiseres um segundo par de olhos sobre o assunto.

Sobre o autor

Mert Batur Gurbuz é cofundador da Techsy.io, onde a equipa entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Estuda na University of Birmingham e escreve sobre a stack de ferramentas de LLM que a equipa da Techsy realmente usa em produção. Liga-te no LinkedIn.

Perguntas frequentes

O que é o Google TurboQuant?

O TurboQuant é o algoritmo de quantização vetorial sem treino da Google Research, publicado no arXiv 2504.19874 e aceite no ICLR 2026. Comprime a KV cache de um LLM cerca de 6x, para aproximadamente 3 bits por valor, com perda de precisão quase nula. Por ser independente dos dados, funciona em modelos existentes sem qualquer fine-tuning ou retreino.

A Google lançou mesmo o TurboVec?

Não. O TurboQuant é o algoritmo da Google. O TurboVec é uma biblioteca separada de Rust e Python, de terceiros (RyanCodrai/turbovec), construída sobre o TurboQuant por um developer independente. Alguns meios atribuíram incorretamente à Google o lançamento do TurboVec quando o benchmark viral de 31GB→4GB se tornou viral, mas o GitHub mostra que é um projeto da comunidade.

O TurboQuant é o mesmo que o TurboVec?

Não. O TurboQuant é o algoritmo de compressão que a Google publicou. O TurboVec é uma biblioteca que implementa esse algoritmo para pesquisa vetorial. Um é a matemática; o outro é uma ferramenta construída com essa matemática. O famoso resultado "31GB → 4GB, supera o FAISS" é do TurboVec, não algo que a Google tenha lançado diretamente.

O TurboQuant perde precisão?

A perda de precisão quase nula é a afirmação em destaque do artigo, mesmo a cerca de 3 bits por valor. O algoritmo atinge uma distorção quase ótima (perto do limite de Shannon) rodando aleatoriamente os vetores antes de quantizar, para que nenhuma dimensão domine. Na prática, isso significa que a quebra de qualidade é pequena o suficiente para ser negligenciável na maioria das cargas de trabalho.

Quanta RAM poupa o TurboQuant?

Cerca de 6x na KV cache, reduzindo-a para aproximadamente 3 bits por valor. No lado do índice vetorial, o TurboVec demonstrou um índice de 10M de documentos a encolher de 31GB para cerca de 4GB, até um corte de 92% de memória. As tuas poupanças reais dependem da tua precisão de base e de se estás a comprimir a KV cache, os embeddings, ou ambos.

Isto é só hype, porque é que as ações de memória caíram?

É um avanço real, mas o pânico sobreinterpretou um resultado de investigação. A Micron, a Western Digital e a Seagate caíram com o receio de que memória de IA mais barata corte a procura de chips. O Wells Fargo contrapôs com o paradoxo de Jevons: memória mais barata e mais eficiente geralmente aumenta a utilização total. Um artigo também não é uma reconversão instantânea da indústria, por isso a reação de curto prazo parece exagerada.

Posso usar o TurboQuant hoje?

Parcialmente. O lançamento oficial da Google é o artigo e o algoritmo, não um produto. Já existem implementações da comunidade: o TurboVec no PyPI para índices vetoriais, o AmesianX/TurboQuant para llama.cpp (DeepSeek-V2/V3 e GLM-4.7-Flash via MLA), e o yashkc2025/turboquant como referência em Python. O ecossistema é jovem, mas já utilizável.

Em que é que o TurboQuant é diferente da quantização que já faço?

A maioria da quantização estuda uma amostra dos teus dados para construir um codebook afinado. O TurboQuant é sem treino e independente dos dados, por isso atinge o seu rácio sem nunca olhar para a tua distribuição. Também visa especificamente a KV cache e os índices vetoriais, com distorção quase ótima, em vez de apenas comprimir os pesos do modelo.

O TurboQuant funciona com DeepSeek ou llama.cpp?

Sim, através da implementação llama.cpp do AmesianX/TurboQuant, que reporta cerca de 5.2x de compressão e suporta DeepSeek-V2/V3 e GLM-4.7-Flash via atenção latente multi-cabeça (MLA). Isso torna-o uma opção prática se auto-hospedas esses modelos e queres uma KV cache mais pequena para contextos mais longos no mesmo hardware.

Quando é que o TurboQuant ajuda realmente mais?

Ajuda mais na inferência de contexto longo e em grandes índices de RAG auto-hospedados, onde a memória é o verdadeiro estrangulamento. Um corte de 6x na KV-cache significa mais sessões simultâneas de contexto de 128k por GPU, e um índice de embeddings comprimido cabe em instâncias mais baratas. Ajuda menos em chats de contexto curto e modelos pequenos, onde a KV cache nunca foi o teu motor de custos.