Ejecutar Gemma 4 como modelo local en Codex CLI

• Caso de uso en el que Gemma 4 se ejecutó en un entorno local de Codex CLI en lugar de la nube para validar el rendimiento y la estabilidad del llamado de herramientas, confirmando ventajas de costo y privacidad frente a GPT-5.4
• En una Mac (M4 Pro) de 24 GB con 26B MoE y en una NVIDIA GB10 de 128 GB con 31B Dense, se realizó la misma tarea de generación de código usando llama.cpp y Ollama respectivamente, comparando el rendimiento según las diferencias de configuración
• La tasa de éxito del llamado de herramientas mejoró de 6.6% a 86.4%, lo que demostró la viabilidad práctica de los modelos locales, y en el entorno GB10 se logró una generación de código completa
• La Mac mostró una velocidad de generación de tokens 5.1 veces mayor, pero debido a restricciones de memoria y ajustes de cuantización necesitó intentos repetidos, mientras que la GB10 fue más lenta pero acertó en el primer intento
• Como conclusión, los modelos locales también pueden generar código a nivel profesional, y se recomienda un enfoque híbrido que combine procesamiento local centrado en la privacidad con migración a la nube para tareas complejas

---

Motivos para pasarse a modelos locales

• Por un tema de costo, ejecutar Codex CLI en varias sesiones al día, a veces en paralelo, hacía que el gasto de API se acumulara
• Por requisitos de privacidad, algunas bases de código no deben enviarse a servidores externos
• Por necesidad de estabilidad, ya que las API en la nube tienen riesgos de throttling, caídas y cambios de precio
• La razón por la que antes no se habían probado modelos locales era la falta de tool calling, y el valor central de Codex CLI está en que el modelo pueda leer archivos, escribir código, ejecutar pruebas y aplicar parches
• La generación previa de Gemma marcaba 6.6% en el benchmark de llamado de funciones de tau2-bench (93 fallos de 100), pero Gemma 4 31B saltó a 86.4%, lo que hizo que valiera la pena probarla

Proceso de configuración en Mac

• Se empezó con Ollama, pero en la v0.20.3 apareció un bug de streaming en Gemma 4 donde la respuesta de llamado de herramientas se enrutaba incorrectamente como reasoning output en vez de usar el arreglo tool_calls
• Al usar Gemma 4 en Apple Silicon, aparecía un freeze de Flash Attention con prompts de unos 500 tokens o más, y como el prompt de sistema de Codex CLI ronda los 27,000 tokens, en la práctica quedaba inutilizable
• Tras cambiar a llama.cpp, se instaló con Homebrew, y el comando de servidor funcional requirió 6 flags clave
  • -np 1: limitar a 1 slot, ya que múltiples slots multiplican el uso de memoria del caché KV
  • -ctk q8_0 -ctv q8_0: cuantización del caché KV, reduciéndolo de 940 MB a 499 MB
  • --jinja: indispensable para la plantilla de llamado de herramientas de Gemma 4
  • Es necesario apuntar directamente a la ruta GGUF con -m; si se usa el flag -hf, se descarga automáticamente un proyector de visión de 1.1 GB que provoca un crash por OOM
• En la configuración de Codex CLI, web_search = "disabled" es obligatorio, porque Codex CLI envía el tipo de herramienta web_search_preview, que llama.cpp rechaza

Proceso de configuración en GB10

• vLLM 0.19.0 está compilado sobre PyTorch 2.10.0, pero el PyTorch con soporte CUDA para Blackwell aarch64 (compute capability sm_121) solo existe en 2.11.0+cu128, así que se produce un ImportError por desajuste de ABI
• Si se compila llama.cpp desde código fuente con CUDA, la compilación y el benchmark pasan, pero llama.cpp rechaza los tipos de herramienta no funcionales que envía wire_api = "responses" de Codex CLI
• El éxito llegó con Ollama v0.20.5, y el bug de streaming visto en Apple Silicon no se reprodujo en NVIDIA
  • Tras ejecutar ollama pull gemma4:31b, se reenviò por SSH el puerto 11434 hacia la Mac (porque el modo --oss de Codex CLI solo revisa localhost)
  • Con codex --oss -m gemma4:31b, tanto la generación de texto como el llamado de herramientas funcionaron al primer intento
• La configuración en Mac tomó casi toda la tarde, mientras que en GB10 tomó alrededor de 1 hora, incluyendo la espera de descarga del modelo

Resultados del benchmark

