Meilleurs LLM locaux en 2026 : Qwen3.6, Gemma 4, gpt-oss et Phi-4

Le meilleur LLM local pour une machine dotée de 32 GB est Qwen3.6-35B-A3B : son package actuel en 4 bits sous Ollama pèse 24 GB, ce qui laisse 8 GB avant que le runtime, le système d'exploitation et le cache de contexte ne prennent leur part. Pour 8 GB, privilégiez Qwen3.5-9B ; pour 16 GB, choisissez Gemma 4 12B pour le travail multimodal ou gpt-oss-20b pour le raisonnement.

Réponse rapide : le meilleur LLM local selon votre machine

Un modèle local doit d'abord entrer en mémoire avant que le moindre benchmark n'ait d'importance. Cela semble évident, et pourtant c'est l'erreur derrière la plupart des mauvaises recommandations : un modèle sparse peut n'activer que quelques milliards de paramètres par token tout en exigeant que l'ensemble de ses poids reste chargé en mémoire vive.

Ce classement part de l'artefact téléchargeable actuel, ajoute la marge opérationnelle nécessaire, et demande seulement ensuite ce que le modèle sait bien faire. Il s'agit de comparaisons issues des model cards et des documentations de runners à ce jour, et non de résultats de tests imaginaires.

Le meilleur choix par défaut absolu est Qwen3.6-35B-A3B sur une machine disposant d'environ 32 GB de mémoire système ou unifiée disponible. Il combine des poids ouverts, une entrée multimodale et du code agentique dans un format Q4_K_M actuel de 24 GB. Si ce fichier ne rentre pas avec une marge suffisante, basculer sur Qwen3.5-9B reste une décision bien plus saine que de forcer un modèle trop grand à swapper sur le disque.

Le palier des 16 GB compte deux gagnants car votre charge de travail doit trancher. Gemma 4 12B est le modèle le plus pertinent lorsqu'un assistant doit analyser des images, de la vidéo ou de l'audio. gpt-oss-20b est l'option de choix pour le raisonnement pur et l'appel d'outils, mais son package de 14 GB ne laisse que 2 GB avant que le reste de la machine ne réclame de la mémoire.

De combien de mémoire les meilleurs LLM locaux ont-ils réellement besoin ?

Quatre grandeurs sont constamment confondues dans les discussions sur les modèles locaux : le nombre total de paramètres, le nombre de paramètres actifs, la taille du fichier quantifié et la mémoire opérationnelle réelle. Elles répondent pourtant à des questions différentes.

Le nombre total de paramètres décrit l'ensemble des poids appris du modèle. Les paramètres actifs décrivent le sous-ensemble qu'un modèle à mixture d'experts (MoE) utilise pour générer un token précis. Ce deuxième chiffre explique l'efficacité de calcul, mais le premier reste le seul déterminant pour le stockage disque et l'occupation en mémoire vive. Google explicite parfaitement cette distinction pour Gemma 4 26B A4B : seuls 4 milliards de paramètres sont actifs par token, mais la totalité des 26 milliards doit être chargée en mémoire.

La quantification réduit la précision numérique utilisée pour stocker ces poids. Une version 4 bits est nettement plus compacte qu'en pleine précision, avec un compromis acceptable sur les capacités. C'est un peu comme compresser une carte géographique détaillée dans un format de poche plutôt que d'en effacer les trois quarts des routes : la structure générale subsiste, mais un peu de précision fine disparaît.

La mémoire opérationnelle regroupe la taille du fichier du modèle plus tout ce qui est nécessaire pour l'exécuter. Le runner a besoin de mémoire. Le système d'exploitation en a besoin. Le cache KV, zone de travail rapide pour stocker le prompt et la conversation générée, grossit avec le contexte. Le tableau officiel de Google pour Gemma rappelle d'ailleurs expressément que ses estimations de poids statiques excluent les logiciels supports et la fenêtre de contexte.

C'est pourquoi un modèle affichant une limite théorique de 256K tokens de contexte peut très bien tenir en mémoire au repos, alors que les 256K de contexte complets feront planter la machine. Une limite de contexte est un plafond permis par l'architecture mathématique, pas une promesse tenue par votre ordinateur portable. Qwen3.5-9B comme Qwen3-Coder-Next conseillent d'ailleurs explicitement de réduire la fenêtre de contexte après une erreur de mémoire saturée (OOM).

