Guide des modèles

Modèles Local LLM expliqués : tailles, formats et compromis

Un guide pratique des familles de modèles Local LLM, du nombre de paramètres, des fichiers GGUF, des niveaux de quantization, de la longueur de contexte et du choix d’un modèle adapté à votre hardware.

Commencez par la famille de modèles, puis vérifiez le fichier exécutable

Un Local LLM n’est pas seulement un nom de marque comme Qwen, Llama, Mistral, Gemma, DeepSeek, Phi ou Yi. Le nom désigne généralement une famille de modèles, tandis que le fichier que vous exécutez réellement peut être une version instruct, une version optimisée pour le code, une variante vision, une conversion GGUF ou un build quantized réalisé par un éditeur communautaire. Deux fichiers de la même famille de modèles peuvent se comporter différemment, car ils peuvent utiliser des prompt templates, des longueurs de contexte, des méthodes de quantization et des hypothèses d’exécution différentes.

Pour un outil de recommandation, la question utile n’est pas seulement « ce modèle est-il populaire ? ». La meilleure question est « quelle variante exécutable correspond à la mémoire, aux attentes de vitesse et à la tâche de cet utilisateur ? ». Hugging Face peut afficher de nombreux fichiers pour un même modèle, et les outils locaux peuvent n’en exposer que certains. Local LLM doit donc traiter l’identité du modèle, le format de fichier, la quantization et l’adéquation au hardware comme des signaux distincts au lieu de tout réduire à un seul nom de modèle.

Le nombre de paramètres est un signal approximatif de qualité, pas une réponse complète

Le nombre de paramètres donne une idée rapide de l’échelle. Un modèle 1B ou 3B est plus facile à exécuter et peut être utile pour du chat léger, de la réécriture, de la synthèse et de l’explication simple de code. Un modèle 7B ou 8B est souvent le point d’entrée pratique pour des réponses quotidiennes plus solides. Un modèle 14B nécessite généralement plus de mémoire, mais peut sembler plus capable. Les modèles 30B, 70B et plus grands peuvent être bien meilleurs pour le raisonnement difficile ou le codage, mais ils entrent dans le domaine de la VRAM élevée, de la grande mémoire unifiée ou du multi-GPU.

La limite est que le nombre de paramètres ne dit pas tout. Un modèle 7B récent peut surpasser un ancien modèle 13B dans de nombreuses tâches. Un modèle 7B optimisé pour le code peut être plus utile au développement qu’un modèle de chat général plus grand. Les modèles MoE ajoutent une complication supplémentaire, car les paramètres totaux et les paramètres actifs sont différents. C’est pourquoi les recommandations doivent combiner qualité de benchmark, cas d’usage, paramètres actifs, besoins de contexte et adéquation mémoire, plutôt que de simplement classer le plus grand modèle en premier.

GGUF, safetensors et le support des outils déterminent ce que vous pouvez vraiment exécuter

De nombreux utilisateurs desktop locaux recherchent des fichiers GGUF, car ils fonctionnent bien avec les outils basés sur llama.cpp et sont largement disponibles sur Hugging Face. GGUF regroupe les poids du modèle et les métadonnées dans un format conçu pour l’inférence locale, et Hugging Face permet de parcourir et d’héberger des fichiers GGUF. D’autres dépôts publient des poids safetensors, qui peuvent être destinés à Transformers, vLLM ou à une conversion avant une utilisation locale sur desktop. Les deux peuvent être légitimes, mais ils servent des workflows différents.

C’est important pour les utilisateurs, car une page de modèle peut sembler attractive tout en restant peu pratique à exécuter localement. Ollama, LM Studio, llama.cpp, MLX, Transformers et vLLM n’exposent pas exactement le même chemin de chargement des modèles. Un bon résultat de recommandation doit renvoyer vers la page source, indiquer si le modèle dispose d’un fichier adapté à l’usage local et éviter de laisser entendre que tous les dépôts Hugging Face sont aussi faciles à exécuter sur un ordinateur portable.

La quantization modifie l’utilisation mémoire et la qualité

La quantization réduit la précision des poids du modèle afin que le fichier soit plus petit et plus facile à charger. Q8 est proche d’une haute qualité, mais utilise plus de mémoire. Q6 et Q5 offrent souvent un bon compromis. Q4 est le point d’entrée courant pour faire tenir des modèles plus grands sur du hardware grand public. Q3 et les niveaux inférieurs peuvent être utiles dans les situations de mémoire très limitée, mais le compromis de qualité devient plus visible, surtout pour le codage, les mathématiques, l’utilisation d’outils et les réponses longues.

La bonne quantization dépend à la fois du modèle et de la tâche. Si l’utilisateur demande un chat rapide et informel, Q4 peut être acceptable. S’il demande du codage ou un raisonnement précis, Q5, Q6 ou Q8 peuvent valoir la mémoire supplémentaire. S’il demande un long contexte, le plus petit fichier de modèle ne suffit pas ; le système a encore besoin de mémoire pour le KV cache et l’overhead d’exécution. Local LLM doit afficher la quantization sélectionnée et la répartition mémoire afin que les utilisateurs comprennent pourquoi une recommandation convient.

La longueur de contexte, la vision et les optimisations spécialisées changent la recommandation

La longueur de contexte dépend du modèle, mais le contexte utilisable dépend du hardware. Un modèle peut annoncer une grande fenêtre de contexte, pourtant le KV cache augmente à mesure que la conversation ou le document s’allonge. Cette mémoire supplémentaire peut faire passer un modèle d’une exécution complète sur GPU à un offload partiel sur CPU. Pour le RAG, l’analyse de codebase ou la lecture de longs documents, un modèle plus petit avec davantage de marge mémoire peut être meilleur qu’un modèle plus grand qui se charge à peine.

Les capacités spécialisées comptent également. Les modèles vision ont besoin d’encodeurs d’images et d’un support multimodal ; un modèle texte seul ne doit donc pas être recommandé pour des tâches d’image, même s’il obtient un score général élevé. Les modèles de codage doivent être évalués différemment des modèles de roleplay. Les modèles de mathématiques et de raisonnement peuvent nécessiter des seuils de qualité plus stricts. Le meilleur modèle local est donc une correspondance entre capacité du modèle, variante de fichier, quantization, objectif de contexte et hardware de l’utilisateur.

FAQ

Les modèles GGUF sont-ils toujours meilleurs pour les Local LLMs ? Pas toujours. GGUF est très pratique pour l’inférence locale de style llama.cpp, mais safetensors ou d’autres formats peuvent être meilleurs pour les workflows serveur, l’entraînement ou des runtimes spécialisés.

Dois-je choisir le plus grand modèle qui tient en mémoire ? Pas automatiquement. S’il tient à peine, la vitesse et la stabilité du contexte peuvent être mauvaises. Un modèle légèrement plus petit en Q5 ou Q6, avec suffisamment de marge mémoire, peut être plus agréable au quotidien.

Pourquoi différents outils recommandent-ils différents modèles ? Ils peuvent prendre en charge des formats, des niveaux de quantization, des backends GPU, des paramètres de contexte par défaut et des catalogues de modèles différents. Le support des outils fait partie de la recommandation.

Comment utiliser Local LLM après avoir lu ceci ? Saisissez votre VRAM, votre RAM, votre système d’exploitation, votre cas d’usage et vos préférences. L’outil peut alors classer les variantes de modèles actuelles au lieu de vous obliger à mémoriser des noms de modèles.

Retour à l’outil de recommandation Local LLM