Exécuter Gemma 4 comme modèle local dans Codex CLI

• Gemma 4 a été exécuté dans un environnement Codex CLI local plutôt que dans le cloud afin de valider les performances et la stabilité des appels d’outils, ce qui a confirmé des avantages en coût et en confidentialité par rapport à GPT-5.4
• Sur Mac (M4 Pro) 24 Go avec le 26B MoE et sur NVIDIA GB10 128 Go avec le 31B Dense, le même travail de génération de code a été effectué avec llama.cpp et Ollama respectivement, afin de comparer les performances selon la configuration
• Le taux de réussite des appels d’outils est passé de 6,6 % à 86,4 %, démontrant la viabilité pratique des modèles locaux, et l’environnement GB10 a permis une génération de code complète
• Le Mac a montré une vitesse de génération de tokens 5,1 fois plus élevée, mais les contraintes mémoire et les réglages de quantification ont nécessité des tentatives répétées, tandis que le GB10, plus lent, a réussi du premier coup
• En conclusion, les modèles locaux peuvent eux aussi générer du code à un niveau exploitable en production, et une approche hybride est recommandée, combinant traitement local centré sur la confidentialité et bascule vers le cloud pour les tâches complexes

---

Motivation du passage aux modèles locaux

• Le coût posait problème, car l’exécution de Codex CLI sur plusieurs sessions par jour, parfois en parallèle, faisait grimper les frais d’API
• Des exigences de confidentialité empêchaient l’envoi de certaines bases de code vers des serveurs externes
• Il fallait aussi garantir la fiabilité, les API cloud comportant des risques de throttling, de panne et de changement tarifaire
• La raison pour laquelle les modèles locaux n’avaient pas été essayés auparavant était l’absence d’appels d’outils (tool calling), alors que la valeur principale de Codex CLI vient de la capacité du modèle à lire des fichiers, écrire du code, exécuter des tests et appliquer des patchs
• La génération précédente de Gemma n’atteignait que 6,6 % sur le benchmark d’appel de fonctions tau2-bench (93 échecs sur 100), mais Gemma 4 31B est monté à 86,4 %, rendant le test réellement pertinent

Configuration sur Mac

• Le test a commencé avec Ollama, mais sur la v0.20.3, un bug de streaming dans Gemma 4 routait à tort les réponses d’appel d’outils vers une sortie de reasoning au lieu d’un tableau tool_calls
• Sur Apple Silicon, l’utilisation de Gemma 4 provoquait un freeze de Flash Attention avec des prompts d’environ plus de 500 tokens ; comme le prompt système de Codex CLI fait environ 27 000 tokens, cela le rendait en pratique inutilisable
• Passage à llama.cpp, installé via Homebrew ; la commande serveur fonctionnelle nécessitait 6 flags essentiels
  • -np 1 : limite à un seul slot, les slots multiples multipliant la mémoire du cache KV
  • -ctk q8_0 -ctv q8_0 : quantification du cache KV, réduisant son empreinte de 940 Mo à 499 Mo
  • --jinja : indispensable pour le template d’appel d’outils de Gemma 4
  • le chemin GGUF devait être indiqué directement avec -m, car l’usage du flag -hf télécharge automatiquement un projecteur vision de 1,1 Go qui provoque un crash OOM
• Dans la configuration de Codex CLI, web_search = "disabled" était indispensable, car Codex CLI envoie un type d’outil web_search_preview refusé par llama.cpp

Configuration sur GB10

• vLLM 0.19.0 est compilé sur la base de PyTorch 2.10.0, mais la seule version de PyTorch avec support CUDA pour aarch64 Blackwell (compute capability sm_121) est 2.11.0+cu128, ce qui provoque une incompatibilité ABI et une ImportError
• llama.cpp, compilé depuis les sources avec CUDA, passait la compilation et les benchmarks, mais refusait les types d’outils non fonctionnels envoyés par wire_api = "responses" de Codex CLI
• Le fonctionnement a été obtenu avec Ollama v0.20.5, le bug de streaming observé sur Apple Silicon ne se reproduisant pas sur NVIDIA
  • exécution de ollama pull gemma4:31b, puis redirection du port 11434 vers le Mac via un tunnel SSH (car le mode --oss de Codex CLI ne vérifie que localhost)
  • avec codex --oss -m gemma4:31b, la génération de texte et les appels d’outils ont fonctionné du premier coup
• La configuration sur Mac a pris la majeure partie d’un après-midi, alors que le GB10 a demandé environ 1 heure, téléchargement du modèle compris

Résultats du benchmark