• A las tres configuraciones se les dio la misma tarea: con codex exec --full-auto, escribir la función Python parse_csv_summary, incluyendo manejo de errores, y además escribir y ejecutar pruebas
• GPT-5.4 (nube): generó código con type hints, encadenamiento adecuado de excepciones, detección de tipo booleano y funciones helper limpias; pasó las 5 pruebas al primer intento, terminó en 65 segundos y no requirió limpieza posterior
• GB10 31B Dense: sin type hints ni detección de booleanos, pero con manejo de errores sólido y sin código muerto; pasó las 5 pruebas al primer intento con 3 llamados de herramientas, y tardó 7 minutos
• Mac 26B MoE: dejó código muerto en la implementación, escribió un loop de inferencia de tipos y lo abandonó, para luego reescribir debajo con el comentario 'Actually, let's simplify'; necesitó 5 intentos para escribir el archivo de pruebas
  • En cada intento apareció un error distinto de heredoc: filerypt → file_path, encoding=' 'utf-8' (espacio insertado), fileint(file_path), etc.
  • Una tarea que la GB10 completó en 3 llamadas requirió 10 llamadas de herramientas
  • Este resultado corresponde al entorno Codex CLI Q4_K_M en 24 GB, y no es una conclusión general sobre Gemma 4 en Apple Silicon

Análisis de velocidad: por qué la Mac fue más rápida de lo esperado

• Con llama-bench se midieron ambas máquinas con la misma longitud de contexto, y la Mac generó tokens 5.1 veces más rápido que la GB10
• Ambas máquinas tienen 273 GB/s de ancho de banda de memoria LPDDR5X, y la generación de tokens es una tarea limitada por ancho de banda
  • 31B Dense lee los 31.2 mil millones de parámetros completos en cada token (unos 17.4 GB)
  • 26B MoE activa solo 3.8 mil millones por token (unos 1.9 GB)
  • Con el mismo ancho de banda, la Mac registró 52 tok/s y la GB10 10 tok/s
• La velocidad de procesamiento del prompt también fue mejor de lo esperado en la Mac: en contexto de 8K, la Mac marcó 531 tok/s frente a 548 tok/s de la GB10, y la activación dispersa del MoE también favoreció el procesamiento del prompt

Lección clave: más importante que la velocidad de tokens es acertar en el primer intento

• Aunque la Mac genera tokens 5.1 veces más rápido, el tiempo final de finalización solo se redujo en 30% (4 min 42 s vs 6 min 59 s)
• La diferencia de tiempo vino de los reintentos: 10 llamados de herramientas frente a 3, 5 fallos al escribir pruebas y código muerto que el modelo no limpió
• El modelo en la nube lo demuestra todavía más: fue el más rápido, usó menos tokens, no necesitó pases de reparación y completó 5/5 en 65 segundos
• Aun así, lo local ya es práctico, y en ambas máquinas se generó código funcional que pasó las pruebas
• La brecha de calidad entre Gemma 3 (6.6% de tool calling) y Gemma 4 (86.4%) es el punto de inflexión clave, pasando de “no funciona” a “sí funciona”, lo que vuelve práctico el coding agent local
• Matiz sobre el resultado en Mac: Q4_K_M fue la mayor cuantización que cabía en una máquina de 24 GB, y volver a probar con cuantizaciones más altas en Apple Silicon con más memoria podría dar resultados distintos
• Es posible un enfoque híbrido: usar codex --profile local para trabajo repetitivo y tareas sensibles a la privacidad, y dejar las tareas complejas para la configuración en la nube; con el sistema de perfiles de Codex CLI, cambiar es cuestión de un solo flag

Consejos prácticos de configuración

• Apple Silicon: Ollama no fue utilizable con Gemma 4, así que se recomienda llama.cpp + --jinja
  • Configurar web_search = "disabled" en el perfil de Codex CLI
  • Apuntar directamente a la ruta GGUF con -m; no usar -hf
  • Definir contexto de 32,768 (el prompt de sistema de Codex CLI necesita al menos 27,000 tokens)
  • Cuantización del caché KV: -ctk q8_0 -ctv q8_0
• NVIDIA GB10: Ollama v0.20.5 fue la primera ruta estable, usar codex --oss -m gemma4:31b, y si la máquina es remota, tunelizar por SSH el puerto 11434
• En la configuración del proveedor, stream_idle_timeout_ms debe establecerse como mínimo en 1,800,000, porque en Mac un solo ciclo de llamado de herramienta tardó 1 minuto 39 segundos y con el timeout por defecto la sesión terminaba
• Se recomienda fijar la versión de llama.cpp, ya que se reportó una caída de rendimiento de 3.3 veces entre builds, y el benchmark puede variar de un día para otro

[tsboard]

En mi empresa probé operar Gemma4-31B con 2 H100, y

