Variantes, formats et quantification des LLMs à poids ouverts

Viacheslav Dubrov

2025-05-11 · Mis à jour 2026-08-16 · 12 min · Ingénierie des modèles

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

Des noms tels que Model-32B-A3B-Instruct-AWQ paraissent complexes, car ils combinent plusieurs décisions indépendantes : famille et taille, architecture, rôle d’entraînement et quantification. Un dépôt peut fournir ces poids sous forme de shards Safetensors, tandis qu’une conversion communautaire du même checkpoint peut apparaître sous la forme de Q4_K_M.gguf.

Ces labels ne relèvent pas tous de la même catégorie : GPTQ et AWQ sont des méthodes de quantification, GGUF est un conteneur et un écosystème de runtime, et MoE est une architecture. En séparant ces niveaux, le choix du téléchargement devient plus simple.

Pour choisir entre un téléchargement Q4_K_M.gguf destiné à l’inférence locale et un dépôt Safetensors AWQ destiné au serving sur GPU, commencez par le comportement du checkpoint et l’architecture requis par votre tâche. Vérifiez ensuite que sa représentation numérique, la structure du package et le runtime cible sont compatibles avec le matériel, la mémoire et les contraintes de serving disponibles.

En bref. Sélectionnez d’abord un checkpoint selon la qualité sur la tâche, la licence, la langue, le contexte et le comportement de l’interface. Choisissez ensuite un runtime prenant en charge son architecture. Ce n’est qu’après qu’il faut choisir une représentation des poids et une quantification adaptées à la mémoire et à la latence mesurées. GPTQ et AWQ sont des méthodes de quantification, Safetensors et GGUF sont des conteneurs, et MoE est une architecture. Un label MoE ne garantit pas que tous les poids tiennent dans la mémoire correspondant aux « paramètres actifs ».

Pour choisir un déploiement compact, consultez Formats de quantification des LLMs.

Lire un artefact de modèle en six couches

La provenance de l’entraînement annote ces couches au lieu d’ajouter une couche d’artefact supplémentaire. Par exemple, distilled décrit la manière dont le comportement a été transféré, et non le rôle du checkpoint. Un checkpoint peut être distillé, instruction-tuned, reasoning-tuned et MoE simultanément.

Le label « open source » doit faire l’objet d’une vérification distincte. Si un modèle ne publie que des poids téléchargeables, ne supposez pas que sa licence répond à une définition de l’open source ou autorise votre cas d’usage. Lisez la model card et la licence avant de comparer l’architecture ou les benchmarks.

Les labels de rôle d’entraînement décrivent le comportement, pas des garanties de capacité

Base

Un checkpoint base est principalement entraîné pour la prédiction du token suivant. Il est utile pour le continued pretraining, la recherche contrôlée ou l’adaptation lorsque vous souhaitez maîtriser le comportement d’instruction. Il peut compléter un prompt plutôt que d’y répondre.

Ne supposez pas que tout fine-tuning doit commencer avec un modèle base. Un checkpoint instruct peut constituer une meilleure initialisation si son comportement existant est aligné sur la cible. Vérifiez avec votre évaluation que ce comportement existant ne s’oppose pas au nouvel objectif.

Instruct ou chat

Ces checkpoints reçoivent un post-entraînement destiné à améliorer le suivi des instructions et la conversation. La recette exacte peut inclure du supervised fine-tuning, de l’optimisation par préférences, du reinforcement learning, de la distillation ou une combinaison de ces techniques. Il ne s’agit pas nécessairement de supervised fine-tuning suivi de RLHF.

Utilisez un checkpoint instruct comme première baseline d’assistant. Vérifiez son chat template, le format de tool call pris en charge, le comportement vis-à-vis des messages système et ses caractéristiques de refus. Le terme « Instruct » ne garantit pas à lui seul la fiabilité du JSON ou du tool use.

Reasoning-tuned

Les checkpoints orientés reasoning sont optimisés sur des tâches ou des trajectoires qui récompensent la résolution de problèmes en plusieurs étapes. Certains exposent le texte de raisonnement, certains le séparent au moyen d’un parser de serving, et certains ne présentent que la réponse. Une génération plus longue ne garantit ni un raisonnement fidèle ni une diminution des hallucinations.

