Gemma 4 en local: la guía práctica para developers (de cero a hardware serio)

Cuando hablamos de modelos locales, hay uno que está muy popular ahora mismo: Gemma 4, la familia de modelos abiertos más capaz de Google. Por fin tenemos un modelo open-weights bueno de verdad para correr en nuestra propia máquina: gratis, offline y sin enviar datos a nadie.

En esta guía lo montamos paso a paso. Desde correrlo con un solo comando hasta exprimirlo con cuantización en hardware serio, pasando por los fine-tunes de la comunidad y el primo experimental de difusión. Todo orientado a developers: comandos reales, decisiones explicadas, y mi experiencia probándolo esta semana, sin relleno.

Para las pruebas más pesadas usé un NVIDIA DGX Spark que me prestaron mis amigos de Vastec, que me permitió instalar este tipo de modelos y medir su rendimiento a fondo, sobre todo para generar código.

1. Qué es Gemma 4 (y por qué me recuerda a Android)

Gemma 4 es la familia de modelos abiertos (licencia Apache 2.0) de Google DeepMind, construida con la misma investigación detrás de Gemini. La diferencia clave: Gemini vive en la nube y es propietario; Gemma corre en tu hardware.

Esto me recuerda mucho a lo que Google hace con Android. La estrategia es de doble vía: Gemini para despliegues cloud a escala y propietarios, Gemma 4 para uso abierto, on-device y self-hosted. No compiten, se complementan. Google ofrece el modelo abierto y guía el desarrollo de la plataforma, pero cualquiera puede construir encima.

En lo personal, Gemma 4 es como el Android de los modelos inteligentes.

Y como es abierto, lo que ha pasado es que mucha gente lo ha fine-tuneado (lo ha especializado). El modelo base puede hacer de todo: tareas de código, agentes (ejecutar comandos), es multimodal (lee imágenes, genera texto, soporta múltiples idiomas). Pero muchos lo han ajustado para mejorarlo en aspectos concretos. De ahí que existan tantas variaciones.

La familia (ojo con las versiones)

Aquí hay confusión real porque salieron por etapas:

En su propia documentación verás que se compara con otros modelos abiertos mucho más grandes, como Qwen o Kimi 2.5 Thinking. Pero recuerda: Gemma 4 es multimodal, no está enfocado en una sola tarea. No tiene todavía un objetivo bien definido, y por eso aparecen los fine-tunings.

2. Los tamaños: ¿cuál instalo?

Si entras a la página de Gemma 4 en Ollama o Hugging Face vas a encontrar todas las variaciones. Una aclaración importante sobre la "E" de E2B/E4B: viene de "efectivos". Significa que ese modelo está pensado para dispositivos chicos (laptops, móviles o equipos con muy poca RAM).

Un punto clave que casi nadie explica: la diferencia entre tamaños no es tanto la velocidad de respuesta, sino la calidad. Más parámetros = mejor respuesta, sobre todo en tareas complejas. Cuando probé el de 26B hizo el sitio sin problema; cuando probé el E4B me lanzaba errores, alucinaba mucho o directamente no creaba el sitio.

Mi recomendación rápida: si tienes un laptop normal con ~12 GB de RAM, ve por el E4B. Si tienes una gráfica de ~16 GB, ve por el 12B. Y a menor equipo, puedes ir bajando hasta el E2B.

3. El protagonista: Gemma 4 12B Unified

Para esta guía me centro en el 12B Unified, porque es el punto dulce para developers: suficientemente capaz, multimodal, y corre en una laptop de 16 GB.

Specs que importan:

• 11.95B parámetros, 48 capas, arquitectura densa (no MoE).
• Ventana de contexto de 256K tokens — suficiente para procesar codebases enteros o documentos largos en una pasada.
• Vocabulario de 262K.
• Multimodal real: texto, imagen y audio en una sola arquitectura, sin encoders separados. Todo pasa por el backbone de lenguaje directamente. Es el primer modelo de su clase (12B) capaz de ingerir audio de forma nativa.
• Multilingüe: soporte out-of-the-box de 35+ idiomas, pre-entrenado en 140+ (español incluido, obvio).
• Modos de razonamiento ("thinking") configurables.