Commencez par votre palier de mémoire avant de choisir le modèle

Considérez ces valeurs comme des seuils minimaux de déploiement, et non comme des garanties valables pour n'importe quelle longueur de contexte :

• 4 GB de VRAM dédiée : le fichier Q4_K_M de 2.5 GB de Phi-4-mini est le seul choix compact crédible lorsque la machine possède également de la RAM système standard. Pour un usage purement CPU, 8 GB de RAM système constituent un seuil plus réaliste.
• 8 GB de VRAM dédiée : le package de 6.6 GB de Qwen3.5-9B rentre si le contexte reste modéré. Une machine dotée de 12 GB ou plus de mémoire système ou unifiée totale est nettement plus sûre.
• 16 GB de mémoire disponible : Gemma 4 12B offre l'intégration la plus fluide. gpt-oss-20b atteint le seuil officiel de 16 GB fixé par OpenAI, mais la marge y est extrêmement étroite.
• 32 GB de mémoire disponible : Qwen3.6-35B-A3B est la recommandation polyvalente la plus solide ici, car son package de 24 GB laisse 8 GB disponibles avant le runtime et la montée en contexte.
• 64 GB ou plus : Qwen3-Coder-Next devient envisageable. Son package de 52 GB ne laisse toutefois que 12 GB de marge avant le reste de la pile logicielle.

Le calcul de la marge de sécurité met en lumière des écarts majeurs. Qwen3.5-9B laisse 1.4 GB dans une allocation de 8 GB, soit 17.5%. gpt-oss-20b laisse 2 GB sur 16 GB, soit 12.5%. Qwen3.6 laisse 8 GB sur 32 GB, soit 25%. Qwen3-Coder-Next laisse 12 GB sur 64 GB, soit 18.75%.

Ces pourcentages ne correspondent pas à la mémoire libre restante une fois la session ouverte. Ils représentent la limite maximale avant que le runner, l'OS et le cache KV ne s'installent. L'association avec gpt-oss représente donc un strict minimum technique, tandis que Qwen3.6 offre la marge la plus saine des quatre.

1. Qwen3.6-35B-A3B : le meilleur choix polyvalent pour 32 GB

Qwen3.6-35B-A3B s'impose comme le meilleur LLM local polyvalent si vous disposez d'au moins 32 GB de mémoire réellement exploitable. Qwen le documente comme un modèle mixture-of-experts de 35 milliards de paramètres au total avec 3 milliards de paramètres actifs, des poids ouverts, un raisonnement multimodal et une forte orientation vers le code agentique. Le build actuel sous Ollama pèse 24 GB en Q4_K_M, ce qui constitue la métrique clé pour savoir s'il peut tourner sur votre matériel.

Ce modèle convient idéalement à un fondateur technique ou à un développeur senior souhaitant un assistant privé unique capable de répondre sur un codebase, de planifier une implémentation, d'analyser des captures d'écran et de coder sur la durée. Il est bien plus pertinent qu'un modèle purement dédié au code lorsque le même assistant doit aussi déchiffrer des schémas ou relire des documents. Ses 3 milliards de paramètres actifs favorisent la vitesse d'inférence, mais ne réduisent pas pour autant la taille de l'archive à 3 GB : le fichier 4 bits installé fait bel et bien 24 GB.

Le défi concret réside dans la gestion du contexte. Le fichier consomme les trois quarts d'une enveloppe de 32 GB avant même que la discussion ne débute. Des dépôts volumineux, de nombreuses images ou des sessions longues remplissent vite le cache : il vaut donc mieux paramétrer un contexte utile et raisonnable plutôt que de viser le plafond théorique et de pousser la machine au swapping.

Recommandé pour : Une machine de 32 GB cherchant un modèle local unique et puissant pour le code, le raisonnement et la vision.
Points forts : 35 milliards de paramètres totaux, 3 milliards actifs, entrées multimodales et build Q4_K_M de 24 GB.
Tarifs : Poids ouverts sous licence Apache License 2.0 associés à l'artefact Ollama actuel ; le coût se limite à votre matériel local.
Essai gratuit : Non applicable pour des poids téléchargeables.

Lancer le modèle avec Ollama

