Vous ouvrez Hugging Face pour faire tourner un LLM en local, et le même modèle affiche un mur de fichiers — Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M… et vous voilà bloqué. C'est le premier mur sur lequel la plupart des gens butent. Cet article répond concrètement à la question : « quel fichier quantifié dois-je télécharger pour que ça marche ? » Nous laissons ce qu'est la quantification (le concept) à un autre article et nous concentrons ici sur le choix du format.

Nous allons voir pourquoi le format est fixé par le moteur d'exécution, la convention de nommage GGUF (Q4_K_M), les 4 formats comparés, comment choisir la profondeur de bits et comment trouver les fichiers. L'essentiel d'abord. ① Le format est surtout déterminé par « le moteur sur lequel vous allez l'exécuter » (GGUF = llama.cpp/Ollama ; GPTQ/AWQ = moteurs GPU comme vLLM). Q4_K_M signifie « 4 bits, K-quant, taille M » — le bon compromis dans la plupart des cas. ③ En cas de doute, commencez par Q4_K_M ; passez à Q5/Q6 si vous avez la VRAM.

FORMATS DE QUANTIFICATION

Le format est fixé par le moteur d'exécution

— choisissez d'abord le moteur, et le choix du fichier se réduit vite

GGUF llama.cpp / Ollama / LM Studio = CPU, Mac, GPU partiel aussi (le seul compatible CPU)
GPTQ vLLM / TGI / ExLlama = GPU (nécessite une calibration)
AWQ vLLM / TGI = GPU (protège les poids saillants via les activations)
EXL2 ExLlamaV2 = GPU (largeur de bits à granularité fine)

La première question est donc « sur quel moteur vais-je l'exécuter ? » En local sur CPU/Mac → GGUF. Serveur GPU pour la vitesse → GPTQ/AWQ.

1. Pourquoi les fichiers quantifiés sèment la confusion

La quantification consiste à arrondir les poids d'un modèle à moins de bits pour réduire sa taille et sa mémoire (voir ce qu'est la quantification). Le hic, c'est qu'il existe plusieurs méthodes (formats) pour cet arrondi, et chacune comporte de nombreuses variantes de profondeur de bits et de granularité. Résultat : plus de 20 fichiers sous un seul modèle sur Hugging Face.

Mais rassurez-vous — le choix devient facile dès qu'on le découpe en deux étapes : ① quel format (= quel moteur pour l'exécuter), puis ② quel fichier de profondeur de bits à l'intérieur. Raisonnez dans cet ordre.

2. La règle clé : le format est fixé par le moteur d'exécution

Le fait le plus important : un fichier quantifié ne tourne que sur les moteurs qui prennent en charge son format. Choisissez donc d'abord le moteur, et le format en découle presque automatiquement.

FormatPrincipaux moteursMatérielCalibration
GGUFllama.cpp / Ollama / LM Studio / KoboldCppCPU, Mac, GPU partiel (mixte)Facultative (imatrix)
GPTQGPTQModel (ex-AutoGPTQ) / vLLM / TGI / ExLlamaGPURequise
AWQAutoAWQ / vLLM / TGIGPURequise
EXL2 / EXL3ExLlamaV2 / ExLlamaV3GPURequise
bitsandbytes (NF4/INT8)Transformers (quantifie au chargement)GPUAucune (sans données)

Retenez une chose : GGUF est le seul format « local tout-terrain » qui tourne sur CPU / Mac / GPU partiel ; les autres (GPTQ/AWQ/EXL2) sont pour l'essentiel réservés au GPU. Donc —

  • Exécution sur votre propre PC / Mac / CPU (Ollama ou LM Studio) → GGUF, sans hésiter.
  • Débit élevé sur un serveur GPU (vLLM/TGI servant de nombreuses requêtes) → GPTQ ou AWQ.
  • Ajuster finement la largeur de bits sur un seul GPUEXL2/EXL3.
  • Test rapide dans Transformers (pas de fichier pré-quantifié) → bitsandbytes (NF4).

3. Décoder les noms GGUF (Q4_K_M)

GGUF, que vous croiserez le plus pour un usage local, devient inoffensif dès qu'on sait lire le « code » dans le nom de fichier. Q4_K_M se compose de trois parties.

Q4_K_M
Q4
Profondeur de bits (nominale) = 4 bits. Nombre plus élevé = meilleure qualité, fichier plus gros.
K
K-quant (quantification intelligente sur des super-blocs). Les versions simples / _0 / _1 sont anciennes.
M
S/M/L = small/medium/large. Indique dans quelle mesure certains tenseurs importants sont « rehaussés » vers plus de bits.

