Faire tourner Gemma 4 et OpenCode localement sur Mac

Un guide publié en avril 2026 décrit une configuration locale pour faire tourner Gemma 4 26B avec OpenCode sur macOS Apple Silicon, en contournant les bugs de tool calling d’Ollama et les limites des fournisseurs OpenAI-compatibles locaux. La pile proposée repose sur llama.cpp compilé depuis les sources et sur une version d’OpenCode reconstruite avec un correctif de compatibilité. Objectif : récupérer des appels d’outils fiables sur Mac, sans dépendre d’un service cloud. Le sujet compte pour les développeurs qui veulent garder leurs données en local, mais aussi pour les équipes qui testent des agents sur machine personnelle sans passer leur soirée à chasser des parsing errors.

Pourquoi Ollama bloque Gemma 4

Selon la note, Ollama v0.20.0 pose trois problèmes avec Gemma 4 : le parseur d’appels d’outils plante, le streaming perd les tool calls en route et le tokenizer produit du bruit en sortie. Le document renvoie à ollama/ollama#15241 pour le crash de parsing, et précise que les appels d’outils peuvent être envoyés dans le champ reasoning avec un contenu vide, ce qui empêche le client de les récupérer. Dans ce contexte, la version recommandée de llama.cpp intègre le correctif de template lié à la PR #21326 et le correctif tokenizer de la PR #21343.

Le même constat vaut côté OpenCode : la version standard n’arrive pas à récupérer proprement les réponses d’un modèle local quand celui-ci renvoie des outils en JSON brut, utilise finish_reason: "stop" au lieu de tool_calls ou s’appuie encore sur l’ancien format function_call. La PR #16531 ajoute une couche de compatibilité pour absorber ces écarts. Autrement dit, le modèle peut parler un dialecte un peu trop créatif, et le wrapper doit faire le traducteur.

Une pile locale pensée pour Apple Silicon

Le guide a été testé sur un Mac Apple Silicon M1 Max avec 32 Go de RAM, le 2 avril 2026. Pour faire tourner le modèle, il recommande de cloner llama.cpp depuis les sources, de récupérer le correctif tokenizer puis de compiler avec -DGGML_METAL=ON pour activer Metal, l’API graphique d’Apple. Le serveur est ensuite lancé sur le port 8089, avec un contexte de 32 768 tokens minimum pour les définitions d’outils d’OpenCode, et l’option --jinja, jugée indispensable pour le tool calling de Gemma 4.

La configuration proposée charge le modèle Gemma 4 26B A4B IT GGUF en quantification Q4_K_M. D’après la note, le modèle consomme environ 17 Go de mémoire pour une session classique, ce qui laisse peu de marge quand Chrome décide de faire son petit déjeuner sur la RAM du Mac. Pour les machines les plus à l’aise, le guide monte jusqu’à 128k de contexte, mais prévient que la pression mémoire augmente nettement.

OpenCode, le maillon qui évite de casser les outils

OpenCode est ensuite installé via son script officiel, puis remplacé par une version reconstruite depuis le dépôt anomalyco/opencode avec la PR #16531. Le fichier de configuration opencode.json pointe vers http://127.0.0.1:8089/v1 et active deux parseurs : raw-function-call et json. Ce duo sert à récupérer les appels d’outils même quand le modèle les renvoie sous une forme bancale. La définition du modèle inclut aussi tool_call: true, pour signaler à OpenCode que le backend local sait parler outils.

Le guide insiste aussi sur AGENTS.md, un fichier d’instructions qui donne au modèle les noms exacts des paramètres attendus par chaque outil. Les schémas sont détaillés pour bash, write, read, edit, glob, grep et todowrite. L’idée est simple : si Gemma 4 se trompe sur le nom d’un champ, la compatibilité s’effondre. L’auteur du guide recommande donc des paramètres stricts, sans improvisation créative.