2025-05-11 · Mis à jour 2026-07-15

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

Variantes à poids ouvert LLM, quantification et formats : Instruct, MoE, GGUF, GPTQ et AWQ

Des noms tels que Model-32B-A3B-Instruct-AWQ Il semble dense car il intègre plusieurs décisions indépendantes : la famille et la taille, l’architecture, le rôle d’entraînement, ainsi que la quantification. Un répertoire peut regrouper ces poids sous forme de Safetensors fragmentés, tandis qu’une conversion communautaire du même checkpoint apparaît comme Q4_K_M.gguf.

Ces étiquettes ne relèvent pas de la même catégorie : GPTQ et AWQ sont des méthodes de quantification, GGUF correspond à un conteneur ainsi qu’à un runtime d’écosystème, tandis que MoE désigne une architecture. En examinant les différentes couches séparément, il devient bien plus simple de choisir la version à télécharger.

En résumé. Il convient de choisir un checkpoint en fonction de la qualité de la tâche, de la licence, de la langue, du contexte et du comportement de l’interface. Ensuite, il faut sélectionner un runtime compatible avec son architecture. Ce n’est qu’après cela que l’on peut opter pour une représentation des poids ainsi qu’une quantification adaptées aux contraintes de mémoire et de latence mesurées. Les GPTQ et AWQ correspondent à des méthodes de quantification, tandis que Safetensors et GGUF sont des conteneurs ; enfin, MoE désigne une architecture – et non une garantie que tous les poids pourront tenir dans la mémoire dédiée aux « paramètres actifs ».

Lire un artefact de modèle en six couches

Ces couches ne sont pas mutuellement exclusives. Un checkpoint peut être distillé, ajusté par des instructions, ajusté pour le raisonnement, et MoE en même temps.

Le concept de « logiciel open source » mérite également une attention particulière. De nombreux modèles téléchargeables sont en réalité de type open-weight, sous des licences qui ne respectent pas la définition officielle d’open source ou qui imposent des restrictions d’utilisation. Il est donc indispensable de lire attentivement la fiche du modèle ainsi que sa licence avant de procéder à toute conception architecturale ou à des comparaisons avec benchmark.

Les étiquettes de rôle d’entraînement décrivent le comportement, et non des garanties de capacités

Base

Une base checkpoint est entraînée principalement pour la prédiction du token suivant. Elle est utile pour un préentraînement continu, des recherches contrôlées, ou encore pour une adaptation où l’on souhaite maîtriser le comportement d’exécution des instructions. Elle peut parfois effectuer un prompt au lieu de y répondre.

Il n’est pas nécessaire de supposer que chaque fine-tuning doive partir de la version de base. Une instruction checkpoint constitue souvent une meilleure initialisation, lorsque son comportement actuel est compatible avec les exigences cibles et que vos évaluations confirment qu’elle ne contredit pas le nouvel objectif à atteindre.

Instruction ou conversation

Ces checkpoints reçoivent des traitements post‑entraînement destinés à améliorer le suivi d’instructions et la capacité de conversation. La recette exacte peut inclure du fine-tuning supervisé, une optimisation des préférences, un apprentissage par renforcement, de la distillation, ou encore des combinaisons de ces méthodes — et pas nécessairement un SFT classique associé à un RLHF.

Utilisez une instruction checkpoint comme référence de base pour le premier assistant. Vérifiez son modèle de conversation, le format des appels d’outils pris en charge, le comportement des messages système ainsi que les caractéristiques de refus. L’instruction seule ne garantit pas un JSON ni un tool use fiables.

Ajusté pour le raisonnement

Les agents orientés vers le raisonnement checkpoints sont optimisés pour des tâches ou des trajectoires qui récompensent la résolution de problèmes en plusieurs étapes. Certains affichent le texte du raisonnement, d’autres le séparent à l’aide d’un analyseur serving, tandis que d’autres ne présentent qu’une réponse finale. Une génération plus longue ne garantit ni un raisonnement fiable ni une réduction des hallucinations.

Il convient d’en adopter un lorsque cela améliore les résultats critiques, une fois pris en compte le nombre de tokens de sortie, la latence et la vérification. L’extraction ou la classification routinières peuvent ralentir sans pour autant devenir plus efficaces.

Distillé

La distillation permet de transférer le comportement d’un modèle « enseignant » ou de données générées par celui‑ci vers un autre modèle. Le modèle « élève » peut être plus petit, de taille équivalente ou présenter une structure différente. Il n’existe pas de règle fixe selon laquelle « 70–80 % de la qualité pour la moitié de la taille » serait toujours valable : la qualité conservée dépend du modèle enseignant, des données, de l’objectif visé, des capacités du modèle élève ainsi que de la méthode d’évaluation utilisée.

Traiter Distill En tant que provenance relative à l’entraînement, benchmark est traité de la même manière que n’importe quel autre checkpoint.

Les étiquettes d’architecture décrivent l’exécution

Modèles densifs

