Quantification : ce que vous perdez vraiment

Le modèle en 4 bits affiche une perplexité à 2 % de celle du modèle d'origine. Vous le déployez sur votre tâche d'extraction. Une semaine plus tard, 6 % des sorties JSON ne passent plus la validation : une accolade manquante au bout de 900 tokens, un montant où 1 250,00 est devenu 1 205,00, une clé "date_échéance" écrite "date_echeance".

Rien de cela ne contredit les 2 %. La perplexité est une moyenne sur tous les tokens d'un texte courant, et dans un texte courant la plupart des tokens sont faciles. Votre tâche, elle, se joue sur quelques tokens difficiles (un chiffre, un délimiteur, un caractère accentué dans un identifiant) où la bonne réponse ne devançait la mauvaise que de peu. La quantification déplace un peu toutes les probabilités, mais elle ne fait basculer que les décisions serrées, et ce sont justement celles que vous vérifiez.

Un arrondi qui fait bifurquer la génération

Quantifier consiste à stocker chaque poids sur moins de bits, 8, 5, 4, parfois 3, au lieu de 16. Chaque poids est arrondi à la valeur représentable la plus proche. L'erreur d'arrondi sur un poids est minuscule ; un modèle en compte des milliards, enchaînés sur des dizaines de couches, et l'erreur de sortie d'une couche devient l'entrée de la suivante.

Les schémas courants ne traitent pas tous les poids de la même manière. Ils gardent plus de bits pour les couches ou les blocs dont l'arrondi coûte le plus, d'où les variantes mixtes qu'on voit dans les noms de fichiers. Cela réduit la perte moyenne sans changer sa nature.

À la sortie, le modèle produit une distribution de probabilité sur le token suivant, que la quantification perturbe légèrement. Selon la marge, l'effet diffère du tout au tout.

décision large                     décision serrée
  « Paris »   0,97 → 0,96            « 5 »   0,48 → 0,44
  « Lyon »    0,01 → 0,015           « 0 »   0,45 → 0,47
  → même token choisi                → le token choisi change