Gemma 4 no Codex CLI: rodar localmente funciona, mas ainda perde para a nuvem

A Gemma 4 local já consegue funcionar no Codex CLI como agente para programação do dia a dia: ler arquivos, escrever patches e rodar testes. Mas um experimento com dois ambientes diferentes mostrou que fazer o modelo rodar é só metade do sucesso. Em confiabilidade, cuidado com o código e qualidade do resultado na primeira tentativa, o GPT-5.4 na nuvem continua claramente à frente.

O autor não queria testar um "desenvolvimento local com IA" abstrato, mas um cenário bem pé no chão: o modelo pode substituir uma API em nuvem no trabalho diário com o Codex CLI? A motivação é fácil de entender: custo dos tokens, requisitos de privacidade e dependência de serviços externos.

Foram montadas duas configurações para o teste. A primeira, um MacBook Pro com chip M4 Pro e 24 GB de memória, rodando a Gemma 4 26B MoE com quantização Q4_K_M via llama.cpp. A segunda, um Dell Pro Max GB10 com 128 GB de memória unificada e NVIDIA Blackwell, rodando a Gemma 4 31B Dense via Ollama 0.20.5. Nos dois casos, o modelo foi conectado ao Codex CLI como provedor personalizado no modo responses API.

Subir a stack local não foi simples. No Mac, o Ollama quebrava no tool calling por bugs de streaming e travava com prompts longos, o que é crítico para o Codex CLI: só o prompt de sistema ocupa cerca de 27 mil tokens. A opção que acabou funcionando foi o llama.cpp com flags ajustadas manualmente, web_search desativado e contexto de 32.768 tokens.

No GB10 também nem tudo funcionou de primeira: o vLLM esbarrou na incompatibilidade entre as builds de PyTorch e CUDA para Blackwell, e um llama.cpp compilado manualmente processava de forma inadequada alguns tipos de ferramentas. Mais uma vez, a solução mais prática não foi a stack "ideal", mas a que simplesmente funcionou: o Ollama.

O benchmark foi realizado em 12 de abril de 2026, no Codex CLI v0.120.0. Com codex exec --full-auto, as três configurações receberam a mesma tarefa: escrever a função Python parse_csv_summary com tratamento de erros, depois preparar testes e rodá-los.

O GPT-5.4 na nuvem, com reasoning effort alto, se saiu melhor: entregou código limpo, com type hints e uma cadeia de exceções adequada, e passou nos cinco testes na primeira tentativa em 65 segundos.

A Gemma 4 31B local no GB10 também entregou um resultado funcional na primeira passada, mas de qualidade inferior: sem type hints e sem reconhecimento de valores booleanos. Em compensação, os cinco testes também passaram de imediato, e a execução levou cerca de sete minutos e três tool calls.

O mais problemático foi o Mac com o 26B MoE: o modelo deixou código morto, reescreveu o arquivo de testes várias vezes e cometeu erros bobos de digitação, como um nome de variável quebrado ou uma string de encoding incorreta. A tarefa levou 4 minutos e 42 segundos, mas exigiu 10 tool calls e cinco tentativas fracassadas de escrever os testes.

O mais interessante é que, em velocidade "bruta", o Mac superou inesperadamente o GB10, que é mais potente. No llama-bench, o 26B MoE no Mac gerava cerca de 52 tokens por segundo contra 10 tokens do 31B Dense no GB10, enquanto no processamento de prompt com contexto de 8K as máquinas ficaram quase empatadas: 531 contra 548 tokens por segundo. A explicação está na arquitetura Mixture of Experts: o MoE ativa apenas parte dos parâmetros a cada passo, então o volume de dados que precisa ser lido da memória por token é bem menor.

Mas essa vantagem quase não ajudou na tarefa real, porque a maior parte do tempo foi gasta não em cálculo, mas em erros do modelo, tool calls repetidas e edições desnecessárias ao longo do trabalho.

A conclusão principal é dupla. Por um lado, a Gemma 4 tirou a programação agêntica local da categoria "quebra quase sempre" e a levou para a de "dá para conviver": o autor lembra que, no tau2-bench, o resultado de function calling da Gemma 3 era de 6,6%, contra 86,4% da Gemma 4 31B. Por outro, no desenvolvimento prático importa mais a confiabilidade na primeira tentativa do que um recorde de tokens por segundo.

Por isso, o modo local já parece realista para tarefas privadas, iterações rápidas e trabalho sem custos contínuos de API, mas em cenários complexos os modelos em nuvem continuam mais fortes. A conclusão mais sensata do teste é um modo híbrido: um modelo local para parte das tarefas e a nuvem como ferramenta principal onde o custo do erro pesa mais que a velocidade ou a privacidade.