Executando o Gemma 4 como modelo local no Codex CLI

• Um caso de uso que validou o desempenho e a estabilidade de chamadas de ferramentas ao executar o Gemma 4 em um ambiente local do Codex CLI em vez da nuvem, confirmando vantagens de custo e privacidade em relação ao GPT-5.4
• No Mac (M4 Pro) 24GB com o 26B MoE e no NVIDIA GB10 128GB com o 31B Dense, a mesma tarefa de geração de código foi executada usando llama.cpp e Ollama, respectivamente, comparando o desempenho conforme as diferenças de configuração
• A taxa de sucesso de chamadas de ferramentas melhorou de 6,6% para 86,4%, comprovando a viabilidade prática de modelos locais, e no ambiente GB10 foi possível gerar código completo
• O Mac mostrou velocidade de geração de tokens 5,1 vezes maior, mas por limitações de memória e configurações de quantização exigiu tentativas repetidas; o GB10 foi mais lento, porém acertou já na primeira tentativa
• Como resultado, modelos locais também conseguem gerar código em nível profissional, e é recomendada uma abordagem híbrida que combine processamento local focado em privacidade com a migração de tarefas complexas para a nuvem

---

Motivação para migrar para modelos locais

• Havia um problema de custo, porque executar o Codex CLI em várias sessões por dia, às vezes em paralelo, fazia os custos de API se acumularem
• Havia exigências de privacidade, já que alguns codebases não podem ser enviados para servidores externos
• Era necessário garantir estabilidade, pois APIs em nuvem trazem riscos de throttling, indisponibilidade e mudanças de preço
• O motivo de não ter tentado antes modelos locais era a ausência de tool calling, e o principal valor do Codex CLI está em permitir que o modelo leia arquivos, escreva código, execute testes e aplique patches
• A geração anterior do Gemma tinha apenas 6,6% no benchmark de chamadas de função do tau2-bench (93 falhas em 100 tentativas), mas o Gemma 4 31B saltou para 86,4%, tornando o teste justificável

Processo de configuração no Mac

• A configuração começou com o Ollama, mas no v0.20.3 apareceu um bug de streaming em que as respostas de chamadas de ferramentas do Gemma 4 eram roteadas incorretamente como reasoning output em vez do array tool_calls
• Ao usar o Gemma 4 no Apple Silicon, ocorria travamento do Flash Attention com prompts de cerca de mais de 500 tokens; como o prompt de sistema do Codex CLI tem cerca de 27.000 tokens, isso o tornava praticamente inutilizável
• Depois houve migração para o llama.cpp, instalado via Homebrew, e o comando de servidor funcional exigiu 6 flags principais
  • -np 1: limita a 1 slot; múltiplos slots multiplicam o uso de memória do cache KV
  • -ctk q8_0 -ctv q8_0: quantização do cache KV, reduzindo de 940MB para 499MB
  • --jinja: essencial para o template de chamadas de ferramentas do Gemma 4
  • É necessário indicar diretamente o caminho do GGUF em -m; ao usar a flag -hf, um projetor de visão de 1,1GB é baixado automaticamente, causando crash por OOM
• Na configuração do Codex CLI, web_search = "disabled" é obrigatório, porque o Codex CLI envia o tipo de ferramenta web_search_preview, que o llama.cpp rejeita

Processo de configuração no GB10

• O vLLM 0.19.0 foi compilado com base no PyTorch 2.10.0, mas o PyTorch com suporte a CUDA para aarch64 Blackwell (compute capability sm_121) existe apenas no 2.11.0+cu128, causando incompatibilidade de ABI e ImportError
• Ao compilar o llama.cpp com CUDA a partir do código-fonte, compilação e benchmark passam, mas o wire_api = "responses" do Codex CLI envia tipos de ferramenta que não são função, e o llama.cpp os rejeita
• O sucesso veio com o Ollama v0.20.5, e o bug de streaming visto no Apple Silicon não se reproduziu na NVIDIA
  • Após executar ollama pull gemma4:31b, a porta 11434 foi encaminhada para o Mac por túnel SSH (porque o modo --oss do Codex CLI verifica apenas localhost)
  • Com codex --oss -m gemma4:31b, tanto a geração de texto quanto as chamadas de ferramentas funcionaram de primeira
• A configuração no Mac consumiu quase toda uma tarde, enquanto no GB10 levou cerca de 1 hora, incluindo a espera pelo download do modelo

Resultados do benchmark

