Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Variantes et formats de fichiers des LLM open source : Instruct, GGUF, GPTQ, AWQ et MoE
Pourquoi les LLM open source ont-ils autant de noms déroutants ?
Vous avez probablement déjà vu des noms comme Llama-3.1-8B-Instruct.Q4_K_M.gguf ou Mistral-7B-v0.3-A3B.awq et vous vous êtes demandé à quoi servent ces suffixes. Ils semblent bruyants, mais ils indiquent en réalité deux choses différentes à la fois.
Les LLM open source varient selon deux dimensions indépendantes :
- Variante de modèle : le suffixe dans le nom (
-Instruct,-Distill,-A3B) décrit comment le modèle a été entraîné et pour quoi il est optimisé. - Format de fichier : l’extension (
.gguf,.gptq,.awq) décrit comment les poids sont stockés et où ils s’exécutent le mieux (CPU, GPU, mobile).
La variante décide de ce que le modèle peut faire. Le format décide où il peut tourner efficacement.
Si vous confondez les deux, vous passerez une soirée à traquer des erreurs CUDA sur un modèle qui n’allait de toute façon jamais tenir sur votre carte.
Explication des variantes de modèle (la recette)
La variante indique quel type d’entraînement les poids ont subi.
Modèles de base
Le modèle pré-entraîné brut. Il a appris des motifs linguistiques à partir d’énormes corpus de texte, mais on ne lui a jamais appris à suivre des instructions ; tout ce qu’il fait, c’est prédire le token suivant.
Vous l’utiliserez si vous prévoyez de le fine-tuner sur vos propres données, si vous faites de la recherche et voulez une fondation « pure », ou si vous voulez spécifiquement un modèle sans entraînement d’alignement.
Le compromis, c’est qu’il ne suivra pas les instructions de façon fiable. Demandez-lui « Quelle est la capitale de la France ? » et il pourrait répondre « et quelle est la capitale de l’Allemagne ? » parce que, de son point de vue, vous avez commencé une liste de questions.
Modèles Instruct / Chat
Un modèle de base ayant suivi un entraînement supplémentaire (Supervised Fine-Tuning plus RLHF) pour savoir suivre des instructions humaines. C’est ce que la plupart des gens veulent réellement quand ils disent qu’ils « veulent un LLM ».
C’est le bon choix pour les chatbots, les agents et le RAG. Idem pour le function calling, l’utilisation d’outils et l’aide au code au quotidien. Environ 95 % des cas d’usage en production tombent ici.
Le coût, c’est qu’il est un peu plus gros et plus lent que le modèle de base à cause de l’entraînement supplémentaire, et l’alignement peut le rendre moins « créatif » parce qu’il a été poussé à être prévisible et utile.
Modèles de raisonnement / CoT
Une génération plus récente comme DeepSeek-R1 ou les dérivés de o1, entraînés avec du reinforcement learning sur la Chain-of-Thought. Ils « réfléchissent » avant de répondre : ils génèrent des tokens de raisonnement internes pour traiter une logique complexe, des maths ou des problèmes de code avant de produire la réponse finale.
Ils excellent sur les tâches de code difficiles, le debugging, les problèmes mathématiques et les puzzles logiques. Ils ont aussi tendance à moins halluciner parce qu’ils revérifient leur propre travail.
Le revers, c’est la latence. Ils produisent un long flux de tokens de « pensée » que vous ne voyez peut-être même pas, mais que vous devez quand même attendre. Ils peuvent aussi être inutilement verbeux pour des prompts triviaux.
Modèles distillés
Un petit modèle « étudiant » entraîné à imiter un grand modèle « enseignant ». Le résultat est une connaissance compressée : typiquement 70 à 80 % de la qualité d’origine pour 30 à 50 % de la taille.
Ils conviennent bien aux appareils mobiles ou edge, aux SaaS sensibles aux coûts où chaque milliseconde compte, et aux services qui doivent servir beaucoup de requêtes.
Vous perdez un peu en capacité de raisonnement complexe, mais le gain d’efficacité est difficile à ignorer.
MoE (Mixture-of-Experts) : A3B, A22B, etc.
Une architecture dans laquelle le modèle possède de nombreux sous-réseaux « experts », mais n’en active qu’un sous-ensemble pour chaque token. « A3B » signifie que 3B paramètres sont actifs par token, même si le modèle total peut dépasser 30B.
C’est utile si vous voulez l’intelligence d’un gros modèle sur une carte avec 12 à 24 Go de VRAM sans payer le coût complet d’inférence, ou si vous exécutez le modèle en local et voulez le meilleur ratio qualité/mémoire.
Les inconvénients : plus volumineux sur disque (il faut quand même stocker tous les experts), et tous les frameworks d’inférence ne prennent pas encore en charge le routage MoE. Vérifiez la compatibilité avant de vous engager dans un téléchargement de 50 Go.
Règle générale :
- Par défaut, prenez un modèle Instruct. C’est ce dont la plupart des gens ont besoin.
- Vous atteignez les limites de mémoire ou de latence ? Essayez une variante Distilled ou MoE.
- Vous résolvez une logique réellement difficile ? Essayez un modèle Reasoning.
Explication des formats de fichiers (le conteneur)
Une fois que vous savez quel modèle vous voulez, il faut choisir comment il est empaqueté. Le format détermine surtout où il peut tourner et de combien de mémoire il a besoin.
Quantization 101 : pourquoi on réduit les modèles
Les modèles standards utilisent des nombres sur 16 bits (FP16) pour chaque poids. Précis, mais lourds. La quantification ramène les poids à 8 bits, 4 bits, voire 2 bits.
- FP16 : 2 octets par paramètre. Un modèle 13B fait ~26 Go.
- 4-bit : 0,5 octet par paramètre. Un modèle 13B fait ~6,5 Go.
Vous abandonnez une petite part d’« intelligence » et récupérez beaucoup de vitesse et de mémoire.
GGUF (.gguf)
Le successeur de GGML, et le standard de facto pour l’inférence locale aujourd’hui. Un seul fichier contient les poids, les métadonnées, et même le prompt template.
C’est le bon choix sur Apple Silicon (M1-M4), où il tourne nativement avec accélération Metal, et sur les machines sans GPU dédié. L’écosystème d’outils est aussi le meilleur de tous les formats : llama.cpp, Ollama et LM Studio consomment tous directement du GGUF.
Un seul fichier, exécutable presque partout, avec un niveau de quantification pour chaque budget mémoire.
Décoder les noms GGUF (Q3_K_M, Q5_K_M, etc.)
Vous verrez souvent une longue liste de fichiers comme Q3_K_M, Q4_K_S, Q5_K_M. Ils ne sont pas aléatoires ; ils appartiennent à la famille K-quant.
Pour lire Q3_K_M :
Q3: quantification moyenne en 3 bits pour les poids.K: utilise le schéma K-quant (une méthode plus récente qui utilise une précision non uniforme).M: taille de bloc moyenne, oùSest petit etLest grand.
Lequel choisir :
Q3_K_M: l’option économique. La qualité baisse nettement, mais cela permet d’exécuter des modèles plus grands sur du matériel plus modeste.Q4_K_M: le standard. Meilleur équilibre entre vitesse, taille et perplexité. Pour la plupart des tâches, il est difficile de le distinguer des poids non compressés.Q5_K_M: le choix premium. Utilisez-le si vous avez de la VRAM à revendre ; la qualité est très proche du FP16 / Q8 tout en restant relativement compact.
Astuce : il vaut souvent mieux exécuter un plus grand modèle avec une quantification plus basse (Llama-70B en Q3) qu’un plus petit modèle avec une quantification élevée (Llama-8B en Q8). Le nombre de paramètres apporte généralement plus d’intelligence que la précision.
GPTQ (.safetensors + config.json)
Une quantification post-entraînement pensée pour les GPU Nvidia. Elle utilise des informations de second ordre pour limiter la perte de précision lors de la compression des poids.
C’est le bon format pour les serveurs de production exécutant CUDA sur Linux, et pour les configurations à haut débit en 4 bits. Avec le loader ExLlamaV2, c’est très rapide.
Le problème, c’est l’exigence matérielle : il faut un GPU, et cela ne tourne pas efficacement sur CPU ni sur Mac.
AWQ (.safetensors)
Activation-Aware Weight Quantization. Elle regarde quels poids comptent le plus pendant l’inférence et préserve leur précision, au lieu de compresser uniformément chaque poids.
Elle tend à rester plus proche de la précision FP16 que GPTQ à budget 4 bits égal, et elle est prise en charge nativement par vLLM. Si vous voulez extraire un maximum de qualité d’un modèle 4 bits, AWQ est généralement le gagnant.
PyTorch / Safetensors (FP16/BF16)
Des poids en pleine précision, sans quantification. C’est le format d’origine dans lequel les modèles sont publiés.
C’est ce qu’il vous faut pour l’inférence cloud sur des GPU sérieux (A100, H100), pour le fine-tuning et la poursuite d’entraînement, et pour les cas où la précision compte plus que la mémoire.
Le coût est évident : un modèle 70B en FP16 demande environ 140 Go de VRAM.
Conseil : en cas de doute, commencez avec GGUF Q4_K_M. Il tourne sur des GPU de 8 Go, des CPU modernes, et presque tout ce qu’il y a entre les deux. Vous pourrez toujours optimiser une fois le goulot d’étranglement identifié.
Comment exécuter concrètement tout ça (moteurs de serving)
Vous avez besoin d’un moteur de serving pour charger le modèle et répondre aux requêtes.
- Ollama consomme du GGUF et tourne sur Mac, Linux et Windows. C’est l’outil CLI le plus simple pour le développement local ;
ollama run llama3et c’est terminé. - LM Studio utilise aussi GGUF et fournit une GUI soignée sur Mac et Windows. Bien pour parcourir visuellement les modèles avant de vous engager sur l’un d’eux.
- vLLM est le standard de production. Il charge AWQ, GPTQ et des safetensors FP16, et il est conçu pour les serveurs haute performance et les déploiements Docker. Le support de GGUF reste encore inégal.
- llama.cpp est le moteur sous-jacent à Ollama. Utilisez-le directement quand vous avez besoin d’une intégration bas niveau, ou quand la cible est petite (Raspberry Pi, Android, embarqué).
Assembler le tout : un cadre de décision
Un flowchart pratique à suivre. Commencez par vos contraintes (matériel et cas d’usage), puis choisissez la variante et le format adaptés.
Recommandations rapides par scénario
Vous construisez un chatbot sur un MacBook Pro (16 Go de RAM). Utilisez un modèle Instruct comme Llama-3-8B ou Mistral-7B en GGUF Q4_K_M. Il tourne de façon fluide sur CPU et Metal, tient en mémoire, et vous n’avez qu’un seul fichier à gérer.
Système RAG sur un serveur avec une RTX 4090 (24 Go de VRAM). Utilisez Instruct ou MoE (Mixtral 8x7B, Qwen-14B) en EXL2 (via ExLlamaV2) ou AWQ 4-bit. C’est ainsi que vous tirez une vraie valeur de 24 Go ; EXL2 est très rapide sur les cartes Nvidia.
Fine-tuning pour un usage métier spécifique sur un GPU cloud. Utilisez un modèle Base en safetensors FP16. Vous voulez la pleine précision pour l’entraînement, et partir de la base non alignée évite de lutter contre l’alignement pendant le fine-tuning.
API à haut débit avec contraintes de coût. Utilisez un modèle Distilled (DeepSeek-Distill ou similaire) en AWQ 4-bit sur vLLM. Le débit par dollar est difficile à battre.
Pièges et idées reçues courants
« Tous les modèles 4-bit ont la même qualité »
Non. Un modèle QAT 4-bit (entraîné en 4 bits) bat souvent un modèle 8-bit quantifié post-entraînement. La méthode compte autant que le nombre de bits, et AWQ préserve généralement mieux la précision qu’un GPTQ naïf.
« Les modèles MoE fonctionnent avec n’importe quel moteur d’inférence »
Pas encore. llama.cpp gère bien le routage MoE, mais le support varie selon les autres moteurs. Vérifiez toujours avant de télécharger un modèle MoE de 50 Go.
« Les modèles distillés ne sont que des versions plus petites de la même chose »
C’est le point que la plupart des gens ratent. Un 7B distillé peut battre un 13B vanilla parce qu’il a appris d’un enseignant bien plus grand (souvent 70B+). C’est de la connaissance compressée, pas seulement des paramètres compressés.
« Je devrais quantifier davantage mon modèle QAT pour gagner de la place »
Ne vous embêtez pas. Les modèles QAT ont déjà été entraînés en basse précision. Les requantifier par-dessus dégrade généralement fortement la qualité. Utilisez-les tels qu’ils sont publiés.
« Plus gros est toujours mieux »
Souvent, mais pas toujours. Un modèle Instruct 8B bien réglé peut surpasser un modèle Base 70B mal aligné sur une tâche précise. Faites correspondre la variante au cas d’usage avant de partir à la chasse aux paramètres.
TL;DR - dites-moi juste quoi télécharger
Si vous voulez juste quelque chose qui fonctionne :
- Téléchargez un fichier
<model-name>-Instruct.Q4_K_M.ggufdepuis Hugging Face.- Exécutez-le avec Ollama ou LM Studio.
- Si c’est trop lent, essayez un plus petit modèle ou une variante Distilled.
- Si vous manquez de mémoire, descendez à une quantification Q3_K_M.
- Si la qualité n’est pas suffisante, passez à Q5_K_M ou choisissez un modèle plus grand.
Commencez simple et optimisez quand vous en avez réellement besoin. Les réglages par défaut fonctionnent dans ~90 % des cas.