1. 1

   Vérifiez la mémoire réellement disponible

   Prévoyez 32 GB comme plancher de travail pour cet artefact de 24 GB. Sur architecture à mémoire unifiée, déduisez ce que le système et vos applications consomment déjà.

2. 2

   Installez Ollama

   Téléchargez la version actuelle d'Ollama sur le site officiel. L'offre Free suffit pour un usage local illimité sur votre propre équipement.

3. 3

   Lancez la commande exacte

   Exécutez ollama run qwen3.6:35b-a3b. Cette commande télécharge l'artefact officiel Q4_K_M de 24 GB documenté sur la page de modèle d'Ollama.

4. 4

   Démarrez avec un contexte restreint

   Ne chargez que le dossier ou les documents strictement nécessaires au prompt initial, sans injecter un dépôt entier d'emblée. En cas de saturation mémoire ou d'erreur OOM signalée par le runtime, réduisez la fenêtre de contexte avant de chercher une quantification plus agressive.

2. Qwen3.5-9B : le meilleur modèle local pour GPU de 8 GB

Qwen3.5-9B est le meilleur modèle compact de ce comparatif pour un GPU dédié de 8 GB. La fiche officielle documente un modèle de langage causal de 9 milliards de paramètres doté d'un encodeur de vision, et son package actuel sous Ollama pèse 6.6 GB avec support texte et image. Cela en fait la plus petite recommandation de cette sélection capable d'assurer le rôle d'assistant multimodal quotidien crédible.

Le cas d'usage typique est celui d'un compagnon de code de bureau capable d'analyser une capture d'écran d'erreur, une maquette UI ou un schéma d'architecture. Un développeur indépendant équipé d'un GPU de 8 GB peut l'exploiter pour l'explication de code, des refactorisations ciblées et des questions visuelles sans monopoliser les 24 GB demandés par Qwen3.6. C'est également l'alternative logique quand le modèle supérieur se met à ralentir à cause du swap.

L'argument commercial des 256K tokens de contexte exige de la prudence. La fiche de Qwen indique une limite native de 262,144 tokens et préconise explicitement de réduire le contexte après une saturation de la mémoire. Le fichier de 6.6 GB ne laissant que 1.4 GB de libre sur 8 GB de VRAM avant le cache et le runner, exploiter ce contexte maximal n'est envisageable que sur des configurations bien plus généreuses.

Recommandé pour : Un GPU dédié de 8 GB, un assistant multimodal compact et de l'aide au code au quotidien.
Points forts : Un fichier de 6.6 GB acceptant à la fois le texte et les images.
Tarifs : Poids téléchargeables sans abonnement requis sur la source officielle ; le matériel et l'éventuel hébergement sont à votre charge.
Essai gratuit : Non applicable pour des poids téléchargeables.

3. Gemma 4 12B : le meilleur choix multimodal local pour 16 GB

Gemma 4 12B constitue le meilleur compromis sur 16 GB lorsque l'analyse multimodale est au cœur de vos besoins. La génération actuelle conçue par Google traite le texte, l'image et la vidéo, tandis que la déclinaison 12B prend également en charge l'audio. Ses poids ouverts autorisent une utilisation commerciale responsable selon les conditions de Gemma, ce qui le rend particulièrement pertinent pour monter un assistant documentaire ou média privé.

Ce modèle est particulièrement adapté à un product manager ou un ingénieur qui a besoin, sur un même poste, de comparer des captures d'écran, résumer un enregistrement audio de réunion, inspecter une courte vidéo et raisonner sur les textes associés. Il couvre une diversité de médias bien plus large que gpt-oss-20b, qui est strictement textuel. Son empreinte mémoire est également plus respirable : le package actuel gemma4:12b sous Ollama pèse 7.6 GB, ménageant une marge très confortable sur une machine de 16 GB.

L'estimation officielle de Google en Q4_0 est de 6.7 GB, alors que l'artefact Ollama affiche 7.6 GB. Ces chiffres ne sont pas contradictoires : ils reflètent simplement des variantes de build et d'empaquetage de quantification. L'avertissement de Google reste essentiel : la mémoire statique exclut les logiciels supports et la fenêtre de contexte, aucun de ces deux chiffres ne doit donc être pris pour l'empreinte mémoire totale en fonctionnement.

