LLM auto hébergées · 10 October 2026Le grand écart des petits modèles : ce que les LLM open-weights sous 7B font vraiment tourner chez vous en 2026
Pendant que Kimi K3 et DeepSeek V4 Pro s’affrontent à coups de centaines de milliards de paramètres, une contre-révolution silencieuse s’installe sur les bureaux et dans les salons. Les modèles sous 7B ne sont plus des jouets : ils sont devenus le vrai terrain de jeu du hardware grand public. Panorama d’une catégorie qui mérite enfin qu’on la prenne au sérieux.
Le paradoxe de 2026 : la course aux 100B+ cache la vraie révolution, celle des moins de 7B
Ouvrez n’importe quel fil d’actualité IA en octobre 2026 : on vous parle de Kimi K3 contre DeepSeek V4 Pro, de modèles à 100 milliards de paramètres et plus, de data centers qui consomment l’équivalent d’une petite ville. C’est spectaculaire, c’est vendeur, et c’est presque entièrement hors de portée de quiconque n’a pas un budget matériel à cinq chiffres. Pendant ce temps, une autre histoire se joue, plus discrète mais peut-être plus importante pour l’immense majorité des utilisateurs : celle des modèles sous 7B paramètres, qui ont silencieusement atteint une maturité que personne n’aurait prédite il y a deux ans.
Pourquoi cette catégorie mérite un panorama à part entière ? Parce que la question n’est plus « peut-on faire tourner un LLM chez soi ? » — la réponse est oui depuis longtemps — mais « lequel, pour quoi, sur quelle machine ? ». Et cette question est devenue suffisamment riche, nuancée et piégeuse pour qu’un simple « installe Ollama et prends Mistral 7B » ne suffise plus. Les familles se sont multipliées, les architectures ont muté, les paliers de quantification se sont complexifiés, et surtout, les attentes des utilisateurs ont changé : on ne veut plus seulement discuter avec un chatbot local, on veut du RAG, des agents légers, de l’extraction structurée, du code.
Ce panorama se propose de cartographier cette catégorie en profondeur. Nous allons radiographier les familles réellement maintenues, décortiquer la mécanique cachée qui rend un 3B utile (distillation, MoE compactes, quantization native), croiser les benchmarks avec ce qu’ils ne disent pas, dresser la carte modèle × tâche × palier VRAM, démontrer pourquoi un 3B bien servi peut écraser un 70B mal configuré, puis descendre sur le terrain avec trois profils matériels concrets. Enfin, nous serons honnêtes sur les pièges — parce qu’un bon panorama n’est pas un catalogue publicitaire.
Un avertissement méthodologique s’impose d’emblée : la documentation disponible sur cette catégorie reste inégale. Beaucoup de sources tierces, peu de papiers techniques primaires, et quelques incohérences temporelles notables — certains blogs citent encore Phi-3 et LLaMA 3.2 comme références 2026, tandis que le blog Hugging Face de référence pointe vers Phi-4-mini et Llama 4 Scout. Nous signalerons ces zones grises au fil du texte plutôt que de les masquer.
Qwen, Gemma, Llama, Phi, Mistral, SmolLM, Granite : radiographie des familles sous 7B encore maintenues en octobre 2026
Commençons par le constat le plus solide : la famille Qwen domine aujourd’hui le paysage des petits modèles. Le blog Hugging Face la présente comme « le meilleur modèle local global en 2026 » pour le raisonnement, le code et le multilingue, sous licence Apache 2.0 — un choix de licence permissif qui explique en grande partie son adoption massive. Les variantes sous 7B de la lignée Qwen 3.x constituent le socle sur lequel se construisent la plupart des configurations locales sérieuses aujourd’hui. C’est la famille à laquelle on se réfère spontanément quand on parle de « petit modèle qui tient la route ».

