rwkv-quant : une seule matrice en bf16 élimine 39 % des pertes de quantification de RWKV-7 2.9B

La quantification des modèles de la famille RWKV, à structure récurrente linéaire, reste moins étudiée que celle des transformers. L'auteur de l'outil rwkv-quant, qui compresse RWKV-7 avec deux préréglages (environ 2.1x et environ 3.1x), a relevé une anomalie. Le préréglage agressif COMPRESSION donne +4.04 % de perplexité sur 2.9B, contre seulement +2.85 % sur 1.5B. L'analyse des causes montre qu'une part importante des pertes se loge dans une seule matrice 2560×2560. La stocker en bf16 coûte 0.5 % du fichier et supprime 39 % du KL.

Deux préréglages et six tailles

L'étude porte sur la gamme RWKV-7 en six tailles. Trois paires permettent de séparer l'effet de la largeur et celui de la profondeur : 0.4B/1.5B (même profondeur, largeur doublée), 2.9B/7.2B (profondeur 32, largeur 2560 contre 4096) et 7.2B/13.3B (largeur 4096, profondeur 32 contre 61).

• 0.1B : 12 couches, largeur 768
• 0.4B : 24 couches, largeur 1024
• 1.5B : 24 couches, largeur 2048
• 2.9B : 32 couches, largeur 2560
• 7.2B : 32 couches, largeur 4096
• 13.3B : 61 couches, largeur 4096

Le préréglage REDUCTION est quasiment sans perte : projections en 8 bits avec disposition symétrique et groupes de 16 poids, cmix (FFN) en 6 bits, embedding et tête en 8 bits. COMPRESSION est plus agressif : projections en 4 bits avec disposition asymétrique en super-blocs et groupes de 32, cmix en 4 bits (ffn.key en 5), tête en 5 bits, embedding en 6 bits. Dans les deux préréglages, les branches LoRA sont en 6 bits (g en 8). Dans les deux cas, l'échelle et le décalage des groupes sont déterminés par une recherche pondérée par le carré moyen de l'activation d'entrée du canal, E[x²].

Où le 2.9B casse

La décomposition du KL par groupes de matrices, selon la méthode leave-one-out, montre que sur 2.9B o_proj représente 46 % de l'ensemble du KL et l'embedding 17 %. Sur 1.5B, ces parts sont de 16 % et 3 %, et la contribution principale vient de cmix.value (37 %). Au sein de o_proj, 85–86 % des dégâts proviennent d'une seule matrice, la projection de sortie du bloc 0.

Une expérience directe sur 2.9B (chemin réel, MLX) le confirme :

• préréglage de base : KL 0.052048, +4.04 % de ppl ;
• o_proj de la couche 0 en bf16 : KL 0.031966, +2.43 % de ppl, fichier plus lourd de 9.4 Mo ;
• o_proj de la couche 31 en bf16 : aucun effet (+4.07 %) ;
• tout o_proj en 5 bits : +3.54 %, +26.2 Mo ;
• tout o_proj en 6 bits : +2.89 %, +52.4 Mo.

Une seule matrice en bf16 fait mieux que le passage de tout o_proj en 6 bits, pour un surcoût de taille plus de cinq fois inférieur. Sur les autres tailles, l'effet est plus faible : le KL baisse de 7.6 % sur 0.1B, de 1.5 % sur 0.4B, de 0.4 % sur 1.5B et de 3.9 % sur 7.2B. Seuls 0.1B et 2.9B sont significatifs.

L'entrée de cette matrice porte un « canal massif ». Sur 2.9B, huit canaux concentrent 98 % de l'énergie, et l'indice du canal, 517, est identique pour deux séries de checkpoints ; sur 1.5B, il s'agit du canal 1202. Il est donc déterminé par la largeur et l'architecture, et non par un entraînement particulier. Mais la force du canal ne prédit pas les dégâts : sur 7.2B, la concentration est la plus élevée (99 %), alors que le KL de base est le plus bas (0.023 contre 0.078 sur 2.9B). Sans pondération AW, 4 bits dans o_proj détruisent le 2.9B : KL 0.340, +37.2 % de ppl.

L'auteur montre que trois métriques d'erreur locales, pourtant naturelles, ne prédisent pas les dégâts. La bonne mesure s'est révélée être l'erreur dans le flux résiduel, multipliée par le gain mesuré.

Fuite de calibration et mesures fiables

Le premier jeu d'évaluation (38 fenêtres de 512 tokens, en/ru/sr) se trouvait entièrement à l'intérieur du corpus de calibration : 100 % de 16-grammes communs. L'ampleur de la fuite a été mesurée sur GPTQ. Sur 1.5B, le gain de KL est de −61.8 % sur l'ancien jeu et de −27.1 % sur le jeu propre : la fuite a donc gonflé le résultat d'un facteur 2.3. L'auto-sélection de la précision en bits n'en a pas tiré avantage : −16.1 % contre −17.6 %.

Les sections 7 à 10 de l'étude n'utilisent donc que des jeux propres : Wikipédia en/ru/sr (36 fenêtres), un jeu de code Python/Swift privé (24 fenêtres) et un jeu public (48 fenêtres). Les intervalles sont calculés par bootstrap apparié par fenêtres, avec 20 000 répétitions ; la demi-largeur de l'intervalle à 95 % pour le KL représente 7–12 % de la valeur.

L'étude décrit en outre une auto-sélection de la précision selon la règle « dégâts par octet », qui fonctionne dans les deux sens, et GPTQ appliqué à la grille du préréglage sans changer le format, les noyaux ni la taille du fichier. Ces méthodes se cumulent de façon quasi multiplicative. Une comparaison avec GGUF et MLX à taille de fichier égale est présentée séparément.

En pratique, la conclusion est simple. Si vous quantifiez RWKV-7 pour une exécution locale, en particulier sur Mac via MLX, gardez o_proj de la première couche en bf16 : cela représente 6–10 Mo sur les modèles 1.5B–2.9B. L'embedding mérite d'être conservé en 6 bits au minimum. Avant de se fier aux chiffres d'une méthode calibrée, vérifiez que l'intersection de 16-grammes entre le texte de calibration et le texte d'évaluation est nulle. Mieux vaut mesurer la contribution de chaque groupe de matrices par leave-one-out que de supposer que, sur un grand modèle, les pertes se répartissent uniformément.