La version 12B se situe dans le milieu de gamme de la famille Gemma, avec une limite de 256K tokens de contexte. Tout comme pour Qwen, ce plafond théorique ne doit pas devenir votre valeur par défaut sur 16 GB. Travaillez d'abord avec les fichiers ou médias strictement utiles, puis n'élargissez la fenêtre que si la machine conserve une parfaite réactivité.

Recommandé pour : Un assistant multimodal sur machine de 16 GB traitant texte, image, vidéo et audio.
Points forts : Prise en charge média complète pour un fichier Ollama actuel de 7.6 GB.
Tarifs : Poids ouverts sous conditions d'utilisation Gemma ; aucun abonnement n'est requis pour le téléchargement.
Essai gratuit : Non applicable pour des poids téléchargeables.

4. gpt-oss-20b : le spécialiste du raisonnement local sur 16 GB

gpt-oss-20b est le modèle local à privilégier pour le raisonnement pur si votre équipement atteint le plancher strict de 16 GB de mémoire. OpenAI indique 21 milliards de paramètres au total, 3.6 milliards de paramètres actifs, un contexte allant jusqu'à 128K, une licence Apache 2.0 ainsi que le support natif des outils, du function calling, des Structured Outputs et d'un niveau d'effort de réflexion ajustable (low, medium ou high). Le package Ollama actuel fait 14 GB et fonctionne exclusivement en mode texte.

C'est le choix idéal pour un workflow d'automatisation local devant résoudre un problème logique étape par étape et renvoyer un format JSON strict, comme le tri et la catégorisation de tickets support avant validation humaine. Il intéressera aussi les développeurs qui préfèrent ajuster l'effort d'inférence plutôt que de bénéficier de la vision. Le modèle ayant été principalement entraîné sur un corpus anglophone textuel orienté sciences, code et culture générale, il ne doit en aucun cas être pris pour un modèle multimodal.

OpenAI affirme que le modèle 20B peut tourner avec 16 GB de mémoire. Le fichier de 14 GB chez Ollama confirme la faisabilité technique de ce plancher, mais les 2 GB restants ne représentent que 12.5% de marge avant même l'intervention du runner, de l'OS et du cache. Une configuration de 24 GB reste bien plus recommandable si vous comptez le solliciter sur des tâches continues plutôt que sur de simples prompts isolés.

Recommandé pour : Le raisonnement textuel poussé, l'appel d'outils, les sorties structurées et les workflows agentiques.
Points forts : 3.6 milliards de paramètres actifs, effort de réflexion ajustable et plancher officiel à 16 GB.
Tarifs : Poids ouverts sous licence Apache 2.0 ; aucun abonnement requis pour une exécution locale.
Essai gratuit : Non applicable pour des poids téléchargeables.

5. Phi-4-mini-instruct : le meilleur petit modèle pour CPU et VRAM de 4 GB

Phi-4-mini-instruct est le modèle local léger le plus adapté de ce classement pour les machines aux ressources réduites. La documentation de Microsoft détaille 3.8 milliards de paramètres, un contexte maximal de 128K, une entrée purement textuelle, la prise en charge de 24 langues et une licence MIT. Le build Q4_K_M proposé par Ollama pèse 2.5 GB, ce qui lui permet de fonctionner parfaitement sur un GPU dédié de 4 GB ou sur une machine purement CPU munie d'au moins 8 GB de RAM système.

Ce modèle excelle sur des micro-tâches locales : reformuler une réponse de support client, extraire des champs précis d'un court extrait, classer des notes ou débugger un petit script Python sans jamais envoyer de données vers un service cloud. Microsoft le positionne explicitement pour les environnements contraints en mémoire, limités en puissance de calcul ou sensibles à la latence, ainsi que pour les mathématiques et la logique. C'est pour ces qualités précises qu'il faut le retenir, et non en espérant égaler un modèle de 24 GB sur tous les fronts.

Sa limite principale est clairement assumée. Sa date de fin d'entraînement (knowledge cutoff) est June 2024, et Microsoft souligne qu'un modèle si compact ne peut pas mémoriser une encyclopédie de connaissances factuelles, exposant l'utilisateur à des erreurs. La fiche préconise d'utiliser la recherche documentaire ou du RAG (retrieval-augmented generation) pour pallier cela : fournissez-lui directement vos sources au lieu de compter sur sa propre mémoire.