Adoptez-en un lorsqu’il améliore les tranches d’évaluation difficiles après prise en compte du nombre de tokens produits, de la latence et de la vérification. Les tâches courantes d’extraction ou de classification peuvent devenir plus lentes sans devenir meilleures.

Distilled

La distillation transfère le comportement d’un teacher ou des données générées par un teacher vers un autre modèle. Le student peut être plus petit, de même taille ou structurellement différent. Il n’existe pas de règle stable du type « 70 à 80 % de la qualité à la moitié de la taille » : la qualité conservée dépend du teacher, des données, de l’objectif, de la capacité du student et de l’évaluation.

Considérez Distill comme une information de provenance de l’entraînement, puis benchmarkez-le comme n’importe quel autre checkpoint.

Quel label doit influencer chaque étape de sélection ? Cette carte permet de distinguer le rôle d’entraînement, la provenance de l’entraînement et l’architecture. Elle ne classe pas les types de modèles.

La documentation des chat templates de Transformers explique pourquoi le format exact des messages d’un modèle instruction-tuned est important. Dans l’article original sur la knowledge distillation, Hinton, Vinyals et Dean transfèrent le comportement vers un student sans revendiquer de ratio de qualité fixe. L’article sur le Switch Transformer présente une conception de routage sparse des experts. Une famille MoE donnée peut router les tokens différemment ; sa model card reste donc la référence.

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

!!! byte « Byte says »

J’ai dimensionné le GPU pour un modèle de 30B paramètres au total et 3B actifs comme s’il s’agissait d’un modèle dense de 3B. Il ne se chargeait pas. Les 30B de poids doivent tout de même être stockés quelque part.

Modèles denses

La plupart des paramètres participent au forward pass de chaque token. Le nombre de paramètres donne une indication approximative du stockage des poids. La mémoire du runtime inclut également le KV cache, les activations ou l’espace de travail, le surcoût de l’allocateur et parfois des états dupliqués ou shardés.

Mixture of Experts

Une couche MoE route chaque token vers un sous-ensemble de réseaux feed-forward experts. Des noms tels que A3B signifient souvent qu’environ trois milliards de paramètres sont actifs par token, mais les conventions de nommage dépendent de la famille. Consultez la model card pour connaître le nombre total de paramètres, le nombre de paramètres actifs, le nombre d’experts et la stratégie de routage.

Le nombre de paramètres actifs décrit le calcul routé, et non le placement des poids. Par exemple, le parallelisme des experts dans vLLM distribue les couches d’experts entre les ranks expert-parallel et déduit l’allocation d’experts de chaque rank à partir du nombre total d’experts. D’autres runtimes peuvent placer ou offloader les poids différemment. Un modèle de 30B paramètres au total et 3B actifs ne tient donc pas automatiquement comme un modèle dense de 3B.

La prise en charge du runtime dépend également de l’architecture. Vérifiez l’implémentation du modèle, la prise en charge de l’expert-parallel ou du tensor-parallel, les kernels de quantification et le contexte maximal avant de télécharger le modèle.

Les conteneurs et la quantification sont des couches différentes

Safetensors

Safetensors est un format de sérialisation sécurisé des tenseurs, couramment utilisé dans les dépôts Hugging Face. Un modèle peut comporter plusieurs shards .safetensors ainsi que des fichiers de configuration, de tokenizer et de génération. Ces tenseurs peuvent être en BF16/FP16 ou préquantifiés avec une méthode telle que GPTQ ou AWQ.

L’extension seule ne renseigne ni sur la précision ni sur la compatibilité avec le runtime. Inspectez config.json, la configuration de quantification, la model card, le dtype des tenseurs et la documentation du runtime.

GGUF

GGUF empaquette les tenseurs et les métadonnées pour l’écosystème ggml/llama.cpp. llama.cpp charge GGUF et prend en charge des backends tels que Metal, CUDA, HIP, Vulkan et les chemins CPU. L’architecture du modèle et la qualité de la conversion déterminent toutefois toujours la compatibilité.

