Meilleur LLM local pour coder : de 8 à 24 Go de VRAM

Le meilleur LLM local pour coder en ce moment : Qwen3 Coder 30B A3B sur une carte 24 Go, Qwen2.5 Coder 14B en Q4 sur 12–16 Go, et Qwen2.5 Coder 7B en Q4 sur 8 Go. Chacun tourne entièrement hors ligne, complète et refactorise du vrai code, et ne coûte rien par token. Si ta GPU a moins de VRAM qu'il n'en faut pour le modèle, baisse le quant d'un cran avant de baisser la taille du modèle. Ce guide associe les modèles aux tranches de VRAM, compare les deux familles de modèles de code sur lesquelles on se dispute vraiment, et finit avec des commandes prêtes à l'emploi pour générer du code en local en cinq minutes environ.

Quel LLM local pour coder sur ta carte graphique ?

Choisis par la VRAM d'abord, le modèle ensuite — le modèle n'entre que si les poids plus le contexte tiennent en mémoire. Voici la sélection qui sort en tête des benchmarks communautaires 2026 comme de l'usage de tous les jours :

VRAM	Modèle	Quant	Poids sur disque	Pourquoi il gagne cette tranche
8 Go	Qwen2.5 Coder 7B Instruct	Q4_K_M	~4,7 Go	Meilleur ratio débit (tokens/s)/qualité pour l'autocomplétion et les petits refactors
12 Go	Qwen2.5 Coder 14B Instruct	Q4_K_M	~9,0 Go	Les éditions de fichiers entiers tiennent dans le contexte ; toujours 30+ tokens/s sur une carte classe 3060
16 Go	Qwen3 14B ou gpt-oss-20b	Q4_K_M	~9–12 Go	Meilleur raisonnement sur des specs ambiguës ; les cartes classe 4090 le gardent rapide
24 Go	Qwen3 Coder 30B A3B	Q4_K_M	~18,6 Go	MoE : seulement ~3 Md de paramètres actifs par token, donc une vitesse restant exploitable

Deux règles rendent ce tableau utilisable en pratique :

Garde 1–2 Go de marge de VRAM pour le cache KV. Un modèle 14B en Q4 plus un contexte de 8K tokens n'entrent pas dans un budget de 10 Go — le contexte compte dans le total.
Descends d'un quant avant de descendre d'une taille de modèle. Les quants Q5/Q4 coûtent quelques pour cent de qualité ; passer d'un 14B à un 7B coûte bien plus.

Quelle VRAM faut-il pour un LLM de code en local ?

La règle de pouce honnête : VRAM nécessaire ≈ poids quantifiés + 0,125 Go par 1K tokens de contexte avec un cache KV en 8 bits. En chiffres clairs :

8 Go fait tourner des modèles 7B–8B en Q4 confortablement. Attends-toi à des réponses longueur autocomplétion, 4K–8K de contexte.
12 Go, c'est le point idéal pour un 14B en Q4 — assez de place pour le modèle plus un contexte de code réaliste de 8K–16K.
16 Go ouvre les modèles denses de classe 20B et Qwen3 14B avec plus de contexte.
24 Go fait tourner le MoE Qwen3 Coder 30B A3B en Q4, ce qui ressemble le plus à un modèle de code de qualité cloud que tu peux héberger toi-même.

CPU seul ? Ça marche — llama.cpp fera tourner un 7B Q4 sur un CPU de portable à 5–10 tokens/s — mais traite ça comme un exercice de patience, pas un pilote quotidien. Pour la partie outillage — quel runtime installer — la comparaison Ollama vs LM Studio couvre quel outil LLM local mettre sous tes modèles.

Qwen3 Coder vs DeepSeek : lequel est le meilleur pour coder ?

C'est le duel que les barres d'autocomplétion demandent toutes, et la réponse se coupe net :

Qwen3 Coder (30B A3B) est construit pour la boucle d'édition : il suit les conventions de format d'instruction pour le tool calling, produit des diffs cohérents et — le point décisif — son architecture MoE n'active que ~3 Md de paramètres par token, donc une seule carte 24 Go obtient 40–60 tokens/s. En usage façon IDE, la réactivité fait partie de la qualité.
La lignée DeepSeek V3/R1 raisonne à un étage au-dessus : décisions d'architecture, algorithmes tordus, raisonnement multi-étapes. Mais le fleuron pèse 600 Md+ de paramètres ; en local on ne le lance que très quantifié, sur du multi-GPU ou de la mémoire unifiée Mac, et il écrit des dissertations sur le code plus vite que le code lui-même.

Choix en local : Qwen3 Coder comme pilote quotidien, DeepSeek seulement si tu as le matériel pour l'héberger proche de la pleine précision. À 8–16 Go le débat est clos — les Qwen2.5/3 Coder sont ce qu'il y a de plus fort qui rentre.

Comment lancer le meilleur LLM de code en local avec Ollama ?

Cinq commandes, de zéro à une API compatible OpenAI que ton éditeur peut utiliser :

# 1. Installer Ollama (Linux)
curl -fsSL https://ollama.com/install.sh | sh

# 2. Tirer le modèle qui correspond à ta tranche de VRAM (carte 8 Go ici)
ollama pull qwen2.5-coder:7b

# 3. Discuter avec le modèle en interactif
ollama run qwen2.5-coder:7b

# 4. L'utiliser comme API compatible OpenAI depuis n'importe quel outil
curl http://localhost:11434/v1/chat/completions \
  -d '{
    "model": "qwen2.5-coder:7b",
    "messages": [{"role": "user", "content": "Refactor this fn to be async: add(a,b){return a+b}"}]
  }'

# 5. Pointer dessus les outils qui attendent OPENAI_BASE_URL
export OPENAI_BASE_URL=http://localhost:11434/v1

Pas de clé d'API, pas de limite de débit, pas de facture au token. Sous Linux, l'installeur enregistre une unité systemd : si le serveur déconne un jour, journalctl dit pourquoi — le mémo journalctl a les filtres exacts pour déboguer un service.

Un LLM local est-il assez bon pour du vrai travail de code ?

Oui pour la boucle d'édition, non pour les problèmes durs — et ce découpage est exactement la bonne façon de l'utiliser. Un modèle local 14B–30B gère les refactors, le boilerplate, les squelettes de tests, les regex et les « explique-moi cette fonction legacy » plus vite que la plupart des APIs cloud ne font l'aller-retour. Là où il perd face aux gros modèles hébergés : le raisonnement long multi-fichiers et les questions pointues de framework — un 30B sait tout simplement moins de choses qu'un modèle de frontière.

Le flux qui marche : garde un modèle local pour 90 % de tes frappes, et réserve un modèle hébergé de frontière aux questions de conception velues. Ton code ne quitte pas la machine pour le travail courant — ce qui compte pour du code client — et la VRAM que tu possèdes déjà remplace discrètement un abonnement.