Passer au contenu principal

​
Pourquoi les noms de modèles comptent

Parcourez Hugging Face ou la bibliothèque de modèles d’Ollama et vous verrez des noms comme Qwen/Qwen3-235B-A22B-Instruct ou bartowski/Llama-3.3-70B-Instruct-GGUF. Ce ne sont pas des chaînes aléatoires — chaque segment encode une décision que vous devrez prendre avant le téléchargement. Le nom vous indique :
  • La taille du modèle — et donc la quantité de VRAM ou de mémoire système nécessaire.
  • Son objectif d’entraînement — chat général, codage, raisonnement, vision ou complétion de texte brute.
  • Sa méthode de compression — et le compromis qualité/taille que vous acceptez.
  • Son créateur — et si les poids sont originaux ou un réempaquetage tiers.
Apprendre à lire ces conventions prend 5 minutes et vous évite de télécharger un modèle 70B qui ne tient pas dans votre GPU, ou de gaspiller de la VRAM sur un modèle de base incapable de suivre des instructions.

​
L’anatomie d’un nom de modèle

La plupart des noms de modèles open-weight suivent un schéma :
Tous les noms n’incluent pas tous les segments, et les éditeurs varient les séparateurs — certains utilisent des tirets, d’autres des slashes ou rien. Mais vous pouvez généralement identifier ces parties : Exemples réels, analysés segment par segment : Qwen/Qwen3-235B-A22B-Instruct mistralai/Mistral-7B-Instruct-v0.3 TheBloke/Llama-2-7B-Chat-GGUF — TheBloke (quantificateur tiers), Llama 2, 7B params, affiné pour le chat, format GGUF.
Lorsque l’organisation est un quantificateur tiers comme TheBloke, bartowski ou unsloth, le modèle lui-même a été entraîné par quelqu’un d’autre — le dépôt contient une version réempaquetée ou quantifiée des poids originaux.

​
Décodage des étiquettes de taille

Le nombre avant B est le nombre de paramètres en milliards. C’est le principal facteur déterminant à la fois les capacités et les exigences en mémoire.

​
Modèles MoE : deux nombres

Les modèles MoE (mélange d’experts) listent à la fois les paramètres totaux et actifs, écrits comme 235B-A22B ou 30B-A3B :
  • Le premier nombre est le nombre total de paramètres — ce dont vous avez besoin pour stocker en mémoire ou sur disque.
  • Le deuxième nombre (après A) est le nombre de paramètres actifs — combien de paramètres s’exécutent par token.
Un modèle 235B-A22B a besoin de suffisamment de mémoire pour contenir 235B paramètres, mais ne calcule qu’avec 22B à la fois, donc il génère des tokens beaucoup plus vite qu’un modèle dense 235B. Le compromis : les modèles MoE sont plus grands sur disque et en mémoire qu’un modèle dense de taille active équivalente, mais plus rapides à l’inférence.
Un modèle MoE 235B-A22B correspond grossièrement à un modèle dense 22B en vitesse par token, mais vous avez toujours besoin de VRAM ou de RAM système pour stocker tous les 235B paramètres. À Q4_K_M, cela fait environ 120 Go — bien plus que les 22B d’un modèle dense qui nécessitent 13 Go.

​
Comment le nombre de paramètres se traduit en capacité

Plus de paramètres signifient généralement plus de capacité, mais la relation n’est pas linéaire. Un modèle 70B n’est pas 10x meilleur qu’un modèle 7B — il est nettement meilleur en raisonnement, nuance et tâches complexes, mais un modèle 7B bien affiné peut toujours gérer bien le chat quotidien et les tâches de codage simples. La bonne taille dépend de votre matériel et de votre tâche, pas seulement d’une règle “plus grand est mieux”.

​
Suffixes d’architecture