GGUF est un conteneur. Il peut contenir des tenseurs haute précision ou quantifiés. Les modèles multimodaux peuvent également nécessiter un fichier distinct pour le projecteur ou l’encodeur. La règle « un seul fichier GGUF contient tout » n’est pas universelle.

GPTQ et AWQ

GPTQ et AWQ sont des méthodes de quantification des poids post-entraînement, et non des extensions de fichier. Leurs artefacts utilisent couramment Safetensors avec une configuration propre à la méthode. Les moteurs de serving ont besoin de kernels compatibles avec la méthode, la largeur en bits, la taille de groupe, l’architecture du modèle et le matériel.

Aucune de ces méthodes n’est universellement meilleure en qualité. Les données de calibration, l’implémentation, le chemin des kernels et la tâche sont déterminants. La prise en charge par les runtimes évolue ; vérifiez donc l’artefact exact avec la version que vous figez. Consultez les pages officielles quantification de Transformers et quantification de vLLM avant de prendre cette décision.

Le matériel ne suffit pas à choisir le conteneur. Commencez par choisir un runtime prenant en charge l’architecture et l’interface de serving. Utilisez ensuite la structure d’artefact et le chemin de quantification documentés par ce runtime.

Par exemple, le projet llama.cpp nécessite GGUF et documente plusieurs backends matériels. La spécification GGUF définit un conteneur pour les tenseurs et les métadonnées. Transformers charge quant à lui les méthodes de quantification via une configuration spécifique au backend, comme l’explique son workflow de quantification. Aucune de ces sources ne garantit qu’une extension compatible prend en charge toutes les architectures ou s’exécute efficacement sur tous les appareils.

Les calculs de quantification donnent une borne inférieure, pas un dimensionnement de capacité

Pour $P$ paramètres de poids à $b$ bits, le stockage brut des poids est approximativement de :

Un modèle 13B avec des poids nominalement en quatre bits commence donc autour de 6,5 Go. Il ne s’exécutera pas nécessairement dans 6,5 Go. Les échelles, les zero points, les tenseurs en précision supérieure, les embeddings, les métadonnées, les buffers du runtime, le KV cache et la fragmentation ajoutent de la mémoire.

Le contexte et la concurrence peuvent dominer la différence entre « se charge » et « sert des requêtes ». Mesurez la mémoire de pointe avec la longueur de séquence maximale réelle, la stratégie de batch, le dtype du cache et le parallélisme utilisés.

La quantification peut réduire la mémoire et parfois améliorer la vitesse, mais les kernels low-bit peuvent aussi être plus lents sur du matériel non pris en charge. Comparez la qualité sur la tâche et le débit de bout en bout, pas uniquement la taille du fichier. Consultez le guide de quantification de llama.cpp pour les recettes propres à ce runtime.

Interprétez soigneusement les noms de quantification GGUF

Dans llama.cpp, Q4_K_M désigne une recette de quantification au niveau du fichier, et non un type de tenseur unique appliqué partout. Les options llama-quantize exposent Q4_K_M comme type sélectionnable et décrivent --pure comme la désactivation des mélanges K-quant. L’implémentation du quantizer utilise Q4_K par défaut pour cette recette et applique d’autres types à certaines catégories de tenseurs. Considérez le suffixe comme un nom de recette llama.cpp, et non comme une spécification portable de la largeur en bits.

La documentation actuelle sur la quantification llama.cpp montre également que les recettes peuvent varier selon l’architecture et la catégorie de tenseur. Une matrice d’importance peut guider le choix des poids qui conservent une précision supérieure.

Évitez les affirmations universelles selon lesquelles Q4_K_M serait indiscernable de BF16 ou qu’un modèle Q3 plus grand surpasserait toujours un modèle Q8 plus petit. Utilisez une petite échelle de comparaison pour le checkpoint exact :

1. un artefact haute précision ou de référence fiable
2. un candidat proche de la limite mémoire
3. un candidat plus petit offrant davantage de marge

