Google DeepMind lançou Gemma 4 em 2 de abril de 2026, e a comunidade de IA local imediatamente começou a rodá-lo em Apple Silicon. A thread no Hacker News se aqueceu rápido — 139 pontos, 51 comentários, e uma atualização bem honesta do autor: o modelo 26B matou seu Mac mini.
Essa é a história real aqui, e é muito mais útil do que qualquer guia de setup. Porque se você tem 16GB, 24GB ou 32GB de memória unificada, isso muda completamente qual variante do Gemma 4 você deveria usar.
Desmistu isso pra você.
O que é Gemma 4 e por que importa
Gemma 4 é a mais recente família de modelos abertos do Google DeepMind, lançada sob licença Apache 2.0 — liberdade comercial total, sem restrições de licença. Vem em quatro tamanhos:
- E2B — modelo edge, ~3GB, para hardware muito limitado
- E4B — modelo edge, ~5GB, o sweet spot para laptops de 8–16GB
- 26B MoE — o modelo estrela. 26 bilhões de parâmetros no total, mas apenas ~3.8B são ativados por inferência via arquitetura Mixture-of-Experts. Qualidade próxima a 30B com velocidade e uso de memória de um modelo de 8B.
- 31B Dense — máxima qualidade, todos os parâmetros ativos. Precisa de hardware bem mais robusto.
O 26B MoE é o que tem todo mundo entusiasmado, e com razão — qualidade próxima a 30B com uma fração do custo de memória. No papel. Na prática, o cenário depende muito da sua máquina.
A realidade da RAM: escolha sua variante
| RAM | Variante recomendada | Tamanho download | Experiência |
|---|---|---|---|
| 16GB | E4B (Q8) | ~5GB | Confortável, rápido |
| 24GB | 8B default (Q4_K_M) | ~9,6GB | Confortável, ~14GB livres |
| 24GB | 26B MoE (Q4_K_M) | ~17GB |  Entra em paging, trava sob carga |
| 32GB+ | 26B MoE (Q4_K_M) | ~17GB | Sólido, context window de 8K–16K |
| 48GB+ | 31B Dense (Q4) | ~20GB | Qualidade máxima, contexto generoso |
O veredicto honesto para 24GB: O 26B MoE tecnicamente entra em memória mas deixa apenas ~7GB para macOS. Com requests concorrentes do Ollama — múltiplas abas, agentes de código, qualquer coisa rodando em paralelo — o sistema começa a fazer paging pesado, fica irresponsivo e pode matar processos. O autor da thread do HN testou um dia inteiro e desceu para o 8B default, que deixa ~14GB livres e roda sem problemas.
Se você tem 24GB, o 8B default é a escolha pragmática. Se você tem 32GB, aí sim o 26B é o objetivo.
Setup: Ollama em Apple Silicon
Ollama é o caminho mais simples. Desde a v0.19, usa o framework MLX do Apple automaticamente — você não precisa de configuração extra.
# Instale via Homebrew
brew install --cask ollama
# Baixe sua variante (escolha uma)
ollama pull gemma4 # 8B default (~9,6GB) — para Macs de 24GB
ollama pull gemma4:26b # 26B MoE (~17GB) — para 32GB+
ollama pull gemma4:e4b # Edge 4B (~5GB) — para Macs de 16GB
# Verifique que a aceleração GPU está ativa
ollama run gemma4 "Olá, que modelos você conhece?"
ollama ps # Tem que mostrar o split CPU/GPU bem carregado para GPU
Importante: Verifique que você está na Ollama v0.20.2 ou superior. Havia um bug nas respostas de tool calls com Gemma 4, e você quer o fix antes de começar a debugar outputs estranhos.
Configuração chave: mantenha o modelo em memória
Por padrão, Ollama descarrega os modelos da memória depois de 5 minutos de inatividade. Recarregar um modelo de 26B leva 15–30 segundos — chato se você está usando como dev server. Dois fixes:
Variáveis de ambiente (adicione a ~/.zshrc):
# Descarregue o máximo possível de camadas para GPU (memória unificada = sempre quer isso)
export OLLAMA_NUM_GPU=99
# Mantenha o modelo carregado indefinidamente (você pode colocar algo como "30m" se preferir)
export OLLAMA_KEEP_ALIVE=0
LaunchAgent para auto-start e pré-carregamento:
# Ative o Ollama no login via ícone na barra de menu → Launch at Login
# Depois crie um agente de pré-carregamento para manter o modelo quente:
cat << 'EOF' > ~/Library/LaunchAgents/com.ollama.preload-gemma4.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key><string>com.ollama.preload-gemma4</string>
<key>ProgramArguments</key>
<array>
<string>/opt/homebrew/bin/ollama</string>
<string>run</string>
<string>gemma4:latest</string>
<string></string>
</array>
<key>RunAtLoad</key><true/>
<key>StartInterval</key><integer>300</integer>
<key>StandardOutPath</key><string>/tmp/ollama-preload.log</string>
<key>StandardErrorPath</key><string>/tmp/ollama-preload.log</string>
</dict>
</plist>
EOF
launchctl load ~/Library/LaunchAgents/com.ollama.preload-gemma4.plist
Isso envia um prompt vazio a cada 5 minutos, mantendo o modelo residente em memória. Rode ollama ps para confirmar — você deveria ver seu modelo com status Forever.
Context window personalizado (apenas 32GB+)
O contexto padrão no Ollama é 2048 tokens. Com 32GB+ e a variante 26B, você pode aumentar esse limite:
cat << 'EOF' > Modelfile
FROM gemma4:26b-q4_K_M
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF
ollama create gemma4-custom -f Modelfile
ollama run gemma4-custom
Olhe Activity Monitor → Memory Pressure enquanto testa. Se ficar amarelo, baixe o contexto. Com 32GB o sweet spot de 8K é sólido; com 48GB+ você pode ir confortavelmente a 16K.
A realidade do Gemma 4 para coding agents
Aqui você precisa ter cuidado. A thread do HN está cheia de pessoas que tentaram conectar Gemma 4 ao OpenCode, LM Studio, ou outros frontends de coding e encontraram falhas nos tool calls.
LM Studio relata falhas 100% em tool calls por enquanto (um erro no template Jinja). Ollama v0.20.2 conserta um bug específico de tool calls, mas os primeiros relatos da comunidade sobre performance em coding agents são mistos — vários voltaram para Qwen para tarefas de código.
A família Gemma 4 é muito nova. Esses são dores de crescimento que vão ser resolvidas nas próximas semanas enquanto as implementações se estabilizam. Por enquanto: Gemma 4 é excelente para processamento de texto, extração de dados, output JSON e raciocínio geral. Para coding agents com tool use complexo, espere a poeira assentar em seu frontend preferido antes de se comprometer.
Referência de performance (llama.cpp em M5 32GB)
Um desenvolvedor na thread do HN rodando gemma4-26B-A4B-it-GGUF:Q4_K_M via llama.cpp em um Mac M5 com 32GB reportou ~38 tokens por segundo — rápido o suficiente para se sentir genuinamente interativo. Essa é a velocidade de geração; o processamento de prompts é mais rápido.
Para referência: o Mac Mini M4 Pro de $1.399–$1.599 com 24GB de memória unificada rodando o modelo 8B oferece um setup de dev server confortável, sem ruído e sem custos de API.
Resumo
Escolha sua variante antes de fazer ollama pull:
- Mac 16GB:
gemma4:e4b— sem problemas - Mac 24GB:
gemma4(8B default) — confortável, a escolha honesta - Mac 32GB+:
gemma4:26b— o modelo estrela, funciona de verdade - Mac Studio 48GB+:
gemma4:31b— qualidade máxima, sem compromissos
Configure OLLAMA_NUM_GPU=99, ajuste o keep-alive, adicione o LaunchAgent se quiser o modelo quente desde o boot. Atualize para Ollama v0.20.2+ antes de testar tool use.
Ter um modelo de classe 26B rodando localmente com zero custos de API e privacidade total de dados é genuinamente útil. Apenas escolha a variante correta para seu hardware.
Fontes: Thread do Hacker News — Gist original do autor — Guia de hardware Gemma 4 — Ollama library: gemma4