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.
Sur cette fiche
Fiche vérifiée il y a 3 mois : certaines commandes ont pu changer. Signalez-le si c’est le cas.
En bref
C'est la mémoire de votre machine qui décide : comptez environ 0,6 Go par milliard de paramètres en 4 bits, plus le contexte. D'après Quelle IA (édition du 28 septembre 2026), Qwen3.5-9B est le meilleur choix jusqu'à 16 Go, Qwen 3.8 27B le meilleur d'une carte graphique de 24 Go jusqu'à un mini-PC de 128 Go, avec Gemma 4 26B A4B en option plus rapide et gpt-oss-120b pour les agents. Les plus grands modèles ouverts, comme GLM-5.3-Flash ou DeepSeek V4.1 Flash, demandent plus de 200 Go. En code, le meilleur modèle local reste nettement sous Claude : le local pour les tâches bornées et privées, le cloud pour les longs chantiers.
À faire avant : Choisir le matériel
Votre machine choisit votre modèle à votre place, et c’est la vérité qu’on aime le moins entendre. 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,6 Go par milliard de paramètres (c’est la règle que suit Quelle IA, détaillée sur sa page « Comment on compte »). 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. Ce sont les choix de Quelle IA à l’édition du 28 septembre 2026 ; ils changent souvent, alors vérifiez la page de votre machine avant de télécharger 20 Go.
| Mémoire de la machine | Le mieux noté qui tient | Dans Ollama |
|---|---|---|
| Carte graphique 8 Go | Qwen3.5-4B | qwen3.5:4b |
| 16 Go (carte graphique, Mac, PC portable) | Qwen3.5-9B | qwen3.5:9b |
| Carte 24 Go, Mac ou Ryzen AI Max 32 Go | Qwen 3.8 27B en 4 bits ; Gemma 4 26B A4B, plus rapide | qwen3.8:27b, gemma4:26b |
| 64 à 128 Go (Ryzen AI Max, Mac) | Qwen 3.8 27B en 8 bits ou complet ; pour les agents sur 128 Go, gpt-oss-120b | qwen3.8:27b-q8_0, gpt-oss:120b |
| Plus de 200 Go (grappe de DGX Spark, Mac 512 Go) | GLM-5.3-Flash, DeepSeek V4.1 Flash | hors mini-PC |
Pour votre configuration exacte : la page de chaque machine (par exemple Ryzen AI Max+ 395 de 128 Go ou Mac mini M6 de 32 Go), ou Trouver mon modèle en quatre questions.
# ce que le GPU intégré a pris au système, en octets
cat /sys/class/drm/card*/device/mem_info_gtt_used
# réserver 28 Go de RAM au reste de la machine (valeur en octets)
# à poser dans l'environnement du service Ollama
OLLAMA_GPU_OVERHEAD=30064771072
Sans ce réglage, Ollama dimensionne ses couches comme s’il était seul sur la machine. Il voit un GPU de 128 Go, il accepte donc de charger un modèle de 65 Go sur une machine de 94 Go qui héberge trente autres services.
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.
0 étape sur 2 faite Vos cases cochées restent dans ce navigateur.
-
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
Ces deux outils disent ce qui rentre. Pour savoir ce qui est le mieux noté parmi ce qui rentre, tâche par tâche (code, agents, français…), c’est Quelle IA, machine par machine : 64 machines réelles, avec des prix datés.
Le paysage des modèles 2026
Le fait marquant : les labos chinois dominent l’open-weight (Alibaba, DeepSeek, Z.ai, Moonshot, MiniMax, Xiaomi), avec Google (Gemma) et OpenAI (gpt-oss) comme principales options américaines. Deux silhouettes se dégagent. Les géants (de quelques centaines de milliards à 2,8 T de paramètres au total) pour le serveur ou la grappe de machines. Et les compacts (autour de 25-30B, denses ou MoE) qui, eux, tournent vraiment sur un mini-PC. C’est cette deuxième famille qui nous intéresse.
Voici les choix sûrs au 28 septembre 2026, d’après Quelle IA :
| Modèle | Type / taille | Pour quoi | Vous pouvez le faire tourner ? |
|---|---|---|---|
| Qwen 3.8 27B (Alibaba, août 2026) | Dense, 27B, contexte 256K | Le mieux noté sous 128 Go, code compris | ✅ Carte 24 Go ou 32 Go unifiés : qwen3.8:27b |
| Gemma 4 26B A4B (Google, avril 2026) | MoE, 26B / ~4B actifs, contexte 256K | Rapide, non chinois, modèle de référence de la machine de test | ✅ Dès 32 Go : gemma4:26b |
| Qwen3.5-9B / 4B (Alibaba, février 2026) | Denses | Les machines de 8 à 16 Go | ✅ qwen3.5:9b, qwen3.5:4b |
| gpt-oss-120b (OpenAI, août 2025) | MoE, 117B | Le mieux noté en agents sous 128 Go | ⚠️ Machine de 128 Go, 65 Go à télécharger : gpt-oss:120b |
| Qwen3.6 27B (Alibaba, avril 2026) | Dense, 27,8B, contexte 256K | Le prédécesseur, toujours solide | ✅ Dès 24 Go : qwen3.6:27b |
| GLM-4.7-Flash (Z.ai) | ~19 Go en Q4, contexte 198K | Le GLM qui rentre vraiment en local | ✅ Dès 32 Go : glm-4.7-flash |
| GLM-5.3-Flash (Z.ai, août 2026) | MoE, 320B | Le meilleur local en code et en agents | ❌ ~220 Go en 4 bits ; en ligne via glm-5.3-flash:cloud |
| DeepSeek V4 Flash / V4.1 Flash | MoE ; V4 Flash : 284B, 13B actifs, contexte 1M | Long contexte ; V4.1 Flash en tête des locaux | ❌ Grappe de DGX Spark |
| Kimi K3 (Moonshot, juillet 2026) | 2,8 T de paramètres au total | Agentique au long cours | ❌ Serveur seulement |
Le premier choix sur un mini-PC, c’est qwen3.8:27b, dès qu’il rentre. Si la vitesse compte plus que les derniers points de qualité, gemma4:26b répond bien plus vite grâce à ses 4B actifs. Et sur une machine de 128 Go qui fait tourner des agents, gpt-oss:120b mérite l’essai. Le classement bouge chaque semaine : classement des modèles locaux, tous les modèles ouverts (y compris ceux qui ne tiennent pas chez vous), et Comparer pour mettre deux modèles face à face.
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 30 % 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.
0 étape sur 2 faite Vos cases cochées restent dans ce navigateur.
-
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.8:27b # Ou le quant explicite, si vous voulez être sûr ollama pull qwen3.8:27b-q4_K_M # Plus fidèle, si vous avez la mémoire (64 Go et plus) ollama pull qwen3.8:27b-q8_0 -
Calez le contexte sur le besoin réel
Le contexte coûte de la RAM (le fameux KV cache). Le défaut d’
OLLAMA_CONTEXT_LENGTHdépend de la mémoire graphique : 4 000 jetons sous 24 Gio, 32 000 de 24 à 48 Gio, 256 000 au-delà. Trop bas pour un agent sur une petite carte, très haut sur un Ryzen AI Max ou un gros Mac, où le cache gonfle en silence (dans la mémoire GTT, sur Strix Halo). Trop de contexte peut aussi vous pousser dans le swap : c’est la cause n°1 du « Ollama est lent ». RéglezOLLAMA_CONTEXT_LENGTHounum_ctxsur ce dont la tâche a vraiment besoin : 64 000 pour un agent de code d’après la doc d’Ollama, beaucoup moins pour un script.
Honnêtement : local ou Claude ?
On ne va pas vous vendre du rêve. Voici où en est le local à l’édition du 28 septembre 2026 de Quelle IA, 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-5.3 et DeepSeek V4 se rapprochent des meilleurs, Kimi K3 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 reste Claude. Au classement code de Quelle IA, Claude Opus 5.5 (99,9) et Claude Fable 5.1 (98,6) mènent. Le meilleur modèle qui tient sur un mini-PC de 128 Go, Qwen 3.8 27B, y obtient 81,1 (score encore provisoire).
- Les meilleurs modèles ouverts ne tournent pas sur un mini-PC. Kimi K3 (2,8 T de paramètres), GLM-5.3 (744B), DeepSeek V4 Pro (1,6 T), c’est de l’API ou du serveur. Même GLM-5.3-Flash, le meilleur local en code (88,9), demande deux DGX Spark. Ce qui rentre (Qwen 3.8 27B, Gemma 4 26B A4B, gpt-oss-120b) est d’un cran en dessous sur la fiabilité agentique au long cours et l’usage d’outils.
Toutes les commandes de cette fiche
Questions fréquentes
Qu'est-ce qu'un modèle MoE et combien de mémoire lui faut-il ?
Un modèle MoE (Mixture of Experts) compte beaucoup de paramètres au total, mais n'en active qu'une petite partie à chaque jeton. Vous dimensionnez la mémoire sur le total, puisque tout doit être chargé, alors que la vitesse dépend des paramètres actifs. Gemma 4 26B A4B, par exemple, occupe 16 à 19 Go mais n'active qu'environ 4 milliards de paramètres par jeton, ce qui le rend bien plus rapide qu'un modèle dense de sa taille.
Quelle quantization choisir pour un modèle local ?
Q4_K_M est le standard de fait : il pèse environ 30 % du modèle d'origine en FP16 pour seulement 2 à 3 % de perte, et tient très bien la route en code. Montez à Q5 ou Q6 seulement pour du raisonnement critique, si vous avez la marge mémoire. Ne descendez sous Q4 que contraint, car le code et le raisonnement trinquent les premiers.
Pourquoi Ollama est-il lent sur ma machine ?
La cause n°1 est un contexte trop grand qui fait déborder le système sur le disque, dans le swap. Le contexte coûte de la mémoire, et la valeur par défaut d'Ollama monte à 256 000 jetons sur les machines qui ont plus de 48 Gio de mémoire graphique. Réglez OLLAMA_CONTEXT_LENGTH ou num_ctx sur le besoin réel : 64 000 pour un agent de code d'après la doc d'Ollama, beaucoup moins pour un script.
Comment savoir quels modèles tournent sur mon PC sans tout calculer ?
L'outil open source llmfit scanne votre machine (RAM, cœurs CPU, VRAM) et les runtimes installés comme Ollama ou LM Studio, puis classe ce qui rentre, ce qui tournera vite et le quant à viser. Il sait aussi simuler une configuration que vous n'avez pas encore, pratique avant un achat. Sans rien installer, le site CanIRun.ai donne une estimation directement dans le navigateur.
Pourquoi la commande free ne montre-t-elle pas la mémoire prise par mes modèles ?
Sur un APU à mémoire partagée comme AMD Strix Halo, les poids des modèles prennent la RAM du système sous forme de mémoire GTT, invisible dans free comme dans la limite mémoire d'un conteneur Docker. La machine peut ainsi se remplir sans que rien ne l'annonce. Avant de garder plusieurs modèles chargés, regardez ce que le GPU intégré a réellement pris, et réservez de la RAM au reste de la machine avec OLLAMA_GPU_OVERHEAD.
Les termes de cette fiche : Modèle open-weight (poids ouverts)ParamètresQuantisationOllamaGPU (carte graphique)Open source (vs open-weight)VRAMDockerOpenCodeAPI
Une erreur ?
Une commande ne marche plus, un prix a changé ?
Les outils bougent tous les mois. Dites-moi ce qui cloche dans cette fiche, je corrige et je redate.