Recommandé pour : Les scripts légers sur CPU, les machines modestes, les micro-tâches textuelles et les GPU de 4 GB.
Points forts : Un fichier Q4_K_M de seulement 2.5 GB distribué sous licence MIT.
Tarifs : Poids téléchargeables sous licence MIT ; le seul coût est l'électricité et le matériel.
Essai gratuit : Non applicable pour des poids téléchargeables.

6. Qwen3-Coder-Next : le spécialiste du code pour configurations de 64 GB et plus

Qwen3-Coder-Next s'impose comme le meilleur modèle local spécialisé dans le code pour les stations de travail équipées d'au moins 64 GB de mémoire. Qwen l'a conçu spécifiquement pour alimenter des agents logiciels et des environnements de développement locaux : 80 milliards de paramètres totaux, 3 milliards de paramètres actifs, un raisonnement sur le temps long, la manipulation d'outils complexes, la récupération après plantage d'exécution et un contexte natif de 262,144 tokens. Le package Q4_K_M proposé sous Ollama pèse 52 GB.

Ce modèle est pensé pour les profils techniques avancés voulant déléguer à un agent local l'analyse d'un dépôt de code complet, la modification itérative de plusieurs fichiers et la correction autonome après une commande de test échouée. Il n'est pas fait pour servir de chat généraliste, ni pour manipuler des images, et ne convient pas à un ordinateur portable standard de 32 GB. La fiche technique précise d'ailleurs qu'il fonctionne uniquement en « non-thinking mode », ce qui signifie qu'il ne produit pas de blocs visibles détaillant sa réflexion interne.

Les 3 milliards de paramètres actifs peuvent induire en erreur de la même manière que sur d'autres architectures MoE. Le fichier pèse bien 52 GB sous Ollama, car les 80 milliards de poids totaux doivent résider en mémoire pour être appelés. Charger ce fichier sur une configuration de 64 GB ne laisse que 12 GB de libre (soit 18.75%) avant le système et le cache. 64 GB est un seuil d'accès minimal : disposer de plus de mémoire s'avère précieux pour maintenir un contexte étendu sur un gros projet.

Qwen recommande formellement d'abaisser la fenêtre de contexte à 32,768 tokens en cas de saturation de la mémoire. C'est le premier réglage à appliquer sur une machine de 64 GB. Il est bien plus judicieux de conserver un agent réactif sur un contexte ciblé que de s'obstiner à saturer les 262,144 tokens au prix d'un blocage complet.

Recommandé pour : Les agents de code autonomes, l'ingénierie logicielle lourde et l'outillage avancé sur 64 GB ou plus.
Points forts : 80 milliards de paramètres totaux, 3 milliards actifs, fichier Q4_K_M de 52 GB et conception agentique sur mesure.
Tarifs : Poids ouverts sous licence Apache License 2.0 associés à la release Ollama ; coût matériel indépendant.
Essai gratuit : Non applicable pour des poids téléchargeables.

Ollama vs LM Studio vs llama.cpp

Si le modèle définit les performances théoriques, le runner détermine le niveau de friction entre le téléchargement des fichiers et leur exploitation concrète. Ollama est le favori pour l'automatisation, LM Studio s'adresse aux adeptes de l'interface graphique et llama.cpp offre un contrôle matériel total. Ces trois solutions peuvent parfaitement cohabiter sur une même machine.

Ollama : la voie la plus directe vers la ligne de commande et l'API

Ollama représente la solution la plus simple dès qu'un modèle local doit alimenter un script, une commande de terminal ou une API locale compatible OpenAI. Son forfait Free actuel couvre l'exécution locale illimitée sur votre matériel, une CLI performante, des bibliothèques logicielles et une application de bureau. L'inférence sur vos propres composants ne fait l'objet d'aucune facturation, ce qui est le seul critère tarifaire déterminant pour un déploiement 100% hors ligne.

Les paliers payants d'Ollama ajoutent uniquement de la capacité d'exécution sur leur cloud sans taxer votre puissance de calcul locale. Tarifs et plafonds vérifiés au August 5, 2026 :

Les limites de sessions cloud individuelles se réinitialisent toutes les 5 heures, et les quotas hebdomadaires tous les 7 jours. Ces restrictions ne concernent absolument pas les modèles tournant directement sur votre équipement. Pour notre recommandation principale, une seule ligne de commande suffit après installation : ollama run qwen3.6:35b-a3b.

