Transforme e conquiste: como o Google comprime LLMs 6x mudando de coordenadas

Multiplicar é difícil. Somar é fácil.

Todo mundo aprende isso na escola. O que quase ninguém sabe é que os logaritmos existem precisamente para explorar essa assimetria: eles transformam uma multiplicação em uma soma, processam o problema no mundo fácil e depois desfazem a transformação. O resultado é correto. O esforço, muito menor.

Esse padrão — transformar o problema para um espaço onde resolvê-lo seja trivial, resolver e voltar ao original — é um dos mais poderosos em toda a engenharia. A transformada FFT faz isso com sinais. Os logaritmos fazem isso com produtos. Agora, o Google acaba de publicar um artigo mostrando como fazer isso com a compressão de modelos de linguagem.

Chama-se TurboQuant, e a ideia é tão elegante que merece um artigo.

O problema: comprimir sem perder precisão

Os LLMs modernos têm um gargalo que não está no modelo em si, mas na sua memória de trabalho. Sempre que um modelo gera texto, ele mantém na memória estruturas chamadas key-value cache (KV cache) — basicamente, o “contexto” que o modelo precisa lembrar para gerar a próxima palavra.

Em um modelo grande com um contexto extenso, o KV cache pode ocupar dezenas de gigabytes de VRAM. Isso é um problema sério: VRAM de GPU é cara, limitada e compartilhada com outros processos.

A solução óbvia é quantizar: reduzir a precisão de cada número. Em vez de armazenar cada valor em 32 bits (float32), você guarda em 4 bits ou até mesmo 3. Você passa de um intervalo contínuo para uma escala discreta com poucos degraus. Funciona razoavelmente bem.

Até você topar com a armadilha.

A armadilha das constantes de normalização

Para quantizar um bloco de números, você precisa saber seu intervalo: o mínimo e o máximo. Esses valores são chamados de constantes de normalização, e precisam ser armazenados com alta precisão (16 bits) para que os valores originais possam ser reconstruídos.

Aqui está a gambiarra: se você quantiza com 3 bits por número, mas precisa guardar uma constante de 16 bits a cada, digamos, 8 números, essas constantes ocupam 2 bits extras por número. Sua compressão “de 3 bits” na verdade consome 5 bits efetivos. Você perdeu quase metade da vantagem.

É como fazer uma mudança para um apartamento menor e descobrir que as caixas da mudança ocupam metade do espaço novo.

E não adianta simplesmente aumentar o tamanho dos blocos para reduzir o impacto das constantes, porque blocos maiores significam pior aproximação — o intervalo se amplia e você perde precisão. Você fica preso entre dois problemas opostos.

Esse dilema permanece sem solução há anos. Todo mundo tenta resolvê-lo inventando compressores melhores. Blocos adaptativos, quantização não uniforme, esquemas híbridos de compressão. Mais complexidade, mais parâmetros, resultados marginais.

O Google fez algo diferente. Não inventou um novo compressor. Mudou de coordenadas.

A mudança de coordenadas: de cartesianas para polares

A ideia central do TurboQuant é aplicar uma rotação aleatória ao vetor antes de quantizá-lo, e depois converter o resultado em coordenadas polares.

Vamos por partes.

Passo 1: Rotação aleatória

Imagine que você tem um vetor em um espaço de alta dimensão. Seus componentes estão distribuídos de forma irregular — algumas dimensões têm valores enormes e outras estão próximas de zero. Esse desequilíbrio é exatamente o que te obriga a usar constantes de normalização por bloco: cada bloco tem um intervalo diferente.

O que acontece se você multiplicar o vetor por uma matriz de rotação aleatória? Geometricamente, você está girando o vetor para uma orientação arbitrária. O vetor continua o mesmo (mesmo comprimento, mesma relação com outros vetores), mas suas componentes são redistribuídas.

E é aí que entra um resultado matemático que parece mágica: em espaços de alta dimensão, uma rotação aleatória faz com que as componentes do vetor fiquem quase uniformes. É um fenômeno chamado concentração da medida — em dimensões altas, quase toda a massa de uma distribuição se concentra perto de sua média. Ao rotacionar aleatoriamente, tudo se regula.

Em português claro: a rotação elimina os picos e os vales. Depois de rotacionar, todos os blocos têm intervalos parecidos. E se todos os blocos têm intervalos parecidos… não é necessário registrar o intervalo de cada um.

Passo 2: Converter para coordenadas polares

Depois da rotação, o TurboQuant converte os vetores de coordenadas cartesianas (x, y, z…) para coordenadas polares (um raio e vários ângulos).

Por quê? Porque a rotação aleatória fez com que os ângulos se tornassem altamente previsíveis — estão concentrados em intervalos estreitos e já conhecidos antecipadamente. Os limites de quantização são fixos. Não dependem dos dados.

Isso significa: zero constantes de normalização para os ângulos. O overhead de 1-2 bits por número desaparece. Só é necessário guardar o raio (um número por vetor) e os ângulos quantizados com limites fixos.

