Quantification : tirer davantage du même matériel

Vous avez une GPU de 16Go de VRAM et un modèle de 14 milliards de paramètres qui, à pleine précision, en demande environ 28. Le modèle ne rentre pas. Et pourtant : presque toujours, une quantification suffit à le faire tourner, avec une perte de qualité que vous ne remarquerez même pas.

La quantification est la technique qui rend possible l'exécution de grands modèles sur du matériel grand public. Dans cet article, vous comprenez ce qu'elle fait exactement, où elle perd en qualité et comment choisir le bon niveau, avec un exemple concret sur un modèle réel.

Qu'est-ce que la quantification

Un modèle de langage conserve ses paramètres sous forme de nombres. À l'entraînement, il les sauvegarde en haute précision : typiquement 16 bits (FP16) ou 32 bits (FP32). Chaque paramètre occupe 2 ou 4 octets, et multiplié par des milliards de paramètres, la dimension devient énorme.

La quantification réduit la précision de ces nombres. Au lieu de 16 bits par paramètre, elle en utilise par exemple 4. Le fichier devient plus petit et, par conséquent, il occupe moins de mémoire et tourne plus vite, car la GPU lit moins de données depuis la VRAM.

Aucun « plus petit modèle » n'est entraîné : c'est le même modèle, les mêmes poids, simplement représentés avec moins de bits. C'est une compression, pas une autre architecture.

Pourquoi la VRAM est la vraie limite

La vitesse de génération dépend de la bande passante mémoire : à chaque token, la GPU doit relire les poids. Moins de poids, moins de données à déplacer, plus de tokens par seconde. La quantification gagne donc sur deux fronts :

1. Mémoire — le modèle occupe moins de VRAM, et il en reste davantage pour le cache de contexte.
2. Vitesse — à GPU égale, le modèle quantifié génère plus de tokens par seconde.

Sur une GPU à mémoire limitée (12-16Go), c'est souvent la différence entre « ça tourne » et « ça ne tourne pas du tout ».

Les niveaux : Q2, Q4, Q5, Q8

Les fichiers pour l'inférence locale sont presque toujours au format GGUF, le standard de fait né avec llama.cpp. Le suffixe dans le nom indique le niveau de quantification :

• FP16 — précision complète. La référence, mais le plus gros.
• Q8_0 — 8 bits. Qualité quasi indiscernable de FP16.
• Q6_K — 6 bits. Presque identique, fichier plus contenu.
• Q5_K_M — 5 bits. Excellent compromis qualité et encombrement.
• Q4_K_M — 4 bits. Le standard de fait : la plupart des setups locaux partent d'ici.
• Q3_K_M — 3 bits. Quand la VRAM est vraiment peu nombreuse.
• Q2_K — 2 bits. Extrême : la qualité dégrade de façon perceptible.

Le « K » désigne les « K-quant », une famille de quantification plus sophistiquée qui répartit les bits de façon non uniforme, en protégeant les paramètres les plus importants. C'est pourquoi un Q4_K_M rend presque toujours mieux qu'un Q4_0 à bits égaux.

Exemple concret : Qwen2.5 14B

Prenons Qwen2.5-14B-Instruct, un modèle de 14 milliards de paramètres très utilisé en local. Les tailles réelles des fichiers GGUF officiels du dépôt Hugging Face :

Niveau	Taille du fichier	Qualité perçue
FP16	~28 Go	Référence
Q8_0	~15,7 Go	Quasi identique
Q6_K	~12,1 Go	Quasi identique
Q5_K_M	~10,5 Go	Excellente
Q4_K_M	~9,0 Go	Très bonne (le standard)
Q3_K_M	~7,3 Go	Bonne, avec des baisses sur les tâches difficiles
Q2_K	~5,7 Go	Pobre, usage occasionnel

Sur une GPU de 16Go (RTX 4060 Ti 16Go, RTX 5080), Q4_K_M laisse environ 7Go libres pour le cache de contexte, de quoi accueillir des dizaines de milliers de tokens. Sur une GPU de 12Go (RTX 3060 12Go), Q4_K_M rentre à peine en contexte court, tandis que Q5_K_M non : c'est le point où le niveau cesse d'être un choix esthétique pour devenir une nécessité.

La règle pratique : partez de Q4_K_M, montez à Q5_K_M ou Q6_K si la mémoire est là et que vous avez besoin de plus de qualité, descendez à Q3_K_M seulement s'il n'y a pas d'alternative.

Comment choisir en pratique

1. Partez du modèle qui vous sert (voir comment choisir le premier modèle) et vérifiez combien de Go il occupe en Q4_K_M.
2. Comparez avec votre VRAM, en gardant 2 à 4Go de côté pour le cache de contexte.
3. S'il ne rentre pas, descendez d'un niveau. S'il rentre avec de la marge, envisagez de monter.
4. Testez. La qualité perçue dépend du modèle et de la tâche : pour résumer des documents, Q3_K_M suffit souvent ; pour le raisonnement ou le code, Q4_K_M et plus.

Avec Ollama, le niveau est implicite dans le tag : ollama run qwen2.5:14b télécharge la variante Q4_K_M, le défaut de la bibliothèque. Avec llama.cpp ou LM Studio, vous choisissez le fichier GGUF explicitement et avez le contrôle total.

Les limites à connaître

• Ce n'est pas gratuit. En dessous de Q4_K_M, la perte devient réelle, surtout sur : le code, le raisonnement en plusieurs étapes, la génération dans des langues autres que l'anglais.
• Le contexte pèse. Un modèle qui « rentre » en contexte court peut ne plus rentrer en contexte long, car le cache clé-valeur croît avec les tokens.
• Chaque modèle réagit différemment. Un 7B en Q3_K_M peut être plus utile qu'un 14B en Q2_K. La taille compte, mais la quantification la module.

En résumé

La quantification est la raison pour laquelle un 14B tourne sur votre 16Go. La comprendre vous donne le contrôle sur un compromis que vous gèreriez autrement au feeling : qualité contre mémoire et vitesse. Partez de Q4_K_M, mesurez sur votre VRAM et réglez un niveau à la fois.

Vous voulez comprendre comment ces chiffres se traduisent dans le choix d'un modèle pour votre matériel ? Continuez avec comment lire les spécifications d'un modèle et quand un grand modèle ne sert à rien.

Article généré par IA