Les éditeurs ajoutent des suffixes pour signaler des variantes d’architecture au-delà du modèle de base. Ceux-ci affectent ce que le modèle peut faire et quel matériel il nécessite.
Un modèle dense utilise chaque paramètre sur chaque token. Un modèle MoE (mélange d’experts) achemine chaque token à travers un sous-ensemble de sous-réseaux “experts”. Les modèles MoE sont plus grands en paramètres totaux mais plus rapides par token car seuls les paramètres actifs calculent. Si un nom de modèle inclut deux nombres de taille (comme 235B-A22B), c’est du MoE.
Les modèles étiquetés -VL acceptent des images ou vidéos en plus du texte. Exemples : Qwen3-VL-32B-Instruct, gemma-4-12b-it. Les modèles VL ont besoin de VRAM supplémentaire pour l’encodeur vision par-dessus les poids du modèle langage.
Les modèles étiquetés -Coder sont affinés ou entraînés principalement sur du code. Ils surpassent généralement les modèles généraux de même taille sur les tâches de programmation mais peuvent être plus faibles en conversation ouverte. Exemple : Qwen3-Coder-480B-A35B-Instruct.
Les modèles avec -Math ou des étiquettes spécifiques au raisonnement sont entraînés sur la résolution de problèmes mathématiques et des données de chaîne de pensée. Ils sont plus forts en logique étape par étape que les modèles généraux de même taille mais plus limités en portée.
Certains éditeurs taguent les releases expérimentales comme next, preview, ou experimental. Ceux-ci peuvent avoir un entraînement incomplet ou des templates de chat non testés — utiles pour l’évaluation, pas pour la production.

​
Étiquettes d’étape d’entraînement

L’étape d’entraînement vous dit si le modèle peut tenir une conversation ou juste compléter du texte. C’est le segment le plus important pour décider si un modèle est utilisable directement. Instruct et Chat sont interchangeables pour la plupart des usages — les deux signifient que le modèle a été affiné pour répondre aux prompts utilisateur. Chat est l’étiquette plus ancienne (Llama 2 l’utilisait) ; Instruct est plus courant dans les nouvelles familles. Certains éditeurs comme Mistral n’utilisent ni l’un ni l’autre et s’appuient plutôt sur des tags de version (v0.3) à côté du nom de base.
Pour un usage local, vous voulez presque toujours Instruct ou Chat. Un modèle Base ne peut pas suivre d’instructions — il complète seulement du texte — et donnera des sorties confuses si vous le promptez comme un chatbot.
Si vous voyez un modèle sans étiquette d’étape d’entraînement et sans tag Base, vérifiez la carte du modèle avant de supposer qu’il est affiné par instructions. Certains éditeurs publient des modèles affinés sans les étiqueter, mais d’autres publient des modèles de base sans les étiqueter non plus.

​
Étiquettes de quantification (le monde GGUF)

Les étiquettes de quantification GGUF suivent un schéma de nommage documenté dans le README de quantize de llama.cpp. Le nombre Q est approximativement combien de bits par poids ; plus haut signifie fichier plus grand et qualité plus élevée. Les K-quants ajoutent une précision mixte — différents tenseurs obtiennent différentes largeurs de bits selon la sensibilité — et le S/M/L final marque les variantes petite/moyenne/grande à ce niveau. Voici la gamme complète que vous rencontrerez, avec des conseils pratiques :

​
Points forts pratiques

  • Q4_K_M — Commencez ici. Bonne qualité, tient sur du matériel grand public.
  • Q5_K_M — Montez d’un cran quand votre VRAM a de la marge. Quasi-sans perte pour la plupart des tâches.
  • Q8_0 — Perte minimale. Utilisez quand la qualité est critique et la mémoire disponible.
  • Q3_K_M — Descendez à ceci seulement pour faire tenir un modèle plus grand qui ne charge pas à Q4_K_M. Attendez une perte de qualité.

​
Comparaison de taille : un modèle 7B à chaque quant

La taille de fichier d’un quant GGUF est votre nombre VRAM de vérité terrain pour les poids. Ajoutez le cache KV par-dessus (voir Cache KV et contexte) pour l’exigence mémoire totale.

​
I-quants (imatrix) vs K-quants

Vous pouvez aussi voir des noms de quant commençant par IQ — comme IQ4_XS ou IQ3_XXS. Ce sont des quants imatrix, construits utilisant une matrice d’importance : des données de calibration qui disent au quantificateur quels poids comptent le plus, pour qu’il puisse les préserver plus soigneusement. Les I-quants peuvent produire une meilleure qualité que les K-quants à la même largeur de bits, particulièrement à très faibles largeurs de bits, au prix d’un processus de quantification plus lent. Si un dépôt offre à la fois Q4_K_M et IQ4_M, l’I-quant peut être légèrement meilleur — mais la différence est généralement assez petite pour que les deux fonctionnent. Pour une explication plus approfondie de comment la quantification fonctionne et pourquoi les K-quants surpassent les quants simples, voir Quantification.

