Rédigé par Rédaction CyberSDF / 19 September 2026

Quelle quantification GGUF choisir : Q4_K_M ou Q5_K_M selon la RAM

Un modèle de 8 milliards de paramètres occupe 7,95 Gio en Q8_0 et 4,58 Gio en Q4_K_M : sur une machine à 8 Go de mémoire vive, le premier ne se charge pas. Ces deux tailles sont celles que le dépôt ggml-org/llama.cpp publie pour meta-llama/Llama-3.1-8B, et le binaire llama-quantize les affiche lui-même, palier par palier, avec la perte de perplexité correspondante.

llama-quantize affiche la taille et la perte de perplexité de chaque palier

Appelé sans fichier d’entrée, llama-quantize imprime la liste des paliers acceptés. Chaque ligne porte le numéro de type de fichier GGUF, le nom du palier, la taille du fichier produit en gibioctets et l’écart de perplexité mesuré sur Llama-3-8B.

llama-quantize --help

 allowed quantization types
-----------------------------------------------------------------------------

  Q2_K    :  2.96G, +3.5199 ppl @ Llama-3-8B
  Q3_K_M  :  3.74G, +0.6569 ppl @ Llama-3-8B
  Q4_K_S  :  4.37G, +0.2689 ppl @ Llama-3-8B
  Q4_K_M  :  4.58G, +0.1754 ppl @ Llama-3-8B
  Q5_K_S  :  5.21G, +0.1049 ppl @ Llama-3-8B
  Q5_K_M  :  5.33G, +0.0569 ppl @ Llama-3-8B
  Q6_K    :  6.14G, +0.0217 ppl @ Llama-3-8B

Les noms Q4_K et Q5_K sont des alias, traduits en Q4_K_M et Q5_K_M. Le G de cette liste est un gibioctet : le fichier Q4_K_M de Llama-3.1-8B fait 4 912 898 304 octets, soit 4,58 Gio et 4,91 Go. L’écart de perplexité est mesuré sur Llama-3-8B, jamais sur le modèle en cours de conversion : il classe les paliers entre eux et ne prédit rien de la qualité d’un autre modèle.

Sur un modèle déjà converti en bf16 ou f16, l’option --dry-run calcule la taille finale sans écrire de fichier, avec la syntaxe donnée par l’aide du binaire :

llama-quantize --dry-run model-f32.gguf Q4_K

La sortie détaille chaque tenseur avant et après conversion, puis un total signé llama_model_quantize_impl qui donne le bits par poids réel du fichier. Pour un Q4_K_M, ce nombre vaut 4,89, jamais 4.

Tableau : les paliers d’un modèle 8B, leur taille et la RAM qu’ils occupent

Les tailles et les bits par poids proviennent du tableau publié par llama.cpp pour Llama-3.1-8B, modèle à 32 couches dont le cache de contexte mesure 1024 valeurs par couche et par jeton. Le total additionne le fichier et un cache de 4096 jetons en f16, soit 512 Mio pour ce modèle. La dernière colonne applique une réserve de 1 Gio au système et aux tampons de calcul, sur un poste vendu 8 Go qui dispose de 7,45 Gio.

La frontière utile d’un modèle 8B se situe entre Q5_K_M et Q6_K : 5,83 Gio contre 6,64 Gio occupés, pour une perte de perplexité qui passe de +0,0569 à +0,0217. Q6_K double presque la finesse du Q5_K_M mais coûte 800 Mio de plus et sort de l’enveloppe d’un poste 8 Go.

Le fichier Q4_K_M ne contient pas que des tenseurs 4 bits

Le code de sélection des types, dans src/llama-quant.cpp, traite Q4_K_M comme un mélange : les tenseurs attn_v et ffn_down des couches qui satisfont le motif i_layer < n_layers/8 || i_layer >= 7*n_layers/8 || (i_layer - n_layers/8) % 3 == 2 passent en Q6_K, les autres restent en Q4_K. C’est ce qui explique les 4,8944 bits par poids réels d’un fichier annoncé en 4 bits, et l’écart avec Q4_K_S, où seuls les quatre premiers tenseurs attn_v sont promus en Q5_K.

L’option --pure, décrite comme « disable k-quant mixtures and quantize all tensors to the same type », supprime ces mélanges. Un Q4_K_M produit avec –pure n’a donc ni la taille ni la qualité du Q4_K_M de la liste : deux fichiers du même nom ne sont pas interchangeables.

Reconvertir un GGUF déjà quantifié échoue sur « requantizing from type q4_K is disabled »

Télécharger un Q4_K_M puis le passer en Q5_K_M ne fonctionne pas : llama-quantize n’accepte en entrée que du f16, du bf16 ou du f32. Dès qu’un tenseur est déjà quantifié et que –allow-requantize est absent, la conversion s’arrête avant toute écriture.

[   1/ 291] blk.0.attn_q.weight                - [ 4096,  4096], type =   q4_K, size =  1024.00 MiB ->  1024.00 MiB
llama_model_quantize: failed to quantize: requantizing from type q4_K is disabled

La cause tient à une seule condition du code, if (ggml_is_quantized(tensor->type) && !params.allow_requantize). Le remède est du côté du fichier source : conservez le bf16 d’origine, seule entrée qui produit proprement n’importe quel palier. L’aide du binaire commente l’option de contournement par « Warning: This can severely reduce quality compared to quantizing from 16bit or 32bit », à compléter par --leave-output-tensor pour laisser le tenseur de sortie en haute précision.

Ollama ne contourne pas cette limite. Sa documentation d’import indique que l’outil ne quantifie pas les GGUF à l’import et renvoie vers llama-quantize : un ollama create sur un fichier existant l’enregistre tel quel. Changer de palier suppose donc de repartir du bf16, puis de recréer le modèle côté Ollama, dans la rubrique IA.

