Explication de la quantification sensible à la sensibilité : comment OrcaSAQ décide quels poids obtiennent plus de bits

La quantification consciente de la sensibilité consiste à dépenser votre budget de bits là où cela compte : les tenseurs que la quantification pénalise le plus reçoivent plus de bits, et tout le reste demeure à une largeur de base inférieure. Cet article explique comment OrcaSAQ — notre méthode de précision mixte sans calibrage et consciente de l’architecture, publiée avec la GLM-5.3-Flashfamille de quantification orcarouter/GLM-5.3-Flash-MLX — détermine lesquels des 37 338 tenseurs d’un modèle Mixture-of-Experts de 320 milliards de paramètres méritent des bits supplémentaires, sans le moindre jeu de données de calibrage. La leçon transférable pour quiconque quantifie un MoE différent : les experts partagés et les projections descendantes méritent les bits supplémentaires, et vous pouvez les trouver en vous servant uniquement des métadonnées de quantification de la version amont elle-même.

La réponse courte

La quantification tenant compte de la sensibilité est une précision mixte avec une politique : la largeur de bits de chaque tenseur dépend de sa sensibilité à l'erreur de quantification, au lieu d'une largeur unique pour tout le modèle. La littérature de recherche mesure la sensibilité à l'aide des hessiennes, de l'information de Fisher ou de la divergence entre les sorties des couches originales et quantifiées, puis alloue des bits aux couches les plus touchées. OrcaSAQ appartient à une famille plus restreinte qui saute entièrement la mesure. Elle encode le classement de sensibilité dans l'architecture elle-même : elle utilise des a priori architecturaux et liés au rôle des tenseurs pour décider quels poids sont fragiles, puis quantifie tout le reste à une précision de base cible.

Ce que cela vous apporte, c'est un pipeline rapide, déterministe et sans calibration. Il n'y a pas de corpus de calibration à assembler, ni de recherche de sensibilité par couche, ni de réglage par modèle, de sorte que la même recette se transfère à une nouvelle architecture dès le jour où ses poids sont publiés. Ce qu'il sacrifie, c'est l'adaptation : une méthode pilotée par calibration, comme GPTQ ou AWQ, examine la distribution d'activation réelle de votre modèle et de vos données, et elle obtient généralement plus de qualité pour la même largeur de bits moyenne. Le pari d'OrcaSAQ est que, pour les modèles Mixture-of-Experts, le rôle d'un tenseur en dit presque autant qu'une exécution de calibration, pour une fraction du coût.

Deux façons de trouver les poids sensibles

Avant la politique, la question : comment savoir quels tenseurs la quantification pénalise ? Les deux réponses couvrent tout l'espace de conception.

• Piloté par calibration.Faites passer un petit corpus dans le modèle, mesurez l'erreur causée par chaque tenseur ou bloc, et allouez les bits pour minimiser l'erreur totale de reconstruction. GPTQ utilise une approximation basée sur la Hessienne pour l'erreur de quantification par couche ; AWQ utilise les statistiques d'activation pour identifier les poids saillants à protéger. La force réside dans l'adaptation à vos données réelles ; les coûts sont un corpus soigneusement sélectionné, des passes avant et des résolutions d'inverse de Hessienne pour chaque couche, ainsi que des résultats qui varient lorsque l'ensemble de calibration change.

• Sans calibrage.Déterminez le classement de sensibilité avant de voir toute donnée, à partir de l'architecture. Dans un MoE, vous connaissez déjà les rôles porteurs : l'expert qui se déclenche sur chaque jeton, et la projection qui écrit dans le flux résiduel. Encodez ce classement comme une politique fixe et appliquez-le mécaniquement.

OrcaSAQ est fermement dans le deuxième camp, et cet article est une défense de ce camp pour la quantification MoE — avec un compte rendu lucide de ce que vous sacrifiez pour cela.

La politique : quels tenseurs obtiennent plus de bits

La politique d'allocation de bits d'OrcaSAQ est indiquée dans la fiche du modèle pour orcarouter/GLM-5.3-Flash-MLX, et elle se réduit à trois règles plus une exception. La base de précision est la construction que vous faites — 6, 4, 3 ou 2 bits — et la politique élève des rôles de tenseurs spécifiques au-dessus de cela :

