La última iteración de la arquitectura de modelos abiertos de Google, Gemma 4, está demostrando ser capaz de gestionar tareas complejas de programación con agentes de forma local. El desarrollador Daniel Vaughan probó recientemente el modelo en el CLI de Codex con el objetivo de determinar si podría servir como una alternativa viable y privada a los modelos basados en la nube, como GPT-5.4.
Para la prueba, Vaughan utilizó dos configuraciones de hardware distintas. Su primer equipo fue un MacBook Pro con chip M4 Pro y 24 GB de RAM, ejecutando la variante Mixture-of-Experts (MoE) de 26B a través de llama.cpp. Su segunda configuración utilizó un Dell Pro Max GB10 equipado con 128 GB de memoria unificada y un chip NVIDIA Blackwell para ejecutar la variante densa de 31B mediante Ollama v0.20.5.
La principal motivación de Vaughan para este cambio fue hacer frente al aumento de los costes de uso de las API y resolver las preocupaciones sobre la privacidad de los códigos fuente sensibles. Señaló que los modelos basados en la nube suelen presentar problemas de limitación de velocidad y volatilidad de precios, lo que convierte a la ejecución local en una opción más robusta para el trabajo diario.
Superando las limitaciones en la ejecución de herramientas
Las versiones anteriores de Gemma no ofrecían una base sólida para la programación con agentes debido a la escasa precisión en la llamada a herramientas. Según los puntos de referencia, los modelos anteriores solo obtenían un 6,6 por ciento en la prueba de llamadas a funciones tau2-bench. Sin embargo, el modelo Gemma 4 de 31B ha mejorado este rendimiento de forma significativa, alcanzando un 86,4 por ciento en la misma prueba.
"Gemma 4 31B obtiene un 86,4 por ciento en la misma prueba. Eso es lo que hizo que valiera la pena realizar este experimento", escribió Vaughan. Esta capacidad permite al modelo leer archivos, escribir código y aplicar parches de forma fiable sin necesidad de enviar peticiones a un servidor externo.
La transición al hardware local no estuvo exenta de obstáculos. Vaughan informó que los intentos iniciales se vieron entorpecidos por errores de software, específicamente dentro del proceso de streaming de Ollama. Descubrió que la versión v0.20.3 redirigía incorrectamente las respuestas de las llamadas a herramientas hacia la salida de razonamiento en lugar de al campo específico de llamadas a herramientas. Estos desafíos requirieron una jornada completa de depuración para resolverse antes de que el modelo pudiera funcionar eficazmente como agente de programación.
Los hallazgos de Vaughan sugieren que, aunque la inferencia local requiere más tiempo de configuración, la calidad del modelo es suficiente para competir con las alternativas en la nube en tareas de programación profesional. Al trasladar la carga de trabajo al hardware local, los desarrolladores pueden mantener el control sobre sus datos y, al mismo tiempo, mitigar los costes continuos asociados a las llamadas frecuentes a las API.