Les paliers IQ1, IQ2 et IQ3 réclament une importance matrix

Descendre sous 3 bits par poids ne se fait pas avec le seul fichier de poids. La fonction tensor_requires_imatrix marque comme obligatoires les types IQ1_S, IQ1_M, IQ2_XXS, IQ2_XS, IQ2_S et IQ3_XXS, ainsi que Q2_K lorsqu’il apparaît dans un fichier Q2_K_S. Sans matrice, la conversion s’arrête sur un bloc qui nomme le tenseur fautif et le type visé.

 ERROR: this quantization requires an importance matrix!
        - offending tensor: blk.0.ffn_down.weight
        - target type: iq2_xxs

Un second contrôle intervient pendant l’écriture, quand un tenseur ne trouve pas sa taille dans la matrice : « Missing importance matrix for tensor … in a very low-bit quantization », suivi de « The result will be garbage, so bailing out ». Une importance matrix se calcule à partir d’un corpus et se passe à --imatrix ; à partir de Q3_K, aucun palier k-quant ne l’exige.

Le cache de contexte occupe 512 Mio à 4096 jetons, et 16 Gio à la longueur annoncée par le modèle

Pour un modèle à attention à requêtes groupées, le cache de clés et de valeurs occupe n_embd_k_gqa × n_layer × 2 × n_ctx valeurs, multipliées par la taille d’un élément, 2 octets en f16. Sur Llama-3-8B, 1024 valeurs de cache sur 32 couches donnent 128 Kio par jeton : 512 Mio à 4096 jetons, 1 Gio à 8192, 4 Gio à 32768 et 16 Gio à 131072.

Le paramètre -c, alias --ctx-size, vaut 0 par défaut dans llama.cpp 0.4.1, version publiée le 14 septembre 2026, et 0 signifie que la longueur est reprise du modèle. Le même fichier Q4_K_M de Llama-3.1-8B annonce 131072 jetons d’entraînement : la réserve de cache peut donc atteindre 16 Gio sans qu’aucune option n’ait été touchée, pour un fichier de 4,58 Gio. Fixer -c 8192 ramène cette réserve à 1 Gio. Les types de cache acceptés par -ctk et -ctv sont f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0 et q5_1, avec f16 par défaut.

Ollama applique la même mécanique avec d’autres valeurs : 4096 jetons par défaut selon sa FAQ, modifiables par OLLAMA_CONTEXT_LENGTH, et trois paliers automatiques selon la mémoire graphique, 4k en dessous de 24 Gio, 32k de 24 à 48 Gio, 256k au-delà. Le cache se règle par OLLAMA_KV_CACHE_TYPE, f16 par défaut, q8_0 pour environ la moitié de la mémoire et q4_0 pour environ le quart, avec Flash Attention activée.

Monter d’un palier coûte aussi de la vitesse

Dans les mesures publiées par llama.cpp pour Llama-3.1-8B, la génération de texte à 128 jetons donne 71,93 jetons par seconde en Q4_K_M, 67,23 en Q5_K_M, 58,67 en Q6_K et 50,93 en Q8_0. Passer de Q4_K_M à Q6_K gagne 0,15 point de perplexité et coûte près de 20 % de débit sur le matériel de mesure du dépôt.

Questions fréquentes sur le choix d’une quantification GGUF

Q4_K_M ou Q5_K_M pour un modèle 8B sur 16 Go de RAM ?

Q5_K_M occupe 5,83 Gio contre 5,08 Gio pour Q4_K_M à 4096 jetons, et ramène la perte de perplexité de +0,1754 à +0,0569 sur Llama-3-8B. Les deux tiennent sur 16 Go. Les 750 Mio d’écart deviennent décisifs seulement au-delà de 32k jetons de contexte, où 4 Gio de cache s’ajoutent.

Pourquoi un fichier Q4_K_M dépasse-t-il 4 bits par poids ?

Parce que le palier est un mélange, pas un type unique : certains tenseurs attn_v et ffn_down restent en Q6_K selon leur position dans le réseau, ce qui porte le fichier à 4,8944 bits par poids réels. Un Q4_K_M à exactement 4,00 bits par poids a été produit avec –pure et n’est pas équivalent.

Peut-on transformer un Q4_K_M téléchargé en Q5_K_M ?

Non, pas sans –allow-requantize, que la documentation du binaire déconseille en signalant une perte de qualité sévère par rapport à une conversion depuis le 16 bits. La seule entrée propre reste le bf16 ou le f32 d’origine, à garder sur disque après avoir produit un palier.

Comment estimer la taille d’un modèle 14B ou 32B sans le télécharger ?

En multipliant le nombre de paramètres par le bits par poids du palier, divisé par 8. Pour Q4_K_M, 4,8944 bits donnent 0,6118 octet par paramètre : 14 milliards de paramètres font 8,6 Go, 32 milliards en font 19,6 Go. La vérification tient sur Llama-3.1-8B, 8 030 261 312 paramètres annoncés par llama-server, dont le fichier Q4_K_M fait 4 912 898 304 octets, soit exactement 4,8944 bits par poids.

Un contexte plus long vaut-il un palier plus bas ?

À mémoire fixée, les deux postes se disputent la même place. Sur Llama-3.1-8B, passer de 4096 à 32768 jetons ajoute 3,5 Gio de cache, davantage que l’écart entre Q2_K et Q6_K. Descendre d’un palier libère 0,8 Gio en moyenne, raccourcir le contexte d’un facteur 8 en libère 3,5.

llama-cli -m modele-8B-Q4_K_M.gguf -c 8192