1. La calidad de las respuestas es bastante decente y maneja bien el coreano.
2. También decide bien cuándo ejecutar herramientas y organiza bien los resultados después de ejecutarlas.
3. Pero, al fin y al cabo, lo sorprendente es considerando que solo tiene 31B parámetros, y por supuesto es cierto que, al compararlo con modelos con más parámetros (por ejemplo, MiniMax-M2.5), queda por debajo en la calidad general de las respuestas y otros aspectos.

En general, si quieren algo pequeño y ágil, creo que Gemma4 es más que suficiente. Yo cambié de GPT-OSS-120B → Qwen3.5-35B-A3B y ahora me terminé quedando con Gemma4-31B, y me dejó bastante satisfecho. Creo que lo voy a seguir usando.

[kaydash]

¡No puede usar búsqueda web! ¿Aunque configure searxng tampoco se puede usar?

[ysm0622]

https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md

Prueba usar esto como reemplazo de esta skill jaja

[yangeok]

Me gustaría comprobar si también funciona bien en coreano.

[GN⁺]

Comentarios en Hacker News

• Gemma 4 26B mostró un rendimiento realmente excepcional entre los modelos de la misma escala de parámetros
  En benchmarks internos obtuvo puntajes similares a GPT 5.2 y Gemini 3 Pro Preview, pero fue débil en codificación tipo agente y en áreas de toma de decisiones no relacionadas con código
  Bajó su puntaje en uso de herramientas, mejora iterativa y manejo de contextos grandes, e incluso rindió peor en situaciones donde tenía que usar herramientas
  Probablemente esté sobreajustado a harnesses o benchmarks comunes. Aun así, la velocidad en MacBook con chip serie M es sorprendente
  Los benchmarks pueden verse en gertlabs.com

  • En mi prueba de “hello world” falló
    El problema era “implementar una calculadora de bin fitting unidimensional en una sola página web”; Qwen3.5, Nematron, Step 3.5 y gpt-oss pasaron, pero Gemma no
  • En general, es un buen modelo de pesos abiertos
    Eso sí, en mi M5 cometió errores de programación simples con más frecuencia que GPT-OSS. Aun así, en términos generales está bastante cerca
  • Me sorprendió que Gemma 31B sacara menos puntaje que 26B-A4B

• Hubo quien dijo que era sorprendente el resultado de que “la calidad del modelo importa más que la velocidad de tokens”
  En realidad suena bastante obvio. En vez de limitar el contexto a 32k, también se puede descargar el cálculo de MoE al CPU con la opción --cpu-moe

  • Pienso que la velocidad de tokens al final solo afecta la velocidad para completar el trabajo
  • Es como tomar café cuando estás cansado. Sigues cansado, solo que te mueves “más rápido”
  • Desde la perspectiva de alguien que usa Codex todos los días, es mucho más importante que el modelo no caiga en bucles inútiles que la velocidad
    Si solo importara la velocidad de tokens, al final explotaría la cantidad de ‘codebases llenos de basura de IA’

• Ahora mismo estoy ejecutando google/gemma-4-26b-a4b en un M3 Ultra (48GB RAM) con LM Studio y Opencode
  Tuve que subir el contexto a 65536, pero funciona bien. También se integra fácilmente con Zed y ACP
  Lo uso principalmente para revisiones simples de código o para generar código frontend

  • Yo tengo un entorno parecido. Vale la pena probar pi-coding-agent
    El prompt del sistema y la sobrecarga de herramientas quedan por debajo de 2k tokens, así que la latencia de prefill es mucho menor
  • Lo estoy usando en una AMD RX7900XTX (24GB VRAM) con 4 chats simultáneos y contexto de 512K
    La velocidad ronda los 100t/s, casi instantánea, y cada vez uso menos Claude Code
  • Lo probé integrado en XCode con la versión MLX en una MacBook M1, pero se quedaba colgado a mitad del proceso en un codebase pequeño de iOS
    Como chatbot está bien, pero no fue adecuado para integrarlo con XCode
  • Probé la versión completa 31B en una GPU de Runpod y me impresionó
    Ahora mismo estoy aprovechando las 1500 solicitudes gratis por día con la API de Google
  • Estoy usando la misma configuración en una MacBook Pro M4 Max (64GB)
    Antes de la actualización a LM Studio 0.4.11+1, la llamada de herramientas no funcionaba, pero ahora tanto Codex como Opencode van bien