• A mesma tarefa foi dada às três configurações: usar codex exec --full-auto para escrever a função Python parse_csv_summary, incluindo tratamento de erros, além de criar e executar testes
• GPT-5.4 (nuvem): gerou código com type hints, encadeamento apropriado de exceções, detecção de tipo booleano e funções auxiliares limpas; passou nos 5 testes na primeira tentativa, concluiu em 65 segundos e não exigiu limpeza posterior
• GB10 31B Dense: sem type hints nem detecção de booleano, mas com tratamento de erros robusto e sem código morto; passou nos 5 testes na primeira tentativa com 3 chamadas de ferramentas, levando 7 minutos
• Mac 26B MoE: deixou código morto na implementação; escreveu um loop de inferência de tipos, abandonou-o e reescreveu abaixo com o comentário "Actually, let's simplify"; foram necessárias 5 tentativas para criar o arquivo de testes
  • Em cada vez surgia um erro diferente de heredoc: filerypt → file_path, encoding=' 'utf-8' (espaço inserido), fileint(file_path) etc.
  • Uma tarefa que o GB10 concluiu em 3 chamadas exigiu 10 chamadas de ferramentas
  • Esse resultado corresponde ao ambiente Codex CLI com Q4_K_M em 24GB e não deve ser tomado como uma avaliação geral do Gemma 4 no Apple Silicon

Análise de velocidade: por que o Mac foi mais rápido do que o esperado

• Com o llama-bench, as duas máquinas foram medidas no mesmo comprimento de contexto, e o Mac gerou tokens 5,1 vezes mais rápido que o GB10
• Ambas as máquinas têm largura de banda de memória LPDDR5X de 273 GB/s, e a geração de tokens é uma tarefa limitada por largura de banda de memória
  • O 31B Dense lê todos os 31,2 bilhões de parâmetros a cada token (cerca de 17,4GB)
  • O 26B MoE ativa apenas 3,8 bilhões por token (cerca de 1,9GB)
  • Na mesma largura de banda, o Mac registrou 52 tok/s e o GB10 10 tok/s
• A velocidade de processamento de prompt também surpreendeu a favor do Mac: em contexto de 8K, Mac 531 tok/s vs GB10 548 tok/s, com a ativação esparsa do MoE favorecendo também o processamento do prompt

Lição principal: mais importante que a velocidade de token é acertar na primeira tentativa

• Embora o Mac gere tokens 5,1 vezes mais rápido, o tempo total de conclusão caiu apenas 30% (4 min 42 s vs 6 min 59 s)
• A causa da diferença de tempo foi a necessidade de novas tentativas: 10 chamadas de ferramentas vs 3, 5 falhas ao escrever testes e código morto que o modelo não limpou
• O modelo em nuvem prova isso de forma ainda mais clara: foi o mais rápido, usou menos tokens, não precisou de passes de correção e concluiu 5/5 em 65 segundos
• Ainda assim, o local já é prático, e em ambas as máquinas foi possível gerar código funcional que passou nos testes
• O salto de qualidade do Gemma 3 (6,6% em tool calling) para o Gemma 4 (86,4%) foi o ponto de virada decisivo; a passagem de "não funciona" para "funciona" é a transição que torna prática a programação agentic local
• Há uma observação importante sobre o resultado do Mac: Q4_K_M era a maior quantização que cabia em uma máquina de 24GB, e rodar de novo em um Apple Silicon com mais memória e quantização mais alta pode produzir resultados diferentes
• Uma abordagem híbrida é possível: usar codex --profile local para tarefas repetitivas e sensíveis à privacidade, e manter o padrão em nuvem para tarefas complexas; com o sistema de perfis do Codex CLI, a troca exige apenas uma flag

Dicas práticas de configuração

• Apple Silicon: o Ollama não foi utilizável com o Gemma 4, e a recomendação é llama.cpp + --jinja
  • Definir web_search = "disabled" no perfil do Codex CLI
  • Indicar diretamente o caminho do GGUF com -m; não usar -hf
  • Configurar contexto de 32.768 (o prompt de sistema do Codex CLI exige no mínimo 27.000 tokens)
  • Quantização do cache KV: -ctk q8_0 -ctv q8_0
• NVIDIA GB10: o Ollama v0.20.5 foi o primeiro caminho estável que funcionou; usar codex --oss -m gemma4:31b e, se a máquina for remota, fazer túnel SSH da porta 11434
• Na configuração do provider, é necessário definir stream_idle_timeout_ms para no mínimo 1.800.000, porque no Mac um único ciclo de chamada de ferramenta levou 1 min 39 s, encerrando a sessão com o timeout padrão
• Recomenda-se fixar a versão do llama.cpp; foi relatada queda de desempenho de 3,3 vezes entre builds, então benchmarks podem mudar de um dia para o outro

[tsboard]

Quando testei o Gemma4-31B na empresa com 2 H100,

