- Recherche d’un modèle capable de gérer une conversation de base sur une 5060ti + 16GB de VRAM. Si possible, il devrait être rapide et fonctionner presque en temps réel
Synthèse des réponses
- Divers modèles de 8B à 14B, et 30B paramètres fonctionnent efficacement avec 16GB de VRAM ; parmi les recommandations fréquentes figurent Qwen3, DeepSeek-R1, Mistral, Gemma3
- L’exécution locale de LLM offre des avantages en matière de performances, de coût et de confidentialité, mais les performances réelles et l’adéquation d’un modèle exigent des tests et un tuning individuels
- Des conseils d’optimisation du matériel sont largement partagés, notamment sur la taille des fichiers de modèle, le niveau de quantification (Q4 à Q6, etc.), et le chargement réparti entre GPU et RAM
- Il existe divers outils comme Ollama, LM Studio, llama.cpp, OpenWebUI, chacun avec ses forces et faiblesses en matière d’accessibilité, de flexibilité et de gestion des modèles
- Les informations communautaires (par ex. Reddit LocalLLaMA) sont utiles pour les actualités récentes et les conseils pratiques, mais il faut rester vigilant face aux exagérations et aux informations erronées
Principales recommandations de LLM et conseils d’usage
- Qwen3 : existe en plusieurs tailles, comme 8B/14B/30B ; les modèles 8B à 14B sont confortables à utiliser avec 16GB de VRAM. Les performances en reasoning sont excellentes, et grâce à une architecture MoE (Mixture of Experts), certains modèles plus gros peuvent aussi tourner via offloading vers la RAM
- DeepSeek-R1-0528-Qwen3-8B : considéré comme l’un des meilleurs modèles 8B récents pour le reasoning. En 8B, il convient à une quantification Q4 à Q6 avec 4GB à 8GB de VRAM
- Mistral Small 3.1 : les variantes 14B ou 24B sont recommandées ; la qualité conversationnelle est élevée et le niveau de censure est relativement faible. Il prend aussi en charge l’entrée image
- Gemma3 : modèle fourni par Google, fort pour les conversations intuitives. Il est toutefois jugé assez orienté RH, avec beaucoup de disclaimers, et présente relativement plus d’hallucinations
- Devstral : grand modèle basé sur Mistral. Au-delà de 30B, la vitesse peut devenir lente avec 16GB de VRAM
- Dolphin, Abliterated : versions moins censurées, utiles dans des situations non routinières
Optimisation du matériel et de l’environnement d’exécution
- Réglages de quantification : avec Q4, Q5, Q6, plus la quantification est basse, plus l’usage de VRAM diminue (Q4 ≒ paramètres/2, Q6 ≒ paramètres*0.75). Il faut toutefois faire attention à la baisse de qualité
- Estimation de la capacité VRAM : exemples — 8B en Q4 nécessite 4GB, 14B en Q4 7GB, 30B en Q4 environ 15GB de VRAM
- Offloading vers la RAM : si la VRAM manque, certaines couches peuvent être déportées vers la mémoire CPU. Il faut en contrepartie accepter une baisse de vitesse
- Quantification du cache KV : pour augmenter la context window, il est recommandé d’utiliser une compression du cache autour de q4
Outils et frontends
- llama.cpp : rapide et flexible sur de nombreuses plateformes. Prend en charge une API REST et un frontend React simple. Peut charger un modèle en le répartissant entre VRAM et RAM
- Ollama : installation facile, changement de modèle simple, intégration aisée avec des frontends GUI. En revanche, le support des modèles récents et la taille de contexte ont des limites
- LM Studio : gestion pratique des modèles dans un environnement GUI. Fournit aussi une fonction d’estimation de compatibilité VRAM
- OpenWebUI : frontend uniquement. Nécessite un backend comme llama.cpp ou vllm. Permet de gérer et tester plusieurs modèles simultanément
- KoboldCPP, SillyTavern : frontends spécialisés pour le jeu de rôle, le storytelling et les jeux
Communauté et informations de terrain
- Reddit LocalLLaMA, HuggingFace, Discord : on y partage activement les nouveautés sur les modèles, les modes d’emploi, les benchmarks et les bonnes pratiques de configuration. Il faut toutefois se méfier de la désinformation et des effets de pensée de groupe
- Sites de benchmarks : livebench.ai, aider.chat, etc., fournissent scores et classements des modèles récents
Objectifs d’usage et retours d’expérience
- Confidentialité, réduction des coûts : pour des données sensibles, des enjeux de confidentialité ou un usage répétitif, les modèles locaux sont souvent plus intéressants que le cloud
- Liberté d’expérimentation et de tuning : plus de souplesse qu’avec des modèles via API pour le fine-tuning sur domaine spécialisé, les stratégies d’échantillonnage et le prompt engineering
- Cas d’usage : nombreux exemples concrets, comme le RAG (génération augmentée par la recherche), l’intégration à une base de données locale, l’automatisation par agents ou l’assistance hors ligne
Questions fréquentes et conseils
- Estimation de la taille d’un modèle : nombre de paramètres × bits (quantization)/8 = besoin approximatif en VRAM (GB). Il faut aussi tenir compte de l’overhead et de la context window
- Caractéristiques par modèle : Qwen3 pour le reasoning/le code, Gemma3 pour l’intuition/la conversation, Mistral avec moins de censure, Dolphin/abliterated pour des versions uncensored, etc.
- Comparaison des performances : il est recommandé de faire ses propres benchmarks et tests personnalisés pour trouver le modèle le plus adapté à ses besoins
Conclusion et conseils pratiques
- Il n’existe pas de « meilleur modèle » absolu ; selon le matériel, l’usage et les préférences, le mieux est d’essayer différents modèles récents de 8B à 14B comme Qwen3, Mistral ou Gemma3
- Comme la taille du fichier du modèle, la quantification et la taille du contexte sont des paramètres très importants, il est efficace de tester directement plusieurs modèles et de s’appuyer sur les conseils de la communauté
1 commentaires
Avis Hacker News
Si vous voulez exécuter un LLM en local, vous pouvez trouver beaucoup d’aide sur la communauté localllama de reddit
Il n’existe pas vraiment de modèle LLM qu’on puisse qualifier de « meilleur » dans l’absolu ; chaque modèle a ses avantages et ses inconvénients, donc il faut en essayer plusieurs soi-même
Par exemple, le modèle DeepSeek-R1-0528-Qwen3-8B est sorti aujourd’hui et offre les meilleures performances en raisonnement logique dans la catégorie 8B
Et la série Qwen3 est également récente, avec une approche hybride, de bonnes performances et plusieurs tailles adaptées à différents matériels
Qwen3-30B-A3B peut tourner à une vitesse correcte même sur CPU
Même le mini-modèle 0.6B est étonnamment cohérent, ce qui est assez surprenant
En utilisant llama-cpp, j’ai déjà vu des cas où déporter certains tenseurs sur le CPU permettait de conserver de bonnes performances
En général, avec llama-cpp, on définit le nombre de couches chargées sur le GPU (
-ngl), mais si les tenseurs concernés ne sont pas ceux qui coûtent le plus en calcul, on peut économiser de l’espace GPU en les déportant sur le CPU sans perte notable de vitesseJ’ai aussi lu un article sur le chargement des seuls neurones « hot » depuis le CPU (lien arxiv), et ça me rend optimiste sur la possibilité d’exploiter l’IA de façon vraiment intéressante à la maison
Un point d’attention pour les gens qui n’ont pas l’habitude d’utiliser Reddit
Reddit, y compris LocalLlama, contient beaucoup d’informations erronées ou de désinformation populaire, et le ratio upvotes/downvotes ne garantit en rien l’exactitude d’une information
Un commentaire précis mais rédigé de façon ennuyeuse peut être impopulaire, tandis qu’une explication fausse mais drôle, émotionnelle ou conforme à l’opinion du groupe devient souvent populaire
Quelqu’un comme moi, qui traîne sur le web depuis longtemps, fait le tri instinctivement, mais si vous découvrez ce type d’espace très sujet à la pensée de groupe, je vous recommande de rester prudent dans la manière d’absorber l’information
En ce moment, presque tous les modèles ont un niveau de base correct, donc on a surtout l’impression de chercher une « personnalité de modèle » qui colle à ses goûts
L’OP peut simplement les télécharger un par un et les tester
Avec 16GB de mémoire, on peut faire tourner avec llama.cpp des modèles jusqu’à 30B, même des modèles denses, à une vitesse « correcte » en faisant un offload partiel sur de la DDR5 ; le déport de tenseurs aide encore plus
Qwen a quelques limites comme modèle conversationnel
Mistral Nemo, Small, ainsi que la série Llama 3.X restent d’excellents choix aujourd’hui
Les Gemma 3s sont bons, mais avec un style un peu imprévisible
Si vous voulez un niveau proche de GPT-4 à la maison, je recommande QwQ
Et il y a sûrement d’autres bons modèles que j’oublie
Je me demande s’il y a des modèles particulièrement recommandés pour être utilisés avec des outils de code comme aider ou roo
J’ai trouvé qu’il est assez difficile de dénicher des modèles vraiment efficaces pour l’usage d’outils
DeepSeek-R1-0528-Qwen3-8B est un modèle obtenu en distillant le chain-of-thought de DeepSeek-R1-0528 dans Qwen3-8B Base ; il dépasse Qwen3-8B de plus de 10 % sur AIME 2024 et atteint un niveau comparable à Qwen3-235B-thinking
C’est une nouvelle preuve frappante de l’efficacité de la distillation des connaissances
C’est sans doute pour cela que plusieurs entreprises comme OpenAI ou divers labos cherchent aujourd’hui à masquer leur chain-of-thought (COT) (billet de référence)
Je suis curieux de savoir à quoi les gens utilisent le plus souvent les LLM locaux
À moins d’avoir un matériel vraiment haut de gamme, ça semble difficile de rivaliser avec des modèles propriétaires comme Gemini ou Claude ; j’imagine que ces petits modèles restent utiles, mais je me demande quels sont les cas d’usage concrets
Il y a déjà la réticence à transmettre ses données à un tiers
Beaucoup de gens ne veulent pas envoyer leurs prompts ou leurs questions à l’extérieur
J’essaie d’abord un modèle local sur la plupart de mes prompts, et à ma surprise, j’obtiens dans plus de la moitié des cas un résultat largement suffisant
À chaque fois que je peux éviter un service cloud, ça me procure un vrai sentiment de satisfaction
À l’avenir, je pense que les LLM locaux évolueront vers des systèmes capables de décider rapidement quel type de tâche traiter et à quoi la déléguer rapidement
Par exemple, distinguer automatiquement ce qui peut être géré par un système local comme MCP, ce qui nécessite des appels à des API système comme le calendrier ou l’e-mail, et ce qu’il vaut mieux transmettre au modèle cloud le plus adapté
J’imagine quelque chose comme un Siri qui fonctionnerait vraiment correctement
En ce moment, j’expérimente avec un agent de code local que j’ai fabriqué moi-même à partir de Devstral
Ce que je préfère par rapport à Codex, c’est qu’il a un accès complet au matériel et peut donc lancer des VM, faire des requêtes réseau et d’autres choses que Codex ne peut pas faire
Il est aussi bien plus rapide que Codex, de la configuration initiale jusqu’à la génération de patchs
Bien sûr, il n’atteint pas encore le niveau de résultat de Codex, mais Devstral est déjà exploitable pour des petites modifications ou du refactoring, et j’espère qu’en faisant évoluer le logiciel il pourra progressivement gérer des changements de plus grande ampleur
Par principe, j’essaie autant que possible d’éviter le cloud
Par exemple, on a récemment appris qu’OpenAI travaillait même sur une sorte de réseau social basé sur le partage des conversations ChatGPT
Faire tourner les modèles en local permet aussi de mieux comprendre le fonctionnement interne de l’IA, ce qui augmente ma valeur sur le marché
Je peux aussi expérimenter librement avec des backends LLM pour la recherche web, les agents, etc., sans coût cloud, et j’avais déjà un PC gaming au moment de la sortie de LLaMa
Le projet LocalScore de Mozilla vaut aussi le détour
C’est un service qui compare et analyse l’efficacité de différents modèles sur divers matériels
Je suis d’accord avec la recommandation du subreddit LocalLLama
Ce n’est pas l’endroit qui choisira « le meilleur modèle » à votre place, mais c’est très utile pour poser des questions, trouver des guides, suivre l’actualité, découvrir des outils et comparer différents modèles
Au final, il faut quand même tester plusieurs modèles soi-même et ajuster les paramètres pour trouver celui qui correspond le mieux à ses usages
Si vous êtes un utilisateur de Hacker News, vous pouvez même envisager de passer votre chemin sur Ollama ou LMStudio
L’accès aux modèles les plus récents peut y être moins bon, et on est souvent limité aux modèles qu’ils ont eux-mêmes testés
Et puis on perd un peu le plaisir de « soulever le capot » pour voir comment tout fonctionne
llamacpp prend déjà en charge la plupart des modèles récents et est mis à jour rapidement si nécessaire
Je préfère récupérer les modèles sur huggingface et utiliser le format GGUF, qui permet d’économiser de la mémoire grâce à une quantization plus basse
En regardant la taille des fichiers GGUF, on se fait une idée approximative de leur compatibilité avec sa VRAM (par exemple : un GGUF de 24GB sera difficile sur 16GB, 12GB peut passer — mais si le context augmente, la RAM utilisée augmente aussi)
Il faut aussi faire attention à la context window ; beaucoup d’anciens modèles ont un contexte de 8K, et le fait de régler à 32K n’apporte pas forcément un gain important
llamacpp permet de télécharger des binaires ou de compiler soi-même sur Linux, Windows et macOS, et de répartir un modèle entre VRAM et RAM
Il fournit un frontend React simple (
llamacpp-server) ainsi qu’une API REST proche de celle d’OpenAICela permet de l’intégrer à différents frontends comme oobabooga (textgeneration webui)
Si llamacpp vous semble trop rustique, Koboldcpp peut être un backend à considérer (même s’il repose toujours en interne sur llamacpp)
L’intérêt d’Ollama, c’est qu’on peut récupérer directement n’importe quel GGUF depuis HuggingFace et le lancer comme ceci :
ollama run hf.co/unsloth/DeepSeek-R1-0528-GGUF:Q8_0L’un des avantages d’Ollama, c’est qu’il permet de charger et décharger facilement les modèles sur le GPU, ce qui facilite énormément le changement de modèle depuis un simple menu déroulant dans des frontends comme librechat ou openwebui
Je veux insister sur le confort de pouvoir changer de modèle sans passer par la ligne de commande
Ollama transforme le desktop en serveur LLM, accessible aussi depuis des appareils distants via le Wi‑Fi
Et quand on change de modèle, Ollama permet un swap fluide sans arrêter le serveur
Avec llama.cpp, en CLI, il faut arrêter le serveur, relancer avec de nouveaux flags, ce qui est peu pratique pour expérimenter ou développer rapidement des applis
J’ai même des applis où il est indispensable de pouvoir passer d’un modèle 1B à 8B ou 30B uniquement via un paramètre de requête web, sans redémarrer le serveur
Je n’ai que 8GB de VRAM, mais j’utilise OpenWebUI comme frontend d’Ollama pour charger plusieurs modèles en même temps et les tester en alternance selon un schéma round robin
Je surveille aussi en continu la qualité des réponses, ce qui me permet de choisir à long terme le modèle qui correspond le mieux à mes besoins
OpenWebUI offre une expérience d’usage assez unique
En tant qu’utilisateur d’une AMD 6700XT (12GB de VRAM), après avoir réussi ma configuration ROCm locale, j’ai pu faire tourner Ollama avec accélération GPU sans difficulté
Relier une instance OpenWebUI lancée via Docker à un serveur Ollama local se résume à définir une seule variable d’environnement
Ce n’est pas de la production mais un environnement de test personnel, et pour l’usage décrit plus haut ça fonctionne très bien
Il faut toutefois savoir qu’OpenWebUI, à la suite d’un récent changement de licence, n’est plus open source
La famille Qwen3 (et le distill R1 qwen3-8b) est numéro 1 pour le code et le raisonnement logique
En revanche, comme il s’agit de modèles chinois, la censure est forte sur les sujets politiques
Pour la culture générale et les informations récentes, je recommande Gemma3
Il y a de fortes chances que ce message soit déjà obsolète dans un mois, donc mieux vaut consulter les benchmarks les plus récents sur livebench.ai ou le leaderboard d’aider.chat
Non seulement les modèles, mais aussi les outils, routeurs, MCP, bibliothèques et SDK évoluent en permanence
Quand on développe seul et qu’on n’a ni collègues ni communauté proche avec qui partager l’information, on a besoin de conseils pour apprendre, suivre et rester à jour
La meilleure source d’information, c’est HuggingFace
La série Qwen est solide sur plusieurs plans, et je recommande le modèle Qwen/Qwen3-14B-GGUF Q4_K_M
Il n’utilise qu’environ 7 à 8GB de VRAM, donc la charge reste raisonnable, et je recommande d’utiliser llama-server ou LM Studio
Llama 3.3 est aussi une bonne option
Devstral est trop gros et n’est vraiment envisageable qu’en version quantifiée
Gemma refuse souvent, mais reste utile pour des objectifs précis comme Medgemma
Les modèles Dolphin « Uncensored » d’Eric Hartford ainsi que les modèles abliterated sont à recommander si vous avez besoin d’un modèle peu réticent, par exemple pour générer des blagues ou traiter des sujets de sécurité ou de défense (ce n’est pas indispensable pour un usage courant)
En
bf16 dtype, on peut estimer la taille d’un modèle non quantifié avec la formule nombre de paramètres x2Avec un modèle quantifié
Q4_K_M(4 bits), la VRAM requise est environ égale à la moitié du nombre de paramètresIl faut aussi prendre en compte les surcoûts comme les activations, donc mieux vaut commencer à expérimenter bien en dessous de 16GB
llama-serverpropose aussi une interface GUI et peut télécharger des modèles via l’option-hfLM Studio est également pratique pour l’installation et la gestion des modèles
Si vous voulez des réponses rapides, il faut lancer le serveur une seule fois et mutualiser le modèle pour plusieurs requêtes ; si vous rechargez le modèle à chaque question, ce sera lent
Avec 16GB, Mistral Small 3.1 en quantification Q4 ou Qwen3-14B en FP8 tournent correctement sans trop de difficultés
En revanche, selon la VRAM consommée, si vous voulez utiliser un long context, Qwen3-14B en Q4 offrira de moins bonnes performances que le FP8 mais laissera plus de marge mémoire
Mistral Small gère aussi l’entrée image, tandis que Qwen3 est plus spécialisé en maths et en code
Descendre sous Q4 est peu efficace, donc ce n’est pas recommandé
Si l’objectif est d’avoir un long context, mieux vaut se tourner vers Qwen3-8B en quantification Q4, et Qwen3-30B-A3 semble un peu trop juste pour 16GB de VRAM (les modèles lourds prennent plus de 15GB en GGUF)
Les modèles denses, qui utilisent tous leurs paramètres, sont plus performants par paramètre que les modèles sparse, mais plus lents ; avec un GPU de type 5060, un 14B reste tout à fait confortable
Sur architecture Blackwell, un modèle quantifié en NVFP4 sera plus rapide qu’en FP8, avec une qualité légèrement moindre, mais ce n’est pas encore pris en charge dans ollama, donc il faut passer par vLLM séparément
Les modèles NVFP4 préquantifiés sont encore peu pris en charge, donc il vaut mieux les quantifier soi-même avec des outils comme llmcompressor
Je recommande de n’utiliser ce genre d’outils qu’une fois le LLM souhaité choisi, quand on veut améliorer les performances
Il est presque impossible de donner une réponse objective, claire et définitive sur les LLM ; le plus important est vraiment d’essayer plusieurs modèles récents sur des tâches qui ont du sens pour soi
La qualité des résultats varie énormément selon le type de travail
Je me demande souvent comment les gens estiment l’usage de VRAM
C’est dommage que les informations téléchargeables sur les modèles, comme les fichiers gguf, n’indiquent pas clairement les besoins en VRAM ou en mémoire
Très grossièrement, on peut considérer que le nombre de paramètres (en milliards) correspond à des gigaoctets de mémoire
Exemples selon la quantification :
FP16 = 2 x 8GB = 16GB (modèle 8B)
Q8 = 1 x 8GB, Q4 = 0.5 x 8GB = 4GB
En pratique ce n’est pas exact au détail près, mais on reste dans le bon ordre de grandeur, et il faut ajouter séparément la mémoire supplémentaire pour la longueur de context, etc.
Le principe repose simplement sur le nombre de valeurs flottantes multiplié par le nombre de bits du type de données (4, 8, 16...)
Si vous voulez calculer cela plus précisément, notamment en incluant le cache KV au-delà de la seule quantification, je recommande ce calculateur de VRAM