Recommandé pour : Les développeurs recherchant une CLI propre, une API locale stable et des tags de modèles simples.
Points forts : Exécution matérielle locale 100% gratuite et illimitée, avec options cloud facultatives.
Tarifs : Free à $0 ; Pro à $20 par mois ou $200 par an ; Max à $100 par mois avec inscriptions suspendues ; Team à $25 par siège et par mois (minimum 5 accès) ; Enterprise sur devis.
Essai gratuit : L'offre Free est permanente et ne constitue pas un essai limité dans le temps.

LM Studio : la meilleure expérience visuelle pour les modèles locaux

LM Studio est le runner recommandé pour ceux qui préfèrent découvrir, charger et tester leurs modèles au sein d'une interface graphique soignée. L'application propose un onglet Discover pour naviguer parmi les modèles, un sélecteur de mémoire et un onglet Chat pour converser. L'offre Free permet d'exécuter localement des LLM et de la transcription vocale, la documentation confirmant qu'aucune donnée ne quitte votre ordinateur dans ce cadre local.

LM Studio propose aussi un accès vers des modèles hébergés sur le cloud : il convient donc de distinguer son usage local de ses services en ligne. Tarifs vérifiés au August 5, 2026 :

• Free, $0 : LLM locaux, Bionic Agent, moteurs d'exécution llama.cpp et MLX, transcription audio locale, outil de recherche web zéro-rétention (sur connexion) et LM Link pour connecter jusqu'à 5 appareils.
• Pay as you go : crédits cloud facturés pour 1 million de tokens. DeepSeek V4 Flash est facturé $0.13 en entrée, $0.028 en cache d'entrée et $0.26 en sortie. DeepSeek V4 Pro coûte $1.74 en entrée, $0.15 en cache d'entrée et $3.48 en sortie.
• Pay as you go (suite) : GLM-5.2 est à $1.50 en entrée, $0.30 en cache et $4.50 en sortie. Kimi K2.6 est à $0.95 en entrée, $0.16 en cache et $4.00 en sortie. Kimi-K2.7-Code affiche également $0.95 en entrée, $0.16 en cache et $4.00 en sortie. Kimi K3 est facturé $3.00 en entrée, $0.30 en cache et $15.00 en sortie.
• Bionic Pass : tarification et fonctionnalités détaillées à venir.

Pour un utilisateur évaluant des modèles sur un ordinateur de bureau, la simplicité graphique de la formule Free est l'atout numéro un de LM Studio. Pour une architecture logicielle devant être industrialisée ou versionnée dans un dépôt Git, Ollama ou llama.cpp seront des choix plus pérennes.

Recommandé pour : L'exploration visuelle de modèles, le téléchargement guidé et le chat direct.
Points forts : Une expérience desktop locale complète à $0 bâtie sur llama.cpp et MLX.
Tarifs : Free à $0 ; l'inférence cloud fonctionne au paiement à l'usage selon les taux ci-dessus ; forfait Bionic Pass prochainement annoncé.
Essai gratuit : L'accès Free est indéfini et ne subit pas d'expiration.

llama.cpp : pour le contrôle chirurgical du matériel et l'inférence hybride

llama.cpp est l'outil incontournable pour les utilisateurs souhaitant ajuster chaque variable de compilation et maîtriser la répartition des couches réseau entre les composants. Ce projet open source sous licence MIT prend en charge l'architecture Apple Silicon via Metal, les GPU NVIDIA via CUDA, les puces AMD via HIP, et autorise l'inférence hybride CPU + GPU lorsqu'un modèle dépasse la VRAM disponible. Il intègre un binaire CLI, un serveur dédié et une interface web légère.

Son utilisation typique est celle d'une station de travail sur mesure où une partie du modèle réside dans la VRAM du GPU tandis que le reste déborde sur la mémoire système, ou lorsqu'un compilateur particulier est nécessaire. Lancer la commande llama serve déploie instantanément le serveur HTTP de l'outil. Ce niveau de contrôle est remarquable, mais il requiert plus de temps de configuration et exige de sélectionner soi-même le bon fichier GGUF et les drapeaux d'optimisation.

llama.cpp n'a aucune grille tarifaire commerciale. C'est un pur projet communautaire sous licence MIT. Vos seuls investissements sont vos composants matériels et votre temps de configuration.

