Choisir sa quantification (Q4, Q5, Q8, FP16)

#Quantification : ce que vous échangez contre de la mémoire

Un modèle est un ensemble de milliards de nombres, les poids. En FP16, chacun occupe 16 bits : un modèle de 8 milliards de paramètres pèse environ 16 Go. La quantification stocke chaque poids sur moins de bits. Selon la documentation de l'outil llama-quantize, ce procédé réduit la taille du modèle et peut accélérer l'inférence, au prix d'une perte de précision mesurée en perplexité ou en divergence de Kullback-Leibler. Le format GGUF utilisé par llama.cpp, Ollama et LM Studio regroupe ces variantes. Le bon choix dépend de trois quantités : la mémoire de votre carte ou de votre Mac, la taille du modèle, et le contexte que vous comptez utiliser. Q4_K_M offre le meilleur rapport dans la plupart des cas, parce que la perte de qualité y reste faible alors que la taille tombe à environ 30 % du FP16.

#Décoder les noms : Q4_K_M, Q5_K_S, Q8_0, IQ3_XXS

Le chiffre (Q2 à Q8)

Le nombre de bits nominal par poids. La valeur réelle est plus haute, car des tenseurs sensibles restent en précision supérieure : Q4_K_M mesure 4,89 bits par poids.

_0 et _1

Formats anciens, à niveau de précision uniforme. Q8_0 reste utilisé pour sa quasi-absence de perte, mais Q4_0 et Q5_0 ont été supplantés par les variantes K.

_K

Les K-quants, plus récents, répartissent les bits selon l'importance des tenseurs.

S, M, L

Small, Medium, Large : pour un même nombre de bits, M garde plus de bits sur les tenseurs importants que S, donc pèse un peu plus et perd un peu moins.

IQ

Les I-quants, à matrice d'importance : à taille égale ils conservent mieux la qualité aux très bas débits (sous 4 bits), et demandent un peu plus de calcul au décodage. Ils s'appuient sur un fichier imatrix.

#Tableau de décision : tailles et pertes mesurées

Le README de llama-quantize publie, pour Llama 3.1 8B, le nombre de bits par poids et la taille de chaque format. La bibliothèque Ollama affiche, pour le même modèle, la taille des fichiers distribués. Les deux sources concordent à peu près, et donnent un ordre de grandeur applicable à d'autres modèles de la même famille.

Une nuance sur la dernière colonne : les pertes de perplexité viennent d'une discussion du dépôt llama.cpp qui recopie le tableau d'aide de l'outil, établi en 2023 sur un modèle de 7 milliards de paramètres. Elles montrent l'ordre des formats, pas le comportement exact des modèles actuels, dont certains sont plus sensibles.

#Calculer la mémoire d'un modèle en quelques secondes

La taille d'un fichier GGUF se déduit de la formule suivante : paramètres en milliards multipliés par les bits par poids, divisés par huit, donnent des gigaoctets. Pour un 70B en Q4_K_M : 70 × 4,89 ÷ 8 ≈ 42,8 Go, ce que confirme la table de llama.cpp pour Llama 3.1 70B (43,1 Go). Ajoutez ensuite le cache KV, qui croît avec le contexte, et une marge pour le système.

taille du fichier (Go) ≈ paramètres (milliards) × bits par poids ÷ 8

Exemple : 32 milliards en Q5_K_M
32 × 5,70 ÷ 8 ≈ 22,8 Go
+ cache KV (selon le contexte) + 1 à 2 Go de marge

#Ce que la quantification fait vraiment à la qualité

Les mesures de perplexité classent les formats de façon régulière : plus de bits, moins de perte. Mais la perplexité prédit mal les capacités précises. Une étude publiée sur arXiv en janvier 2026 a comparé les formats de llama.cpp sur Llama-3.1-8B-Instruct, avec des tests de raisonnement, de connaissances et de suivi d'instructions : la perplexité sur WikiText-2 y va de 7,32 pour le FP16 à 8,96 pour Q3_K_S, et les auteurs notent que la perplexité n'est pas un prédicteur complet du comportement en aval. Le score moyen de Q5_0 y dépasse même légèrement celui du FP16 (69,92 % contre 69,47 %), ce qui relève du bruit de mesure, pas d'un modèle amélioré.

Le résultat utile concerne le raisonnement mathématique : sur GSM8K, le score passe de 77,63 en FP16 à 68,31 en Q3_K_S. Les auteurs recommandent d'éviter les 3 bits agressifs et de préférer Q4_K_S ou Q5_0 quand la charge implique du raisonnement en plusieurs étapes. Les tâches qui pénalisent d'abord la quantification sont donc le calcul, le code et les longues chaînes de raisonnement, pas la conversation courante.

De Q8 à Q6

Différence non mesurable en pratique dans les tables publiées.

De Q6 à Q4_K_M

