Gemma 4 dans Codex CLI : l'exécution en local fonctionne, mais reste derrière le cloud

Gemma 4 en local peut désormais fonctionner dans Codex CLI comme agent pour le codage quotidien : lire des fichiers, écrire des patchs et lancer des tests. Mais une expérience menée sur deux configurations différentes montre que le simple fait de la faire tourner ne représente que la moitié du chemin. En fiabilité, en soin apporté au code et en qualité du résultat dès le premier essai, GPT-5.4 dans le cloud garde une avance nette.

L'auteur ne voulait pas tester un « développement IA local » abstrait, mais un scénario très concret : le modèle peut-il remplacer une API cloud dans le travail quotidien avec Codex CLI ? La motivation se comprend aisément : coût des tokens, exigences de confidentialité et dépendance aux services externes.

Deux configurations ont été montées pour le test. La première : un MacBook Pro avec puce M4 Pro et 24 Go de mémoire, où tournait Gemma 4 26B MoE en quantification Q4_K_M via llama.cpp. La seconde : un Dell Pro Max GB10 avec 128 Go de mémoire unifiée et NVIDIA Blackwell, où l'on a utilisé Gemma 4 31B Dense via Ollama 0.20.5. Dans les deux cas, le modèle était branché à Codex CLI comme fournisseur personnalisé en mode responses API.

Monter la pile locale n'a pas été simple. Sur le Mac, Ollama plantait sur le tool calling à cause de bugs de streaming et se bloquait sur les longs prompts, ce qui est critique pour Codex CLI : son seul prompt système pèse environ 27 mille tokens. La solution qui a finalement fonctionné est llama.cpp avec des flags réglés à la main, web_search désactivé et un contexte de 32 768 tokens.

Sur le GB10 non plus, tout n'a pas marché du premier coup : vLLM s'est heurté à une incompatibilité entre les builds de PyTorch et de CUDA pour Blackwell, et un llama.cpp compilé à la main traitait mal certains types d'outils. Là encore, la solution la plus pratique n'a pas été la pile « idéale », mais celle qui a simplement fonctionné : Ollama.

Le benchmark a été réalisé le 12 avril 2026 sur Codex CLI v0.120.0. Avec 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 dans le cloud, avec un reasoning effort élevé, s'en est le mieux sorti : il a produit un code propre avec des type hints et une chaîne d'exceptions correcte, et a réussi les cinq tests du premier coup en 65 secondes.

Gemma 4 31B en local sur le GB10 a elle aussi livré un résultat fonctionnel dès la première passe, mais de moindre qualité : sans type hints et sans reconnaissance des valeurs booléennes. En revanche, les cinq tests sont également passés immédiatement, et l'exécution a pris environ sept minutes et trois tool calls.

Le plus problématique a été le Mac avec le 26B MoE : le modèle a laissé du code mort, réécrit plusieurs fois le fichier de tests et commis des fautes de frappe absurdes, comme un nom de variable cassé ou une chaîne d'encoding incorrecte. La tâche a pris 4 minutes 42 secondes, mais a exigé 10 tool calls et cinq tentatives infructueuses d'écriture des tests.

Le plus intéressant, c'est qu'en vitesse « brute », le Mac a battu de façon inattendue le GB10, pourtant plus puissant. Dans llama-bench, le 26B MoE sur le Mac produisait environ 52 tokens par seconde contre 10 tokens pour le 31B Dense sur le GB10, tandis que sur le traitement du prompt avec un contexte de 8K, les machines étaient presque à égalité : 531 contre 548 tokens par seconde. L'explication tient à l'architecture Mixture of Experts : un MoE n'active qu'une partie de ses paramètres à chaque étape, si bien que le volume de données à lire en mémoire par token est nettement plus faible.

Mais cet avantage n'a presque pas aidé sur la tâche réelle, car l'essentiel du temps n'a pas été consommé par le calcul, mais par les erreurs du modèle, les tool calls répétés et les corrections superflues en cours de route.

La conclusion principale est double. D'un côté, Gemma 4 a fait passer le codage agentique local de la catégorie « plante presque tout le temps » à celle de « on peut s'en accommoder » : l'auteur rappelle que sur tau2-bench, le score de function calling de Gemma 3 était de 6,6 %, contre 86,4 % pour Gemma 4 31B. De l'autre, en développement concret, la fiabilité dès le premier essai compte davantage qu'un record de tokens par seconde.

Le mode local paraît donc déjà réaliste pour les tâches privées, les itérations rapides et le travail sans dépenses d'API récurrentes, mais dans les scénarios complexes, les modèles cloud restent plus solides. La conclusion la plus raisonnable du test est un mode hybride : un modèle local pour une partie des tâches, et le cloud comme outil principal là où le coût d'une erreur pèse plus lourd que la vitesse ou la confidentialité.