Face à elle, Gemma 3 joue une carte différente. Les variantes 12B et 27B sont mises en avant pour leur multimodalité et leur contexte natif de 128K, avec un positionnement « bon compromis sur GPU unique ». Attention toutefois : ces tailles dépassent le seuil des 7B qui nous intéresse ici. Les déclinaisons réellement sous 7B de la famille Gemma 3 existent, mais la documentation disponible reste moins précise sur leurs caractéristiques exactes — tailles, licences, contextes — que pour les grosses variantes. C’est un point à vérifier directement sur les model cards officielles avant de s’engager.
Du côté de Microsoft, Phi-4-mini occupe une place à part. Avec ses 3,8B paramètres, sa licence MIT et son contexte de 128K, il coche toutes les cases du « petit modèle sérieux » : tourne sur machines modestes, licence ultra-permissive, contexte généreux. C’est l’un des rares modèles de cette catégorie dont les spécifications sont chiffrées et cohérentes dans les sources disponibles. Phi-3, encore cité par certains blogs tiers comme référence 2026, appartient en revanche à une génération antérieure (2024) dont la pertinence en octobre 2026 est douteuse — une incohérence temporelle qu’il faut signaler.
La situation de Llama est plus confuse. Llama 4 Scout est crédité d’un contexte de 10 millions de tokens, mais nécessite « du matériel sérieux » — autrement dit, il sort largement de notre périmètre. Les variantes réellement sous 7B de la famille Llama 4 restent mal documentées dans les sources disponibles. Quant à LLaMA 3.2, encore mentionné par des blogs tiers comme référence, il s’agit d’une génération antérieure dont la pertinence actuelle est discutable.
Mistral occupe une position singulière : Mistral 7B, modèle de 2023, est encore cité par des sources tierces comme pertinent en 2026, installable via Ollama sur un MacBook Pro M3 ou un PC avec RTX 3080. C’est un signe de longévité remarquable, mais aussi le symptôme d’un certain retard documentaire : s’appuyer sur un modèle de 2023 en octobre 2026 pour des tâches exigeantes relève plus de la nostalgie que de la stratégie. Devstral, en revanche, positionné comme agent de code local sous licence Apache 2.0, représente la branche moderne de l’écosystème Mistral.
Enfin, deux familles complètent le tableau : SmolLM (Hugging Face) et Granite (IBM), toutes deux présentes dans le paysage mais dont les caractéristiques précises sous 7B ne sont pas détaillées dans les sources disponibles. Signalons aussi l’existence de gpt-oss-20b et gpt-oss-120b, modèles open-weight orientés raisonnement sous licence Apache 2.0 — mais leurs tailles les placent hors de notre périmètre.
Ce qui est vérifié vs ce qui reste à confirmer. Vérifié (source tierce unique, Hugging Face blog) : Qwen 3.x comme référence, Phi-4-mini à 3,8B/MIT/128K, Gemma 3 12B-27B multimodal 128K, Devstral Apache 2.0, Llama 4 Scout 10M de contexte. À confirmer faute de sources primaires : les tailles exactes des variantes sous 7B de Qwen, Gemma, Llama 4 ; les licences précises par variante ; les contextes natifs systématiques ; l’existence et l’identité des « nouveaux entrants chinois et européens » évoqués dans le cadrage mais absents des extraits disponibles.
Distillation, MoE compactes, GQA, quantization native : la mécanique cachée qui rend un 3B utile en 2026
Ici, il faut être franc : la documentation technique primaire sur les architectures des modèles sous 7B est quasi absente des sources disponibles. Pas de papiers de recherche, pas de blogs de laboratoires détaillant les choix architecturaux, pas de benchmarks contrôlés. Ce qui suit relève donc de la synthèse prudente, pas de la démonstration chiffrée — et c’est en soi une information importante sur l’état de la documentation dans cette catégorie.
Cela posé, la mécanique générale est bien connue. La distillation depuis des modèles 70B+ a été le levier principal : on entraîne un petit modèle à imiter les sorties d’un grand, en espérant capturer une partie de ses capacités de raisonnement dans des poids minuscules. C’est ce qui explique qu’un 3B de 2026 puisse tenir des conversations structurées qu’un 3B de 2022 aurait été incapable d’approcher. Le coût : une dépendance au modèle enseignant, et une difficulté à généraliser hors des distributions vues à l’entraînement.
Les MoE compactes (Mixture of Experts) changent une autre donne. Le principe : au lieu d’activer tous les paramètres à chaque token, on n’en active qu’une fraction — les « experts actifs ». Un modèle peut afficher un nombre total de paramètres élevé tout en n’en activant qu’une petite partie à l’inférence, ce qui réduit drastiquement le coût réel. Le revers de la médaille est un piège classique : les paramètres totaux affichés ne reflètent pas le coût d’inférence. Un modèle « 8x7B » n’est pas un modèle de 56B en termes de calcul par token. Les sources disponibles ne fournissent pas de chiffres précis sur le nombre d’experts et d’experts actifs des modèles sous 7B actuels — prudence donc sur les affirmations marketing.
Le GQA (Grouped Query Attention) joue un rôle plus discret mais crucial : il permet de tenir un contexte long sur une VRAM modeste en réduisant la taille du cache KV. C’est ce qui rend possible l’affichage de contextes 128K sur des machines qui, autrement, s’effondreraient. Mais attention : contexte natif affiché et contexte réellement tenable sont deux choses différentes (nous y reviendrons).
Reste la quantization native, le sujet le plus concret pour l’utilisateur. Les formats disponibles — Q4_K_M, AWQ, GPTQ, MLX 4-bit — offrent des compromis différents entre VRAM économisée et qualité préservée. Le format GGUF, bien documenté dans les sources du magazine, précise les tailles de fichiers et les choix de quantification selon les plateformes (Windows, macOS, Linux). La règle empirique, largement admise mais rarement chiffrée dans nos sources : la dégradation n’est pas uniforme. Un modèle quantizé en Q4 peut perdre peu en génération libre de texte tout en se dégradant nettement sur le raisonnement multi-étapes. C’est un point essentiel pour choisir sa quantization selon sa tâche, pas selon un score global.
MMLU-Pro, GPQA, SWE-bench, IFEval : ce que disent (vraiment) les benchmarks de 2026 sur les moins de 7B
Nouvelle zone grise : les sources disponibles ne contiennent aucun chiffre exploitable de benchmarks pour les modèles sous 7B en 2026. Ni MMLU-Pro, ni GPQA, ni HumanEval/SWE-bench, ni IFEval, ni MT-Bench, ni LiveBench, ni Aider polyglot. Les sources citées dans le cadrage (benchlm.ai, mljourney, spheron VRAM tier guide, Hugging Face Open LLM Leaderboard) ne sont pas présentes dans les extraits fournis. Impossible donc de dresser un tableau chiffré fiable — et quiconque prétendrait le contraire inventerait.

