O dia em que um paper do Google fez a Samsung perder 5% em horas
Na última terça-feira, algo curioso aconteceu no mercado financeiro. Ações da Samsung, SK Hynix e Micron — as três maiores fabricantes de chips de memória do planeta — despencaram entre 5% e 6% em questão de horas. O motivo? Não foi uma crise econômica, nem uma guerra comercial. Foi um paper acadêmico.
O Google Research publicou o TurboQuant, um algoritmo de compressão que reduz a memória necessária para rodar modelos de IA em pelo menos 6 vezes — sem perder qualidade nenhuma. E a internet, com seu humor impecável, imediatamente apelidou a coisa de “Pied Piper da vida real”, referência ao startup fictício de compressão da série Silicon Valley da HBO.
Mas ao contrário da ficção, esse algoritmo já tem benchmarks publicados, roda em GPUs H100, e vai ser apresentado no ICLR 2026. Então vamos entender o que ele faz, por que assustou Wall Street, e o que isso significa pra quem trabalha com IA.
O problema que ninguém fala: o KV Cache está comendo sua VRAM
Quem já tentou rodar um LLM localmente sabe: memória é o gargalo. Mas o que muita gente não entende é onde exatamente essa memória está sendo consumida.
Durante a inferência (quando o modelo gera texto), existe uma estrutura chamada KV Cache (Key-Value Cache). Cada token que o modelo processa gera pares de chaves e valores que precisam ficar na memória para que os tokens seguintes possam “prestar atenção” nos anteriores. Isso é o mecanismo de atenção do Transformer em ação.
O problema? Esse cache cresce linearmente com o comprimento do contexto. Um modelo com janela de 128K tokens pode facilmente consumir dezenas de gigabytes só de KV Cache. Em muitos cenários, o KV Cache ocupa mais memória que os próprios pesos do modelo.
| Componente | Memória típica (Llama 3.1 8B, 128K contexto) |
|---|---|
| Pesos do modelo | ~16 GB (FP16) |
| KV Cache | ~20-40 GB (dependendo do batch) |
| Ativações | ~2-4 GB |
| Overhead | ~1-2 GB |
Percebe o absurdo? O cache temporário consome mais que o modelo inteiro. E é exatamente aí que o TurboQuant ataca.
Como o TurboQuant funciona (sem enrolação)
O algoritmo opera em dois estágios independentes que, combinados, conseguem comprimir o KV Cache de 16 bits para apenas 3 bits por valor. Vou explicar cada um.
Estágio 1: PolarQuant — coordenadas polares ao resgate
A primeira sacada genial é mudar a representação dos dados. Em vez de trabalhar com coordenadas cartesianas tradicionais (X, Y, Z), o PolarQuant converte os vetores para coordenadas polares — um raio (magnitude) e ângulos (direção).
Por que isso ajuda? Porque as distribuições angulares dos vetores no KV Cache são altamente concentradas e previsíveis. Isso significa que você pode quantizar esses ângulos de forma muito agressiva sem perder informação relevante.
O truque é aplicar transformações polares recursivas, reduzindo progressivamente cada vetor a um raio final e um conjunto compacto de ângulos descritivos. E como as distribuições são conhecidas, o PolarQuant elimina completamente a etapa de normalização por bloco que outros métodos de quantização exigem — uma operação que normalmente consome memória e tempo de processamento.
Estágio 2: QJL — um bit para governar todos
O segundo estágio cuida do erro residual usando uma técnica chamada Quantized Johnson-Lindenstrauss (QJL). Se o nome parece intimidador, a ideia é mais simples do que parece.
O Lema de Johnson-Lindenstrauss é um resultado clássico de matemática que diz: você pode projetar dados de alta dimensão para uma dimensão muito menor, preservando as distâncias relativas entre pontos. O QJL aplica essa transformação e depois reduz cada valor do vetor resultante a um único bit de sinal — positivo ou negativo.
Sim, 1 bit. E funciona porque o QJL usa um estimador especial que equilibra estrategicamente uma query de alta precisão com os dados comprimidos de baixa precisão, permitindo calcular os scores de atenção com acurácia.
O resultado? Zero overhead de memória adicional na correção de erro. Normalmente, quando você adiciona uma camada de correção, precisa de memória extra para armazenar os metadados dessa correção. O QJL simplesmente não precisa.
A mágica da combinação
O TurboQuant primeiro aplica uma rotação aleatória nos vetores de dados, depois usa o PolarQuant para a compressão principal, e finaliza com o QJL de 1 bit para eliminar o viés residual. O resultado final:
- Compressão de 16 bits para 3 bits (redução de ~5.3x)
- Sem necessidade de treinamento ou fine-tuning
- Overhead de runtime desprezível
- Sem perda mensurável de acurácia
Eu já vi muita promessa de “compressão sem perda” que na prática degradava a qualidade. Mas os benchmarks do TurboQuant são difíceis de contestar.
Os benchmarks que convenceram (quase) todo mundo
Os pesquisadores testaram o TurboQuant em cenários que normalmente destroem métodos de quantização: tarefas de contexto longo.
No Needle in a Haystack (aquele teste onde o modelo precisa encontrar uma informação específica escondida em um texto enorme), o TurboQuant atingiu resultados perfeitos em todos os benchmarks enquanto comprimia a memória do KV em pelo menos 6x.
No LongBench, um suite que cobre perguntas e respostas, geração de código e sumarização, o TurboQuant igualou ou superou o KIVI (o baseline anterior do estado da arte) em todas as tarefas. Isso rodando no Llama-3.1-8B-Instruct.
Mas o número que realmente chama atenção é o benchmark de hardware:
No H100 da Nvidia, o TurboQuant em 4 bits atingiu um aumento de performance de até 8x no cálculo de attention logits, comparado com chaves não-quantizadas de 32 bits.
Oito vezes mais rápido. Na mesma GPU. Sem trocar hardware. Dá pra entender por que os fabricantes de chips de memória ficaram nervosos.
Para quem trabalha com busca vetorial, o TurboQuant também se mostrou superior aos métodos PQ e RabbiQ no dataset GloVe (d=200), mantendo ratios de recall ótimos consistentemente.
Por que Wall Street entrou em pânico (e por que provavelmente exagerou)
Quando o paper saiu, a reação do mercado foi imediata e brutal:
| Empresa | Queda | Mercado |
|---|---|---|
| SK Hynix | -6% | Coreia do Sul |
| Samsung | -5% | Coreia do Sul |
| Kioxia | -6% | Japão |
| Micron | queda significativa | EUA |
| SanDisk | queda significativa | EUA |
A lógica dos investidores foi simples: se a IA precisa de 6x menos memória, a demanda por chips de memória vai cair. Menos demanda = menos receita = ações caem.
Mas essa lógica tem buracos enormes, e vários analistas correram pra apontar isso.
Primeiro: o TurboQuant otimiza inferência, não treinamento. A memória HBM (High Bandwidth Memory) usada para treinar modelos — que é o principal driver de receita da SK Hynix e Samsung — não é afetada. O treinamento de LLMs continua exigindo quantidades absurdas de memória, e nenhum algoritmo de compressão de KV Cache muda isso.
Segundo: algoritmos de quantização existem há anos. O GPTQ, AWQ, GGUF — todos prometeram (e entregaram) reduções significativas de memória. E a demanda por chips de memória para IA só cresceu. Por quê? Porque quando você reduz o custo de rodar IA, mais gente passa a rodar IA. É a velha história do Paradoxo de Jevons: maior eficiência não reduz consumo — aumenta.
Terceiro: o TurboQuant ainda está em fase de pesquisa. Não existe implementação de produção oficial. Sim, a comunidade já começou a portar para MLX (Apple Silicon) e llama.cpp, mas de um paper acadêmico até uma integração em cloud providers como AWS e GCP vai um longo caminho.
Eu apostaria que em duas semanas as ações já terão recuperado a maior parte da queda. Mas o sinal é claro: o mercado está cada vez mais sensível a qualquer avanço em eficiência de IA.
O que isso significa pra quem desenvolve com IA
Agora a parte que realmente importa pra quem lê este blog: implicações práticas.
Modelos maiores na sua GPU
Se o TurboQuant (ou técnicas derivadas) chegarem às ferramentas populares como llama.cpp, vLLM e TensorRT-LLM, o impacto direto é claro: você vai conseguir rodar modelos maiores na mesma GPU.
Aquele modelo de 70B que hoje exige uma A100 de 80GB? Com compressão 6x do KV Cache, o gargalo de memória cai drasticamente. Não significa que vai caber inteiro numa RTX 4090 (os pesos ainda existem), mas janelas de contexto muito maiores se tornam viáveis em hardware consumer.
Custo de inferência em cloud
Para empresas que pagam por GPU-hora na cloud, a redução de memória se traduz diretamente em custo menor. Menos memória por request = mais requests por GPU = menor custo por token.
Considerando que o custo de inferência é a maior parte do orçamento de IA da maioria das startups, uma redução de 6x no KV Cache pode significar economias de 40-60% nos custos de serving.
Contextos longos finalmente viáveis
A janela de contexto de 128K tokens do Llama 3 é impressionante no papel, mas na prática poucos conseguem usar porque o KV Cache explode. Com compressão de 6x, contextos longos deixam de ser um feature de marketing e passam a ser algo que você realmente pode usar em produção.
Isso abre portas para aplicações como:
- RAG com documentos inteiros em vez de chunks pequenos
- Agentes de IA que mantêm histórico completo de conversas longas
- Análise de código com repositórios inteiros no contexto
- Sumarização de reuniões de horas sem perder detalhes
A corrida pela eficiência se intensifica
O TurboQuant não existe no vácuo. Ele faz parte de uma tendência clara: a competição em IA está migrando de “quem tem o modelo maior” para “quem roda de forma mais eficiente”.
O Google, com o Gemini, tem um incentivo direto para reduzir custos de inferência — cada consulta ao Gemini custa dinheiro, e otimizar a memória é otimizar a margem. A Meta já publicou técnicas similares para o Llama. A Anthropic investe pesado em eficiência para o Claude.
A mensagem é clara: o futuro da IA não é só sobre modelos maiores. É sobre fazer mais com menos.
“Pied Piper” — a piada que virou profecia
Eu preciso falar sobre o elefante na sala. Quando o TurboQuant viralizou no X (antigo Twitter) com mais de 7.7 milhões de visualizações, o primeiro comentário que explodiu foi: “O Pied Piper é real.”
Para quem não assistiu Silicon Valley: a série da HBO gira em torno de uma startup que cria um algoritmo de compressão revolucionário capaz de reduzir qualquer dado a uma fração do tamanho original — sem perda de qualidade. A série inteira é basicamente uma sátira do Vale do Silício e suas promessas absurdas.
E agora temos literalmente um algoritmo do Google que comprime dados de IA em 5x+ sem perda de qualidade. A ficção virou realidade. Em menos de 24 horas após o anúncio, desenvolvedores da comunidade já estavam portando o algoritmo para bibliotecas populares como MLX (para Apple Silicon) e llama.cpp.
O paper, de autoria de Amir Zandieh e Vahab Mirrokni, com colaboradores do Google DeepMind, KAIST e NYU, será apresentado no ICLR 2026 — uma das conferências mais prestigiadas de machine learning do mundo.
Na prática, o que você deve fazer agora?
Se você trabalha com IA e está se perguntando “ok, legal, mas o que eu faço com essa informação?”, aqui vão algumas sugestões concretas:
Se você roda modelos localmente: fique de olho no llama.cpp e no vLLM. A comunidade já está integrando técnicas derivadas do TurboQuant, e em poucas semanas devem surgir flags experimentais para ativar compressão de KV Cache mais agressiva.
Se você paga por inferência em cloud: use essa informação como argumento de negociação. Os providers vão adotar essas otimizações — e quando adotarem, seus custos devem cair. Se não cairem, é hora de trocar de provider.
Se você desenvolve aplicações com contextos longos: o TurboQuant valida que o caminho de compressão de KV Cache é viável. Projete suas aplicações assumindo que janelas de 128K+ tokens serão práticas em breve — não apenas teóricas.
Se você investe em tech: não entre em pânico com a queda das ações de memória. A demanda por HBM para treinamento continua forte, e a história mostra que eficiência em inferência aumenta — não diminui — o consumo total de compute.
O TurboQuant é um daqueles avanços que parecem incrementais no paper mas podem ser transformadores na prática. Um algoritmo que roda sem treinamento, sem fine-tuning, sem overhead, e entrega 6-8x de ganho de performance? A gente não vê isso todo dia.
A pergunta que fica é: quanto tempo até isso estar rodando silenciosamente em cada API de IA que você usa — e você nem perceber?
Fonte de inspiração: TurboQuant: Redefining AI Efficiency with Extreme Compression — Google Research Blog
















830 Milhões Em GPUs Nvidia: Plano Da Mistral Para IA Na Europa
[…] com a OpenAI, Google com o Gemini (a mesma Google que recentemente abalou o mercado com seu algoritmo TurboQuant)), a dependência vira […]