Les meilleurs LLM locaux en 2026 : lesquels utiliser et sur quel matériel ?

Contrairement à l’habitude sur ce blog, nous n’avons pratiquement rien à vous vendre ici. Nous sommes Geonode, nous vendons des proxys, et l’exécution d’un modèle linguistique sur votre propre machine ne nécessite absolument rien de tout cela. Pas de proxys, pas de bande passante, pas de compte. Le lien est indirect : les modèles locaux sont souvent déployés pour extraire des informations à partir de vos propres données, et si ces données proviennent du Web public, quelqu’un doit les collecter. C’est notre rôle dans le processus, et il est véritablement distinct du modèle. Considérez donc ce guide comme rédigé par des personnes qui n’ont aucun intérêt particulier à ce que vous choisissiez tel ou tel modèle, ce qui est une position plus rare qu’elle ne devrait l’être dans ce domaine.

Ce que vous apporte le « local » et ce que cela coûte

Il convient d’être précis, car ces deux aspects sont régulièrement exagérés.

Ce que vous y gagnez. Les données ne quittent jamais votre machine, ce qui, pour les activités soumises à une réglementation, n’est pas une préférence mais une exigence. Pas de coût par jeton : une utilisation intensive ou expérimentale est donc gratuite une fois le matériel acquis. Pas de limites de débit et aucune dépendance vis-à-vis de la disponibilité d’un tiers. Une stabilité totale de la version : le modèle ne change pas sans que vous en ayez connaissance, ce qui est extrêmement important si vous avez adapté vos invites en fonction de son comportement. Et la possibilité d’effectuer un réglage fin sur vos propres données sans avoir à les envoyer nulle part.

Ce que vous payez. Principalement, les capacités. Les meilleurs modèles locaux de 2026 sont véritablement performants, mais restent en deçà des modèles hébergés de pointe en matière de raisonnement complexe. Le matériel, qui représente un réel coût d’investissement. La vitesse, à moins que vous n’ayez acheté du matériel haut de gamme. Votre temps consacré à la configuration, aux choix de quantification et à l’intégration. Et l’électricité, ce qui n’est pas négligeable pour une machine soumise à une charge soutenue.

Ce qui induit les gens en erreur, c’est de considérer cela comme une comparaison de coûts. Si vous envoyez quelques centaines de milliers de tokens par mois à une API hébergée, les modèles locaux ne vous feront pas économiser d’argent : le matériel coûte plus cher que plusieurs années d’une telle utilisation. Les modèles locaux l’emportent en matière de confidentialité, de contrôle et de stabilité, ou en cas de volumes très élevés. Si aucun de ces cas ne s’applique à vous, l’aspect économique ne s’applique pas non plus.

La question du matériel détermine tout le reste

Avant d’examiner un modèle quelconque, déterminez votre mémoire vidéo (VRAM). Tout le reste en découle.

Deux éléments font pencher la balance en votre faveur.

Les architectures de type « mixture-of-experts » (MoE). Celles-ci possèdent un nombre total de paramètres élevé, mais n’en activent qu’une fraction par token. Le modèle « gpt-oss-120b » compte 117 milliards de paramètres au total et 5,1 milliards de paramètres actifs ; La fiche technique du modèle d’OpenAI indique qu’il tient « dans un seul GPU de 80 Go (comme le NVIDIA H100 ou l’AMD MI300X) » grâce à la quantification MXFP4 des poids des experts. gpt-oss-20b compte 21 milliards de paramètres au total, dont 3,6 milliards actifs, et fonctionne « avec 16 Go de mémoire ». Vous bénéficiez des avantages d’un modèle plus volumineux en termes de qualité, tout en ne payant qu’en mémoire et en vitesse ce qu’un modèle beaucoup plus petit coûterait.

Mémoire unifiée Apple Silicon. Sur un Mac, la mémoire système est la mémoire du GPU. Une machine dotée de 64 Go de mémoire unifiée exécute des modèles qui nécessiteraient une carte dont la plupart des gens ne disposent pas. Le débit est inférieur à celui d’un GPU discret de capacité équivalente, mais le plafond de capacité est bien plus élevé pour le même prix.

Il faut également tenir compte du contexte dans votre budget. La taille des modèles ne fait pas tout : le cache KV augmente avec la longueur du contexte et peut consommer plusieurs gigaoctets sur des entrées longues. Un modèle qui tient dans un contexte de 4K ne tiendra peut-être pas dans un contexte de 128K.

