Gemma 4 QAT: Rodando modelos de 31B em GPUs de consumo e celulares com 1GB

A linha completa de modelos Gemma 4 QAT

Cinco tamanhos de modelo receberam checkpoints QAT, acompanhados de modelos "drafter" menores para decodificação especulativa. A tabela abaixo compara as diferenças práticas de consumo de memória entre a precisão BF16 original e a versão QAT de 4 bits :

Os números de memória vêm dos guias oficiais do Google e da documentação da Unsloth, representando o popular nível de quantização Q4_0 para GGUF . O destaque é o modelo E2B no formato mobile, que chega a aproximadamente 1 GB — o Google projetou um esquema sob medida com camadas de decodificação em 2 bits e caches KV otimizados para isso . Para modelos só de texto, sem Per-Layer Embeddings, o consumo pode ficar abaixo de 1 GB .

O modelo 26B A4B merece atenção especial. Por ser uma Mistura de Especialistas, ele ativa apenas cerca de 3,8 bilhões de parâmetros por token, apesar de ter 26 bilhões no total. Isso significa que ele se comporta, em termos de computação, como um modelo de 4B — mas entrega um raciocínio comparável ao de modelos densos muito maiores . Na versão de 4 bits, ele cabe em GPUs de 12 a 16 GB, exatamente o tipo de placa que muitos desenvolvedores já têm em casa .

Formatos de implantação: escolha com cuidado

O Google liberou checkpoints QAT em quatro formatos distintos, e a escolha afeta diretamente a qualidade final :

• Compressed-tensors (W4A16): O formato oficial para inferência com vLLM, com pesos em inteiro de 4 bits e ativações em 16 bits (group_size=32). É o caminho mais seguro para ficar dentro do envelope de qualidade testado pelo Google .
• GGUF / Q4_0: O formato mais usado em ferramentas do ecossistema aberto, como llama.cpp e Ollama. Arquivos GGUF prontos estão disponíveis para os cinco tamanhos .
• Formato otimizado para dispositivos móveis: Um esquema personalizado que mistura diferentes larguras de quantização, feito sob medida para hardware mobile. Disponível apenas para E2B e E4B, é o que atinge 1 GB no E2B .
• Checkpoints QAT não quantizados: Pesos em meia-precisão extraídos do pipeline QAT. São voltados para pesquisadores que queiram aplicar suas próprias quantizações ou compilações personalizadas .

Um alerta crucial: converter pesos QAT diretamente para Q4_0 sem os devidos cuidados pode derrubar a precisão. Segundo a documentação da Unsloth, uma conversão ingênua do modelo 26B para Q4_0 atinge apenas 70,2% de acurácia top-1. O método Dynamic deles eleva esse número para 85,6% — um salto de 15,4 pontos percentuais —, o que evidencia como a metodologia de conversão é determinante para preservar a qualidade .

Para a maioria dos usuários, o ponto de partida mais seguro são os checkpoints oficiais em compressed-tensors ou os arquivos GGUF do Hugging Face.

Que hardware realmente consegue rodar esses modelos?

O QAT não apenas reduz a memória: ele redesenha o mapa do que é possível rodar localmente. Modelos que antes pediam GPUs de data center agora funcionam em hardware de consumo — e até em celulares.

Smartphones e dispositivos de borda: O E2B foi feito para o mundo mobile. A estrutura LiteRT-LM do Google consegue executá-lo com menos de 1,5 GB de RAM usando quantização de 2 e 4 bits. O aplicativo AI Edge Gallery na Play Store já permite selecionar e rodar o E2B ou o E4B totalmente no dispositivo . Ambos aceitam texto, imagem e áudio, abrindo caminho para tradução de voz em tempo real, respostas visuais e assistentes pessoais que funcionam offline .

GPUs de 8 GB: Aqui está o ponto ideal. Os modelos E2B (~3,2 GB), E4B (~5 GB) e 12B (~7 GB) cabem com folga em 8 GB de VRAM na quantização Q4_0 . Um notebook intermediário com RTX 4060 ou um desktop antigo com RTX 2070 agora roda um modelo multimodal unificado com janela de contexto de 256 mil tokens — algo que, em 16 bits, beirava os 24 GB.