1. A qualidade das respostas é bem decente e ele lida bem com coreano.
2. Também é bom em decidir sobre a execução de ferramentas e em organizar os resultados depois da execução.
3. Mas isso é no nível de “surpreendente considerando que são só 31B de parâmetros!”, e, claro, quando comparado a modelos com mais parâmetros (ex.: MiniMax-M2.5), é verdade que fica atrás em qualidade geral das respostas e afins.

No geral, se você quer algo pequeno e ágil, o Gemma4 deve ser suficiente. Eu troquei de GPT-OSS-120B → Qwen3.5-35B-A3B e agora me estabeleci no Gemma4-31B, e fiquei bastante satisfeito. Acho que vou continuar usando.

[kaydash]

Nossa, não dá para usar busca na web? Mesmo configurando o searxng também não funciona?

[ysm0622]

https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md

Experimente usar isto como alternativa para essa skill haha

[yangeok]

Queria verificar se também funciona bem em coreano.

[GN⁺]

Comentários no Hacker News

• O Gemma 4 26B mostrou um desempenho realmente excepcional entre modelos da mesma escala de parâmetros
  Em benchmarks internos, obteve pontuações parecidas com GPT 5.2 e Gemini 3 Pro Preview, mas foi fraco em codificação orientada a agentes e em áreas de tomada de decisão não relacionadas a código
  Teve pontuação baixa em uso de ferramentas, melhoria iterativa e gerenciamento de contexto amplo, e seu desempenho caía justamente em situações em que precisava usar ferramentas
  Provavelmente parece ter sofrido overfitting em harnesses ou benchmarks comuns. Ainda assim, a velocidade em Macbooks da série M é impressionante
  Os benchmarks podem ser vistos em gertlabs.com

  • No meu teste de “hello world”, ele falhou
    O problema era “implementar uma calculadora de bin fitting unidimensional em uma única página web”; Qwen3.5, Nematron, Step 3.5 e gpt-oss passaram, mas o Gemma não
  • No geral, é um bom modelo open-weight
    Mas no meu M5 ele cometeu erros simples de programação com mais frequência do que o GPT-OSS. Mesmo assim, no conjunto, está em um nível próximo
  • Fiquei surpreso que o Gemma 31B tenha tirado nota menor que o 26B-A4B

• Houve quem dissesse que é surpreendente o resultado de que “a qualidade do modelo é mais importante do que a velocidade de tokens”
  Na verdade, isso soa bastante óbvio. Em vez de limitar o contexto a 32k, também dá para fazer offload das operações MoE para a CPU com a opção --cpu-moe

  • Acho que a velocidade de tokens, no fim, só afeta a velocidade de conclusão da tarefa
  • É como tomar café quando se está cansado. Você continua cansado, só que se move “mais rápido”
  • Do ponto de vista de quem usa Codex todos os dias, é muito mais importante que o modelo não caia em loops inúteis do que ele ser rápido
    Se só a velocidade de tokens for alta, no fim haverá uma explosão de “codebases de código ruim gerado por IA”

• Atualmente estou testando google/gemma-4-26b-a4b em um M3 Ultra (48GB RAM) com LM Studio e Opencode
  Precisei aumentar o contexto para 65536, mas está funcionando bem. Também integra facilmente com Zed e ACP
  Estou usando principalmente para reviews simples de código e geração de código frontend

  • Estou em um ambiente parecido. Vale a pena testar o pi-coding-agent
    O prompt de sistema e o overhead das ferramentas ficam abaixo de 2k tokens, então a latência de prefill é muito menor
  • Estou usando em uma AMD RX7900XTX (24GB VRAM), rodando 4 chats ao mesmo tempo com contexto de 512K
    A velocidade é de cerca de 100t/s, praticamente instantânea, e estou usando cada vez menos o Claude Code
  • Testei no Macbook M1 com a versão MLX integrada ao XCode, mas ele travava no meio do caminho em codebases iOS pequenas
    Como chatbot é aceitável, mas foi inadequado para integração com o XCode
  • Testei a versão completa 31B em uma GPU da Runpod e fiquei impressionado
    Agora estou aproveitando as 1500 requisições gratuitas por dia via Google API
  • Estou usando a mesma configuração em um MacBook Pro M4 Max (64GB)
    Antes da atualização do LM Studio 0.4.11+1, as tool calls não funcionavam, mas agora tanto o Codex quanto o Opencode funcionam bem