Ainsi Q4_K_M = « K-quant 4 bits, taille M (certains tenseurs rehaussés pour protéger la qualité) ». Les bits effectifs dépassent un peu l'étiquette (p. ex. Q4_K ≈ 4,5 bpw).

Deux termes de plus vous éviteront de vous perdre.

  • La famille IQ (IQ2_XS, IQ3_M, etc.) = les I-quants : une lignée plus récente, fondée sur un répertoire de codes (codebook), qui peut aller encore plus petit à profondeur de bits égale. Mais l'inférence est plus lourde, et ils exigent en pratique l'imatrix décrit ci-dessous. Un atout maître pour « je dois vraiment le faire tenir dans la VRAM ».
  • imatrix (matrice d'importance) : on fait passer un texte de calibration dans le modèle pour mesurer quels poids comptent, puis on protège ceux-là en priorité à faible profondeur de bits. Facultatif pour les K-quants, quasi indispensable pour les I-quants. Les GGUF construits avec imatrix tiennent mieux le coup à bas nombre de bits.

4. Les 4 formats comparés (GGUF/GPTQ/AWQ/EXL2)

Voici le caractère de chaque format majeur, ceux pour GPU inclus.

GGUF

Le seul format qui tourne sur CPU/Mac/mixte. Le standard de llama.cpp. Souple avec K-quant/I-quant/imatrix. Premier choix pour un usage personnel local.

GPTQ

Le standard 4 bits sur GPU. Minimise l'erreur couche par couche via une calibration. Rapide sur vLLM/TGI. Désormais remplacé par GPTQModel.

AWQ

Protège les « poids saillants » en observant les activations (activation-aware). GPU, 4 bits sur les poids seulement. Largement utilisé sur vLLM/TGI.

EXL2 / EXL3

Définit la largeur de bits sous forme de fraction (p. ex. 4,5 bpw). Réservé à ExLlama, GPU. EXL3 est une lignée plus récente fondée sur QTIP, encore en maturation.

💡 GPTQ vs AWQ (en bref) : GPTQ « minimise l'erreur de reconstruction couche par couche », tandis qu'AWQ « observe la distribution des activations pour protéger environ 1 % des poids les plus importants ». Le gagnant dépend du modèle, de la largeur de bits et de l'implémentation ; aucun n'est universellement meilleur. Choisissez simplement celui que votre moteur prend en charge.

5. Quel fichier / quelle profondeur de bits choisir

Une fois le format fixé, vient la profondeur de bits. En prenant GGUF comme exemple, voici une échelle pratique du type « en cas de doute, prenez ceci » (les chiffres sont approximatifs et varient selon le modèle et le build).

FichierRôleQuand le choisir
Q4_K_MLe bon compromis courant (valeur par défaut d'Ollama pour beaucoup de modèles)En cas de doute. En règle générale, le meilleur équilibre taille/qualité
Q5_K_M / Q6_KPlus proche de la qualité pleineVous avez de la VRAM en réserve et voulez monter d'un cran
Q8_0Quasi sans perte mais déconseilléRarement nécessaire (beaucoup plus de RAM/plus lent pour un gain de qualité minime)
IQ2 / IQ3 (I-quant)Faire tenir à très faible nombre de bitsUniquement quand vous devez faire tenir un gros modèle dans la VRAM

En règle générale, on dit souvent qu'environ 4,5 à 5 bits par poids (Q4_K–Q5_K) est la « bonne » bande (une heuristique). Au-delà de Q6, les gains de qualité ralentissent, et Q8_0 ou FP16 coûtent beaucoup en mémoire et en vitesse pour peu de différence — c'est le consensus pratique. Commencez par faire tourner Q4_K_M, montez à Q5/Q6 si ça semble juste, descendez à IQ si ça ne tient pas, et ajustez au fur et à mesure. Pour estimer la VRAM nécessaire, voir la configuration matérielle requise pour un LLM local.

6. Trouver les fichiers sur Hugging Face et Ollama

Sur Hugging Face, filtrez les GGUF avec library=gguf, ou allez dans le dépôt d'un reconditionneur de quantifications. À l'heure où nous écrivons, bartowski et mradermacher publient activement des GGUF (y compris des builds imatrix) — mais l'activité des reconditionneurs évolue, donc vérifiez la date de mise en ligne la plus récente. (Les dépôts autrefois incontournables de TheBloke existent toujours, mais les nouveaux dépôts ont largement cessé.) Pour convertir les vôtres, le Space officiel gguf-my-repo fait l'affaire.

Sur Ollama, les tags suivent le schéma model:size-variant-quant.

# Sans tag = la valeur par défaut (Q4_K_M pour beaucoup de modèles)
ollama pull llama3.1

# Choisir la quantification explicitement
ollama pull llama3.1:8b-instruct-q5_K_M
ollama pull qwen2.5-coder:7b-instruct-q8_0

# Voir les tags disponibles sur ollama.com/library/<model>/tags

Le vrai déroulé tient donc en trois mouvements : choisir le moteur → réduire à son format → prendre le fichier de profondeur de bits qui tient dans votre VRAM. Maîtrisez cela et le mur des 20 fichiers cesse de vous impressionner. Pour en exécuter un concrètement, voir comment faire tourner un LLM en local et le guide Ollama.

Résumé

Choisir un format de quantification, c'est deux étapes. D'abord ① sur quel moteur vous allez l'exécuter — local CPU/Mac → GGUF ; serveur GPU pour la vitesse → GPTQ/AWQ ; largeur de bits ajustée finement sur un seul GPU → EXL2 ; test rapide dans Transformers → bitsandbytes. La règle numéro un : un format ne tourne que sur les moteurs qui le prennent en charge.

Ensuite ② la profondeur de bits. Le Q4_K_M de GGUF signifie « 4 bits, K-quant, taille M » — la valeur par défaut courante. En cas de doute, Q4_K_M → (si vous avez de la marge) Q5/Q6 → (si ça ne tient pas) IQ. Ancrez-vous sur l'heuristique de la « bonne bande » à ~4,5–5 bpw et ajustez à l'exécution. Les builds imatrix tiennent mieux à bas nombre de bits. À lire aussi : ce qu'est la quantification, comment faire tourner un LLM en local, la configuration matérielle requise, les meilleurs modèles locaux, le guide Ollama.

FAQ

Q. Alors, quel fichier dois-je choisir ?
A. Décidez d'abord « sur quel moteur vous allez l'exécuter ». Votre propre PC ou Mac (Ollama/LM Studio) → GGUF ; un serveur GPU (vLLM/TGI) → GPTQ ou AWQ. Ensuite, pour la profondeur de bits, en cas de doute, Q4_K_M (bon équilibre taille/qualité, et valeur par défaut d'Ollama pour beaucoup de modèles). Avec de la VRAM en réserve, Q5_K_M/Q6_K ; uniquement quand vous devez faire tenir un gros modèle, envisagez IQ2/IQ3.

Q. Que signifie Q4_K_M ?
A. Trois parties. Q4 = ~4 bits (nombre plus élevé = meilleure qualité, fichier plus gros), K = K-quant (quantification intelligente sur des super-blocs ; les versions simples ou _0/_1 sont anciennes), et M = taille medium (S/M/L indique dans quelle mesure certains tenseurs importants sont rehaussés vers plus de bits). Les bits effectifs dépassent un chouïa l'étiquette (Q4_K ≈ 4,5 bpw).

Q. En quoi GGUF et GPTQ/AWQ diffèrent-ils ?
A. Par le moteur d'exécution (le matériel) qu'ils prennent en charge. GGUF est le seul format « local tout-terrain » qui tourne sur CPU, Mac et GPU partiel, pour llama.cpp/Ollama. GPTQ et AWQ sont orientés GPU d'abord et conviennent au débit élevé sur vLLM/TGI. Ils diffèrent aussi par la méthode (GPTQ minimise l'erreur couche par couche ; AWQ protège les poids saillants via les activations), mais aucun n'est universellement meilleur. Choisissez simplement celui que votre moteur prend en charge.

Q. En quoi IQ (I-quant) diffère-t-il d'un Q4 normal ?
A. Il peut aller encore plus petit à profondeur de bits égale (une méthode plus récente fondée sur un répertoire de codes). En contrepartie, l'inférence est un peu plus lourde, et il exige en pratique un imatrix pour tenir la qualité. Son usage est un atout maître pour « je dois faire tenir un gros modèle dans la VRAM ». Si ça tient normalement, un K-quant comme Q4_K_M est plus facile à manier.

Q. Q8_0 ou FP16 ne sont-ils pas de meilleure qualité ? Pourquoi « déconseillés » ?
A. Ils sont en effet quasi sans perte, mais ils consomment beaucoup plus de mémoire et tournent plus lentement pour un gain de qualité minime par rapport à Q5/Q6. Même la communauté llama.cpp ne les recommande pas pour un usage normal. En pratique, environ 4,5–5 bpw (Q4_K–Q5_K) est la « bonne » bande, et l'on monte ou descend à partir de là selon les besoins (les chiffres sont approximatifs et varient selon le modèle/build).