Recommandé pour : Les architectures matérielles spécifiques, l'inférence partagée CPU/GPU et le réglage fin des paramètres d'exécution.
Points forts : Compatibilité matérielle exceptionnelle et serveur local sans modèle économique payant.
Tarifs : Projet open source sous licence MIT ; aucun niveau de tarification payant.
Essai gratuit : Non applicable.

Méthode de sélection de ces modèles locaux

La date de validation des informations de ce comparatif est le August 5, 2026. Pour figurer dans ce classement, un modèle devait présenter une documentation technique officielle à jour, des poids téléchargeables publiquement, un cas d'usage pertinent pour un professionnel ou un particulier averti, et un fichier vérifiable sur un runner reconnu.

La sélection s'appuie sur six critères stricts :

1. Empreinte 4 bits viable : le package du modèle doit pouvoir tourner sur un palier de RAM/VRAM défini en préservant une marge de sécurité.
2. Utilité concrète : chaque modèle doit justifier sa présence par un point fort distinct (capacités multimodales, outils logiques, légèreté extrême ou développement logiciel agentique).
3. Génération logicielle actuelle : les générations passées ont été écartées dès lors qu'un successeur direct était documenté et opérationnel.
4. Limites documentées par l'éditeur : taille de contexte, modalités d'entrée, licences et contraintes proviennent directement des model cards officielles.
5. Prise en charge par les runners : un artefact officiel sous Ollama ou un support clair dans les principaux runtimes devait être effectif.
6. Exclusion lucide des modèles serveurs : aucun modèle orienté infrastructure n'a été inséré artificiellement sous prétexte d'un nombre restreint de paramètres actifs.

Aucun score synthétique unique n'a été utilisé pour classer l'ensemble des modèles, les laboratoires publiant rarement des bancs d'essai rigoureusement identiques. La décision finale repose sur la viabilité du déploiement en conditions réelles et sur la tâche visée : ce sont les deux éléments concrets qu'un développeur peut valider avant de lancer un téléchargement lourd.

C'est aussi pour cela que cette sélection se concentre sur six modèles clés, au lieu de gonfler la liste pour paraître exhaustive. Qwen3.6 et Gemma 4 rendent obsolètes de nombreuses options passées, tandis que la segmentation par seuils de RAM évite de lister des doublons inutiles.

Les modèles à éviter sur du matériel grand public standard

Déconseiller un modèle ne signifie pas qu'il est mauvais. Cela signifie simplement qu'il ne convient pas aux capacités de calcul d'une machine de bureau classique.

Mistral Small 4 est un modèle récent et très abouti, doté d'entrées texte et vision, d'un raisonnement paramétrable, d'une fenêtre de contexte de 256K et d'une licence Apache 2.0. Cependant, il mobilise 119 milliards de paramètres au total pour 6 milliards de paramètres actifs par token. Avec un tel poids mémoire, il s'adresse à des serveurs ou à des stations de travail très lourdes, et non à un ordinateur portable conventionnel.

Llama 4 Scout affiche 109 milliards de paramètres totaux pour 17 milliards d'actifs. Meta indique que la déclinaison Int4 nécessite un GPU professionnel NVIDIA H100 dédié. De son côté, Llama 4 Maverick monte à 400 milliards de paramètres totaux avec 17 milliards d'actifs, Meta décrivant son déploiement sur un cluster d'au moins un serveur complet équipé de H100. Ce sont des données techniques admirables, mais qui ne concernent en rien une installation locale personnelle.

DeepSeek-V4-Flash peut sembler être une option compacte au vu de son nom, mais il compte 284 milliards de paramètres au total (dont 13 milliards actifs). DeepSeek-V4-Pro atteint quant à lui 1.6 trillion de paramètres au total pour 49 milliards actifs. Les deux supportent un contexte de 1 million de tokens via l'infrastructure officielle hébergée de DeepSeek : il s'agit d'une prouesse pour des services cloud, pas d'une solution réaliste pour votre poste de travail.

En 2026, une sélection propre ne devrait plus recommander par automatisme Llama 3.1 8B, Mistral 7B, Phi-3.5 Mini, Gemma 2 9B ou Qwen2.5 7B sous prétexte que d'anciens guides les citent encore. Ces modèles restent exploitables sur des infrastructures existantes, mais pour tout nouveau projet local, les générations actuelles Qwen3.5, Qwen3.6, Gemma 4 et Phi-4 doivent être testées en priorité.