Además de texto, también entiende imágenes, así que puede servirte hasta como OCR: leer facturas, formularios o documentos escaneados (DocVQA).

El dato que lo vende: casi iguala a modelos del doble de tamaño en la mayoría de benchmarks, pero entra en 16 GB de RAM. Eso es lo que lo hace ideal para correr local.

4. Probarlo sin instalar nada

Antes de montar nada en tu máquina, puedes probarlo directo en el navegador desde Google AI Studio. En el selector de modelos escoge Gemma 4 26B A4B IT y lánzale un prompt para ver cómo razona. Por ejemplo:

"Explica cuál es el diseño para escalar un URL shortener web y qué stack debería usar."

Es una buena forma de calibrar qué esperar antes de descargar gigas de modelo.

5. La forma más rápida de correrlo en local: Ollama

Si solo quieres probarlo ya, sin configurar nada:

# Instalar Ollama (Linux/Mac)
curl -fsSL https://ollama.com/install.sh | sh

# Correr Gemma 4 (descarga el último por defecto, el E4B ~9.6 GB)
ollama run gemma4

# O un tamaño específico
ollama run gemma4:12b
ollama run gemma4:e4b   # corre cómodo en 8 GB
ollama run gemma4:e2b   # el más liviano

Por debajo Ollama usa llama.cpp, así que es la ruta "fácil" sin tocar flags. No requiere conocimiento técnico, son solo un par de comandos.

Una vez instalado, puedes preguntarle cualquier cosa. Por ejemplo, le pedí un planning para crear un e-commerce con Next.js.

Ojo con el modo thinking: este modelo tiene su versión thinking, ese esfuerzo extra que hace antes de responder. Lo que parece la respuesta al inicio en realidad es solo su procesado previo; la respuesta real viene después. Te entrega todo en Markdown, no responde lento y lo hace bastante bien.

Conectándolo a OpenCode

También puedes lanzarlo con OpenCode. En la misma página de Ollama te aparece el comando. Le pedí crear un landing page para un CRM tipo SaaS. OpenCode define las tareas (de nuevo, a partir del modelo thinking) y empieza a ejecutar, llamando internamente herramientas como webfetch para buscar en internet.

¿El resultado con el modelo base? Después de unos 15-20 minutos generó código... pero no del todo. Solo armó una especie de plantilla. El problema es que este modelo genérico alucina demasiado: no lee bien una herramienta de edición, y a veces cuando llama al webfetch coloca una URL real que no toca.

La conclusión es clara: el modelo base de Gemma 4 no está enfocado en escribir código. Es para tareas genéricas.

6. Con LM Studio (si prefieres interfaz gráfica)

Para los que no viven en terminal: abre LM Studio, busca gemma 4 en el explorador de modelos, elige el tamaño y el quant, y descarga. Tiene chat visual, ajustes de parámetros y syntax highlighting. Bonus: puede levantar un servidor local con API compatible con OpenAI desde la propia interfaz.

Disponible tanto en GGUF (para llama.cpp / Ollama / LM Studio) como en MLX (para Macs con Apple Silicon). Si no sabes nada de modelos y solo quieres chatear en local, esta es la ruta más sencilla.

7. El papel del harness (esto es lo importante)

Aquí está lo que mucha gente no toma en cuenta. Cuando volví a probar generación de código, esta vez con el Gemma 4 de 26B, la cosa cambió, y no solo por el tamaño.

¿Qué cambia? En OpenCode le das acceso explícito a las herramientas: que sí puede acceder a bash, que sí puede editar archivos, etc. Al recibir esa configuración, el agente sabe que puede editar un archivo o escribir algo. Esa es la ayuda que le da el harness al modelo.

