Exécuter Gemma 4 comme modèle local dans Codex CLI
(blog.danielvaughan.com)- 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-hfté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’outilweb_search_previewrefusé 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--ossde 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
- exécution de
- 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_summaryaveccodex 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_Msur une machine de 24 Go, et ne constitue pas un jugement général sur Gemma 4 sur Apple Silicon
- à chaque fois, des erreurs différentes de heredoc apparaissaient :
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+--jinjaest 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
- dans le profil Codex CLI, définir
- 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
6 commentaires
Dans mon entreprise, j’ai fait tourner Gemma4-31B avec deux H100, et voilà ce que j’en ai pensé.
Globalement, si vous voulez quelque chose de petit et réactif, Gemma4 devrait largement suffire. Je suis passé de GPT-OSS-120B à Qwen3.5-35B-A3B, puis je me suis finalement fixé sur Gemma4-31B, et j’en ai été assez satisfait. Je pense que je vais continuer à l’utiliser.
Quoi, on ne peut pas utiliser la recherche web ! Même en configurant searxng, ça ne marche pas ?
https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md
Essayez ça à la place de cette skill, haha
J’aimerais bien vérifier si ça fonctionne aussi bien en coréen.
Avis sur Hacker News
Gemma 4 26B a montré des performances vraiment exceptionnelles parmi les modèles de taille de paramètres comparable
Dans des benchmarks internes, il a obtenu des scores proches de GPT 5.2 et Gemini 3 Pro Preview, mais il était plus faible en codage agentique et dans les tâches de prise de décision hors codage
Les scores baissaient sur l’utilisation d’outils, l’amélioration itérative et la gestion de grands contextes, et ses performances étaient même plus faibles dans les situations où il fallait justement utiliser des outils
Il semble probablement surappris sur des harnesses ou benchmarks courants. Cela dit, sa vitesse sur les Macbook de série M est impressionnante
Les benchmarks sont consultables sur gertlabs.com
Le problème était : « implémenter un calculateur de bin fitting en 1 dimension sur une seule page web » ; Qwen3.5, Nematron, Step 3.5 et gpt-oss passaient, mais pas Gemma
Cela dit, sur mon M5 il faisait des erreurs de codage simples plus souvent que GPT-OSS. Malgré tout, le niveau global reste proche
Certains disaient qu’il était surprenant de constater que « la qualité du modèle compte plus que la vitesse en tokens »
En réalité, cela semble assez évident. On peut aussi déporter les calculs MoE vers le CPU avec l’option
--cpu-moeau lieu de limiter le contexte à 32kSi seule la vitesse en tokens compte, on va surtout voir exploser les codebases de « AI slop »
En ce moment, je fais tourner
google/gemma-4-26b-a4bsur un M3 Ultra (48GB RAM) avec LM Studio et OpencodeJ’ai dû monter le contexte à 65536, mais cela fonctionne bien. L’intégration avec Zed et ACP se fait aussi facilement
Je l’utilise surtout pour de petites revues de code ou la génération de code frontend
Son prompt système et l’overhead des outils restent sous les 2k tokens, donc la latence de préremplissage est bien plus courte
La vitesse tourne autour de 100t/s, c’est presque instantané, et j’utilise de moins en moins Claude Code
Correct comme chatbot, mais inadapté à l’intégration XCode
Pour l’instant, j’utilise surtout les 1500 requêtes gratuites par jour via l’API Google
Avant la mise à jour LM Studio 0.4.11+1, les appels d’outils ne fonctionnaient pas, mais maintenant tout marche bien avec Codex et Opencode
Dire que « les modèles locaux ne peuvent pas faire d’appels d’outils » est faux
Je fais déjà des appels d’outils en local depuis 2 ans, et affirmer que Gemma3 n’a qu’un taux de réussite de 7% sur ce point n’a aucun sens
Même avec Llama3.3, j’étais au minimum à 75%
Les modèles trop quantifiés, comme Gemma 4 gguf Q4 (16GB), perdent énormément en performances
Si vous avez une machine GB10, je recommande d’essayer une config spark-vllm-docker ou une version optimisée de Qwen 3.5 122B A10B. C’est assez rapide, autour de 50tk/s
Je suis passé d’un M4 Pro (24GB) à un M5 Pro (48GB), et le même Gemma 4 MoE (Q4) affichait un t/s 8 fois plus rapide
La vitesse de chargement du disque vers la mémoire a aussi doublé
Il faut vérifier que vous utilisez bien la version MLX. Les quantifications communautaires de mlx-lm ont été corrigées récemment
Sur mon Macbook M1 16GB, c’était difficile, mais sur un AMD Framework 13 avec 64GB RAM, cela tourne assez vite même en CPU seul
La fonctionnalité de cache de prompt est utile quand on insère un gros prompt système
Quelqu’un propose l’idée d’un harness qui fait tourner du matériel local 24/7 pour automatiser les expérimentations avec des modèles comme Gemma 4, tout en confiant les décisions importantes à Claude Opus
Le modèle local gère les petites expériences et les POC, puis demande de l’aide à Opus quand il bloque
Cela permettrait de contrôler totalement le prompt caching et de garder les coûts presque nuls
On peut voir la vidéo de démo et le dépôt pi-model-switch
Pour le codage, les quantifications en Q6_K ou moins n’ont pas vraiment de sens
En dessous, le taux d’erreurs de code grimpe brutalement
Tant que la mémoire le permet, mieux vaut utiliser la quantification la plus élevée possible
J’aimerais voir une comparaison de qualité par méthode de quantification entre Q4_K_M, Q8_0, Q6_K, etc. Ce serait probablement plus utile que de simples chiffres de tok/s
Je suis curieux de voir la comparaison entre Qwen3.5 et Gemma 4
En particulier, le modèle Qwen3.5-27B-Claude-4.6-Opus est spécialisé dans les appels d’outils et a déjà dépassé les 500 000 téléchargements
Les modèles Qwen demandaient trop souvent de corriger des erreurs pendant l’orchestration, ce qui nuisait à la productivité
Je l’ai fait tourner avec les poids pour Ollama
La version la plus récente est Qwopus3.5-27B-v3
J’ai utilisé Gemma 4 pendant quelques jours : c’est rapide et intelligent, mais les problèmes d’utilisation d’outils persistent
Ce n’est pas la vitesse mais la limite d’intelligence qui bride la productivité. Il tombe souvent dans des boucles
Ce serait bien de pouvoir détecter ce genre de situation et « demander de l’aide » à un modèle plus intelligent
Désormais, je travaille moins comme codeur que comme orchestrateur d’agents. Mon rôle consiste à gérer plusieurs agents en parallèle
chat_template.jinjaettokenizer_config.jsonde gemma-4-31B-itIls disent avoir corrigé les problèmes liés aux appels d’outils, donc mieux vaut mettre à jour le modèle
Il est certes facile de configurer un LLM local avec ollama, mais il paraît que les appels d’outils ont de fortes chances d’échouer selon le modèle open source. Cela viendrait de la combinaison de règles internes assez souples dans ollama et de problèmes de parseur d’appels d’outils propres à chaque modèle.
Le vrai problème fondamental des LLM locaux, c’est qu’il faut du matériel coûteux pour faire tourner des modèles de taille moyenne à grande. Un Mac Studio 32 Go coûte autour de 3,5 millions de wons, et un GB10 environ 5 à 6 millions, donc c’est lourd à assumer pour un particulier qui voudrait en acheter un par simple loisir (?). Pour les LLM locaux, il faut se contenter de petits modèles, et pour les modèles moyens à grands, en dehors du cloud il n’y a pas vraiment d’alternative.