Gemma 4 no Codex CLI: execução local funciona, mas ainda é mais fraca que a nuvem

O Gemma 4 local já é capaz de funcionar no Codex CLI como um agente para codificação cotidiana: ler arquivos, escrever patches e executar testes. Mas um experimento com dois setups diferentes mostrou que o fato de rodar é apenas metade do sucesso. Em termos de confiabilidade, precisão de código e qualidade de resultado na primeira tentativa, o GPT-5.

4 baseado em nuvem ainda permanece notavelmente à frente. O autor do teste quis verificar não um "desenvolvimento IA local" abstrato, mas um cenário bem fundamentado: o modelo pode substituir a API em nuvem no trabalho diário com Codex CLI. A motivação é clara: custos de tokens, requisitos de privacidade e dependência de serviços externos.

Para verificar, duas configurações foram montadas. A primeira — MacBook Pro com chip M4 Pro e 24 GB de memória, onde Gemma 4 26B MoE era executado em quantização Q4_K_M via llama.cpp.

A segunda — Dell Pro Max GB10 com 128 GB unified memory e NVIDIA Blackwell, onde Gemma 4 31B Dense era usado via Ollama 0.20.5.

Em ambos os casos, o modelo foi conectado ao Codex CLI como provedor customizado em modo responses API. Montar a stack local provou não ser tão direto. No Mac, a versão Ollama quebrava em tool calling por bugs de streaming e travava em prompts longos, e para Codex CLI isso é crítico: um único prompt de sistema lá ocupa cerca de 27 mil tokens.

A solução funcional acabou sendo llama.cpp com ajuste manual de flags, web_search desabilitado e contexto de 32.768 tokens.

No GB10 também nem tudo funcionou na primeira: vLLM esbarrou em incompatibilidade entre builds PyTorch e CUDA para Blackwell, e llama.cpp montado manualmente processava inadequadamente certos tipos de ferramentas. Como resultado, a solução mais prática novamente foi não a stack "ideal", mas aquela que simplesmente funcionou — Ollama.

O benchmark foi conduzido em 12 de abril de 2026 no Codex CLI v0.120.0.

Através de codex exec --full-auto, todas as três configurações receberam a mesma tarefa — escrever uma função Python parse_csv_summary com tratamento de erros, depois preparar testes e executá-los. O GPT-5.4 em nuvem com reasoning effort alto teve o melhor desempenho: entregou código limpo com type hints, cadeia adequada de exceções e passou em todos os cinco testes na primeira tentativa em 65 segundos.

O Gemma 4 31B local no GB10 também entregou um resultado funcional na primeira passagem, mas mais simples em qualidade: sem type hints e sem reconhecimento de valores booleanos. Porém, todos os cinco testes também passaram imediatamente, e a execução levou cerca de sete minutos e três tool calls. O mais problemático foi o Mac com 26B MoE: o modelo deixava código morto, reescrevia o arquivo de teste várias vezes e cometia typos ridículos como nome de variável quebrado ou string encoding incorreta.

No total, a tarefa levou 4 minutos 42 segundos mas exigiu 10 tool calls e cinco tentativas falhadas de escrever os testes. Interessantemente, o Mac superou inesperadamente o GB10 mais poderoso em velocidade "bruta". Em llama-bench, 26B MoE no Mac entregava cerca de 52 tokens por segundo versus 10 tokens em 31B Dense no GB10, e ao processar um prompt em contexto 8K, as máquinas iam quase iguais — 531 versus 548 tokens por segundo.

A explicação está na arquitetura Mixture of Experts: com MoE, apenas parte dos parâmetros ativa a cada passo, então a quantidade de dados que precisa ser puxada da memória por token é drasticamente reduzida. Mas essa vantagem quase não ajudou na tarefa real porque o tempo principal foi consumido não por computação, mas por erros do modelo, repeated tool calls e correções desnecessárias ao longo do caminho. A conclusão principal aqui é dupla.

Por um lado, Gemma 4 realmente deslocou codificação local com agentes da categoria "quebra quase sempre" para a categoria "dá para conviver com isso": o autor nos lembra que em tau2-bench, o desempenho de function calling para Gemma 3 era 6,6%, enquanto para Gemma 4 31B era 86,4%. Por outro lado, em desenvolvimento prático, confiabilidade na primeira tentativa importa mais que registros tokens-por-segundo. Portanto, modo local já parece realista para tarefas privadas, iterações rápidas e trabalho sem gastos constantes com API, mas em cenários complexos modelos em nuvem ainda permanecem mais fortes por enquanto.

A conclusão mais razoável do teste parece ser modo híbrido: modelo local para algumas tarefas, nuvem — como ferramenta primária onde o custo do erro supera velocidade ou privacidade.