GPUs de 12–16 GB: O modelo MoE 26B A4B ocupa cerca de 15 GB em Q4_0, encaixando em placas como RTX 3080, 4070 Ti ou 4080 . Por ativar poucos parâmetros por token, a latência de inferência também é muito menor do que a de um modelo denso de pegada similar .

GPUs de 20–24 GB: O modelo denso de 31B pede entre 17 e 18 GB em Q4_0, ficando acessível para donos de RTX 3090 e 4090, com alguma folga para KV cache e tamanho de lote . Em 16 bits, esse modelo exigiria quase 60 GB — impensável para GPUs de consumo. O QAT torna o maior modelo da família Gemma 4 genuinamente viável em uma única placa de alto desempenho.

Ponto de atenção: Os números de memória falam do tamanho dos pesos do modelo, não do consumo total de VRAM. A sobrecarga de execução — especialmente o KV cache em contextos longos — pode adicionar vários gigabytes extras. Com 256K de contexto, por exemplo, o modelo de 31B pode chegar perto de 22 GB de uso real . Sempre deixe uma margem de segurança além dos valores listados.

Preservação de qualidade e limites práticos

A promessa central do QAT — performance quase idêntica ao original com um corte de aproximadamente 72% na memória — é sustentada pelos números da comunidade. Os benchmarks indicam perda de qualidade na faixa de 3% a 5% na comparação entre Q4 e BF16 .

Mas o diabo mora nos detalhes. O alerta da Unsloth — 70,2% de acurácia top-1 contra 85,6% após a otimização Dynamic — mostra que a qualidade final depende profundamente de como você converte e implanta os pesos . Se alguém simplesmente pegar um checkpoint QAT e passar por um conversor GGUF padrão sem os cuidados adequados, não obterá a qualidade esperada.

Para uso em produção, a abordagem mais segura é usar os checkpoints oficiais do Google no formato compressed-tensors (para vLLM) ou os arquivos GGUF oficiais do Hugging Face . Se precisar de uma quantização personalizada além do que o Google oferece, reserve tempo para benchmarks — pesos QAT são mais sensíveis à metodologia de conversão do que pesos quantizados por PTQ.

O que esse lançamento libera na prática

Este lançamento muda a resposta padrão para a pergunta “consigo rodar esse modelo localmente?”. Pela primeira vez, uma grande família de modelos de código aberto chega com checkpoints QAT como produto de primeira classe, não como um improviso posterior. As implicações se espalham por várias categorias:

Cenários com exigência de privacidade: Aplicações médicas, jurídicas e assistentes pessoais que antes dependiam de APIs na nuvem agora podem rodar inteiramente no dispositivo — seja um notebook ou um celular —, com qualidade suficiente para que a inferência local seja realmente útil .

Campo e ambientes desconectados: Pesquisas de campo, resposta a desastres e uso industrial sem conectividade confiável agora podem implantar modelos multimodais em hardware comum. O suporte a áudio do E2B, combinado com a quantização mobile de 1 GB, torna a tradução de voz em tempo real uma realidade prática mesmo em telefones intermediários .

Ferramentas de desenvolvimento e IDEs: Os modelos 12B e 26B cabem no hardware que os desenvolvedores já têm, permitindo autocompletar, refatoração e geração de documentação rodando localmente, sem custo e sem latência de rede. O próprio Google posiciona as versões quantizadas para “IDEs, assistentes de código e fluxos de trabalho com agentes” .

Experimentação e ajuste fino (fine-tuning): Times de pesquisa menores e desenvolvedores independentes que não podem pagar por clusters de A100 ou H100 agora conseguem trabalhar com modelos de 12B a 31B em hardware de consumo. Isso reduz enormemente a barreira de entrada para personalização e fine-tuning de domínio específico.

Os checkpoints foram lançados sob a mesma licença Apache 2.0 dos modelos Gemma 4 originais e estão disponíveis agora no Hugging Face, nos cinco tamanhos .