Les modèles à privilégier en 2026

Qwen3 est la famille la plus utile pour un déploiement local, principalement parce qu’elle couvre toute la gamme de tailles avec un comportement cohérent. La collection Hugging Face répertorie des modèles denses de 0,6 milliard, 1,7 milliard, 4 milliards, 8 milliards, 14 milliards et 32 milliards de tokens, ainsi que les variantes « mixture-of-experts » 30B-A3B et 235B-A22B, avec des versions quantifiées aux formats FP8, GGUF, AWQ, GPTQ et MLX.

La fiche technique du modèle Qwen3-8B présente les caractéristiques essentielles : licence Apache 2.0, 32 768 tokens de contexte natif pouvant atteindre 131 072 grâce à la mise à l'échelle YaRN, et « prise en charge de plus de 100 langues et dialectes ». Sa particularité réside dans la possibilité de basculer, au sein d’un même modèle, entre un mode « réflexion » destiné aux tâches nécessitant un raisonnement approfondi et un mode « non-réflexion » destiné à un dialogue efficace.

Un détail pratique de cette fiche qui échappe souvent aux utilisateurs : les paramètres d’échantillonnage ont leur importance, et les valeurs recommandées varient selon le mode — température 0,6, top-p 0,95, top-k 20 en mode « réflexion » ; température 0,7, top-p 0,8, top-k 20 dans les autres cas. Le décodage « greedy » est explicitement déconseillé en mode « réflexion ». Si un modèle affiche des performances inférieures à vos attentes, vérifiez vos paramètres d’échantillonnage avant de blâmer le modèle.

Gemma 4 de Google est une version remarquable pour tous ceux qui étaient auparavant rebutés par la licence de Gemma, car elle est désormais sous licence Apache 2.0. La fiche du modèle répertorie cinq tailles — E2B, E4B, 12B, 26B, A4B et 31B — avec « une fenêtre de contexte de 128K, tandis que les modèles de taille moyenne prennent en charge 256K », une prise en charge multilingue dans « plus de 140 langues », ainsi que la saisie de texte et d’images avec prise en charge audio sur les modèles E2B, E4B et 12B. La saisie audio native dans un petit modèle open-weight est inhabituelle et mérite d’être soulignée si cela correspond à votre cas d’utilisation.

gpt-oss d’OpenAI couvre les deux extrêmes. Le modèle 20B tient sur une machine de 16 Go ; le 120B tient sur une seule carte de 80 Go. Tous deux sont sous licence Apache 2.0, décrite sur les fiches techniques des modèles comme une « licence Apache 2.0 permissive : compilez librement sans restrictions de copyleft ni risque lié aux brevets ». Le modèle 20B est destiné à « une latence réduite et à des cas d’utilisation locaux ou spécialisés », avec notamment parmi ses applications déclarées le travail agentique, l’appel de fonctions et l’exécution de code.

DeepSeek-R1 reste la référence en matière de modèles de raisonnement ouverts et est sous licence MIT, ce qui, comme le précise la fiche du modèle, « autorise l’utilisation commerciale, permet toute modification et toute œuvre dérivée ». Pour une utilisation locale, les versions distillées sont plus pertinentes que le modèle complet : les versions distillées basées sur Qwen à 1,5 milliard, 7 milliards, 14 milliards et 32 milliards, et celles basées sur Llama à 8 milliards et 70 milliards, toutes affinées sur « 800 000 échantillons sélectionnés avec DeepSeek-R1 ». Les versions distillées de 14 milliards et 32 milliards de paramètres constituent les choix les plus pratiques pour le matériel grand public.

Llama reste de loin la famille la plus téléchargée — la bibliothèque d’Ollama indique 119,1 millions de téléchargements pour llama3.1 et 82,1 millions pour llama3.2, devant deepseek-r1 (92,2 millions) et gemma3 (40 millions). La popularité est synonyme de meilleurs outils, d’un plus grand nombre d’ajustements effectués par la communauté et de ressources de dépannage plus abondantes, ce qui constitue un véritable avantage indépendant des capacités brutes.

Et ne négligez pas les modèles embarqués. « nomic-embed-text » occupe la troisième place dans la bibliothèque d’Ollama avec 84,2 millions de requêtes, ce qui montre à quel point l’utilisation locale des LLM consiste en réalité davantage en une recherche dans des documents privés qu’en une conversation.

