Gemma 4 en Codex CLI: ejecutarla en local funciona, pero aún queda por detrás de la nube

Gemma 4 en local ya puede funcionar en Codex CLI como agente para la programación cotidiana: leer archivos, escribir parches y ejecutar tests. Pero un experimento con dos configuraciones distintas mostró que lograr arrancarla es solo la mitad del éxito. En fiabilidad, limpieza del código y calidad del resultado al primer intento, GPT-5.4 en la nube sigue claramente por delante.

El autor no quería probar un abstracto «desarrollo local con IA», sino un escenario muy práctico: ¿puede el modelo sustituir a una API en la nube en el trabajo diario con Codex CLI? La motivación es fácil de entender: el coste de los tokens, los requisitos de privacidad y la dependencia de servicios externos.

Para la prueba se montaron dos configuraciones. La primera, un MacBook Pro con chip M4 Pro y 24 GB de memoria, donde se ejecutó Gemma 4 26B MoE con cuantización Q4_K_M mediante llama.cpp. La segunda, un Dell Pro Max GB10 con 128 GB de memoria unificada y NVIDIA Blackwell, donde se usó Gemma 4 31B Dense con Ollama 0.20.5. En ambos casos el modelo se conectó a Codex CLI como proveedor personalizado en modo responses API.

Levantar el stack local no fue sencillo. En el Mac, Ollama fallaba en el tool calling por errores de streaming y se colgaba con prompts largos, algo crítico para Codex CLI: solo su prompt de sistema ocupa unos 27 mil tokens. La opción que al final funcionó fue llama.cpp con flags ajustados a mano, web_search desactivado y un contexto de 32 768 tokens.

En el GB10 tampoco funcionó todo a la primera: vLLM chocó con la incompatibilidad entre las versiones de PyTorch y CUDA para Blackwell, y un llama.cpp compilado a mano procesaba de forma inadecuada algunos tipos de herramientas. Una vez más, la solución más práctica no fue el stack «ideal», sino el que simplemente funcionó: Ollama.

El benchmark se realizó el 12 de abril de 2026 con Codex CLI v0.120.0. Con codex exec --full-auto, las tres configuraciones recibieron la misma tarea: escribir una función en Python, parse_csv_summary, con gestión de errores, y después preparar tests y ejecutarlos.

GPT-5.4 en la nube, con reasoning effort alto, lo hizo mejor: entregó código limpio con type hints y una cadena de excepciones razonable, y pasó los cinco tests al primer intento en 65 segundos.

Gemma 4 31B local en el GB10 también dio un resultado funcional en la primera pasada, pero de menor calidad: sin type hints y sin reconocimiento de valores booleanos. Eso sí, los cinco tests también pasaron de inmediato, y la ejecución llevó unos siete minutos y tres tool calls.

El más problemático fue el Mac con el 26B MoE: el modelo dejó código muerto, reescribió varias veces el archivo de tests y cometió erratas absurdas, como un nombre de variable roto o una cadena de encoding incorrecta. La tarea tardó 4 minutos y 42 segundos, pero requirió 10 tool calls y cinco intentos fallidos de escribir los tests.

Lo más interesante es que, en velocidad «en bruto», el Mac superó inesperadamente al más potente GB10. En llama-bench, el 26B MoE en el Mac generaba unos 52 tokens por segundo frente a 10 tokens del 31B Dense en el GB10, mientras que en el procesamiento de prompt con contexto de 8K las máquinas iban casi a la par: 531 frente a 548 tokens por segundo. La explicación está en la arquitectura Mixture of Experts: un MoE activa solo una parte de los parámetros en cada paso, por lo que el volumen de datos que hay que leer de la memoria por token es mucho menor.

Pero esta ventaja apenas ayudó en la tarea real, porque la mayor parte del tiempo no se fue en cálculo, sino en errores del modelo, tool calls repetidos y ediciones innecesarias durante el trabajo.

La conclusión principal es doble. Por un lado, Gemma 4 ha movido la programación agéntica local de la categoría «falla casi siempre» a la de «con esto ya se puede vivir»: el autor recuerda que en tau2-bench el resultado de function calling de Gemma 3 era del 6,6 %, frente al 86,4 % de Gemma 4 31B. Por otro, en el desarrollo práctico importa más la fiabilidad al primer intento que un récord de tokens por segundo.

Por eso el modo local ya parece realista para tareas privadas, iteraciones rápidas y trabajo sin gastos continuos de API, pero en escenarios complejos los modelos en la nube siguen siendo más fuertes. La conclusión más sensata de la prueba es un modo híbrido: un modelo local para parte de las tareas y la nube como herramienta principal donde el coste de un error pese más que la velocidad o la privacidad.