• É incorreto dizer que “modelos locais não conseguem fazer tool calling”
  Já faço tool calling localmente há 2 anos, e dizer que o Gemma3 tem taxa de sucesso de 7% nisso não faz sentido
  Até no Llama3.3 deu pelo menos 75%

  • Também fiquei surpreso com essa frase. Talvez o autor tenha sido a primeira vez rodando um modelo local
    Modelos excessivamente quantizados, como o Gemma 4 gguf Q4 (16GB), perdem muito desempenho
  • Mesmo assim, é verdade que há uma grande diferença no benchmark de function calling Tau entre o Gemma 3 e o 4
  • O texto inteiro parecia gerado automaticamente por IA
    Se você tiver equipamento GB10, recomendo usar a configuração spark-vllm-docker ou a versão otimizada do Qwen 3.5 122B A10B. Roda a cerca de 50tk/s, o que é bem rápido

• Fiz upgrade de um M4 Pro (24GB) para um M5 Pro (48GB), e o mesmo Gemma 4 MoE (Q4) mostrou 8x mais t/s
  A velocidade de carregamento do disco para a memória também melhorou 2x

  • Se você tiver bastante RAM, recomendo rodar diretamente em Q8_0. Tirando o carregamento inicial, não fica lento e a qualidade é quase a mesma
    Vale conferir se está usando a versão MLX. A versão quantizada pela comunidade do mlx-lm foi corrigida recentemente
    No meu Macbook M1 de 16GB foi difícil, mas no AMD Framework 13 com 64GB RAM, só com CPU, roda rápido o suficiente
    O recurso de cache de prompt é útil ao inserir prompts de sistema grandes

• Foi proposta a ideia de um harness que mantém o hardware local rodando 24/7, automatiza experimentos com modelos como o Gemma 4 e deixa as decisões maiores para o Claude Opus
  A estrutura seria: o modelo local executa pequenos experimentos e POCs, e, quando trava, pede ajuda ao Opus
  Assim, dá para controlar totalmente o cache de prompt, então o custo fica quase zero

  • Nico Bailon, desenvolvedor da expansão do Pi coding agent do Mario, está tentando algo parecido
    Dá para ver o vídeo de demonstração e o repositório pi-model-switch

• Para programação, quantizações abaixo de Q6_K não fazem sentido
  Em quantizações mais baixas, a taxa de erro de código sobe drasticamente

  • A maioria das pessoas não sabe disso. A qualidade do token importa mais do que a quantidade de tokens
    Vale usar a quantização mais alta possível dentro do limite de memória

• Seria bom ver uma comparação de qualidade por método de quantização, como Q4_K_M, Q8_0 e Q6_K. Parece mais útil do que simples números de tok/s

• Tenho curiosidade sobre a comparação entre Qwen3.5 e Gemma 4
  Em especial, o modelo Qwen3.5-27B-Claude-4.6-Opus é especializado em tool calling e já passou de 500 mil downloads

  • Estou vendo o guia de fine-tuning publicado pelo Jackrong. Está bem organizado, com exemplos em notebook inclusive
  • Eu mesmo testei no DGX Spark, mas no fim voltei para o Gemma 4
    Os modelos Qwen pediam correções de erro com frequência durante a orquestração, o que reduzia a produtividade
    Rodei com os pesos para Ollama
  • A alegação de que um desenvolvedor individual tirou mais desempenho do que um grande laboratório de pesquisa parece um pouco duvidosa
    A versão mais recente é Qwopus3.5-27B-v3

• Usei o Gemma 4 por alguns dias, e ele é rápido e inteligente, mas os problemas no uso de ferramentas continuam
  Mais do que a velocidade, a inteligência é o limite, então a produtividade fica restrita. Ele entra em loop com frequência
  Seria bom poder detectar esse tipo de situação e “pedir ajuda” a um modelo mais inteligente
  Agora trabalho mais como orquestrador de agentes do que como programador. Meu papel é gerenciar vários agentes rodando em paralelo

  • O Google trocou recentemente o chat_template.jinja e o tokenizer_config.json do gemma-4-31B-it
    Disseram que corrigiram os problemas relacionados a tool calling, então é bom atualizar o modelo

[boolsee]

É fácil configurar um LLM local com o ollama, mas dizem que há uma grande chance de a chamada de ferramentas falhar dependendo do modelo open source. Pelo visto, isso acontece por causa de uma combinação entre regras flexíveis dentro do ollama e problemas no parser de chamadas de ferramentas específicos de cada modelo.
No fim das contas, o problema mais fundamental dos LLMs locais é que, para rodar modelos de porte médio a grande, é preciso ter hardware caro. Um Mac Studio de 32 GB custa na faixa de 3 milhões e meio de won, e o GB10 fica em torno de 5 a 6 milhões de won, então é pesado para uma pessoa comprar só por hobby (?). Para LLMs locais, o caminho é usar modelos pequenos; para modelos médios e grandes, fora da nuvem não há muita alternativa.