• Expert partagé : base +2 bits. L'expert partagé s'active sur chaque jeton, si bien que son erreur de quantification est réinjectée dans chaque sortie produite par le modèle. C'est le tenseur le plus influent du modèle, et il reçoit le plus de bits.

• down_proj : base +1 bit. Dans un bloc MLP SwiGLU, la projection descendante est le goulot d'étranglement résiduel — sa sortie est ajoutée directement au flux résiduel que chaque couche plus profonde lit. Une erreur ici corrompt directement tout ce que les couches en aval voient.

• gate_proj et up_proj : précision de base.Ce sont les chemins d'expansion et de gating ; leurs sorties sont multipliées élément par élément dans l'activation. Une erreur modeste y est en partie atténuée par le gating, de sorte qu'ils tolèrent la largeur de base.

• Jamais quantifiés, conservés en BF16 : les 34 couches d'attention linéaire, l'indexeur épars appris, les tableaux d'hyper-connexion, les normes, embed_tokens, lm_head, et toute la tour de vision. Ces éléments n'étaient pas en FP8 dans la version en amont, et ils restent en pleine précision.

Le nombre de bits est arrondi au supérieur, vers la largeur prise en charge par MLX la plus proche, soit {2,3,4,5,6,8}. Concrètement, sur GLM-5.3-Flash — 320B au total / 18B actifs, 288 experts routés plus 1 expert partagé avec routage top-8, 45 couches — la version 4 bits attribue 6 bits à l’expert partagé, 5 bits à chaque projection descendante, et 4 bits aux projections de porte et ascendantes. La version 6 bits arrondit les projections descendantes à 8 bits. La taille de groupe est de 64 pour les versions 4 et 6 bits, de 32 pour les versions 2 et 3 bits, et l’expert partagé utilise toujours 64.

La règle de l'expert partagé en vaut-elle la peine ? Avec une base de 2 bits, l'expert partagé se situe à 4 bits, et avec une base de 6 bits, à 8 — dans les deux cas, les deux bits supplémentaires coûtent de la mémoire que les experts routés auraient pu utiliser autrement, et les chiffres de la fiche du modèle, discutés plus bas, suggèrent que le compromis est rentable. C'est le même raisonnement qui rend la version 2bit-lite digne d'être diffusée : l'expert toujours actif est l'endroit où un peu de précision supplémentaire apporte le plus.

La règle de sélection : _scale_inv comme signal de sensibilité libre

La politique d'allocation des bits suppose que vous savez déjà quels tenseurs sont candidats. C'est en choisissant cet ensemble qu'OrcaSAQ se montre le plus astucieux, car la règle est mécanique et ne nécessite aucune donnée : un tenseur est re-quantisé si et seulement si la version FP8 l'a livré avec un compagnon _scale_inv.

Pourquoi cela fonctionne : la base amont GLM-5.3-Flash est en FP8 — par blocs e4m3, blocs de 128×128, avec un schéma d'activation dynamique. La quantification FP8 par blocs stocke une échelle et son inverse pour chaque bloc, avec le poids ; la présence de _scale_inv dans le checkpoint est un marqueur durable indiquant que le tenseur a suivi le chemin de quantification en amont. La version amont vous a déjà dit quels tenseurs sont sûrs à quantifier — pas de Hessien, pas de corpus de calibration, pas de passes avant.

Pour GLM-5.3-Flash, cet ensemble correspond aux couches linéaires MoE et dense-MLP, plus les quatre projections de chaque bloc de type deepseek_sparse_attention — q_a_proj, q_b_proj, kv_a_proj_with_mqa, et o_proj — sur les 11 couches éparses aux profondeurs 3, 7, 11 … 43, plus le bloc MTP, 12 × 4 = 48 tenseurs. Tout le reste n’a jamais porté le marqueur et reste en BF16 : les 34 linear_attention couches, l’indexeur épars et la tour de vision. La couche MTP — couche 45 — est incluse dans les poids quantifiés plutôt que d’être exportée en tant que module séparé.

Ce qui vaut la peine d'être repris, c'est l'astuce elle-même. Une version de modèle qui quantifie ses poids en amont a déjà effectué une grande partie du travail consistant à décider ce qui peut être quantifié ; le marqueur _scale_inv est cette décision, sérialisée dans le format de fichier. OrcaSAQ la relit. C'est ce qui rend le pipeline déterministe et transférable — tout modèle qui fournit des poids FP8 avec des métadonnées d'échelle peut être pris en charge par la même règle, sans aucun pipeline de données.