Cette distinction compte pour maîtriser le coût de migration : un système qui fonctionne de manière stable n'a pas besoin d'être mis à jour par simple effet de mode. En revanche, un nouveau service ne devrait pas s'appuyer sur d'anciens standards sans vérifier d'abord si la génération la plus récente respecte ses contraintes matérielles et contractuelles.

Synthèse : quel LLM local choisir ?

Avec 4 GB de VRAM dédiée, orientez-vous vers Phi-4-mini-instruct pour des opérations textuelles ciblées, en prenant soin de lui fournir les documents de référence pour les sujets factuels. Avec 8 GB de VRAM dédiée, préférez Qwen3.5-9B avec une fenêtre de contexte sobre pour obtenir le meilleur ratio texte, image et code dans un format réduit.

Avec 16 GB de mémoire, privilégiez Gemma 4 12B si vous manipulez des images, des fichiers audio ou de la vidéo. Choisissez gpt-oss-20b si la logique pure, les outils et les formats JSON stricts sont essentiels, en prévoyant si possible 24 GB de mémoire totale si vous utilisez d'autres outils de développement en parallèle.

Avec 32 GB de mémoire, retenez Qwen3.6-35B-A3B. C'est le compromis le plus performant et le plus équilibré de ce comparatif, son format de 24 GB préservant une marge de manœuvre suffisante tout en offrant d'excellentes capacités en vision et en code agentique.

Avec 64 GB ou davantage, adoptez Qwen3-Coder-Next uniquement si la conception d'agents logiciels autonomes représente votre priorité. Son package de 52 GB et sa spécialisation en code sont disproportionnés pour une simple discussion, mais idéaux pour naviguer dans un dépôt complet.

Pour explorer les modèles à poids ouverts sans restriction de matériel grand public, découvrez notre comparatif des meilleurs LLM open source. Si votre choix de modèle est arrêté mais que vous hésitez sur le runner, lisez notre article sur les alternatives actuelles à Ollama.

La sélection du moteur se résume simplement : Ollama pour des scripts fiables et une API locale, LM Studio pour une interface graphique clé en main, et llama.cpp pour régler l'utilisation des composants au millimètre. Le meilleur LLM local reste toujours celui qui rentre proprement sur votre équipement, répond à votre charge de travail et conserve assez de mémoire pour terminer de générer votre prompt.

Foire aux questions

Quel est le meilleur LLM local pour coder en 2026 ?

Qwen3-Coder-Next est le choix de pointe sur les configurations de 64 GB ou plus, son package Q4_K_M actuel pesant 52 GB et son architecture étant conçue pour les agents logiciels. Sur une machine de 32 GB, Qwen3.6-35B-A3B est le meilleur modèle polyvalent pour le développement.

Quel est le meilleur LLM local pour 16 GB de RAM ?

Gemma 4 12B offre l'intégration la plus sûre et multimodale avec son fichier Ollama de 7.6 GB. gpt-oss-20b respecte le plancher officiel d'OpenAI pour le raisonnement, mais son fichier de 14 GB ne laisse que 2 GB de marge avant l'OS et le contexte.

Ollama est-il meilleur que LM Studio pour faire tourner un LLM local ?

Ollama est plus performant pour manipuler une CLI, automatiser des scripts et exposer une API locale. LM Studio s'avère bien plus adapté si vous privilégiez un catalogue visuel, un chargeur de modèles intégré et une interface de chat. Les deux solutions sont gratuites en local.

Combien de RAM ou de VRAM faut-il pour faire tourner un LLM en local ?

Partez toujours de la taille du fichier quantifié, puis ajoutez l'espace requis pour le runner, le système d'exploitation et le cache KV. Les modèles de ce comparatif s'échelonnent d'un fichier de 2.5 GB pour les petites configurations jusqu'à 52 GB réclamant au minimum 64 GB de mémoire.

Les LLM locaux sont-ils vraiment gratuits ?

Les modèles présentés disposent de poids ouverts téléchargeables sans coût par token. En revanche, le matériel informatique, le stockage SSD, l'électricité consommée, le temps d'intégration et les éventuels services cloud tiers représentent un coût réel.

Recevez notre checklist d'audit des workflows IA pour identifier concrètement les automatisations locales ou cloud qui méritent d'être déployées dans votre entreprise.