• La même tâche a été donnée aux trois configurations : écrire la fonction Python parse_csv_summary avec codex exec --full-auto, y compris la gestion d’erreurs, puis écrire et exécuter les tests
• GPT-5.4 (cloud) : génération de code avec annotations de type, chaînage d’exceptions approprié, détection du type booléen et fonctions utilitaires propres ; les 5 tests sont passés du premier coup, en 65 secondes, sans nettoyage ultérieur
• GB10 31B Dense : pas d’annotations de type ni de détection des booléens, mais une gestion d’erreurs robuste, aucun code mort, et 5 tests réussis du premier coup après 3 appels d’outils, en 7 minutes
• Mac 26B MoE : présence de code mort dans l’implémentation, avec une boucle d’inférence de types écrite puis abandonnée avant une réécriture plus bas accompagnée du commentaire « Actually, let’s simplify » ; 5 tentatives ont été nécessaires pour écrire le fichier de tests
  • à chaque fois, des erreurs différentes de heredoc apparaissaient : filerypt → file_path, encoding=' 'utf-8' (espace inséré), fileint(file_path) etc.
  • il a fallu 10 appels d’outils pour une tâche que le GB10 a terminée en 3
  • ce résultat concerne l’environnement Codex CLI en Q4_K_M sur une machine de 24 Go, et ne constitue pas un jugement général sur Gemma 4 sur Apple Silicon

Analyse des performances : pourquoi le Mac était plus rapide que prévu

• Mesure des deux machines avec llama-bench à longueur de contexte identique : le Mac était 5,1 fois plus rapide que le GB10 en génération de tokens
• Les deux machines disposent d’une bande passante mémoire de 273 Go/s en LPDDR5X, mais la génération de tokens est une tâche limitée par la bande passante mémoire
  • le 31B Dense lit l’ensemble de ses 31,2 milliards de paramètres à chaque token (environ 17,4 Go)
  • le 26B MoE n’active que 3,8 milliards de paramètres par token (environ 1,9 Go)
  • à bande passante identique, le Mac a atteint 52 tok/s contre 10 tok/s pour le GB10
• La vitesse de traitement du prompt a elle aussi été meilleure que prévu sur Mac : en contexte 8K, 531 tok/s pour le Mac contre 548 tok/s pour le GB10, l’activation sparse du MoE aidant aussi sur cette phase

Leçon principale : le taux de réussite au premier essai compte plus que la vitesse en tokens

• Le Mac générait les tokens 5,1 fois plus vite, mais le temps total de fin n’a été réduit que de 30 % (4 min 42 s contre 6 min 59 s)
• La différence vient des reprises : 10 appels d’outils contre 3, 5 échecs d’écriture des tests, et du code mort que le modèle n’a pas nettoyé
• Le modèle cloud l’a démontré encore plus nettement : le plus rapide, le moins gourmand en tokens, sans passage de réparation, avec un 5/5 en 65 secondes
• Malgré cela, le local est praticable, les deux machines ayant généré du code fonctionnel passant les tests
• Le saut qualitatif entre Gemma 3 (6,6 % d’appels d’outils) et Gemma 4 (86,4 %) constitue le véritable point de bascule, faisant passer l’agentic coding local de « ne fonctionne pas » à « fonctionne », et le rendant réellement exploitable
• Nuance concernant le résultat sur Mac : Q4_K_M était la quantification la plus élevée tenant en mémoire sur une machine de 24 Go, et un nouveau test avec une quantification plus élevée sur un Apple Silicon plus généreux en mémoire pourrait donner un autre résultat
• Une approche hybride est possible : traiter les tâches répétitives et sensibles à la confidentialité avec codex --profile local, et garder le cloud par défaut pour les tâches complexes ; grâce au système de profils de Codex CLI, le basculement se fait avec un seul flag

Conseils pratiques de configuration

• Apple Silicon : Ollama était inutilisable avec Gemma 4 ; llama.cpp + --jinja est recommandé
  • dans le profil Codex CLI, définir web_search = "disabled"
  • indiquer directement le chemin GGUF avec -m, ne pas utiliser -hf
  • configurer un contexte de 32 768 (le prompt système de Codex CLI exige au minimum 27 000 tokens)
  • quantification du cache KV : -ctk q8_0 -ctv q8_0
• NVIDIA GB10 : Ollama v0.20.5 a été la première voie stable ; utiliser codex --oss -m gemma4:31b, et si la machine est distante, ouvrir un tunnel SSH vers le port 11434
• Dans la configuration du provider, il faut définir stream_idle_timeout_ms à au moins 1 800 000, car sur Mac un seul cycle d’appel d’outil prenait 1 min 39 s, ce qui faisait expirer la session avec le timeout par défaut
• Il est recommandé de figer la version de llama.cpp, une baisse de performance de 3,3x ayant été observée entre certains builds, au point de faire varier les benchmarks d’un jour à l’autre