L'écueil : une configuration par module, pas de bits au niveau supérieur.

Si vous écrivez votre propre quantificateur MLX — et c'est à ce public que s'adresse cette section — la chose la plus utile dans la carte du modèle est un avertissement : au niveau racine, les bits et group_size dans config.json ne suffisent pas.

Au total, 37 338 tenseurs sont quantifiés. L’affectation est enregistrée dans config.json → quantization sur une base par module {group_size, bits}, avec des surcharges indexées par chemin de module MLX — par exemple model.layers.3.mlp.switch_mlp.down_proj. Comme MLX fusionne les experts routés d’une couche en un seul switch_mlp, 173 entrées couvrent les 37 338 tenseurs.

Et le chargeur lit ces entrées au moment du chargement. Si vous quantifiez tout le fichier à la largeur de base, chaque tenseur à précision augmentée — l'expert partagé à base +2, chaque projection descendante à base +1 — se retrouve avec la mauvaise largeur, et le modèle se charge avec une forme incorrecte. La carte par module n'est pas une optimisation que vous pouvez ignorer ; c'est le chemin de chargement. Lorsque vous écrivez votre propre quantificateur, émettez les remplacements pour chaque tenseur que la politique élève, et vérifiez-les par rapport à la valeur par défaut de niveau supérieur avant de livrer.

La police se rentabilise-t-elle ?

Les preuves sont les nôtres, mesurées sur un seul modèle : GLM-5.3-Flash, chaque build déquantifié et exécuté via le même glm5_next forward, si bien que la seule variable est la quantification. Les chiffres ci-dessous proviennent de la fiche du modèle, et ce ne sont ni des benchmarks de fournisseurs ni des données d’un tiers — prenez-les comme un point de données unique, pas comme une loi.

Perplexité, par rapport à la référence FP8 à 2,7797 : 6 bits 2,7864 (+0,24 %), 4 bits 2,8620 (+2,96 %), 3 bits 3,0566 (+9,96 %), 2 bits 4,3622 (+56,9 %).

• Concordance de jetons Top-1 avec la référence, dans le même ordre : 97,76 %, 96,13 %, 92,06 %, 86,56 %.

La lecture correspond exactement à ce que prévoit la politique. Tout jusqu'au 3 bits se dégrade en douceur — c'est la signature d'un budget de bits dépensé sur les bons tenseurs — et le 2 bits est un précipice, car en dessous d'un certain seuil, les rehaussements basés sur les rôles cessent de couvrir les dégâts. En 4 bits, +2,96 % de perplexité pour un build environ 38 % plus petit que la référence FP8 est un compromis réellement intéressant, et c'est la même politique, appliquée plus agressivement, qui permet au build 2bit-lite de 102 Go de se charger tout court. Les praticiens indépendants qui quantifient la même base rapportent le même ordre — les échelons supérieurs près du plancher de bruit, le 4 bits réel mais modeste — avec des nombres absolus différents issus d'un corpus d'évaluation différent.

Qu'est-ce qui est transféré vers votre propre MoE ?

Le raisonnement réutilisable, pour un modèle qui n'est pas le nôtre :

• Trouvez les experts toujours actifs. Tout ce qui se déclenche à chaque jeton — généralement un expert partagé ou toujours routé — reçoit vos bits les plus généreux. Son erreur est rejouée partout.

• Trouvez les goulots d'étranglement résiduels.La projection qui écrit dans le flux résiduel (généralement la projection descendante de chaque bloc MLP) reçoit une base +1. Une erreur à cet endroit est visible pour chaque couche plus profonde.

• Laissez les chemins d'expansion et de gating à leur valeur de base. Si une sortie est multipliée élément par élément à l'intérieur d'une activation, l'erreur de quantification qui s'y trouve est partiellement absorbée.

• Jamais quantifié en amont signifie jamais quantifié par vous. Si la version de base transportait ces tenseurs en pleine précision, transportez-les en pleine précision.

• Utilisez les métadonnées d'échelle de la version en amont comme règle de sélection. Si le modèle de base quantifie ses poids, les marqueurs d'échelle/d'échelle inverse qu'il laisse derrière lui sont une carte gratuite de ce qui est quantifiable — aucune recherche de sensibilité n'est requise.

