Pourquoi passer au local ?

Tout le monde connaît ça. Tu es en pleine session de code, le flow créatif est enfin là, et patatra — la connexion plante. Ton assistant IA cloud devient totalement inutile, et tu te retrouves à contempler ton écran en te demandant comment avancer.

C'est exactement ce qui m'est arrivé récemment. Cette frustration m'a poussé à explorer enfin les possibilités d'un agent de coding IA fonctionnel en local. Ce que j'y ai découvert m'a surpris : avec la bonne configuration, les performances sur Apple Silicon sont bluffantes, et surpassent même certaines solutions Mac-optimized spécialisées.

La config qui marche vraiment

Après pas mal de tests et de benchmarks, voici l'association qui deliver les meilleurs résultats sur mon M1 Max avec 64 Go de mémoire unifiée :

Stack de base :

• llama.cpp compilé avec l'accélération Metal
• Gemma 4 26B-A4B en format GGUF (quantisé Q4)
• Un modèle draft MTP (Multi-Token Prediction) pour le speculative decoding
• Le projecteur multimodal Gemma 4 pour gérer les screenshots
• Pi comme agent de coding en terminal

Ce n'est pas la config la plus puissante qu'on puisse théoriquement monter, mais c'est le sweet spot pour une vraie utilisabilité au quotidien. Ce qui compte, c'est la vitesse en tokens par seconde, pas en minutes par réponse.

Les chiffres qui comptent vraiment

J'ai lancé des benchmarks cohérents avec ce prompt sur toutes les configs :

"Écris une fonction Python compacte qui parse un unified diff et retourne les chemins des fichiers modifiés. Puis explique deux cas limites."

Chaque test générait environ 128 tokens, ce qui donne une base de comparaison honnête de la vitesse de génération.

Performances de base :

Faire tourner Gemma 4 directement via llama.cpp avec Metal nous a donné 58,2 tokens par seconde. C'est utilisable, mais honnêtement ? Durante les sessions de code réelles où tu enchaînes les tool calls et les réponses, ça rame.

La différence MTP :

Là ça devient intéressant. Le Multi-Token Prediction permet au modèle de "spéculer" plusieurs tokens ahead, en acceptant les prédictions correctes et en rollbackant les erreurs. Avec le modèle draft MTP Q8 activé, les perfs ont grimpé à 72,2 tokens par seconde — soit 24% de gain sans changer le modèle principal.

Le traitement du prompt est resté quasi identique (autour de 297-299 tokens/seconde), mais c'est la vitesse de génération qui compte pour les agent workflows. Tu ne soumets pas des nouveaux prompts en permanence — tu attends que le modèle génère des réponses, prenne des décisions, et exécute des tools.

J'ai testé des valeurs de draft tokens de 1 à 6, et sur mon M1 Max, 3 draft tokens hit the sweet spot. Au-delà de 4, ça commençait à ralentir, ce qui fait sens — plus de spéculation = plus de travail gaspillé quand les prédictions foirent.

llama.cpp vs MLX : le perdant surprise

Voilà ce qui m'a blowé : je m'attendais à ce que MLX (le framework ML natif Apple) domine vu qu'il est spécifiquement optimisé pour Apple Silicon. La réalité était différente.

| Runtime | Génération tok/s | |---------|------------------| | llama.cpp Metal + MTP | 72.2 | | llama.cpp Metal | 58.2 | | MLX-LM (Unsloth 4-bit) | 45.8 | | MLX-LM (standard 4-bit) | 43.9 | | MLX-LM (OptiQ 4-bit) | 38.1 |

Llama.cpp avec MTP était environ 58% plus rapide que la meilleure config MLX. Les années d'optimisation qui sont passées dans llama.cpp ont clairement payé — ça tourne excellemment sur macOS malgré son côté cross-platform.

Ajouter la vision

Pour une vraie expérience d'agent de coding, tu veux pouvoir envoyer des screenshots. Peut-être que tu veux que l'agent voie ce qu'il a buildé, ou qu'il review un changement UI que tu viens de faire.

Le hic ? Seul Gemma 4 12B est nativement multimodal. Le modèle 26B qu'on utilise nécessite le projecteur multimodal externe.

Quand j'ai ajouté le --mmproj projector à llama.cpp, il a bien advertised les capacités multimodales à Pi, et les sorties d'outils image ont commencé à passer correctement. Plus important : ça n'a introduisit aucun slowdown mesurable — la vitesse de génération est restée à 72,2 tokens par seconde.

L'expérience terrain

Avec cette config, tu obtiens environ 17 Go de fichiers modèles (16 Go pour le modèle principal, plus la tête MTP et le projector). Pour quelqu'un avec 64 Go de mémoire unifiée, c'est totally manageable.

Pi comme agent fournit une interface terminal propre qui se connecte à l'API compatible OpenAI que le mode server de llama.cpp expose. Ça veut dire que tu peux l'utiliser avec n'importe quel tool qui supporte le format API OpenAI — de la flexibilité sans lock-in.

Le benefit majeur ? Quand ton internet lache — et ça arrivera, au pire moment possible — tu continues à coder. L'agent sera peut-être légèrement plus lent que les alternatives cloud, mais suffisamment responsive pour maintenir ton workflow.

Par où commencer

Tu devras build llama.cpp avec le support Metal activé. Le projet a une doc solide pour les builds macOS, et une fois compilé, le mode server te donne cet endpoint compatible OpenAI.

Pour les modèles, les quantizations GGUF Unsloth sur Hugging Face sont bien optimisées. Vise la quantization Q4_K_XL pour le modèle principal et le modèle draft MTP Q8 correspondant.

Tune ta valeur --spec-draft-n-max — commence à 3 et teste de 1 à 6 pour trouver ce qui fonctionne le mieux sur ton hardware. Différentes configs Apple Silicon peuvent avoir des sweet spots différents.

Est-ce que ça vaut le coup ?

Si tu codes régulièrement avec des assistants IA et que t'as le hardware (16 Go minimum, 32 Go+ recommended), absolument. L'indépendance face à la connectivité internet seule already makes it valuable, et avec MTP qui bring les vitesses de génération dans un truc réellement utilisable, l'expérience est étonnamment polished.

Tu ne vas pas égaler l'intelligence de classe GPT-4 avec ces modèles open, mais pour du code completion, du refactoring, du debugging assistance, et des tâches d'agent de coding général ? C'est plus capable que la plupart des gens ne le pensent, et c'est le tien — running locally, privately, sans latency spikes ou service outages.

Les outils ont muri significativement. Si t'as déjà essayé les modèles locaux et été déçu par la vitesse, donne une chance à cette config. MTP change l'équation considérablement.