Gemma 4 en Codex CLI: la ejecución local funciona, pero sigue siendo más débil que la nube

El Gemma 4 local ya es capaz de funcionar en Codex CLI como agente para codificación cotidiana: leer archivos, escribir patches y ejecutar pruebas. Pero un experimento con dos configuraciones diferentes mostró que el hecho de ejecutarse es solo la mitad del éxito. En términos de confiabilidad, precisión de código y calidad de resultado en el primer intento, GPT-5.

4 basado en nube sigue estando notablemente adelante. El autor de la prueba quiso verificar no un "desarrollo IA local" abstracto, sino un escenario bien fundamentado: ¿puede el modelo reemplazar la API en la nube en el trabajo diario con Codex CLI? La motivación es clara: costos de tokens, requisitos de privacidad y dependencia de servicios externos.

Para verificar, se armaron dos configuraciones. La primera — MacBook Pro con chip M4 Pro y 24 GB de memoria, donde Gemma 4 26B MoE se ejecutaba en cuantización Q4_K_M a través de llama.cpp.

La segunda — Dell Pro Max GB10 con 128 GB de memoria unificada y NVIDIA Blackwell, donde se usaba Gemma 4 31B Dense mediante Ollama 0.20.5.

En ambos casos, el modelo se conectaba a Codex CLI como proveedor personalizado en modo responses API. Montar la pila local resultó no ser tan sencillo. En Mac, la versión Ollama se rompía en tool calling debido a bugs de streaming y se colgaba en prompts largos, y para Codex CLI esto es crítico: un único system prompt allí ocupa alrededor de 27 mil tokens.

La solución funcional acabó siendo llama.cpp con ajuste manual de flags, web_search deshabilitado y contexto de 32.768 tokens.

En GB10 tampoco todo funcionó al primer intento: vLLM chocó con incompatibilidad entre compilaciones PyTorch y CUDA para Blackwell, y llama.cpp construido manualmente procesaba inadecuadamente ciertos tipos de herramientas. Como resultado, la solución más práctica nuevamente fue no la pila "ideal", sino la que simplemente funcionó — Ollama.

El benchmark se realizó el 12 de abril de 2026 en Codex CLI v0.120.0.

A través de codex exec --full-auto, las tres configuraciones recibieron la misma tarea — escribir una función Python parse_csv_summary con manejo de errores, luego preparar pruebas y ejecutarlas. GPT-5.4 en la nube con reasoning effort alto tuvo el mejor desempeño: entregó código limpio con type hints, cadena adecuada de excepciones y pasó las cinco pruebas en el primer intento en 65 segundos.

Gemma 4 31B local en GB10 también entregó un resultado funcional en el primer paso, pero más simple en calidad: sin type hints y sin reconocimiento de valores booleanos. Sin embargo, las cinco pruebas también pasaron inmediatamente, y la ejecución tomó aproximadamente siete minutos y tres tool calls. El más problemático fue el Mac con 26B MoE: el modelo dejaba código muerto, reescribía el archivo de prueba varias veces e incurría en errores de tipografía ridículos como nombre de variable roto o string encoding incorrecto.

En total, la tarea tomó 4 minutos 42 segundos pero requirió 10 tool calls y cinco intentos fallidos de escribir las pruebas. Curiosamente, la Mac superó inesperadamente al GB10 más potente en velocidad "cruda". En llama-bench, 26B MoE en Mac entregaba alrededor de 52 tokens por segundo contra 10 tokens en 31B Dense en GB10, y al procesar un prompt en contexto 8K, las máquinas iban casi parejas — 531 contra 548 tokens por segundo.

La explicación radica en la arquitectura Mixture of Experts: con MoE, solo parte de los parámetros se activan en cada paso, por lo que la cantidad de datos que necesita extraerse de la memoria por token se reduce drásticamente. Pero esta ventaja casi no ayudó en la tarea real porque el tiempo principal fue consumido no por computación, sino por errores del modelo, repeated tool calls y ajustes innecesarios en el camino. La conclusión principal aquí es doble.

Por un lado, Gemma 4 realmente ha desplazado la codificación local con agentes de la categoría "se rompe casi siempre" a la categoría "con esto ya se puede vivir": el autor nos recuerda que en tau2-bench, el rendimiento de function calling para Gemma 3 fue 6,6%, mientras que para Gemma 4 31B fue 86,4%. Por otro lado, en desarrollo práctico, la confiabilidad en el primer intento importa más que récords de tokens por segundo. Por lo tanto, el modo local ya se ve realista para tareas privadas, iteraciones rápidas y trabajo sin gastos constantes en API, pero en escenarios complejos los modelos en nube siguen siendo más fuertes por ahora.

La conclusión más razonable de la prueba parece ser modo híbrido: modelo local para algunas tareas, nube — como herramienta principal donde el costo del error supera la velocidad o la privacidad.