Porque el modelo, digamos, viene "crudo". A veces simplemente te dice que no sabe hacer algo o que no puede, y depende de que el harness se lo permita.

Con el de 26B sí trabaja, sí responde mucho mejor. Generó un landing page con Vite + React. No es extremadamente sorprendente, pero tampoco está nada mal, y se está ejecutando completamente en local. Para cosas comunes como generar aplicaciones web está bastante bien, mientras no pidas algo demasiado complejo.

8. La ruta con control total: llama.cpp

Cuando quieres exprimir el hardware, elegir el quant exacto y controlar el contexto, vas directo con llama.cpp. Es otro proyecto abierto, un motor de inferencia: un programa que ejecuta modelos inteligentes. Es un poco más complicado que Ollama porque no solo lleva comandos, sino que tienes que ajustar parámetros como el contexto o la cuantización. No es extremadamente difícil, pero necesitas saber uno que otro flag.

Compilar (Linux con GPU NVIDIA)

sudo apt update
sudo apt install -y build-essential cmake git libcurl4-openssl-dev libssl-dev

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DLLAMA_OPENSSL=ON
cmake --build build -j --target llama-server llama-cli

El -DLLAMA_OPENSSL=ON habilita HTTPS, necesario para descargar modelos con el flag -hf. Sin él, falla con HTTPS is not supported.

En Mac es más simple — Homebrew te da el binario con Metal:

brew install llama.cpp

Correr el modelo

./build/bin/llama-cli \
  -hf ggml-org/gemma-4-12b-GGUF:Q4_K_M \
  --n-gpu-layers 99 \
  -fa on \
  --ctx-size 16384 \
  --temp 1.0 --top-p 0.95 --top-k 64

O como servidor con API compatible con OpenAI:

./build/bin/llama-server \
  -hf ggml-org/gemma-4-12b-GGUF:Q4_K_M \
  --n-gpu-layers 99 -fa on \
  --ctx-size 16384 \
  --host 0.0.0.0 --port 8080

Abres http://localhost:8080 y tienes chat web + endpoint /v1/chat/completions.

Conectándolo a OpenCode (con un fine-tune de código)

Para usar un modelo de llama.cpp con OpenCode, editas tu opencode.json. En la sección de providers agregas uno nuevo. Lo interesante es que puedes declararlo como compatible con OpenAI, le pasas la dirección donde corre llama.cpp, y un nombre (yo le puse Gemma 4 Coder).

{
  "provider": {
    "llamacpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama.cpp",
      "options": {
        "baseURL": "http://localhost:7000/v1"
      },
      "models": {
        "gemma-4-coder": {
          "name": "Gemma 4 Coder"
        }
      }
    }
  }
}

Luego lo lanzas con opencode --model llamacpp/gemma-4-coder.

Los parámetros que marcan la diferencia

Aquí viene la parte de "ajuste" que siempre hace falta con modelos locales. En mis pruebas:

• Sin la configuración correcta, el modelo respondía cualquier cosa (hasta me contestó algo raro relacionado con audio).
• Quité el parámetro --chat-template para que el modelo use su propio template. Ahí ya empezó a ejecutar comandos relacionados con código de verdad.
• Añadí el flag --jinja para que pudiera hacer llamadas a herramientas correctamente.

Aun así, hay un problema recurrente: el modelo no siempre llama la herramienta. A veces solo te muestra el código en pantalla en lugar de guardarlo en un archivo, o muestra los comandos pero no los ejecuta.

Un truco que ayuda es ser muy explícito en el prompt:

"Crea una API CRUD con FastAPI y SQL y usa herramientas para escribir cada archivo en disco. No me expliques el plan."

Mucha gente piensa que "como es puramente código, va a funcionar sin contexto", pero es al revés: están adaptados, y si no escribes bien el prompt, a veces solo te muestran algo sin hacer nada.

9. Cuantización: la decisión que define velocidad y calidad

