· reAPI Team
LLM local pour coder : quels modèles tiennent dans 8, 16, 32 ou 64 GB
Un LLM local pour coder doit tenir en mémoire et offrir un contexte de 64K. Modèles de programmation avec outils dans Ollama, classés par taille de téléchargement et contexte.
Choisir un LLM local pour coder commence par deux chiffres, plutôt que par un classement : la mémoire de votre machine et la taille du contexte que le modèle peut accueillir. Un agent de programmation comme Claude Code ou Cline a besoin d'un modèle prenant en charge les appels d'outils, et la documentation d'Ollama indique que les outils de programmation nécessitent un contexte d'au moins 64,000 tokens.[1] Les modèles ci-dessous figurent dans la bibliothèque d'Ollama avec prise en charge des outils, classés selon la taille de téléchargement de leurs versions 4 bits indiquée le 4 novembre 2026.[2]
Nous ne les classons pas par qualité. Aucun benchmark indépendant unique ne les couvre tous sur les mêmes tâches d'agent, et le bon choix dépend de votre dépôt. Nous pouvons en revanche indiquer lesquels tiennent en mémoire, lesquels offrent assez de contexte et lesquels tournent vite avec une bande passante mémoire limitée.
LLM locaux pour coder, selon la mémoire disponible
| Mémoire disponible | Modèle (tag Ollama) | Téléchargement en 4 bits | Fenêtre de contexte | Notes |
|---|---|---|---|---|
| Jusqu'à 8 GB | qwen2.5-coder:7b | 4.7 GB | 32K | En dessous des 64K nécessaires aux agents |
| Jusqu'à 8 GB | mimo-v2.6:9b-q4_K_M | 6.6 GB | 256K | Xiaomi ; entrée texte et image |
| Jusqu'à 16 GB | qwen2.5-coder:14b | 9.0 GB | 32K | En dessous des 64K nécessaires aux agents |
| Jusqu'à 16 GB | gpt-oss:20b | 14 GB | 128K | Modèle à poids ouverts d'OpenAI |
| Jusqu'à 32 GB | qwen3.6:27b-q4_K_M | 17 GB | 256K | Entrée texte et image ; une variante pour le code fait 18 GB |
| Jusqu'à 32 GB | qwen3-coder:30b | 19 GB | 256K | Tag complet 30b-a3b-q4_K_M |
| Jusqu'à 32 GB | north-mini-code-1.0 | 19 GB | 488K | Cohere ; 30B au total, 3B actifs |
| Jusqu'à 32 GB | qwen2.5-coder:32b | 20 GB | 32K | En dessous des 64K nécessaires aux agents |
| Jusqu'à 64 GB | qwen3-coder-next | 52 GB | 256K | Modèle de Qwen pour la programmation agentique |
| Plus de 64 GB | gpt-oss:120b | 65 GB | 128K | |
| Plus de 64 GB | nemotron-3.5-super:120b-a12b-q4_K_M | 90 GB | 1M | NVIDIA ; 12B actifs |
| Plus de 64 GB | qwen3-coder:480b | 290 GB | 256K | Station de travail ou serveur uniquement |
Sources : bibliothèque de modèles et pages de tags d'Ollama.[2][3]
La taille de téléchargement est un minimum, pas le besoin total. Le cache de contexte grandit avec la fenêtre définie : un modèle de 19 GB exécuté avec un contexte de 64K ou plus nécessite donc plus de 19 GB libres. Ollama avertit qu'un contexte plus grand augmente la mémoire nécessaire pour exécuter un modèle.[1]
Pourquoi la longueur du contexte exclut certains modèles
Ollama définit le contexte selon la mémoire de votre GPU si vous n'en choisissez pas un : 4K tokens en dessous de 24 GiB de VRAM, 32K entre 24 et 48 GiB, et 256K au-delà.[1] Son guide Claude Code demande 64K ou plus pour les dépôts volumineux.[4] Sur une carte de 16 GB, il faut donc augmenter manuellement la valeur par défaut, tout en gardant assez de mémoire pour le modèle et son cache.
Le plafond du modèle compte aussi. Les tags qwen2.5-coder indiquent une fenêtre de contexte de 32K : même avec de la mémoire disponible, ils ne peuvent donc pas atteindre les 64K qu'Ollama recommande pour les agents de programmation.[3] Ils restent utiles pour l'autocomplétion et les petites modifications. Pour un agent qui lit plusieurs fichiers et conserve un long historique d'outils, les modèles de 128K à 488K du tableau sont les options réalistes.
Les modèles à mélange d'experts tournent plus vite avec la même mémoire
Cohere décrit North Mini Code comme « un modèle à mélange d'experts de 30B avec 3B de paramètres actifs » : environ 30 milliards de paramètres au total, dont environ 3 milliards utilisés pour chaque token.[2] Le tag 30B de Qwen3-Coder porte le même suffixe a3b, et celui de Nemotron de NVIDIA indique 120b-a12b.[3] Tous les poids doivent quand même résider en mémoire : la taille de téléchargement reste donc la même que celle d'un modèle dense de taille totale similaire. La vitesse de génération, elle, diffère. Chaque token ne lit que les experts actifs, et c'est généralement la bande passante mémoire, plutôt que la puissance de calcul, qui limite la vitesse de génération des tokens sur une machine locale.
L'effet est considérable. Sur une machine offrant une bande passante mémoire de 273 GB/s, la lecture de 35 GB de poids denses d'un modèle de 70B par token plafonne la sortie à environ 8 tokens par seconde, tandis que la lecture d'environ 1.5 GB de poids en 4 bits pour un modèle à 3B de paramètres actifs permet un plafond bien plus élevé. Nous détaillons ce calcul dans notre guide des caractéristiques du DGX Spark. Pour les agents de programmation, qui génèrent de longues sorties et de nombreux appels d'outils, cette différence se ressent à chaque tour.
Connecter un modèle local à un agent de programmation
Ollama peut démarrer Claude Code avec un modèle local grâce à ollama launch claude ; pour les scripts, ollama launch claude --model <model> --yes -- -p "..." évite les invites de confirmation.[4] Ollama indique que l'appel d'outils et la réflexion sont disponibles « avec les modèles compatibles » : vérifiez donc la présence du tag d'outils sur la page du modèle avant de le connecter.[4] LM Studio fonctionne aussi, via son endpoint compatible Anthropic sur le port 1234 ; notre comparatif Ollama vs LM Studio couvre les deux configurations.
Définissez explicitement le contexte dans l'un comme dans l'autre. Un modèle qui s'exécute silencieusement en 4K écartera des fichiers de la conversation et paraîtra moins performant qu'il ne l'est.
FAQ
Combien de mémoire faut-il pour un modèle local de programmation ?
Pour un agent avec un contexte de 64K, prévoyez environ 24 GB ou plus : un modèle de 17 GB à 19 GB tel que qwen3.6:27b ou qwen3-coder:30b, plus de la place pour le cache de contexte. Des modèles plus petits tiennent dans 8 GB à 16 GB, mais ceux dont le plafond est de 32K conviennent mieux à la complétion qu'aux agents.[1][3]
Qu'est-ce que Nemotron 3.5 Super ?
Ollama le présente comme « le modèle vision-langage de NVIDIA pour la programmation, le raisonnement, l'utilisation d'outils et la compréhension de documents ». Le tag local correspond à un modèle de 120B avec 12B de paramètres actifs et un contexte de 1M de tokens ; son téléchargement en 4 bits fait 90 GB.[2][3]
Peut-on utiliser un LLM local pour coder sur un ordinateur portable ?
Oui, dans les limites de mémoire ci-dessus. Un portable de 8 GB à 16 GB peut exécuter mimo-v2.6:9b ou gpt-oss:20b, dont les fenêtres de contexte annoncées sont de 256K et 128K, mais il faut laisser de la place pour le cache de contexte.[3]
Quand choisir plutôt un modèle hébergé
Un LLM local pour coder est intéressant lorsque votre code ne peut pas quitter la machine ou lorsque vous effectuez assez de tours pour que le matériel coûte moins cher que les tokens. Si votre mémoire maximale reste en dessous des besoins d'un modèle à contexte de 256K, ou si vous voulez comparer un modèle local à un modèle hébergé plus gros sur la même tâche, une API hébergée est plus simple. reAPI propose des modèles tels que Kimi K3, DeepSeek V4 et GLM-5.2 via une seule clé compatible OpenAI : un changement de modèle sur une ligne suffit donc pour faire cette comparaison.
Références
- Ollama. Context length. Consulté le 4 novembre 2026 sur docs.ollama.com/context-length
- Ollama. Model library search: tools capability, "coder". Consulté le 4 novembre 2026 sur ollama.com/search?c=tools&q=coder
- Ollama. Model tag pages: qwen3-coder, qwen3-coder-next, qwen3.6, north-mini-code-1.0, mimo-v2.6, nemotron-3.5-super, qwen2.5-coder and gpt-oss. Consulté le 4 novembre 2026 sur ollama.com/library
- Ollama. Claude Code integration. Consulté le 4 novembre 2026 sur docs.ollama.com/integrations/claude-code