Perte faible, visible surtout sur les tâches à raisonnement long, le code et les langues peu représentées.

Sous 4 bits

Chute nette sur le raisonnement : à éviter sans raison de mémoire.

#Pourquoi un fichier plus petit génère aussi plus vite

Les mesures du README de llama.cpp, faites sur Llama 3.1 8B, illustrent un point que les guides omettent : la génération de texte lit l'intégralité des poids actifs à chaque token, donc elle dépend surtout de la quantité d'octets à lire. Dans ce tableau, le débit de génération passe d'environ 51 tokens par seconde en Q8_0 à environ 72 en Q4_K_M, et 90 pour Q2_K_S. La lecture du prompt, elle, reste stable autour de 800 tokens par seconde parce qu'elle est limitée par le calcul et non par la mémoire. Ces chiffres viennent d'un matériel précis du dépôt et ne sont pas ceux de votre machine ; retenez la tendance : moins de bits, génération plus rapide.

Deux conséquences pratiques. Premièrement, passer de Q4_K_M à Q8_0 pour gagner une qualité imperceptible coûte environ 30 % de vitesse de génération dans ces mesures. Deuxièmement, la quantification des poids et celle du cache KV sont deux réglages distincts : la seconde réduit la mémoire du contexte long et se traite dans son propre guide.

#Choisir en trois règles

1. 01
   Partez de votre mémoire disponible

   VRAM d'une carte NVIDIA ou AMD, ou mémoire unifiée d'un Mac moins environ 25 % pour le système. Si le modèle dépasse, le calcul déborde sur le CPU et la vitesse chute, souvent d'un facteur de plusieurs unités.
2. 02
   Prenez le modèle le plus gros qui tient en Q4_K_M

   À mémoire égale, un modèle plus grand en 4 bits est généralement meilleur qu'un plus petit en 8 bits. C'est une règle empirique largement partagée, à vérifier sur vos propres tâches, surtout pour le code.
3. 03
   Montez ensuite la précision avec la marge restante

   S'il reste de la VRAM une fois le contexte réservé, passez à Q5_K_M puis Q6_K. Le gain est moindre que le passage d'une taille à la suivante.

ollama run llama3.1:8b-instruct-q5_K_M

Les étiquettes de la bibliothèque Ollama indiquent le format et la taille de chaque variante ; lorsque vous omettez le suffixe, Ollama applique l'étiquette par défaut du modèle. Sur Hugging Face, les fichiers GGUF portent le nom de la quantification dans leur nom.

#Les I-quants et formats sous 4 bits

Le tableau de llama.cpp permet de mesurer l'économie réelle. Sur Llama 3.1 8B, IQ4_XS pèse 4,17 Gio contre 4,58 Gio pour Q4_K_M, soit environ 9 % de moins ; IQ3_XXS pèse 3,04 Gio ; IQ2_XXS 2,23 Gio. Dans les mesures du dépôt, les débits de génération de ces formats restent proches de ceux des K-quants, à quelques tokens par seconde près : le surcoût de décodage est donc modeste. Les I-quants dépendent en revanche de la qualité de l'imatrix et du modèle : ils n'ont de sens que lorsque Q4_K_M ne tient pas.

IQ4_XS

Proche de Q4_K_M en taille moins ~9 %. Utile quand la VRAM est juste.

IQ3_XXS et IQ3_S

Un 13B en environ 5 Go de poids, avec une perte sensible sur le raisonnement.

IQ2 et IQ1

Pour les modèles gigantesques uniquement, quand rien d'autre ne tient. Sur des quantifications de ce type, la fidélité se mesure : voir l'exemple de Kimi K3, où le 1 bit dynamique n'a que 78,9 % d'accord avec l'original.

#Modèles publiés directement en 4 bits

Certains modèles récents ne sont plus entraînés en 16 bits puis compressés : leurs poids sont produits en 4 bits avec un entraînement conscient de la quantification. Kimi K3 en est un exemple : sa fiche indique des poids MXFP4 et des activations MXFP8, avec quantization-aware training. Pour ces modèles, le fichier natif est déjà la référence, et une quantification supplémentaire vers un format plus bas dégrade davantage qu'une quantification d'un modèle en 16 bits. Lisez toujours la fiche du modèle avant de le convertir.

#Que prendre selon votre mémoire

#Pour aller plus loin

• Q4_K_M, Q5_K_M et Q6_K en pratique
• Comprendre la fenêtre de contexte
• Quantifier le KV cache : gagner de la VRAM
• GGUF, safetensors : comprendre les formats
• Calculateur de VRAM

• Source : README de llama-quantize (llama.cpp)
• Source : étude arXiv sur la quantification llama.cpp (2026)
• Source : étiquettes Ollama de Llama 3.1
• Source : discussion llama.cpp sur les méthodes de quantification