La quantification, en profondeur

La quantification réduit les poids de flottants 16 bits vers moins de bits, échangeant un peu de qualité contre beaucoup de mémoire. La version en une ligne (Q8 ≈ sans perte, Q4_K_M ≈ point optimal, sous Q3 ça fait mal) suffit pour démarrer. Cette page descend d'un niveau : ce que les étiquettes font réellement, comment K-quants et I-quants diffèrent, et où la perte de qualité apparaît en premier.

Pourquoi le 4 bits marche du tout

Les poids entraînés ne sont pas du bruit uniforme. Les valeurs de chaque tenseur se regroupent dans une distribution étroite à peu près en cloche, et le comportement du réseau est porté par la forme de cette distribution — pas par la dernière décimale d'un poids pris isolément. Cela rend les poids compressibles : stockez chaque poids comme un petit entier plus un facteur d'échelle partagé, et vous ne perdez que le détail fin.

Une vraie complication : les canaux aberrants. Une petite fraction de canaux porte des activations bien plus grandes que le reste. Une échelle unique pour tout le tenseur dépense toute sa plage sur ces aberrants et écrase le reste en boue. Tout schéma de quant sérieux est fondamentalement un schéma de traitement des aberrants — échelles par bloc, protection sensible aux activations (AWQ), ou calibration contre des données réelles (imatrix).

Mécanique de la quantification par blocs

L'astuce centrale : découper chaque tenseur en petits blocs qui partagent une échelle. Déquantifier un poids est une seule multiplication :

w ≈ s · q                       # s : échelle de bloc, q : entier stocké

Q4_0:     bloc = 32 poids → 1×fp16 échelle + 32×entiers 4 bits ≈ 4.5 bpw
K-quants: super-bloc = 256 poids
          1×fp16 super-échelle + 8×fp8 sous-échelles + entiers ≈ 4.8 bpw

bpw = bits par poids, frais généraux d'échelle compris. Ces frais expliquent pourquoi rien ne fait exactement 4.0 : un poids 4 bits fait un demi-octet, et une échelle de 2 octets répartie sur 32 poids ajoute 0.5 bpw. Les K-quants amortissent le coût avec une mise à l'échelle à deux niveaux — des super-blocs de 256 poids dont les 8 sous-blocs reçoivent des échelles fp8 bon marché — et atterrissent à ~4.8 bpw avec une meilleure qualité que Q4_0 à taille similaire.

Les K-quants et les suffixes _M / _S

Q4_K_M n'est pas « Q4_K avec un chapeau » — le suffixe est un mix. Le quantificateur monte des tenseurs précis vers un quant supérieur tandis que la masse reste en Q4_K : typiquement les projections d'attention (wv, wo) et parfois la table d'embedding des jetons passent en Q6_K. Le suffixe classe le mix :

• _S (small) — le moins de tenseurs montés, le plus petit fichier
• _M (medium) — la recommandation par défaut, meilleur équilibre taille/qualité
• _L (large) — plus de tenseurs à plus haute précision, rendements décroissants

Le mix existe parce que les couches se dégradent inégalement : projections d'attention et embeddings sont plus sensibles que les grosses matrices feed-forward. Quelques centaines de MB de plus là achètent de la vraie qualité — voilà pourquoi _M est le défaut communautaire plutôt que le Q4_K simple.

I-quants : calibrés, plus petits, lents sur CPU

Les quants IQ (IQ4_XS, IQ3_XXS, IQ2_XS…) ajoutent une étape de calibration. D'abord calculer une matrice d'importance (imatrix) en exécutant le modèle sur un échantillon de texte représentatif ; puis placer les niveaux de quantification là où vivent réellement les poids qui comptent. Le gain : une qualité donnée à une taille inférieure au K-quant équivalent — IQ4_XS bat Q4_K_S à qualité égale ou supérieure, et IQ2/IQ3 rendent possibles les modèles 7–8B sous les 3 GB tout court.