• Es falso decir que “los modelos locales no pueden hacer tool calling”
  Ya llevo 2 años haciendo tool calling en local, y eso de que Gemma3 tenga una tasa de éxito de 7% no tiene sentido
  Incluso con Llama3.3 daba al menos 75%

  • A mí también me sorprendió esa frase. Probablemente el autor estaba ejecutando modelos locales por primera vez
    Modelos excesivamente cuantizados como Gemma 4 gguf Q4(16GB) pierden mucho rendimiento
  • Aun así, sí es cierto que hay una gran diferencia en el benchmark de function calling de Tau entre Gemma 3 y 4
  • Todo el texto tenía una vibra de contenido generado automáticamente por IA
    Si tienes hardware GB10, recomendaría la configuración de spark-vllm-docker o la versión optimizada de Qwen 3.5 122B A10B. Va bastante rápido, alrededor de 50tk/s

• Actualicé de un M4 Pro (24GB) a un M5 Pro (48GB), y el mismo Gemma 4 MoE (Q4) mostró 8 veces más t/s
  La velocidad de carga de disco a memoria también mejoró al doble

  • Si tienes suficiente RAM, recomiendo ejecutarlo directamente en Q8_0. Salvo la carga inicial, no se siente lento y la calidad es casi la misma
    Hay que verificar si estás usando la versión MLX. La versión cuantizada por la comunidad de mlx-lm fue corregida recientemente
    En mi MacBook M1 de 16GB me costó, pero en una AMD Framework 13 con 64GB RAM corre lo bastante rápido incluso solo con CPU
    La función de caché de prompts es útil al insertar prompts de sistema grandes

• Se propuso una idea de harness para automatizar experimentos con un modelo como Gemma 4 en hardware local 24/7, y dejar las decisiones grandes a Claude Opus
  El modelo local realiza experimentos pequeños y POC, y si se atasca pide ayuda a Opus
  Así se puede controlar por completo el prompt caching y el costo es casi nulo

  • Nico Bailon, desarrollador que amplía Pi coding agent de Mario, está intentando algo similar
    Se puede revisar el video demo y el repositorio pi-model-switch

• Para programación, cuantizar por debajo de Q6_K no tiene sentido
  Con una cuantización más baja, la tasa de errores de código sube bruscamente

  • La mayoría no lo sabe. La calidad del token importa más que la cantidad de tokens
    Conviene usar la cuantización más alta posible mientras la memoria lo permita

• Me gustaría ver una comparación de calidad según el método de cuantización entre Q4_K_M, Q8_0, Q6_K, etc. Parece más útil que solo ver cifras de tok/s

• Me da curiosidad comparar Qwen3.5 con Gemma 4
  En especial el modelo Qwen3.5-27B-Claude-4.6-Opus está especializado en tool calling y ya supera las 500 mil descargas

  • Estoy viendo la guía de fine-tuning que publicó Jackrong. Incluso los ejemplos en notebook están bien organizados
  • Yo lo probé directamente en DGX Spark, pero al final volví a Gemma 4
    El modelo Qwen pedía demasiadas correcciones de errores durante la orquestación, así que la productividad bajaba
    Lo ejecuté con los pesos para Ollama
  • La afirmación de que un desarrollador individual logró sacar más rendimiento que un gran laboratorio de investigación me parece algo dudosa
    La versión más reciente es Qwopus3.5-27B-v3

• Tras usar Gemma 4 durante varios días, me pareció rápido e inteligente, pero el problema con el uso de herramientas sigue ahí
  Más que la velocidad, el límite está en la inteligencia, y eso restringe la productividad. Muchas veces cae en bucles
  Estaría bien poder detectar esas situaciones y “pedir ayuda” a un modelo más inteligente
  Ahora trabajo más como orquestador de agentes que como programador. Mi rol es gestionar varios agentes en paralelo

  • Google reemplazó recientemente chat_template.jinja y tokenizer_config.json de gemma-4-31B-it
    Dicen que corrigieron los problemas relacionados con tool calling, así que conviene actualizar el modelo

[boolsee]

Con ollama es fácil configurar un LLM local, pero dicen que hay una alta probabilidad de que fallen las llamadas a herramientas según el modelo open source. Al parecer, esto se debe a una combinación de reglas internas flexibles de ollama y problemas con el parser de llamadas a herramientas de cada modelo.
Al final, el problema más fundamental de los Local LLM es que se necesita hardware caro para ejecutar modelos medianos y grandes. Un Mac Studio de 32 GB cuesta alrededor de 3.5 millones de wones, y un GB10 ronda los 5 a 6 millones, así que para una persona es una carga comprarlo solo por hobby (¿?). Para los Local LLM no queda otra que usar modelos pequeños, y para los modelos medianos o grandes, fuera de la nube no hay mucha alternativa.