Exécutez les mêmes prompts, vérifications de structured output, cas de long contexte et tests de latence sur les trois.

Un workflow de sélection qui résiste aux nouveaux formats

1. Fixer le contrat de la tâche

Définissez la langue, la modalité, la longueur de contexte, l’interface d’outil ou de schéma, les contraintes de sécurité, les exigences de licence et les tranches d’évaluation. Comparez les checkpoints dans une représentation suffisamment précise pour que la quantification ne décide pas du premier tour.

2. Sélectionner le checkpoint

Choisissez le plus petit checkpoint qui franchit les seuils de qualité et de comportement non négociables. Notez le dépôt et la révision exacts, le tokenizer, le chat template et tout parser de reasoning requis.

3. Sélectionner le runtime

Vérifiez la prise en charge de l’architecture, du backend matériel, du parallélisme, des kernels de quantification, du structured output, des adapters et de l’interface opérationnelle. Pour l’inférence locale GGUF, llama.cpp est le runtime de référence. Pour le serving sur GPU, comparez les versions actuelles de vLLM, TGI, Transformers ou des moteurs spécialisés avec l’artefact réel.

4. Établir un budget mémoire mesuré

Incluez les poids, le KV cache, l’espace de travail du runtime, la concurrence attendue et une marge pour le système d’exploitation ou les processus colocalisés. Faire tenir un fichier en RAM ou en VRAM est nécessaire, mais pas suffisant.

5. Choisir et valider une représentation

Privilégiez les artefacts fournis par l’éditeur, avec une calibration et une provenance documentées. Si vous utilisez une conversion communautaire, enregistrez la révision source, la révision du convertisseur, la recette de quantification, les données de calibration ou d’importance et les hashes.

6. Benchmarkez l’unité de release

Mesurez la qualité sur la tâche, la correction des schémas et des tool calls, le time to first token, le débit de sortie, la mémoire de pointe et les échecs avec le contexte et la concurrence cibles. Relancez les mesures après toute modification du checkpoint, du runtime, du kernel ou du paramétrage de quantification.

Exemple de nom

Supposons qu’un dépôt soit nommé :

Acme-32B-A3B-Instruct-AWQ

Interprétez-le comme une série de questions :

• Acme : quelle famille, quelle licence et quelle révision ?
• 32B : poids totaux ou autre convention de l’éditeur ?
• A3B : comment cette famille définit-elle les paramètres actifs ?
• Instruct : quelle recette post-entraînement et quel chat template ?
• AWQ : quelle largeur en bits, quelle taille de groupe, quelle calibration et quels kernels pris en charge ?
• fichiers du dépôt : shards Safetensors, configurations, tokenizer et code personnalisé ?
• runtime cible : la version figée prend-elle en charge cette architecture et cette quantification précises ?

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

Conclusion

La sélection d’un modèle devient moins confuse dès lors que les labels ne sont plus considérés comme appartenant à une seule catégorie. Le rôle d’entraînement indique quel comportement a été optimisé. L’architecture indique comment le calcul est organisé. La quantification indique comment certains tenseurs ont été approximés, les conteneurs indiquent comment les artefacts sont stockés, et les runtimes indiquent ce qui s’exécute efficacement sur votre matériel.

Choisissez dans cet ordre, conservez une provenance exacte et utilisez une même évaluation de tâche pour comparer les artefacts de release. Un suffixe familier ne prouve ni que le modèle tient en mémoire, ni qu’il s’exécute rapidement, ni qu’il conserve le comportement dont vous avez besoin.

Références

• Chat templates de Transformers - Formatage des messages pour les modèles de langage causaux base et instruction-tuned.
• Distilling the Knowledge in a Neural Network - Article original sur la distillation par Hinton, Vinyals et Dean.
• Switch Transformers - Architecture sparse de routage des experts proposée par Fedus, Zoph et Shazeer.
• Spécification GGUF et guide de quantification de llama.cpp
• Concepts de quantification de Hugging Face Transformers
• Article sur GPTQ
• Article sur AWQ
• Documentation de quantification de vLLM