Ce que l’on peut dire avec prudence, en revanche, c’est la mise en perspective qualitative. Les modèles sous 7B de 2026 se situent, selon toute vraisemblance, dans une zone de performance qui chevauche les 70B de 2024 sur certaines tâches — notamment la génération de texte, le résumé et l’extraction structurée simple. Sur le raisonnement complexe et le code agentique, l’écart reste significatif. Face aux 100B+ actuels, le fossé est structurel : on ne compense pas 20 à 30 fois plus de paramètres avec de la distillation seule.
Le fameux « écart de 4,4 mois » entre open source et propriétaires, relayé par MSN, mérite d’être remis dans son contexte. Il s’agit d’un chiffre unique, non recoupé par une source indépendante dans les extraits disponibles, sans méthodologie visible ni définition opérationnelle du « retard ». Est-ce un retard sur les benchmarks ? Sur les capacités perçues ? Sur les dates de sortie ? L’article ne le précise pas. À prendre comme un ordre de grandeur évocateur, pas comme une mesure.
Avertissement méthodologique. Trois pièges classiques guettent toute lecture de benchmarks : (1) la contamination des jeux de test — des modèles peuvent avoir vu les questions lors de l’entraînement ; (2) les écarts entre leaderboards — un même modèle peut afficher des scores très différents selon la méthodologie d’évaluation ; (3) la non-transférabilité — un score MMLU-Pro élevé ne prédit pas la performance en RAG ou en function calling. C’est peut-être l’enseignement le plus important de cette section : les benchmarks sont un filtre grossier, pas un guide d’achat.
4, 6, 8, 12 Go de VRAM : la carte modèle × tâche × palier qui dit vraiment ce qui tourne
Faute de chiffres précis sur les modèles sous 7B eux-mêmes, nous pouvons nous appuyer sur les données matérielles documentées par le magazine pour cartographier les paliers. Le tableau suivant synthétise ce qui est raisonnablement tenable à chaque niveau de VRAM, en croisant les débits observés sur différents matériels et les contraintes de quantification.
| Palier VRAM | Modèles sous 7B tenables | Quantization typique | Contexte réellement tenable | Débit observé (référence matérielle) |
|---|---|---|---|---|
| 4 Go | 3B en Q4 | Q4_K_M | Court (quelques milliers de tokens) | Faible, dépend du CPU/offload |
| 6 Go | 3B en Q5/Q6, 7B en Q3 | Q3-Q6 | Court à moyen | Faible à modéré |
| 8 Go | 7B en Q4_K_M, 3B en Q8 | Q4_K_M à Q8 | Moyen | ~8-12 tok/s (iGPU Radeon 780M, Vulkan) |
| 12 Go | 7B en Q5/Q6, 3B en FP16 | Q5-Q6 | Moyen à long | Variable selon GPU |
Pour donner des repères concrets : sur un iGPU AMD Radeon 780M en Vulkan, on observe environ 10-12 tok/s sur Llama 3 8B Q4, 8-11 tok/s sur Mistral 7B Q4_K_M, et 10-12 tok/s sur Qwen 2.5 7B — avec un gain de +50 % apporté par les optimisations Vulkan de llama.cpp et un réglage MMVQ qui ajoute +12,9 %. Sur un Strix Halo, on grimpe à ~40-60 tok/s sur Llama 3 8B Q4, mais on retombe à ~5-10 tok/s sur Mixtral 8x7B Q4_K_M — illustration parfaite du piège des paramètres totaux.
Par tâche, la déclinaison est plus nuancée. Le RAG léger (quelques documents, retrieval simple) est accessible dès 8 Go avec un 7B en Q4_K_M. L’extraction structurée JSON fonctionne bien sur des schémas simples, mais devient instable quand le schéma se complexifie — c’est un point de rupture documenté. Le résumé long bénéficie du contexte étendu mais se heurte à la dégradation au-delà de quelques milliers de tokens réellement traités. Les agents légers avec function calling cassent typiquement au-delà de 2-3 outils. Le code reste le parent pauvre : utilisable pour des complétions simples, pas pour de l’agentique sérieuse.
Le piège du benchmark marketing. Un modèle qui brille sur MMLU-Pro peut être inutilisable en production sur une tâche précise. La raison : les benchmarks mesurent des capacités isolées dans des conditions contrôlées, pas la robustesse en conditions réelles avec des prompts mal formés, des contextes bruités et des schémas de sortie stricts.
Quand un 3B bien choisi écrase un 70B mal servi : anatomie du grand écart
Voici le cœur argumentatif de ce panorama, et le scénario le plus contre-intuitif de la catégorie. Un 70B forcé en quantization agressive, avec offload CPU massif et contexte tronqué, peut être battu — sur des tâches précises — par un 3B bien sélectionné, bien quantizé et bien servi. Démonstration en trois facteurs.

