🧠Choisir et dimensionner son modèle
Quel modèle local faire tourner sur VOTRE machine ? Le paysage des modèles open-weight 2026 (surtout chinois), et la règle simple pour les caler sur votre RAM.
Voici la vérité qu’on n’aime pas entendre : ce n’est pas vous qui choisissez votre modèle, c’est votre machine. Vous pouvez rêver de faire tourner le plus gros monstre open-weight de la planète, si vous avez 32 Go de RAM, il ne se lancera jamais. La bonne nouvelle, c’est qu’en 2026 le paysage local est devenu excellent, à condition de viser juste. On va d’abord poser la règle qui décide de tout (le dimensionnement), puis on regardera le catalogue, et enfin on tranchera la vraie question : à quel moment votre mini-PC suffit, et à quel moment Claude reste devant.
La règle de dimensionnement (celle qui décide de tout)
Avant le nom des modèles, la physique. Un modèle, ce sont des milliards de paramètres (les « poids »), et chacun occupe de la place en mémoire. La formule mentale tient en une ligne :
RAM nécessaire ≈ (nombre de paramètres × octets par poids) + le cache de contexte (le KV cache)
Les octets par poids dépendent de la précision (on y revient avec la quantization). En pratique, en Q4_K_M, le format standard, comptez ~0,56 Go par milliard de paramètres. Ajoutez 0,5 à 2 Go pour le système, et +30 à 50 % si vous travaillez avec un long contexte ou plusieurs requêtes en parallèle.
Quelques repères en Q4_K_M, histoire de vous faire l’œil : un Llama 8B tient dans ~6 Go, un modèle dense de 32B dans ~19 Go, un Llama 70B demande 40-43 Go. Et voici la table à garder sous le coude, par palier de mémoire :
| Mémoire dispo | Ce que vous faites tourner (Q4) | Modèle conseillé |
|---|---|---|
| 16 Go | Un 7-8B dense, ou un petit MoE compact | qwen2.5-coder:7b |
| 32 Go | Un 30B Q4 confortablement ✅ | qwen3-coder:30b |
| 64 Go | Un 70B Q4/Q5, ou GLM-4.5-Air | là, le local devient sérieux |
| 96 Go + | Marge KV pour le long contexte, gros MoE bien quantizé | au choix |
| 250 Go + | Les géants (Qwen3-Coder 480B, GLM-4.6, Kimi) | workstation uniquement |
Le raccourci : laissez un outil dimensionner pour vous
Toute la règle qu’on vient de poser (compter les Go, jauger le quant, repérer les MoE), un petit outil open-source la fait à votre place en deux secondes : llmfit (licence MIT, dépôt AlexsJones/llmfit). Il scanne votre machine (RAM, cœurs CPU, VRAM, multi-GPU) et les runtimes installés (Ollama, llama.cpp, LM Studio, MLX, Docker Model Runner), croise ça avec un catalogue de modèles et de quants, et vous sort un classement noté : ce qui rentre, ce qui tournera vite, et le quant à viser. De quoi éviter de tirer 20 Go de modèle pour rien.
L'installer
Par votre gestionnaire de paquets habituel, selon votre système :
# macOS / Linux (Homebrew)
brew install AlexsJones/llmfit/llmfit
# macOS / Linux (script rapide)
curl -fsSL https://llmfit.axjns.dev/install.sh | sh
# Windows (Scoop)
scoop install llmfit
# Sans rien installer durablement : Docker
docker run ghcr.io/alexsjones/llmfit
Lancer l'analyse
Sans argument, vous obtenez une interface terminal interactive (et un tableau de bord web sur http://<ip-machine>:8787). Vous préférez un tableau brut ou du JSON pour scripter ? Les options sont là.
llmfit # interface interactive + dashboard web
llmfit --cli # tableau classique dans le terminal
llmfit recommend --json --use-case coding --limit 3 # top 3 pour du code, en JSON
Le paysage des modèles 2026
Le fait marquant de l’année : les labos chinois dominent l’open-weight. Deux silhouettes utiles se dégagent. Les MoE géants (≈1000 milliards de paramètres au total, ~30B actifs) pour le cloud ou la workstation. Et les MoE compacts (~30B total, ~3B actifs) qui, eux, tournent vraiment sur un mini-PC. C’est cette deuxième famille qui nous intéresse.
Voici les choix réalistes pour une machine locale :
| Modèle | Type / taille | Pour quoi | Vous pouvez le faire tourner ? |
|---|---|---|---|
| Qwen3-Coder 30B | MoE, 30B total / 3,3B actifs | Code, refactor, debug, contexte 256K | ✅ Dès 32 Go, le meilleur pick mini-PC |
| Qwen2.5-Coder 7B/14B/32B | Dense | Autocomplétion (FIM), complétion | ✅ Selon la RAM (7B dès 16 Go) |
| GLM-4.5-Air | MoE, ~106B | Le GLM réaliste en local | ⚠️ Si vous avez 64-96 Go |
| Gemma 4 | MoE, ~26B (Google) | Point de départ non-chinois honnête | ✅ Sur une machine correcte |
| GLM-4.6 | ~357B, licence MIT | Niveau Claude Sonnet 4.x sur du vrai code | ❌ Workstation / API |
| DeepSeek-V3.2 | MoE + attention éparse | Top « intelligence », excellent long contexte | ❌ Trop gros pour un mini-PC |
| Kimi K2.6 (Moonshot) | 1000B MoE / 32B actifs | Roi des benchmarks agentiques open-weight | ❌ API / grosse workstation |
Le premier choix sur un mini-PC, c’est qwen3-coder:30b, sans hésiter. Pour l’autocomplétion en arrière-plan, qwen2.5-coder:14b ou 32b sont parfaits. Et si vous avez une machine bien dotée (64-96 Go), GLM-4.5-Air est le GLM qui rentre.
La quantization en clair
Vous avez vu passer des noms comme Q4_K_M. Décodons. GGUF est le format de fichier des modèles locaux, et le suffixe indique la précision : combien de bits par poids on garde. Moins de bits = fichier plus léger = ça rentre dans moins de RAM. Le compromis, c’est une petite perte de qualité.
| Niveau | Qualité | Quand l’utiliser |
|---|---|---|
Q8_0 | Quasi parfait | Rarement justifié pour du code (trop lourd) |
Q6_K / Q5_K_M | Excellent | Raisonnement critique, si vous avez la marge mémoire |
Q4_K_M | Très bon | Le standard de fait : votre choix par défaut |
< Q4 | Dégradation visible | Seulement si la mémoire vous y force |
Le Q4_K_M pèse environ 28 % du modèle FP16 d’origine pour seulement ~2-3 % de perte. Pour du code spécifiquement, il tient très bien la route, passer à Q5 ou Q6 n’améliore pas la génération de code de façon perceptible. Vous ne descendez sous Q4 que contraint, et vous le sentez vite (code et raisonnement trinquent les premiers).
Brancher le bon quant dans Ollama
En pratique, c’est simple : avec Ollama, le tag encode déjà le quant. Vous choisissez votre précision en l’écrivant dans le nom.
Tirez le modèle au bon quant
Le suffixe après le tag, c’est la quantization. Sans suffixe, Ollama prend un défaut (souvent Q4_K_M).
# Le défaut (généralement Q4_K_M), parfait pour commencer
ollama pull qwen3-coder:30b
# Ou le quant explicite, si vous voulez être sûr
ollama pull qwen3-coder:30b-a3b-q4_K_M
Calez le contexte sur le besoin réel
Le contexte coûte de la RAM (le fameux KV cache). Par défaut OLLAMA_CONTEXT_LENGTH vaut 2048, ce qui est ridiculement bas pour du code. Mais le monter trop fort gonfle la RAM et peut vous pousser dans le swap : c’est la cause n°1 du « Ollama est lent ». Réglez num_ctx sur ce dont la tâche a vraiment besoin, pas au maximum par réflexe.
Honnêtement : local ou Claude ?
On ne va pas vous vendre du rêve. À la mi-2026, voici où en est le local, sans filtre.
Pour les tâches bornées et privées : génération sur fenêtre courte, refactor, autocomplétion, debug ciblé, le local est vraiment compétitif. C’est privé, c’est gratuit à l’usage, et l’écart sur les benchmarks s’est nettement resserré (GLM-4.6 tutoie Claude Sonnet 4.x, Kimi K2.6 est costaud en agentique). Et un point trop souvent oublié : un modèle open-weight performe bien mieux dans un bon harnais (un OpenCode bien configuré) que dans un chat brut.
Mais deux limites à garder en tête :
- Le sommet absolu reste Claude. Claude Fable 5 tourne autour de ~95 % sur SWE-bench Verified, nettement au-dessus du cluster open-weight (~80 %).
- Les meilleurs modèles ouverts ne tournent pas sur un mini-PC. Kimi (1000B), GLM-5.2, MiniMax M3, c’est de l’API ou de la workstation. Ce qui rentre localement (Qwen3-Coder 30B, GLM-4.5-Air) est d’un cran en dessous sur la fiabilité agentique au long cours et l’usage d’outils.