Google DeepMind lanzó Gemma 4 el 2 de abril de 2026, y la comunidad de IA local inmediatamente se puso a correrlo en Apple Silicon. El thread de Hacker News se calentó rápido — 139 puntos, 51 comentarios, y una actualización muy honesta del autor: el modelo 26B mató su Mac mini.
Esa es la historia real acá, y es más útil que una guía de setup cualquiera. Porque si tenés 16GB, 24GB o 32GB de memoria unificada, eso cambia completamente qué variante de Gemma 4 deberías usar.
Te lo desglosamos.
Qué es Gemma 4 y por qué importa
Gemma 4 es la última familia de modelos open de Google DeepMind, lanzada bajo licencia Apache 2.0 — libertad comercial total, sin restricciones de licencia. Viene en cuatro tamaños:
- E2B — modelo edge, ~3GB, para hardware muy limitado
- E4B — modelo edge, ~5GB, el sweet spot para laptops de 8–16GB
- 26B MoE — el modelo estrella. 26 mil millones de parámetros totales, pero solo ~3.8B se activan por inferencia via arquitectura Mixture-of-Experts. Calidad cercana a 30B a velocidad y uso de memoria de un modelo de 8B.
- 31B Dense — máxima calidad, todos los parámetros activos. Necesita hardware serio.
El 26B MoE es el que tiene a todos entusiasmados, y con razón — calidad near-30B a una fracción del costo de memoria. En papel. En la práctica, el panorama depende mucho de tu máquina.
La realidad de la RAM: elegí tu variante
| RAM | Variante recomendada | Tamaño descarga | Experiencia |
|---|---|---|---|
| 16GB | E4B (Q8) | ~5GB | Cómodo, rápido |
| 24GB | 8B default (Q4_K_M) | ~9.6GB | Cómodo, ~14GB de headroom |
| 24GB | 26B MoE (Q4_K_M) | ~17GB |  Entra en reposo, crashea bajo carga |
| 32GB+ | 26B MoE (Q4_K_M) | ~17GB | Sólido, context window de 8K–16K |
| 48GB+ | 31B Dense (Q4) | ~20GB | Calidad máxima, contexto generoso |
El veredicto honesto para 24GB: El 26B MoE técnicamente entra en memoria pero deja apenas ~7GB para macOS. Con requests concurrentes de Ollama — múltiples pestañas, agentes de código, cualquier cosa corriendo en paralelo — el sistema empieza a hacer swap pesado, se vuelve irresponsivo y puede matar procesos. El autor del thread de HN lo testeó un día entero y bajó al 8B default, que deja ~14GB de headroom y corre sin drama.
Si tenés 24GB, el 8B default es la elección pragmática. Si tenés 32GB, ahí sí el 26B es el objetivo.
Setup: Ollama en Apple Silicon
Ollama es el camino más simple. Desde la v0.19, usa el framework MLX de Apple automáticamente — no necesitás configuración extra.
# Instalá via Homebrew
brew install --cask ollama
# Descargá tu variante (elegí una)
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
# Verificá que la aceleración GPU esté activa
ollama run gemma4 "Hola, ¿qué modelos conocés?"
ollama ps # Tiene que mostrar el split CPU/GPU muy cargado hacia GPU
Importante: Verificá que estés en Ollama v0.20.2 o superior. Había un bug en las respuestas de tool calls con Gemma 4, y querés el fix antes de empezar a debuggear outputs raros.
Configuración clave: mantené el modelo en memoria
Por defecto, Ollama descarga los modelos de memoria después de 5 minutos de inactividad. Recargar un modelo de 26B tarda 15–30 segundos — molesto si lo estás usando como dev server. Dos fixes:
Variables de entorno (agregá a ~/.zshrc):
# Offload la mayor cantidad posible de capas a GPU (memoria unificada = siempre querés esto)
export OLLAMA_NUM_GPU=99
# Mantené el modelo cargado indefinidamente (podés poner algo como "30m" si preferís)
export OLLAMA_KEEP_ALIVE=0
LaunchAgent para auto-start y precarga:
# Habilitá Ollama al login via el ícono en la barra de menú → Launch at Login
# Después creá un agente de precarga para mantener el modelo caliente:
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
Esto manda un prompt vacío cada 5 minutos, manteniendo el modelo residente en memoria. Corré ollama ps para confirmarlo — deberías ver tu modelo con estado Forever.
Context window personalizado (solo 32GB+)
El contexto por defecto en Ollama es 2048 tokens. Con 32GB+ y la variante 26B, podés subir ese límite:
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
Mirá Activity Monitor → Memory Pressure mientras testeás. Si se pone amarillo, bajá el contexto. Con 32GB el sweet spot de 8K es sólido; con 48GB+ podés ir cómodo a 16K.
La realidad de Gemma 4 para coding agents
Acá hay que ir con cuidado. El thread de HN está lleno de gente que intentó conectar Gemma 4 a OpenCode, LM Studio, u otros frontends de coding y se encontró con fallas en los tool calls.
LM Studio reporta fallas 100% en tool calls por el momento (un error en el template Jinja). Ollama v0.20.2 arregla un bug específico de tool calls, pero los primeros reportes de la comunidad sobre performance en coding agents son mixtos — varios volvieron a Qwen para tareas de código.
La familia Gemma 4 es muy nueva. Estos son dolores de crecimiento que se van a resolver en las próximas semanas a medida que las implementaciones se estabilicen. Por ahora: Gemma 4 es excelente para procesamiento de texto, extracción de datos, output JSON y razonamiento general. Para coding agents con tool use complejo, esperá a que se asiente el polvo en tu frontend preferido antes de comprometerte.
Referencia de performance (llama.cpp en M5 32GB)
Un desarrollador en el thread de HN corriendo gemma4-26B-A4B-it-GGUF:Q4_K_M via llama.cpp en un M5 Mac con 32GB reportó ~38 tokens por segundo — suficientemente rápido para sentirse genuinamente interactivo. Esa es la velocidad de generación; el procesamiento de prompts es más rápido.
Para referencia: el Mac Mini M4 Pro de $1,399–$1,599 con 24GB de memoria unificada corriendo el modelo 8B da un setup de dev server cómodo, sin ruido y sin costos de API.
Resumen
Elegí tu variante antes de hacer ollama pull:
- Mac 16GB:
gemma4:e4b— sin drama - Mac 24GB:
gemma4(8B default) — cómodo, la elección honesta - Mac 32GB+:
gemma4:26b— el modelo estrella, funciona de verdad - Mac Studio 48GB+:
gemma4:31b— calidad máxima, sin compromisos
Configurá OLLAMA_NUM_GPU=99, ajustá el keep-alive, agregá el LaunchAgent si querés el modelo caliente desde el arranque. Actualizá a Ollama v0.20.2+ antes de testear tool use.
Tener un modelo de clase 26B corriendo localmente con cero costos de API y privacidad total de datos es genuinamente útil. Solo elegí la variante correcta para tu hardware.
Fuentes: Thread de Hacker News — Gist original del autor — Guía de hardware Gemma 4 — Ollama library: gemma4