• Enregistrez les remplacements par module. Une largeur de bits globale déformera chaque tenseur élevé au chargement. Écrivez la carte des chemins de modules.

Et si vous pouvez conserver un ensemble de calibration, utilisez-le pour auditer la politique — pas pour la remplacer. Effectuez une quantification pilotée par calibration au même nombre moyen de bits et vérifiez si l'ordre du prior de rôle correspond à ce que disent les données. Sur un modèle dense ou une toute nouvelle architecture, cet audit fait la différence entre un défaut défendable et une supposition.

Là où OrcaSAQ est le mauvais choix

C'est la section qui devrait garder la méthode honnête, car le compromis sans calibration est bien réel.

• Lorsque le plafond de qualité prime sur la vitesse du pipeline, et que vous disposez d'un ensemble de calibration. Les méthodes de type GPTQ ou AWQ s'adaptent aux statistiques d'activation réelles de votre modèle et de vos données, et à nombre moyen de bits égal, elles surpassent généralement une politique fixe basée sur les rôles. Si vous quantifiez un modèle une seule fois sans jamais le re-quantifier, les heures supplémentaires de calibration représentent un coût unique qui procure une qualité mesurable.

• Modèles denses non-MoE. L'a priori de rôle — expert partagé, gate/up/down — n'existe pas, donc la politique perd la structure qui la rend fiable. Il ne reste que « tout ce qui est quantifié en amont reste quantifié », ce qui est une affirmation plus faible.

• Modèles sans publication amont FP8. La _scale_inv règle de sélection n'a rien sur quoi s'appuyer. Vous devez déterminer l'ensemble quantifiable d'une autre manière, et l'argument de transférabilité mécanique s'effondre.

• Des architectures entièrement nouvelles.Les a priori sont précisément les hypothèses qui peuvent ne pas se vérifier. Une méthode pilotée par calibration détecterait un tenseur fragile qu'une politique basée sur les rôles aurait manqué ; OrcaSAQ ne le fera pas, car il ne regarde jamais.

• Cibles sous 3 bits. La politique ne vous sauve pas. À 2 bits, le modèle a une perplexité de +56.9% peu importe où sont allés les bits supplémentaires ; la version 2bit-lite existe pour l’ajustement, pas pour la qualité.

• Lorsque vous avez besoin de garanties. Les garanties par tenseur, les budgets d’entraînement sensible à la quantification (QAT), ou la meilleure qualité possible pour une taille fixe sans tenir compte du coût du pipeline relèvent tous du territoire de la calibration.

En résumé

La quantification tenant compte de la sensibilité est la pratique ; OrcaSAQ est une recette déterministe et sans calibration pour y parvenir. Les leçons durables sont les élévations de l'expert partagé et de la projection descendante, la règle de sélection mécanique _scale_inv, et la configuration par module que le chargeur lit réellement. Pour un MoE de 320 milliards de paramètres comme GLM-5.3-Flash, cette recette produit une version MLX 4 bits à +2,96 % de perplexité — et le dépôt orcarouter/GLM-5.3-Flash-MLX fournit la même politique en 2, 3, 4 et 6 bits, avec une version séparée 2bit-lite pour les machines de 128 Go. Notre guide GLM-5.3-Flash-MLX couvre, étape par étape, quelle version exécuter sur quelle machine.

Si votre priorité est la dernière once de qualité à taille fixe et que vous pouvez constituer un corpus de calibration, utilisez les outils pilotés par calibration et laissez-les s'adapter. Si votre priorité est une quantification reproductible, rapide, sans données, qui se transpose à la prochaine architecture — ou si vous ne souhaitez tout simplement pas construire de pipeline de données — la politique fondée sur les rôles est un choix par défaut défendable. Et si vous préférez ne pas quantifier du tout, la version pleine précision de GLM-5.3-Flash est servie via OrcaRouter sous le nom z-ai/glm-5.3-flash. Le choix porte sur la quantité de pipeline que vous êtes prêt à exécuter, pas sur la question de savoir si la quantification tenant compte de la sensibilité vaut la peine d'être faite.

Vous préférez ne rien quantifier du tout ? z-ai/glm-5.3-flash est le modèle en pleine précision servi sur OrcaRouter au prix du fournisseur, avec 0% de majoration.