Les licences comptent plus que les benchmarks

C’est cette section qui évite aux utilisateurs de commettre une erreur coûteuse, et elle est systématiquement omise dans les comparaisons de modèles.

Le terme « poids ouverts » ne désigne pas une seule et même chose. Les modèles ci-dessus se répartissent en trois groupes :

Apache 2.0 — Qwen3, Gemma 4, gpt-oss, les dérivés de DeepSeek basés sur Qwen. Licence permissive, utilisable à des fins commerciales, aucune restriction quant au domaine d’utilisation, octroi de brevet inclus. Si vous commercialisez un produit, c’est ce qu’il vous faut.

MIT — DeepSeek-R1 lui-même. Tout aussi permissif, il autorise explicitement l’utilisation commerciale, la modification et les œuvres dérivées.

Licences communautaires personnalisées — la famille Llama, et par extension les distillats DeepSeek basés sur Llama, qui sont respectivement soumis aux licences Llama 3.1 et Llama 3.3. Celles-ci autorisent beaucoup de choses mais ne sont ni Apache ni MIT : elles comportent des politiques d’utilisation acceptable, des exigences d’attribution et des conditions qui s’appliquent à partir d’un certain nombre d’utilisateurs. En général, cela ne pose pas de problème. Mais ce n’est pas systématiquement le cas, et il vaut mieux les lire avant de développer un produit sur cette base.

Le passage de Gemma 4 à la licence Apache 2.0 est significatif précisément parce que Gemma utilisait auparavant une licence personnalisée. Si vous aviez déjà évalué la famille et l’aviez écartée pour des raisons de licence, ce motif n’est plus valable.

Deux points pratiques. Premièrement, vérifiez la licence du modèle spécifique que vous téléchargez, et non celle de la famille de modèles — les distillats DeepSeek en sont l’exemple le plus clair : différents distillats d’une même version sont soumis à des licences différentes selon leur modèle de base. Deuxièmement, si vous procédez à un ajustement, lisez ce que la licence stipule concernant les œuvres dérivées et la dénomination, car certaines exigent que l’œuvre dérivée conserve le nom d’origine.

Les outils : Ollama, llama.cpp, LM Studio, vLLM

Ollama est le choix par défaut idéal pour la plupart des utilisateurs. Une seule commande pour récupérer un modèle, un point de terminaison HTTP compatible OpenAI, des paramètres de quantification par défaut judicieux. Son seul bémol est que si vous souhaitez ajuster précisément les paramètres d’inférence, vous finirez par le dépasser.

llama.cpp est le fondement d’Ollama, et son utilisation directe vous offre un contrôle total sur la quantification, la gestion du contexte, le déchargement des couches sur le GPU et le multithreading du CPU. C’est également la solution la mieux prise en charge pour les configurations matérielles atypiques : cartes anciennes, configuration CPU seul, Apple Silicon.

LM Studio est une application de bureau dotée d’une fonctionnalité de découverte de modèles et d’une interface de chat. Si l’utilisateur du modèle n’est pas un développeur, c’est la solution qu’il vous faut.

vLLM est un système de déploiement plutôt qu’un outil local, conçu pour le débit avec un traitement par lots en continu. Si vous exploitez un modèle pour une équipe plutôt que pour vous-même, c’est vers ce niveau que vous devez vous orienter, et il nécessite un véritable matériel GPU.

Une approche utile : développez votre application en utilisant le point de terminaison compatible OpenAI d’Ollama, puis, si vous avez besoin par la suite de déployer correctement le modèle, passez à vLLM via la même interface. Le code de votre application reste inchangé.

La quantification sans approximations

La quantification réduit la précision numérique des poids, ce qui permet au modèle de nécessiter moins de mémoire. C'est ainsi qu'un modèle qui nécessite normalement 60 Go peut fonctionner sur une carte de 24 Go.

La règle qui se vérifie dans la pratique : un modèle plus grand avec une quantification plus forte est généralement plus performant qu’un modèle plus petit avec une quantification plus faible. Un modèle de 32 milliards de paramètres à Q4 sera généralement plus performant qu’un modèle de 14 milliards à Q8, à mémoire égale. L’exception se situe à l’extrême : en dessous de Q3, la dégradation devient suffisamment importante pour que la tendance s’inverse.