Facteur 1 : la quantization. Un 70B qui ne tient pas en VRAM doit être quantizé agressivement, souvent en Q3 ou en dessous. Or la dégradation n’est pas linéaire ni uniforme : elle frappe d’abord le raisonnement multi-étapes et la cohérence longue, précisément là où un gros modèle est censé exceller. Un 3B en Q4_K_M, lui, conserve l’essentiel de ses capacités natives parce qu’il a été conçu pour tourner dans ces conditions. Le petit modèle perd peu parce qu’il part de moins haut ; le gros perd beaucoup parce qu’on le mutile.
Facteur 2 : le contexte. Tronquer à 4K pour tenir en VRAM revient à priver un 70B de sa principale force. Un modèle à contexte étendu forcé de travailler sur un contexte court devient un modèle moyen — parfois moins bon qu’un 3B dont le contexte natif correspond à l’usage. La leçon : le contexte utile réel compte plus que le contexte maximal affiché.
Facteur 3 : l’offload CPU. Le coût réel en tok/s et en latence perçue est brutal. Un 70B avec offload massif peut tomber à quelques tokens par seconde, avec des temps de première token qui rendent l’interaction pénible. Un 3B bien servi répond instantanément. Pour un usage interactif ou un agent qui enchaîne les appels, la latence perçue pèse plus lourd que la qualité marginale.
Règles empiriques. En dessous de 8 Go de VRAM, un 3B bien choisi bat presque toujours un 70B mal servi. Entre 8 et 12 Go, la balance dépend de la tâche : le petit modèle garde l’avantage sur l’interactif et l’extraction, le gros reprend la main sur le raisonnement si le contexte reste court. Au-delà de 12 Go, un 70B correctement servi redevient supérieur — mais à ce stade, on n’est plus dans la catégorie « sans se ruiner ».
Laptop iGPU, mini-PC Strix Halo, vieille RTX 3060 : trois profils, trois réalités terrain
Profil 1 — laptop iGPU (Apple M-series, Ryzen AI, Lunar Lake). C’est le profil le plus répandu et le plus contraint. Sur un iGPU Radeon 780M, les débits observés (10-12 tok/s sur un 7B Q4) rendent l’usage conversationnel confortable mais limitent les agents. L’avantage : consommation faible, silence total, autonomie préservée. Le coût : contexte réellement tenable modeste, et pas de marge pour monter en taille de modèle. Recommandation : un 3B ou un 7B en Q4_K_M, pour du chat, du résumé et de l’extraction simple.
Profil 2 — mini-PC (Strix Halo, Mac mini M4). C’est le sweet spot 2026 pour l’IA locale silencieuse et économe. Le Strix Halo offre 64 à 128 Go de mémoire unifiée selon configurations, une bande passante de 256 Go/s et un bus mémoire de 256 bits — ce qui permet de faire tourner des modèles bien plus gros que les 7B qui nous intéressent, avec une marge confortable. Sur Llama 3 8B Q4, on observe ~40-60 tok/s : c’est le niveau où l’IA locale devient vraiment fluide. Le Mac mini M6 et ses 32 Go de mémoire, documenté par ailleurs, accélère OpenClaw et l’IA locale sans égaler le cloud. Recommandation : 7B en Q5/Q6, voire des MoE compactes, pour du RAG, des agents légers et du code simple.
Profil 3 — vieux GPU 8 Go (RTX 3060/4060). Le profil le plus frustrant, mais pas désespéré. Avec 8 Go, on tient un 7B en Q4_K_M ou un 3B en Q8. Les débits sont corrects, mais la VRAM est le facteur limitant absolu : impossible de monter en contexte sans exploser. Recommandation : accepter la contrainte, choisir un 7B Q4_K_M optimisé, et réserver les tâches lourdes au cloud.
Niveau de confiance. Ces retours proviennent largement de témoignages Reddit r/LocalLLaMA, de blogs et de GitHub issues — beaucoup de retours non vérifiés, peu de benchmarks contrôlés. Les chiffres matériels (Strix Halo, Radeon 780M) sont les plus solides ; les recommandations par tâche relèvent de l’expérience agrégée, pas de la mesure rigoureuse.
Là où ça casse encore : les cinq pièges qui transforment un bon petit modèle en frustration
Piège 1 — le contexte long qui n’en a que le nom. 128K annoncés, 8K réellement utilisables. Le cache KV explose, la qualité se dégrade, et le modèle perd le fil. Symptôme : réponses qui ignorent le début du document. Contournement : découper, résumer par morceaux, ne jamais faire confiance au contexte maximal affiché.
Piège 2 — le function calling instable au-delà de 2-3 outils. Les petits modèles gèrent bien un ou deux outils, puis confondent les schémas, oublient des paramètres, inventent des fonctions. Symptôme : appels malformés, boucles. Contournement : limiter le nombre d’outils exposés simultanément, valider strictement les sorties.
Piège 3 — la dérive multilingue sur les langues peu représentées. Un modèle excellent en anglais peut se dégrader nettement sur des langues moins dotées. Symptôme : mélange de langues, grammaire approximative. Contournement : tester systématiquement dans sa langue cible avant de s’engager.
Piège 4 — l’hallucination en extraction structurée quand le schéma JSON se complexifie. Plus le schéma a de champs et de contraintes, plus le modèle invente des valeurs plausibles. Symptôme : champs remplis avec des données inexistantes. Contournement : schémas plats, validation post-traitement, jamais de confiance aveugle.
Piège 5 — la dégradation silencieuse après quantization Q3 ou inférieure. On gagne de la VRAM, on perd de la cohérence sans s’en rendre compte immédiatement. Symptôme : réponses qui semblent correctes mais échouent sur les cas limites. Contournement : rester en Q4_K_M minimum, tester sur des cas difficiles.
Encadré — pourquoi les model cards n’en parlent pas. Les model cards et benchmarks officiels mentionnent rarement ces points de rupture parce qu’ils mesurent des capacités dans des conditions favorables. Le function calling instable, la dérive multilingue, l’hallucination structurée : autant de faiblesses qui n’apparaissent pas dans un score MMLU-Pro, mais qui décident de l’utilisabilité réelle.
Ce que ça change : vers une IA locale vraiment personnelle, et ce qu’il faut surveiller en 2027
La maturité des modèles sous 7B change concrètement quelque chose de profond : elle rend possible une IA locale réellement personnelle. Souveraineté des données, coût marginal proche de zéro, agents embarqués sur matériel modeste — ce ne sont plus des slogans mais des réalités accessibles. Un mini-PC à quelques centaines d’euros fait aujourd’hui ce qu’un serveur coûtait il y a deux ans.
Les tendances à surveiller pour 2027 sont claires. D’abord, la consolidation des familles : toutes ne survivront pas, et le paysage sous 7B devrait se resserrer autour de quelques acteurs dominants (Qwen en tête). Ensuite, la progression des MoE compactes, qui pourraient redéfinir ce qu’on attend d’un « petit » modèle en termes de rapport capacité/coût. Puis la quantification native de plus en plus agressive sans perte perceptible, qui repousse les limites du matériel modeste. Enfin, l’arrivée annoncée de nouveaux entrants européens — annoncée mais non documentée dans nos sources, donc à surveiller avec prudence.
Question ouverte. À quel moment un 3B de 2027 vaudra-t-il un 70B de 2024 ? La trajectoire suggère que ce seuil est proche, peut-être déjà franchi sur certaines tâches. Mais la réponse dépendra moins des paramètres que de l’écosystème : qualité des données d’entraînement, robustesse des harnais, maturité des outils d’orchestration.
Trois recommandations pour se lancer demain matin. Pour un laptop iGPU : commencez par un 3B en Q4_K_M, testez sur vos tâches réelles avant de monter en taille. Pour un mini-PC : visez un 7B en Q5/Q6, c’est le meilleur rapport qualité/fluidité en 2026. Pour un vieux GPU 8 Go : acceptez la contrainte, choisissez un 7B Q4_K_M bien optimisé, et hybridez avec le cloud pour les tâches lourdes. Dans tous les cas, testez avant de croire les benchmarks — c’est le seul conseil qui ne se démode jamais.
Sources
- The Best Open Source and Open-Weight LLM Models to Run Locally in 2026 — Hugging Face blog
- Best Open-Source LLMs Under 7B Parameters (Run Locally in 2026) — ML Journey
- Best Open-Source LLMs to Self-Host in 2026: VRAM Tier Guide — Spheron
- Best Local LLMs (October 2026): Benchmarks, Memory & Workload — BenchLM
- Best Local LLM Models 2026: Benchmarks & Use Cases — AI Tool Discovery
- Local LLM 2026: Every Major Model Release + Ollama Status — PromptQuorum
- Best Open Source LLM (2026): Ranked by Use Case — Layer3Labs
- Best Hardware for Running Open-Source AI Models Locally in 2026 — Memeburn
- Kimi K3 vs DeepSeek V4 Pro: Best Open Source LLM in 2026? — Memeburn
- Best Open-Source Agent Harnesses for Local LLMs in 2026 — MarkTechPost
- Modèles GGUF : types de quantification et exécution — Convly
- LLM sur Raspberry Pi 5 : IA locale embarquée — QuelLLM.fr
- Modèles d’IA chinois en 2026 : DeepSeek, Qwen, Kimi, GLM… lequel pour quoi ? — Iatrust
- Open-weights ou open-source ? La différence qui compte — QuelLLM.fr
- Mac mini M6 et OpenClaw : le vrai gain en IA locale — Lokan.fr
- FreeToken : Exécutez d’énormes modèles d’IA MoE 3x plus vite qu’avec Ollama — Stork.ai
Article recherché et rédigé automatiquement · Magazine Electrosens