​
Autres suffixes courants

Au-delà des étiquettes de quantification, les noms de modèles incluent des tags de format et de précision qui vous disent quel backend peut charger le fichier.
Le format utilisé par les backends basés sur llama.cpp — Ollama, LM Studio, et n’importe quel serveur llama.cpp. Les fichiers GGUF regroupent les poids, le tokenizer et le template de chat dans 1 fichier. La plupart du matériel grand public exécute GGUF.
Un format de quantification GPU (typiquement 4-bit ou 8-bit) qui s’exécute sur des GPU NVIDIA via AutoGPTQ ou vLLM. Plus rapide que GGUF sur GPU mais NVIDIA-only et incompatible avec les backends llama.cpp.
Quantification de poids consciente de l’activation — un autre format GPU similaire à GPTQ mais calibré utilisant des statistiques d’activation. Supporté par vLLM et certains autres moteurs d’inférence. GPU NVIDIA.
Le format ExLlamaV2 — supporte la quantification à ratio mixte où différentes couches utilisent différentes largeurs de bits. Optimisé pour les GPU NVIDIA et le moteur d’inférence ExLlamaV2.
Précision complète 16-bit. FP16 (float16) et BF16 (bfloat16) sont tous deux 2 octets par paramètre. BF16 a une plage d’exposant plus large et est plus stable numériquement pendant l’entraînement ; pour l’inférence, les deux se comportent similairement. Nécessite vLLM ou des moteurs similaires.
Flottant 8-bit — la moitié de la taille de FP16 avec une perte de qualité minimale. Utilisé par des moteurs d’inférence comme vLLM et SGLang sur des GPU qui supportent FP8 (NVIDIA Ada Lovelace et plus récent, AMD MI300).
Le format flottant 4-bit de NVIDIA, disponible sur les GPU Blackwell incluant DGX Spark. Offre une réduction de taille agressive avec un support natif matériel — voir Compatibilité des modèles DGX Spark.

​
Quantification par l’éditeur vs tiers

Plusieurs parties publient souvent des versions quantifiées du même modèle :
  • Quants de l’éditeur — Qwen, Mistral, Google, et d’autres livrent de plus en plus leurs propres fichiers GGUF à côté des poids à précision complète. Ceux-ci sont généralement le choix le plus sûr car l’éditeur contrôle les poids originaux et le template de chat.
  • Unsloth — Livre des quants GGUF avec des templates de chat optimisés et une quantification dynamique. Offre aussi des variantes 1.58-bit (unsloth/...-1.58bit) extrêmement petites. Généralement fiable et largement utilisé.
  • TheBloke — Quantificateur prolifique précoce dont les dépôts ont aidé à définir l’écosystème de distribution GGUF. Bien organisé mais peut traîner derrière les modèles les plus récents ou manquer des mises à jour de template de chat pour les releases récentes.
  • bartowski — Quantificateur communautaire actif avec un nommage cohérent et une bonne couverture des nouvelles releases. Souvent parmi les premiers à publier des variantes GGUF quand un nouveau modèle sort.

​
Comment vérifier un quant tiers

  1. Vérifiez que le dépôt renvoie vers le modèle original.
  2. Comparez la taille de fichier à ce à quoi vous vous attendriez à ce niveau de quant (le tableau ci-dessus est une référence).
  3. Cherchez les métadonnées du template de chat — un template manquant ou incorrect dégrade la sortie silencieusement.
  4. Si des benchmarks de perplexité sont publiés pour le quant, comparez-les aux chiffres de l’éditeur lui-même.

​
Guide de décision rapide

Faites correspondre votre matériel à une taille de modèle et un niveau de quantification :

8 Go VRAM

7B Q4_K_M ou 14B Q3_K_M. Restez avec des modèles plus petits à des quants confortables — un 7B à Q4_K_M surperforme un 14B à Q2_K.

16 Go VRAM

14B Q5_K_M ou 32B Q4_K_M. Le 14B à Q5 est quasi-sans perte ; le 32B à Q4 échange un peu de qualité pour significativement plus de capacité.

24 Go VRAM

32B Q5_K_M ou 70B Q4_K_M. Le 32B à Q5 est le point fort pour la qualité sur un seul GPU. Un 70B à Q4 pousse la capacité plus haut mais remplit la plupart de la VRAM.