Notez également que MXFP4, utilisé pour les poids experts de gpt-oss, est un cas où la quantification fait partie intégrante de la conception du modèle plutôt que d’être appliquée a posteriori. C’est pourquoi les chiffres relatifs à la mémoire sur ces fiches de modèles sont aussi bas.

Testez votre propre charge de travail plutôt que de vous fier à un tableau, y compris celui-ci. La quantification dégrade les différentes capacités de manière inégale, et un niveau inaperçu pour la synthèse peut s’avérer évident pour la génération de code.

Attentes réalistes face à la « frontière »

En définissant correctement ces attentes, on évite la plupart des déceptions.

Domaines dans lesquels les modèles locaux sont véritablement compétitifs : synthèse, extraction, classification, traduction, complétion de code simple, rédaction, réponse à des questions enrichie par la recherche dans vos propres documents. Pour toutes ces tâches, un modèle de 14 à 32 milliards de paramètres bien choisi suffit, et la différence par rapport à un modèle de pointe hébergé est si minime que vous auriez du mal à la remarquer.

Dans quels domaines l’écart reste-t-il réel ? : raisonnement long en plusieurs étapes, tâches complexes impliquant une action active, bases de code volumineuses nécessitant une véritable compréhension, tâches exigeant des connaissances générales et actualisées sur le monde. L’écart s’est considérablement réduit, mais il n’a pas disparu.

Les domaines où les modèles locaux l’emportent haut la main : tout ce qui concerne les données ne pouvant pas quitter votre infrastructure, et tout ce qui présente un volume suffisamment important pour que la tarification au token devienne prépondérante. Il ne s’agit pas là d’arguments liés aux capacités, mais ce sont souvent ceux qui sont décisifs.

Une autre attente à prendre en compte : la vitesse. Sur du matériel grand public, un modèle de 32 milliards de paramètres produit des tokens à un rythme qui convient pour une interface de chat, mais qui est trop lent pour tout traitement par lots. Si vous traitez dix mille documents, mesurez le débit avant de vous engager sur une architecture.

Quand il vaut mieux se contenter d’une API

La section qui remet en cause cette hypothèse.

Lorsque votre volume est faible. Quelques centaines de milliers de tokens par mois ne coûtent presque rien sur une API hébergée et ne justifieront jamais l’achat d’un GPU. Acheter du matériel pour éviter une petite facture n’est pas un bon choix, à moins que ce matériel n’ait d’autres utilisations.

Lorsque vous avez besoin de capacités de pointe. Si la tâche nécessite véritablement les capacités de raisonnement les plus puissantes disponibles, les modèles locaux n’en sont pas encore là et prétendre le contraire vous fera perdre des semaines.

Lorsque vous ne disposez pas du matériel nécessaire. Exécuter un modèle de 7 milliards de paramètres sur une carte de 8 Go simplement parce que c’est tout ce dont vous disposez, puis en conclure que les modèles locaux ne sont pas performants, est une déception courante et évitable. Le modèle que vous pouvez exécuter n’est pas forcément celui dont vous avez entendu parler.

Lorsque la maintenance représente un coût que vous ne pouvez pas absorber. Les modèles sont mis à jour, les outils changent, les formats de quantification évoluent. Une API hébergée, c’est le problème opérationnel de quelqu’un d’autre.

Lorsque vous êtes en phase de prototypage. Développez en vous appuyant sur une API, vérifiez que le produit fonctionne, puis évaluez si le passage en local en vaut la peine. L’ordre inverse revient à résoudre des problèmes matériels avant même de savoir si l’idée est valable.

Et le cas sans ambiguïté : si votre contrainte est que les données ne doivent pas quitter vos locaux, rien de ce qui précède ne s’applique. Dans cette situation, le mode local n’est pas une préférence, et la seule question est de savoir quel modèle s’adapte à votre matériel.

Questions fréquentes

Quel est le meilleur LLM local en 2026 ?

Il n’y a pas de réponse unique, mais Qwen3 est la famille la plus utile pour un déploiement local, car elle couvre des tailles allant de 0,6 milliard à 235 milliards de paramètres, avec un comportement cohérent et une licence Apache 2.0. Adaptez la taille à votre mémoire vidéo (VRAM) : 8 milliards pour 8 à 16 Go, le modèle « mixture-of-experts » de 30 milliards à 3,3 milliards pour 24 Go, et gpt-oss-120b si vous disposez d’une carte de 80 Go.

De combien de VRAM ai-je besoin pour faire tourner un LLM en local ?

