Gemma 4 dans Codex CLI : l'exécution locale fonctionne, mais reste plus faible que le cloud

Le Gemma 4 local est déjà capable de fonctionner dans Codex CLI en tant qu'agent pour la programmation quotidienne : lire des fichiers, écrire des correctifs et exécuter des tests. Mais une expérience avec deux configurations différentes a montré que le fait de fonctionner n'est que la moitié du succès. En termes de fiabilité, de précision du code et de qualité des résultats au premier essai, GPT-5.

4 basé sur le cloud reste notablement en tête. L'auteur du test a voulu vérifier non un « développement IA local » abstrait, mais un scénario bien fondé : le modèle peut-il remplacer l'API cloud dans le travail quotidien avec Codex CLI ? La motivation est claire : les coûts des tokens, les exigences de confidentialité et la dépendance vis-à-vis des services externes.

Pour vérifier, deux configurations ont été assemblées. La première — MacBook Pro avec chip M4 Pro et 24 GB de mémoire, où Gemma 4 26B MoE s'exécutait en quantification Q4_K_M via llama.cpp.

La seconde — Dell Pro Max GB10 avec 128 GB de mémoire unifiée et NVIDIA Blackwell, où Gemma 4 31B Dense était utilisé via Ollama 0.20.5.

Dans les deux cas, le modèle était connecté à Codex CLI en tant que fournisseur personnalisé en mode responses API. Mettre en place la stack locale s'est avéré ne pas être aussi simple. Sur Mac, la version Ollama se cassait sur tool calling en raison de bugs de streaming et gelait sur les longs prompts, et pour Codex CLI c'est critique : un seul system prompt là occupe environ 27 mille tokens.

La solution fonctionnelle s'est avérée être llama.cpp avec ajustement manuel des flags, web_search désactivé et contexte de 32.768 tokens.

Sur GB10 non plus tout n'a pas fonctionné du premier coup : vLLM s'est heurté à une incompatibilité entre les builds PyTorch et CUDA pour Blackwell, et llama.cpp compilé manuellement traitait mal certains types d'outils. En conséquence, la solution la plus pratique s'est avérée être non la stack « idéale », mais celle qui a simplement fonctionné — Ollama.

Le benchmark a été conduit le 12 avril 2026 sur Codex CLI v0.120.0.

Via codex exec --full-auto, les trois configurations ont reçu la même tâche — écrire une fonction Python parse_csv_summary avec gestion des erreurs, puis préparer des tests et les exécuter. GPT-5.4 cloud avec reasoning effort élevé a eu les meilleures performances : livré du code propre avec type hints, chaîne d'exceptions appropriée et passé les cinq tests au premier essai en 65 secondes.

Gemma 4 31B local sur GB10 a également livré un résultat fonctionnel au premier passage, mais plus simple en qualité : sans type hints et sans reconnaissance des valeurs booléennes. Cependant, les cinq tests ont également tous réussi immédiatement, et l'exécution a pris environ sept minutes et trois tool calls. Le plus problématique fut le Mac avec 26B MoE : le modèle laissait du code mort, réécrivait le fichier de test plusieurs fois et commettait des fautes de frappe ridicules comme un nom de variable cassé ou une chaîne encoding incorrecte.

Au total, la tâche a pris 4 minutes 42 secondes mais a nécessité 10 tool calls et cinq tentatives échouées d'écriture des tests. Curieusement, le Mac a inopinément surpassé le GB10 plus puissant en vitesse « brute ». En llama-bench, 26B MoE sur Mac livrait environ 52 tokens par seconde contre 10 tokens en 31B Dense sur GB10, et lors du traitement d'un prompt en contexte 8K, les machines allaient presque à égalité — 531 contre 548 tokens par seconde.

L'explication réside dans l'architecture Mixture of Experts : avec MoE, seule une partie des paramètres s'active à chaque étape, donc la quantité de données qui doit être extraite de la mémoire par token est drastiquement réduite. Mais cet avantage a presque aidé dans la tâche réelle car le temps principal a été consommé non par le calcul, mais par les erreurs du modèle, les repeated tool calls et les ajustements inutiles en cours de route. La conclusion principale ici est double.

D'une part, Gemma 4 a vraiment déplacé la programmation agentic locale de la catégorie « se casse presque toujours » à la catégorie « on peut vivre avec ça » : l'auteur nous rappelle que sur tau2-bench, les performances de function calling pour Gemma 3 étaient de 6,6%, tandis que pour Gemma 4 31B c'était 86,4%. D'autre part, dans le développement pratique, la fiabilité au premier essai importe plus que les records tokens par seconde. Par conséquent, le mode local semble déjà réaliste pour les tâches privées, les itérations rapides et le travail sans frais API constants, mais dans les scénarios complexes les modèles cloud restent plus forts pour l'instant.

La conclusion la plus raisonnable du test semble être le mode hybride : modèle local pour certaines tâches, cloud — comme outil principal où le coût de l'erreur dépasse la vitesse ou la confidentialité.