Modèles locaux pour agents de code

Un modèle local vaut la peine d’être envisagé quand le code ne peut pas quitter la machine, ou quand des milliers de petites modifications tournent chaque jour. Cette page classe les candidats selon la mémoire de la carte graphique (8, 12, 16 et 24 Go) et selon la mémoire unifiée des Mac Apple Silicon (16, 32 et 64 Go). Savoir si un modèle tient en mémoire, et ce qu’il reste pour le contexte, se calcule dans Déployer sur un appareil.

Le premier test d’un candidat porte sur le format, pas sur le score : un score élevé à un benchmark ne compense pas une sortie que le harnais ne sait pas analyser. gpt-oss-20b, par exemple, a été entraîné au format Harmony, le format de conversation et d’appel d’outils défini par OpenAI pour gpt-oss, et sa fiche modèle indique qu’il ne fonctionne pas correctement avec un autre format. Si le runtime ne prend pas en charge Harmony, le harnais ne peut pas analyser les appels d’outils du modèle, quels que soient ses scores.

La mémoire unifiée d’un Mac doit aussi contenir le système, l’affichage et les autres programmes ; il en reste donc moins pour le modèle que la capacité nominale. Depuis Ollama 0.40.0, les architectures prises en charge par MLX tournent automatiquement sur MLX sur Apple Silicon ; Gemma 4 en fait partie.

Instantané des candidats

Vérifié à partir des fiches modèles officielles des fournisseurs le 29 octobre 2026. Aucun candidat ci-dessous n’a encore mérité le qualificatif universel de « meilleur modèle de code local ». La quantification exacte, le runtime, le template, le contexte et le harnais définissent le système testé.

Candidats par niveau de mémoire

Niveau de mémoire	À essayer d’abord	À essayer aussi	À vérifier d’abord
Carte 8 Go	Gemma 4 E4B : 4,5 B de paramètres effectifs, contexte de 128K ; GGUF QAT q4_0 officiel de 5,15 Go	MiniCPM5-2B : 2,5 B dense (1,98 B hors embeddings), contexte de 131 072, Apache-2.0, versions officielles GGUF, MLX et GPTQ	Ce niveau convient seulement au tri, à la génération de requêtes et aux petites modifications sur un fichier. LiveCodeBench v6 : 52,0 pour E4B et 69,1 pour MiniCPM5, chiffres des fournisseurs ; MiniCPM5 demande l’analyseur d’appels d’outils minicpm5 dans SGLang
Carte 12 Go	Gemma 4 12B : 11,95 B dense, contexte de 256K, LiveCodeBench v6 72,0 ; GGUF QAT q4_0 officiel de 6,98 Go	Les modèles du niveau 8 Go avec un contexte plus long	Le fichier occupe environ 7 Go et laisse environ 5 Go au cache KV et au runtime
Carte 16 Go	gpt-oss-20b : MoE de 21 B au total / 3,6 B actifs, MXFP4, qui selon la fiche tourne dans 16 Go de mémoire ; Apache-2.0	Gemma 4 26B-A4B : MoE de 25,2 B au total / 3,8 B actifs ; GGUF QAT q4_0 officiel de 14,4 Go	gpt-oss exige un runtime qui gère Harmony ; une fois le fichier Gemma 26B chargé, il reste moins de 2 Go pour le contexte
Carte 24 Go	Devstral Small 2 24B : Apache-2.0, contexte de 256K, SWE-bench Verified 68,0 (chiffre du fournisseur) ; la fiche indique qu’il tourne sur une seule RTX 4090	Gemma 4 31B : 30,7 B dense, LiveCodeBench v6 80,0, GGUF QAT q4_0 officiel de 17,7 Go. Qwen3.8-27B : 27 B dense, Apache-2.0, contexte natif de 262 144, environ 13,5 Go de poids en 4 bits	Dans vLLM, Devstral demande --tool-call-parser mistral --enable-auto-tool-choice. Qwen3.8-27B n’a pas de GGUF officiel, seulement environ 1 600 quantifications communautaires ; le raisonnement est activé par défaut et se coupe par requête avec enable_thinking: False
Mac 16 Go	Le GGUF QAT de Gemma 4 E4B ou 12B	La version MLX 4 bits officielle de MiniCPM5-2B	mlx-lm 0.31.2 a ajouté l’analyseur d’appels d’outils de Gemma 4, et 0.32.0 celui de MiniCPM5. gpt-oss-20b est annoncé pour 16 Go, trop juste quand le système partage cette mémoire
Mac 32 Go	Devstral Small 2 24B : la fiche indique qu’il tourne sur un Mac doté de 32 Go de RAM	Le GGUF QAT de Gemma 4 26B-A4B ou 31B (14,4 / 17,7 Go) ; gpt-oss-20b	Vérifier que le runtime analyse correctement le format d’appel d’outils Mistral de Devstral et le format Harmony de gpt-oss
Mac 64 Go	Une quantification communautaire 8 bits de Qwen3.8-27B ou de Qwen3-Coder-30B-A3B, environ 27 à 31 Go de poids	Flint 40B-A2.5B : le modèle pour agents de code de Recursive, 39,8 B au total / environ 2,5 B actifs. Contexte de 262 144, Apache-2.0, SWE-bench Verified 74,2 (chiffre du fournisseur) ; la version Ollama pèse 23 Go	Qwen3-Coder-30B-A3B n’a qu’un mode sans raisonnement et un contexte natif de 262 144. La fiche officielle de Flint prévoit un déploiement sur une seule B300 ou H200 et ne fournit aucun fichier quantifié officiel ; la version Ollama est empaquetée à part

Remarque : « À essayer d’abord » et « À essayer aussi » sont des déductions tirées de la taille des fichiers et du positionnement des modèles, pas des recommandations officielles des fiches. Les « paramètres actifs » d’un MoE décrivent le calcul par token ; ils ne réduisent pas le volume total des poids à stocker. « Environ N Go de poids » correspond au nombre de paramètres multiplié par les octets par paramètre (0,5 octet en 4 bits, 1 octet en 8 bits), sans le cache KV.

Les candidats qui entrent dans une vraie sélection sont retestés avec le protocole d’évaluation des modèles locaux.

Axes de sélection

Avant de télécharger, choisissez la tâche et évaluez les candidats selon :

• la validité exacte des correctifs et des appels d’outils ;
• la couverture des langages du dépôt, et pas seulement de Python ;
• le taux de résultats acceptés sur des exécutions répétées ;
• la latence, la mémoire de pointe, le délestage CPU et le contexte utilisable ;
• la licence et les obligations de redistribution en aval pour l’artefact exact ;
• la prise en charge des formats de discussion/raisonnement dans le runtime choisi ;
• le comportement multilingue ainsi que le comportement de sécurité/refus pertinent pour le workflow.

Routage basé sur les rôles

• Un modèle compact prend les étapes à faibles conséquences et vérifiées en externe : tri de fichiers, génération de requêtes, réduction de journaux ou édition mécanique sur un seul fichier ; un modèle quantifié plus grand prend une implémentation ou une revue délimitée.
• Chaque modification se fait dans une copie du dépôt où les tests sont lancés ; en cas d’échec, on jette la copie sans toucher au répertoire de travail.
• L’architecture, les opérations sensibles pour la sécurité ou une signature d’erreur qui se répète passent à un modèle plus fort ou à un humain ; quand une tâche compte comme terminée et quand s’arrêter relève des Boucles d’agent bornées.

Mes lectures