8 Go permettent de faire tourner des modèles quantifiés de 4B à 8B. 16 Go couvrent largement les modèles de 12B à 14B, ou le modèle gpt-oss-20b dont il est documenté qu’il fonctionne avec 16 Go. 24 Go ouvrent la voie aux modèles de la classe des 30 milliards. Les architectures de type « mixture-of-experts » font pencher la balance en votre faveur, car seule une fraction des paramètres est activée par token.

Les LLM locaux sont-ils aussi performants que ChatGPT ou Claude ?

Pas pour les tâches de raisonnement les plus complexes, non. Pour la synthèse, l’extraction, la classification, la traduction et la recherche dans vos propres documents, un bon modèle local de 14B à 32B est suffisamment performant pour que la différence soit rarement perceptible. L’écart se réduit, mais n’est pas encore comblé.

Quels LLM locaux puis-je utiliser à des fins commerciales ?

Qwen3, Gemma 4 et gpt-oss sont sous licence Apache 2.0. DeepSeek-R1 est sous licence MIT. Tous autorisent une utilisation commerciale sans restriction quant au domaine d’application. La famille Llama utilise des licences communautaires personnalisées qui accordent de nombreuses libertés, mais comportent des conditions qu’il vaut mieux lire attentivement. Vérifiez le modèle spécifique plutôt que la famille : les distillats de DeepSeek basés sur Qwen sont sous licence Apache 2.0, tandis que ceux basés sur Llama sont sous licence Llama.

Quel est le moyen le plus simple d’exécuter un LLM localement ?

Ollama pour les développeurs : une seule commande pour récupérer un modèle, et un point de terminaison HTTP compatible avec OpenAI. LM Studio si vous préférez une interface graphique sans ligne de commande. Les deux s’occupent pour vous de la quantification et de la détection du matériel.

La quantification nuit-elle à la qualité ?

Dans une certaine mesure, et de manière inégale. Le niveau Q8 est pratiquement impossible à distinguer de la pleine précision. Le niveau Q4_K_M est la valeur par défaut courante, avec une légère dégradation que la plupart des gens ne remarquent pas. En dessous de Q3, la dégradation devient évidente. En règle générale, un modèle plus volumineux en Q4 surpasse un modèle plus petit en Q8 avec le même budget mémoire.

Puis-je exécuter un LLM local sur un Mac ?

Oui, et souvent mieux que sur un PC de prix comparable, car la mémoire unifiée d’Apple Silicon est accessible au GPU. Un Mac de 64 Go exécute des modèles qui nécessiteraient une carte graphique que la plupart des gens ne possèdent pas. Le débit est inférieur à celui d’un GPU discret, mais le plafond de capacité est bien plus élevé par livre.

Ai-je besoin de proxys ou d’une configuration réseau particulière pour les LLM locaux ?

Non. Le modèle s’exécute sur votre machine et n’effectue aucune requête réseau. Le réseau n’entre en jeu que si vous collectez des données Web à récupérer, ce qui constitue une partie distincte du pipeline.

Conclusion

Privilégiez d’abord la mémoire, puis la licence, et enfin les benchmarks. Cet ordre est à l’opposé de celui suivi dans la plupart des comparatifs, mais c’est celui qui permet d’obtenir un système fonctionnel.

C’est votre mémoire vidéo (VRAM) qui détermine quels modèles sont même envisageables, et les architectures de type « mixture-of-experts » ont considérablement assoupli cette contrainte : 117 milliards de paramètres sur une seule carte de 80 Go, ou 21 milliards sur une carte de 16 Go, n’étaient pas des propositions réalistes il y a encore peu de temps. La licence détermine si vous pouvez commercialiser ce que vous développez, et le passage de Gemma 4 à la licence Apache 2.0 signifie que le niveau permissif couvre désormais la plupart des options les plus performantes. Les benchmarks viennent en dernier car, au sein d’une même classe de taille, les différences sont minimes et votre charge de travail spécifique ne correspondra de toute façon pas au classement.

Voici un résumé honnête de la situation actuelle : pour les travaux soumis à des contraintes de confidentialité, pour les volumes élevés et pour tout ce qui nécessite que le modèle cesse d’évoluer sous vos pieds, le traitement local est désormais une bonne option à part entière plutôt qu’un compromis. Pour une utilisation occasionnelle à la pointe des capacités, ce n’est toujours pas le cas, et une API hébergée reste la solution la plus judicieuse.