flowchart LR
    subgraph antes["   Quantização Clássica   "]
        direction LR
        V1[" Vetor original "] --> B1[" Dividir em blocos "]
        B1 --> N1["&nbsp;Calcular min/max&nbsp;<br/>por bloco&nbsp;"]
        N1 --> Q1["&nbsp;Quantizar&nbsp;<br/>3 bits + 2 bits de overhead&nbsp;"]
    end

    subgraph depois["&nbsp;&nbsp;&nbsp;TurboQuant&nbsp;&nbsp;&nbsp;"]
        direction LR
        V2["&nbsp;Vetor original&nbsp;"] --> R2["&nbsp;Rotação&nbsp;<br/>aleatória&nbsp;"]
        R2 --> P2["&nbsp;Coordenadas&nbsp;<br/>polares&nbsp;"]
        P2 --> Q2["&nbsp;Quantizar&nbsp;<br/>3 bits, overhead ≈ 0&nbsp;"]
    end

    antes ~~~ depois

O grande truque é que a rotação é reversível. Para recuperar o vetor original, você descodifica, volta para cartesianas e aplica a rotação inversa. O resultado é uma compressão de 6x do KV cache sem perder precisão perceptível.

Por que funciona: adicionar aleatoriedade reduz a incerteza

Esse é o ponto mais contraintuitivo do artigo. Adicionar ruído (a rotação aleatória) reduz a incerteza. Parece contraditório, mas tem uma explicação elegante.

Sem a rotação, cada vetor tem sua própria estrutura interna. Dimensões dominam, outras são ruído. Você não sabe de antemão qual será o intervalo de cada bloco. Essa incerteza te obriga a medir e armazenar os intervalos.

Com a rotação, você força todos os vetores a terem a mesma distribuição estatística (a concentração da medida em ação). Não é necessário medir nada porque você já sabe como os valores estarão distribuídos. A aleatoriedade elimina informações específicas de cada vetor (algo que não te ajuda) e as substitui por uma regularidade previsível (algo útil).

É como embaralhar um baralho de cartas. Antes de embaralhar, você não sabe em que ordem estão — é preciso olhar cada carta. Depois de embaralhar bem, você sabe exatamente qual é a ordem: ela será aleatória e uniforme. Paradoxalmente, você sabe mais sobre o sistema embaralhado do que sobre o original, se o que quer é prever propriedades estatísticas.

TurboQuant em números

O Google avaliou o TurboQuant em vários benchmarks com os modelos Gemma e Mistral. Resultados:

Esse último ponto é crucial. A maioria das técnicas de quantização exige um conjunto de dados para calibrar os parâmetros. TurboQuant não exige nada. A rotação aleatória funciona com qualquer dado porque a concentração da medida é uma propriedade do espaço, não do conteúdo.

O padrão que todo programador deveria conhecer

TurboQuant é um caso específico de um padrão muito mais amplo que merece um nome: transforme e conquiste.

A ideia: quando um problema é difícil de resolver, pergunte-se se você está trabalhando no espaço certo. Às vezes, a solução não é criar um algoritmo mais inteligente, mas sim usar uma representação diferente do mesmo problema.

Exemplos que você já conhece:

Em todos os casos, a dificuldade não estava no problema, mas na representação. Você muda de coordenadas e o que era complexo se transforma em algo simples.

Aplicações práticas para você

Não é necessário estar comprimindo LLMs para usar este padrão. Da próxima vez que ficar empacado em um problema que “deveria ser fácil, mas não é”, faça estas perguntas:

1. Estou no espaço certo? Se comparar duas coisas está difícil, talvez você precise normalizar antes de comparar. Se buscar algo está lento, talvez seja necessário criar um índice (uma representação alternativa otimizada para busca).

2. Existe uma transformação conhecida para meu domínio? FFT existe desde 1965. As transformadas wavelet, desde os anos 80. Embeddings vetoriais, desde 2013. Muitos problemas “difíceis” já têm transformações padrão que os resolvem. Antes de inventar algo, pesquise para ver se alguém já encontrou as coordenadas ideais.

3. Posso adicionar aleatoriedade para simplificar? Hashing, random projections, sketches probabilísticos — todos funcionam porque a adição de aleatoriedade controlada elimina complexidades desnecessárias. Se o seu problema tem uma estrutura irregular que complica seu trabalho, às vezes a melhor estratégia é propositalmente eliminar essa estrutura.

Da próxima vez que tentar forçar uma solução

A lição do TurboQuant não é só sobre compressão de modelos. É sobre resistir à tentação de criar um compressor melhor quando na verdade o que você precisa é mudar de perspectiva.

Por anos, a comunidade de aprendizado de máquina tentou resolver o overhead das constantes de normalização com esquemas de quantização mais sofisticados. Mais blocos, mais níveis, mais heurísticas. Tudo dentro do mesmo sistema de coordenadas cartesianas. E tudo com melhorias incrementais.

O Google fez algo diferente. Rotacionou os dados, mudou de coordenadas e o problema simplesmente desapareceu. Eles não resolveram. Dissolveram.

Da próxima vez que passar horas lutando com uma solução que parece inadequada, pare por um momento e pergunte-se: estou brigando com o problema ou com a representação? Porque, se você estiver nas coordenadas erradas, o melhor algoritmo do mundo não vai te salvar.

Fonte: TurboQuant: Redefining AI Efficiency with Extreme Compression — Blog de Pesquisa do Google.