Esto es lo que casi ningún tutorial explica bien, y es la decisión técnica clave. La cuantización reduce la precisión de los pesos (de 16 bits a 8, 4 o 2) para que el modelo ocupe menos memoria y corra más rápido, a cambio de algo de calidad.

En el video usé el Q8 (máxima calidad), pero para uso cómodo el Q4 es más que suficiente.

El hallazgo que cambia cómo eliges

Probando esto en el DGX Spark (128 GB de memoria unificada) medí algo revelador:

• Bajé el contexto de 131K a 16K → la velocidad NO cambió.
• Bajé el quant de Q8 a Q4 → subió 57% (16.7 → 26.3 t/s).

¿Por qué? Porque en generación el cuello de botella no es el cómputo de la GPU, es el ancho de banda de memoria. Cada token generado relee TODOS los pesos del modelo. Menos bytes por token (quant más bajo) = más velocidad. El contexto casi no influye en la velocidad de generación.

La lección práctica: para ir más rápido, baja el quant, no el contexto. Y no bajes a Q2 salvo que te falte memoria — la pérdida de calidad ahí es brusca, sobre todo en código.

Medir el rendimiento

Para una cifra limpia y reproducible:

./build/bin/llama-bench \
  -m ~/.cache/llama.cpp/<archivo>.gguf \
  -ngl 99 -fa 1 \
  -p 512 -n 128

Te da pp (prompt processing) y tg (token generation) en tokens/segundo. Referencia: por encima de 15-20 t/s ya se siente fluido (la lectura humana cómoda ronda los 7 t/s).

10. La comunidad lo extiende: fine-tunes

Aquí está lo interesante del ecosistema abierto. Como Gemma 4 es Apache 2.0, cualquiera puede tomar el modelo base y especializarlo para una tarea.

Un ejemplo real es gemma-4-12B-coder-fable5-composer2.5, un fine-tune de la comunidad afinado para programación al estilo de modelos como Composer 2.5. No es de Google: alguien tomó el 12B base y le dio entrenamiento extra enfocado en código. Como está en Hugging Face (no en Ollama), lo corres con llama.cpp:

./build/bin/llama-cli \
  -hf yuxinlu1/gemma-4-12B-coder-fable5-composer2.5-v1-GGUF:Q4_K_M \
  --n-gpu-layers 99 -fa on \
  --ctx-size 16384 \
  --temp 1.0 --top-p 0.95 --top-k 64

Qué saber sobre los fine-tunes de comunidad:

• Son más fuertes en su dominio (código, roleplay, idioma específico) pero pueden ser más débiles en lo general.
• No siempre conservan el alineamiento de seguridad del modelo oficial de Google. Si lo pones en producción, añade tus propios guardrails.
• La calidad varía mucho entre autores. Revisa la tarjeta del modelo y los benchmarks que reporten.

fine-tune ≠ modelo nuevo. No es que Google sacó un coder; es que un dev independiente especializó el 12B. La capacidad de fondo viene de Google; la especialización, del autor.

Y aquí va mi advertencia honesta tras probar varias variaciones: como Gemma 4 trata de ser un modelo pequeño, el fine-tuning para código no termina de funcionar bien. El que probé estaba enfocado solo en Python, y cuando le pedí una aplicación completa no lo hacía bien. El sueño del "modelo ilimitado" que escriba código por ti, con este modelo, todavía no llega.

11. Bonus avanzado: DiffusionGemma

El primo experimental de la familia. DiffusionGemma rompe el esquema clásico: en vez de generar un token a la vez (autorregresivo), genera bloques enteros de texto a la vez usando difusión, como los generadores de imágenes. Por eso va muchísimo más rápido.

• Es un MoE de 26B que solo activa ~3.8B por token → entra en 18 GB de VRAM cuantizado.
• Promete velocidades de 1000+ tokens/seg en GPUs de datacenter.
• Pero: menor calidad que el Gemma 4 estándar, y su time-to-first-token es más alto (hace denoising de un bloque antes de emitir nada).