48 Go+

70B Q5_K_M ou des modèles MoE comme 235B-A22B Q4_K_M avec délestage. Vous avez de la place pour des quants haute qualité des plus grands modèles.

128 Go (DGX Spark)

120B+ de modèles MoE à FP8 ou NVFP4. Précision complète ou quasi-complète de modèles à échelle frontier. Voir Compatibilité des modèles DGX Spark.

CPU uniquement

3B Q4_K_M ou 7B Q3_K_M. L’inférence CPU est lente — gardez le modèle petit. Attendez 1–5 tokens par seconde.
Ce sont des points de départ. Votre utilisation VRAM réelle dépend aussi de la longueur de contexte (le cache KV grandit avec le contexte), de la taille de lot, et si le backend délègue des couches à la RAM système. Utilisez le guide d’ajustement de modèle pour un dimensionnement précis.

​
Drapeaux rouges de nommage

Tous les noms de modèles ne suivent pas les conventions, et certains motifs méritent prudence :
  • Pas d’étiquette de taille — Un nom de modèle sans nombre de paramètres peut être n’importe quoi. Vérifiez la carte du modèle avant de télécharger.
  • Variantes “Uncensored” — Généralement juste l’entraînement de sécurité retiré, pas une amélioration de capacité. La qualité du modèle de base peut être inchangée ou pire si le retrait a cassé l’alignement.
  • Modèles fusionnés — Combinent des poids de 2 ou plus modèles (par exemple, fusionner un modèle de codage avec un modèle de chat). La qualité varie énormément et est difficile à prédire du nom seul. Cherchez la méthode de fusion (SLERP, DARE, TIES) et si des résultats d’évaluation sont publiés.
  • Quants extrêmement bas — Q2_K est presque toujours trop lossy pour quoi que ce soit au-delà de tester si un modèle charge. Attendez un raisonnement dégradé, un formatage cassé et des hallucinations. Si un modèle ne livre que des quants Q2, cherchez un modèle différent au même nombre de paramètres.
  • Numéros de version sans journaux de changements — v0.1 à v0.9 sans description claire de ce qui a changé entre les versions. Utilisez la plus récente sauf si vous avez une raison spécifique de ne pas le faire.
  • Tags hype “AWSD” ou similaires — Certains dépôts ajoutent des suffixes accrocheurs qui ne correspondent à aucune technique standard. Si vous ne pouvez pas trouver le terme ailleurs, traitez-le avec scepticisme.

​
Tout mettre ensemble

Prenons unsloth/Qwen3-30B-A3B-Instruct-GGUF. Lire de gauche à droite :
  1. unsloth — quantifié par Unsloth (quantificateur tiers).
  2. Qwen3 — Architecture Qwen3, génération actuelle d’Alibaba.
  3. 30B-A3B — Modèle MoE : 30B paramètres totaux, 3B actifs par token.
  4. Instruct — affiné par instructions, prêt pour le chat.
  5. GGUF — Format llama.cpp, s’exécute sur Ollama, LM Studio, ou n’importe quel backend llama.cpp.
Du nom seul vous savez : c’est un petit modèle MoE qui s’exécute vite, tient dans 8 Go de VRAM à Q4_K_M, et peut suivre des instructions. Vous n’avez pas besoin d’ouvrir la carte du modèle pour décider si vous voulez l’essayer. Comparez maintenant meta-llama/Llama-3.3-70B-Instruct. C’est le Llama 3.3 de Meta, 70B paramètres denses, affiné par instructions — pas de tag GGUF signifie que vous regardez des poids à précision complète qui ont besoin de vLLM ou d’un moteur similaire. Le nom vous dit que c’est un grand modèle haute qualité qui nécessite du matériel sérieux.

​
Suite : lire la carte du modèle

Maintenant que vous pouvez décoder le nom, la carte du modèle vous dit tout ce que le nom omet — longueur de contexte, licence, template de chat, et usage prévu.

Lire une carte de modèle

Trouvez les paramètres, l’architecture, la longueur de contexte, et la licence qui comptent avant de télécharger.

Quantification

Comment la quantification fonctionne et pourquoi les K-quants surpassent les quants simples.

Guide d'ajustement de modèle

Vérifiez si une combinaison modèle-et-quant tient dans votre matériel.