La plupart des paramètres interviennent lors du passage en avant de chaque token. Le nombre de paramètres constitue un indicateur approximatif de l’espace de stockage nécessaire pour les poids, mais la mémoire runtime comprend également les KV cache, c’est‑à‑dire les activations ou l’espace de travail, les surcoûts liés à l’allocation mémoire, ainsi que parfois des états dupliqués ou fragmentés.

Mélange d’experts

Une couche MoE dirige chaque token vers un sous-ensemble de réseaux feed-forward experts. Des noms tels que A3B Cela signifie généralement qu’environ trois milliards de paramètres sont actifs par token, mais les conventions de nommage varient selon la famille de modèles. Consultez la fiche du modèle pour obtenir le nombre total de paramètres, le nombre de paramètres actifs, le comptage des experts, ainsi que les détails concernant la conception du routage.

Les paramètres actifs décrivent principalement les opérations de calcul. À moins que runtime ne transfère le traitement aux experts, tous les poids associés à ces derniers nécessitent encore un espace de stockage, généralement dans la mémoire du dispositif, au sein de la topologie serving. Un modèle totalisant 30 milliards de paramètres dont 3 milliards sont actifs ne s’adapte pas automatiquement de la même manière qu’un modèle dense de 3 milliards de paramètres.

Le support de Runtime dépend également de l’architecture choisie. Vérifiez avant le téléchargement la mise en œuvre du modèle, le type de parallélisme pris en charge – soit expert, soit tensoriel –, les noyaux de quantification, ainsi que la longueur maximale du contexte.

Les conteneurs et la quantification correspondent à des couches distinctes

Safetensors

Safetensors est un format de sérialisation de tenseurs sécurisé fréquemment utilisé dans les répertoires Hugging Face. Un modèle peut comporter plusieurs .safetensors des shards ainsi que des fichiers de configuration, de tokenisation et de génération. Ces tenseurs peuvent être BF16/FP16 ou pré-quantifiés à l’aide de méthodes telles que GPTQ ou AWQ.

La simple extension ne vous indique ni la précision ni la compatibilité avec runtime. Il convient de l’inspecter. config.jsonla configuration de quantification, la fiche modèle, le type de données du tenseur, ainsi que la documentation runtime.

GGUF

GGUF Empaquetage des tenseurs ainsi que des métadonnées destinés à l’écosystème ggml/llama.cpp. llama.cpp Il nécessite GGUF et prend en charge des backends tels que Metal, CUDA, HIP, Vulkan ainsi que des chemins CPU. L’architecture du modèle et la qualité de la conversion restent les facteurs déterminants de la compatibilité.

GGUF représente un conteneur. Il est capable de stocker des tenseurs à haute précision ou quantifiés. Les modèles multimodaux peuvent également nécessiter un projeteur ou un fichier d’encodage distinct ; l’idée selon laquelle « un seul fichier GGUF contient tout » s’applique pas systématiquement.

GPTQ et AWQ

GPTQ et AWQ sont des méthodes de quantification des poids après entraînement, et non des extensions de fichiers. Leurs artefacts font généralement appel à Safetensors ainsi qu’à une configuration spécifique à la méthode. Les moteurs Serving nécessitent des noyaux compatibles avec la méthode choisie, la largeur en bits, la taille du groupe, l’architecture du modèle et le matériel utilisé.

Aucune de ces méthodes ne constitue systématiquement la solution optimale en termes de qualité. Les données de calibration, la mise en œuvre, le chemin du noyau ainsi que la nature de la tâche jouent un rôle crucial. Les transformateurs courants, TGI et vLLM, prennent en charge plusieurs backends de quantification, mais leurs matrices évoluent ; il convient donc de vérifier les valeurs fixées de runtime plutôt que de se fier à des tableaux statiques publiés sur des blogs.

Les calculs de quantification représentent une borne inférieure, et non une planification de capacité

Pour les paramètres de poids (P) à (b) bits, le stockage brut des poids est d’environ :

[ \text{octets de poids} \approx \frac{P \times b}{8} ]

Un modèle de 13 milliards de paramètres avec des poids nominaux de quatre bits commence donc autour de 6,5 Go. Il n’est pas nécessaire que son exécution consomme précisément 6,5 Go. Les échelles, les points zéro, les tenseurs à plus haute précision, embeddings, les métadonnées, les buffers runtime, KV cache, ainsi que la fragmentation augmentent la consommation mémoire.

Le contexte et la concurrence peuvent déterminer fondamentalement la différence entre les « charges » et les « services ». Mesurez la mémoire maximale en tenant compte de la séquence réelle, de la politique de lot, du type de données du cache ainsi que du niveau de parallélisme.

La quantification peut réduire la consommation mémoire et améliorer parfois la vitesse, mais les noyaux à faible nombre de bits peuvent également être plus lents sur du matériel non pris en charge. Il convient de comparer la qualité de la tâche ainsi que le débit bout en bout, et non uniquement la taille du fichier.

Décoder avec soin les noms de quantification GGUF

In Q4_K_M:

• Q4 indique une famille de quantification à quatre bits, mais ce n’est pas systématiquement quatre bits par tenseur. K identifie le schéma K-quant. M Il permet d’identifier une recette mixte qui emploie des types de tenseurs différents pour les poids sélectionnés. Cela ne signifie pas « taille de bloc moyenne ».

Le courant llama.cpp La documentation sur la quantification indique que les recettes peuvent varier en fonction de l’architecture et de la catégorie des tenseurs. Une matrice d’importance peut également aider à déterminer quels poids doivent conserver davantage de précision.

Évitez les affirmations universelles qui Q4_K_M il n’est pas possible de faire la distinction entre BF16 et un modèle de taille supérieure dans la catégorie Q3 qui surpassera toujours un modèle de taille inférieure dans la catégorie Q8. Il convient d’utiliser une échelle de petite échelle pour les valeurs exactes de checkpoint :

1. artefact de référence à haute précision ou fiable
2. un candidat proche de la limite de mémoire
3. un candidat plus petit disposant d’une marge de manœuvre plus importante

Exécutez les mêmes vérifications de sortie structurée prompts, les cas à contexte long et les tests de latence sur les trois systèmes.

Un flux de sélection capable de gérer de nouveaux formats

1. Corriger le contrat de tâche

Définissez le langage, la modalité, la longueur de contexte, l’interface outil ou schéma, les contraintes de sécurité, les exigences de licence ainsi que les tronçons d’évaluation. Comparez checkpoints dans une représentation suffisamment précise pour éviter que la quantification ne dicte le résultat de la première étape.

2. Sélectionnez le checkpoint

Sélectionnez le plus petit checkpoint capable de respecter les exigences impératives en matière de qualité et de comportement. Notez précisément le répertoire et la version concernés, ainsi que le tokeniseur, le modèle de conversation et tout analyseur de raisonnement requis.

3. Sélectionnez le runtime

Vérifiez le soutien de l’architecture, le matériel backend, le parallélisme, les noyaux de quantification, structured output, les adaptateurs ainsi que l’interface opérationnelle. Cela concerne l’inference locale GGUF. llama.cpp Il s’agit de la référence runtime. Pour GPU serving, comparez les valeurs actuelles de vLLM, TGI, des Transformers ou des moteurs spécialisés avec l’artefact réel.

4. Définir un budget mémoire mesuré

Il convient d’inclure les poids, l’espace de travail KV cache et runtime, la concurrence attendue, ainsi que la marge disponible pour le système d’exploitation ou les processus hébergés sur le même matériel. Un fichier qui tient dans la RAM ou VRAM est nécessaire, mais ce n’est pas suffisant.

5. Sélectionner et valider une représentation

Préférez les artefacts fournis par le fabricant, qui disposent d’une calibration documentée ainsi que d’une traçabilité fiable. Lorsque vous utilisez une conversion issue de la communauté, enregistrez la version source, la version du convertisseur, les paramètres de quantification, les données de calibration ou d’importance, ainsi que les hachages correspondants.

6. Benchmark l’unité de déploiement

Évaluer la qualité de la tâche, la correction du schéma ainsi que des appels d’outils, le temps nécessaire pour générer le premier token, le débit de sortie, la mémoire maximale utilisée, ainsi que le nombre d’échecs dans le contexte et la concurrence ciblés. Réexécuter l’opération après toute modification de checkpoint, runtime, du noyau, ou des paramètres de quantification.

Nom fonctionnel

Supposons qu’un répertoire soit nommé :

Acme-32B-A3B-Instruct-AWQ

Lisez-le comme un ensemble de questions :

• Acme: quelle famille, licence et révision ? 32B: poids totaux ou une autre convention de l’éditeur ? A3B: comment cette famille définit-elle les paramètres actifs ? Instruct: Quelle recette de post‑entraînement et quel modèle de dialogue ? AWQ: Quelle largeur de bit, quelle taille de groupe, quelle calibration, et quels noyaux sont pris en charge ?
• Fichiers du répertoire : fragments Safetensors, fichiers de configuration, tokenizer, et code personnalisé ?
• Cible runtime : la version fixée prend-elle en charge cette architecture et cette quantification précises ?

Ce nom constitue un index vers la documentation, et non une spécification complète de déploiement.

Conclusion

Le choix du modèle devient moins déroutant dès que les étiquettes ne se retrouvent plus dans le même groupe. Le rôle d’entraînement indique quel comportement a été optimisé. L’architecture précise comment les calculs sont organisés. La quantification explique comment certains tenseurs ont été approximés. Les conteneurs indiquent comment les artefacts sont stockés. Les environnements d’exécution déterminent ce qui s’exécute de manière efficace sur votre matériel.

Choisissez dans cet ordre, en préservant l’origine exacte, et permettez à une évaluation de tâche de comparer les artefacts de déploiement. Un suffixe familier n’est pas une preuve que le modèle convient, s’exécute rapidement, ou conserve le comportement souhaité.

Références

• spécification GGUF et llama.cpp guide de quantification
• Hugging Face Concepts de quantification des Transformers
• le document théorique GPTQ
• le document théorique AWQ
• vLLM documentation sur la quantification