La contrepartie est la vitesse de décodage. La déquantification I-quant n'est pas une simple multiplication — elle exige des lookups hors puissances de deux et une reconstruction structurée. Sur CPU, ces maths supplémentaires se voient en jetons/s ; sur GPU, elles se cachent derrière la latence mémoire et ne coûtent presque rien. Règle empirique : K-quants pour les machines CPU, I-quants très bien sur GPU, IQ2/IQ3 seulement quand la VRAM vous y force.

L'échelle de qualité, honnêtement

Tailles de fichier approximatives pour un modèle 7–8B. Ça passe à l'échelle à peu près linéairement avec les paramètres — un 14B fait environ le double :

Traitez les pourcentages exacts comme de qualité folklore : la perte dépend du modèle, de la langue et de la tâche. L'ordre est stable même quand les ampleurs ne le sont pas.

Où la quantification fait mal en premier

Les dégâts ne sont pas uniformes entre capacités. À peu près par ordre décroissant :

1. Rappel factuel — noms, dates, chiffres dérivent en premier. Un modèle Q3 attribue mal avec assurance.
2. Maths et raisonnement multi-étapes — les petites erreurs se composent le long de la chaîne.
3. Cohérence long contexte — la récupération au fond d'un long prompt devient plus vacillante que le comportement en prompt court ne le suggère.
4. Langues moins dotées — le coréen se dégrade plus tôt que l'anglais aux quants lourds ; les jetons coréens étaient plus rares à l'entraînement, il y a donc moins de mou de précision. Si le coréen compte pour vous, tenez Q5+ quand vous le pouvez.
5. Fluidité et style du chat — se voit à peine. Un modèle Q2 sonne encore bien, et c'est le piège : la fluidité est un mauvais indicateur des dégâts.

Les petits modèles souffrent davantage

L'erreur de quantification mange la redondance, et les petits modèles en ont le moins. Un 70B en Q4 ne perd presque rien ; un 3B en Q4 perd visiblement plus ; sous ~2B, les quants lourds peuvent vider le modèle de sa substance. Règle pratique : Q6_K ou Q8_0 pour tout ce qui est sous ~4B paramètres — les GB absolus économisés en écrasant un petit modèle sont de toute façon minuscules. Prenez le repère taille-vs-capacité dans paramètres avant de décider où dépenser des bits.

Le cache KV est une décision séparée

Quantifier les poids ne fait rien au cache KV — c'est sa propre ligne mémoire (fp16 par défaut, séparément quantifiable en q8_0/q4_0 dans llama.cpp). En long contexte, le cache peut rivaliser avec les poids en taille ; budgétez-le indépendamment dans cache KV.

Une échelle de décision pratique

Exemple détaillé — carte 12 GB, modèle dense 8B, contexte 8k :

poids          Q4_K_M                 4.9 GB
cache KV       8k jetons, fp16        1.0 GB    (8B GQA ≈ 128 KiB/jeton)
frais généraux tampons de calcul + ctx  ~1.5 GB
─────────────────────────────────────────
total                                 ~7.4 GB  → tient avec de la marge

Avec le calcul de VRAM, l'échelle :

1. Budget : VRAM − contexte − frais généraux = ce qui reste pour les poids.
2. Q6_K tient → exécutez Q6_K. Seul Q4_K_M tient → exécutez Q4_K_M sans culpabilité.
3. Descendez à IQ4_XS/Q3 seulement pour faire tenir le contexte ou éviter le délestage CPU — le délestage coûte plus de vitesse qu'un pas de quant ne coûte de qualité.
4. Si votre modèle cible ne tient pas en Q4, descendez d'une classe de taille plutôt que de quantifier en Q2 : un 8B solide en Q4 bat habituellement un 14B écrasé en pratique.

Voir aussi : calcul de VRAM · cache KV · paramètres · formats de modèles