Hoy no corre en llama.cpp (soporte por llegar). Se sirve con vLLM en Docker:

docker pull vllm/vllm-openai:gemma

docker run -itd --name diffusiongemma \
    --ipc=host --network host --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    vllm/vllm-openai:gemma \
        --model google/diffusiongemma-26B-A4B-it \
        --max-model-len 262144 \
        --max-num-seqs 4 \
        --gpu-memory-utilization 0.85 \
        --host 0.0.0.0 --port 8000

El --max-num-seqs 4 es crítico — no lo subas, los buffers de difusión causan OOM con valores altos. Para trabajo serio, quédate con el Gemma 4 estándar; esto pruébalo solo si quieres explorar generación por difusión.

Hay también versiones experimentales que corren dentro del navegador usando kernels que conectan el navegador con el GPU (WebGPU). La idea es preguntarle directo desde el navegador. No es para producción y falla según el dispositivo (en mi prueba me dio error de WebGPU), pero es una dirección interesante.

12. Conectarlo a tu editor o herramientas

Como tanto llama.cpp como vLLM exponen API compatible con OpenAI, puedes engancharlo a casi cualquier cosa cambiando solo la URL base:

• Open WebUI → interfaz tipo ChatGPT, ideal para chatear y probar (chat puro, sin depender de tool calling).
• Continue (extensión VS Code) → chat + autocompletado dentro del editor. Funciona sin tool calling, perfecto para Gemma.
• Cline / OpenCode → agentes que editan archivos y ejecutan comandos. Necesitan tool calling sólido; funcionan con el Gemma 4 estándar, pero fallan con DiffusionGemma.

Config tipo para Continue (config.json):

{
  "models": [
    {
      "title": "Gemma 4 12B (local)",
      "provider": "openai",
      "model": "gemma-4-12b",
      "apiBase": "http://localhost:8080/v1",
      "apiKey": "EMPTY"
    }
  ]
}

Si el servidor corre en otra máquina de tu red (un mini-PC, un Spark headless), cambia localhost por su IP. Y si quieres acceso desde fuera de tu red, Tailscale resuelve sin abrir puertos.

13. Cuándo usar Gemma 4 (y cuándo no)

Úsalo cuando:

• Quieres privacidad total — código de cliente, datos sensibles que no deben salir.
• No quieres pagar por token ni depender de rate limits.
• Necesitas multimodal (texto + imagen + audio) en local, o usarlo como OCR.
• Trabajas offline o con conexión inestable.
• Vas a hacer tareas agénticas comunes: ejecutar algún comando normal, generar textos, apps web básicas.

Piénsalo dos veces cuando:

• Necesitas el máximo en razonamiento puro — los modelos más grandes (31B, y los cloud gigantes) siguen superando al 12B en matemática y lógica compleja.
• Quieres usarlo como copilot ilimitado para escribir código serio. Tras probar varias variaciones, incluso con fine-tuning, no me ha respondido como yo quería. Para código, todavía no.

Conclusión

Gemma 4 es, para muchos flujos de trabajo, el primer modelo abierto de Google lo bastante bueno para reemplazar una API de frontera en una parte real de tu trabajo. La ruta es clara: Ollama o LM Studio para probar rápido, llama.cpp para control y rendimiento, y entender la cuantización para no dejar velocidad sobre la mesa.

Para tareas generales y agénticas comunes está bastante bien. Para escribir código de forma seria, aún no llega, ni siquiera con los fine-tunes de la comunidad. Pero ha mejorado, y lo mejor del ecosistema abierto es que la comunidad lo extiende constantemente, mientras experimentos como DiffusionGemma empujan los límites de lo que un modelo local puede hacer.

Todo corriendo en tu propia máquina. Sin nube, sin cuotas, sin que tu código salga de tu disco. 🐾

¿Lo has probado tú? Cuéntame si lo has podido descargar y ejecutar por tu cuenta, y sobre todo si lo usas en algún tipo de agente.