PrismML e Google aproximam a inferência local de modelos 200B com Bonsai e TurboQuant

A execução local de modelos de linguagem muito grandes está deixando de ser fantasia para entusiastas com um rack de servidores. Duas abordagens novas — pesos de 1 bit do Bonsai da PrismML e compressão de KV-cache TurboQuant do Google Research — atacam diretamente as duas partes mais caras da inferência: memória para o modelo e memória para contexto longo.

Como os pesos são comprimidos

A PrismML apresentou Bonsai 8B com licença Apache 2.0 — um modelo baseado em Qwen3-8B, onde quase todos os pesos são armazenados em representação de 1 bit. Em termos práticos, isso significa uma redução abrupta no tamanho: aproximadamente 1,15 GB versus 16,38 GB para a versão FP16, aproximadamente 14 vezes menor.

A empresa enfatiza que isso não é simplesmente empacotamento de arquivo. Esse formato requer kernels especiais para evitar desempacotar pesos de volta para FP16 completo durante a inferência. O esquema parece bruto, mas não primitivo: cada peso é codificado em um único bit, e um grupo de 128 pesos recebe uma escala comum em FP16.

Como resultado, o custo efetivo chega a cerca de 1,125 bits por peso. De acordo com as alegações da PrismML, Bonsai 8B produz até 368 tokens por segundo em RTX 4090, cerca de 131 tokens por segundo em M4 Pro e permanece competitiva em qualidade entre modelos 8B, embora não se torne uma líder absoluta em benchmarks.

Como o KV-cache é reduzido

Mas pesos leves sozinhos não são o suficiente. Modelos grandes desenvolvem rapidamente KV-cache — memória de trabalho que armazena representações de tokens e cresce com o comprimento do contexto. É aqui que o Google Research propõe TurboQuant.

O método comprime KV-cache sem retreinamento do modelo e, de acordo com os resultados dos autores, mantém qualidade mesmo na faixa de aproximadamente 3–3,5 bits por canal, onde a quantização comum já começa a arriscar notavelmente a qualidade da resposta. Dentro da abordagem existem duas ideias-chave: primeiro, os dados são rotacionados para um espaço mais conveniente onde é mais fácil comprimir fortemente, e então um passo separado compensa o erro de compressão. Através disso, TurboQuant resolve não apenas a questão do tamanho, mas também o problema de custos indiretos que frequentemente consomem o benefício da quantização vetorial comum.

Nos testes do Google, o método mostrou pelo menos uma redução de seis vezes na memória de KV-cache e aceleração da computação de atenção comparado à representação descomprimida.

Se as abordagens forem combinadas

A parte mais interessante começa onde essas duas ideias se empilham juntas. Se a abordagem de 1 bit da PrismML um dia se dimensionar para modelos na classe 200B+, e TurboQuant preservar suas propriedades em contexto longo, a execução local de tais sistemas deixará de ser domínio de servidores com centenas de gigabytes de memória. Usando Qwen3-235B-A22B como exemplo, as estimativas já não parecem fantásticas, mas tecnicamente discutíveis, porém bastante realistas. Não se trata ainda de um produto acabado, mas da trajetória do desenvolvimento de hardware e inferência.

• Pesos do modelo em bfloat16: aproximadamente 437,7 GiB
• Variante hipotética de 1 bit por analogia com Bonsai: aproximadamente 30,8 GiB
• KV-cache para contexto de 128k em 16 bits: aproximadamente 23,5 GiB
• KV-cache com TurboQuant em 3,5 bits: aproximadamente 5,1 GiB
• Total de pesos e cache: na ordem de 36 GiB em vez de mais de 460 GiB

Isso ainda não é uma promessa de um assistente doméstico 235B pronto. Questões permanecem sobre a largura de banda da memória, a qualidade dos kernels de baixo bit, estabilidade em tarefas reais e quão bem o esquema de 1 bit se transfere de 8B para modelos substancialmente maiores. Mas a trajetória está mudando: anteriormente a conversa era sobre como comprimir 7B ou 14B para um laptop, agora já está sendo discutida a questão de se uma classe 200B pode ser levada para hardware local.

O que isso significa

O mercado de LLM local está migrando de otimização cosmética para avanços arquiteturalmente significativos em inferência. Se Bonsai e TurboQuant provarem ser escaláveis, os vencedores não serão apenas entusiastas, mas também empresas que precisam de privacidade, baixa latência e execução de modelos poderosos sem dependência constante da nuvem. Para equipes corporativas, já é um caminho para assistentes locais de uma nova classe em um único nó poderoso, em vez de em um cluster separado.