Gevoeligheidsbewuste kwantisering uitgelegd: hoe OrcaSAQ bepaalt welke gewichten meer bits krijgen

Gevoeligheidsbewuste kwantisering is de praktijk om je bitbudget uit te geven waar het ertoe doet: de tensoren die het meest onder kwantisering lijden krijgen meer bits, en al het andere blijft op een lagere basisbreedte. Dit artikel legt uit hoe OrcaSAQ — onze kalibratievrije, architectuurbewuste mixed-precision-methode, uitgebracht met de GLM-5.3-Flashkwantisatiefamilie orcarouter/GLM-5.3-Flash-MLX — bepaalt welke van de 37.338 tensoren in een Mixture-of-Experts-model met 320 miljard parameters extra bits verdienen, volledig zonder kalibratiedataset. De overdraagbare les voor iedereen die een andere MoE kwantiseert: gedeelde experts en down-projecties verdienen de extra bits, en je kunt ze vinden met niets meer dan de kwantiseringsmetadata van de upstream-release zelf.

Het korte antwoord

Gevoeligheidsbewuste kwantisering is gemengde precisie met een beleid: de bitbreedte van elke tensor volgt hoe gevoelig die is voor kwantiseringsfouten, in plaats van één breedte voor het hele model. De onderzoeksliteratuur meet gevoeligheid met Hessianen, Fisher-informatie of divergentie tussen outputs van oorspronkelijke en gekwantiseerde lagen, en kent vervolgens bits toe aan de lagen die het zwaarst lijden. OrcaSAQ behoort tot een kleinere familie die de meting volledig overslaat. Het codeert de gevoeligheidsrangorde in de architectuur zelf: het gebruikt architecturale en tensorrol-priors om te bepalen welke gewichten fragiel zijn, en kwantiseert vervolgens al het andere op een beoogde basisprecisie.

Wat dat je oplevert is een snelle, deterministische pipeline zonder kalibratie. Er is geen kalibratiecorpus om samen te stellen, geen zoektocht naar gevoeligheid per laag en geen her-afstemming per model, dus hetzelfde recept is overdraagbaar naar een nieuwe architectuur op de dag dat de gewichten uitkomen. Wat het opoffert is aanpassingsvermogen: een kalibratiegedreven methode zoals GPTQ of AWQ kijkt naar de daadwerkelijke activatieverdeling van je model en je data, en zal meestal meer kwaliteit uit dezelfde gemiddelde bitbreedte persen. De weddenschap van OrcaSAQ is dat voor Mixture-of-Experts-modellen de rol van een tensor je het grootste deel vertelt van wat een kalibratierun zou doen, tegen een fractie van de kosten.

Twee manieren om de gevoelige gewichten te vinden.

Vóór het beleid, de vraag: hoe weet je welke tensors kwantisatie schaadt? De twee antwoorden vormen de gehele ontwerpruimte.

• Kalibratiegedreven. Laat een klein corpus door het model lopen, meet de fout die elke tensor of elk blok veroorzaakt, en wijs bits toe om de totale reconstructiefout te minimaliseren. GPTQ gebruikt een Hessiaan-gebaseerde benadering van de kwantiseringsfout per laag; AWQ gebruikt activatiestatistieken om de belangrijkste gewichten te identificeren die beschermd moeten worden. De kracht is de aanpassing aan uw daadwerkelijke data; de kosten zijn een samengesteld corpus, forward passes en inverse-Hessiaan-oplossingen voor elke laag, en resultaten die verschuiven wanneer de kalibratieset verandert.

• Kalibratievrij.Bepaal de gevoeligheidsrangschikking voordat je gegevens ziet, op basis van de architectuur. In een MoE weet je al welke rollen het zwaarst wegen: de expert die op elke token vuurt, en de projectie die in de residustroom schrijft. Codeer die rangschikking als een vast beleid en pas het mechanisch toe.

OrcaSAQ staat stevig in het tweede kamp, en dit artikel is een verdediging van dat kamp voor MoE-kwantisering — met een nuchtere uiteenzetting van wat je daarvoor inlevert.

Het beleid: welke tensoren krijgen meer bits

Het bittoewijzingsbeleid van OrcaSAQ staat vermeld in de modelkaart voor orcarouter/GLM-5.3-Flash-MLX, en het komt neer op drie regels plus één uitzondering. De basisprecisie is de build die je maakt — 6, 4, 3 of 2 bits — en het beleid verhoogt specifieke tensorrollen boven dat niveau:

• Gedeelde expert: basis +2 bits. De gedeelde expert wordt op elk token geactiveerd, dus de kwantiseringsfout wordt herhaald in elke uitvoer die het model produceert. Het is de meest invloedrijke tensor in het model, en het krijgt de meeste bits.

• down_proj: basis +1 bit. In een SwiGLU MLP-blok is de down-projectie de residuele bottleneck — de output ervan wordt rechtstreeks toegevoegd aan de residuele stroom die elke diepere laag leest. Een fout hier beschadigt direct wat alles stroomafwaarts ziet.

• gate_proj en up_proj: basisprecisie. Dit zijn de expansie- en gating-paden; hun uitvoer wordt elementsgewijs vermenigvuldigd binnen de activatie. Een bescheiden fout daarin wordt gedeeltelijk geneutraliseerd door de gating, dus ze tolereren de basisbreedte.

• Nooit gekwantiseerd, opgeslagen in BF16: de 34 linear-attention-lagen, de geleerde sparse indexer, de hyper-connectie-arrays, de normen, embed_tokens, lm_head, en de gehele vision tower. Deze waren niet FP8 in de upstream-release en blijven op volledige precisie.

Bits worden naar boven afgerond op de dichtstbijzijnde door MLX ondersteunde breedte, {2,3,4,5,6,8}. Concreet, op GLM-5.3-Flash — 320B totaal / 18B actief, 288 gerouteerde experts plus 1 gedeelde expert met top-8-routing, 45 lagen — geeft de 4-bit-build de gedeelde expert 6 bits, elke down-projectie 5 bits, en de gate- en up-projecties 4 bits. De 6-bit-build rondt de down-projecties naar boven af naar 8 bits. De groepsgrootte is 64 voor de 4- en 6-bit-builds, 32 voor 2- en 3-bit, en de gedeelde expert gebruikt altijd 64.

Is de shared-expert-regel het waard? Bij een 2-bit basis zit de shared expert op 4 bits en bij een 6-bit basis op 8 — in beide gevallen kosten de extra twee bits geheugen dat de routed experts anders hadden kunnen gebruiken, en de eigen cijfers van de model card, hieronder besproken, suggereren dat de afweging de moeite loont. Het is dezelfde redenering die de 2bit-lite-build sowieso de moeite waard maakt om uit te brengen: de altijd actieve expert is de enige plek waar een beetje extra precisie het meeste oplevert.

De selectieregel: _scale_inv als een vrij gevoeligheidssignaal

Het bitallocatiebeleid gaat ervan uit dat je al weet welke tensoren kandidaten zijn. Het uitkiezen van die set is waar OrcaSAQ het slimst is, omdat de regel mechanisch is en geen data nodig heeft: een tensor wordt opnieuw gekwantiseerd dan en slechts dan als de FP8-release hem met een _scale_inv-begeleider heeft meegeleverd.

Waarom dat werkt: de upstream-basis van GLM-5.3-Flash is FP8 — bloksgewijs e4m3, 128×128-blokken, met een dynamisch activeringsschema. Bloksgewijze FP8-kwantificering slaat een per-blok schaal en de inverse daarvan naast het gewicht op; de aanwezigheid van _scale_inv in het checkpoint is een blijvende markering dat de tensor upstream het kwantiseringspad heeft doorlopen. De upstream-release heeft je al verteld welke tensoren veilig zijn om te kwantiseren — geen Hessiaan, geen kalibratiecorpus, geen forward passes.

Voor GLM-5.3-Flash bestaat die set uit de MoE- en dense-MLP-lineaire lagen, plus de vier projecties van elk deepseek_sparse_attention blok — q_a_proj, q_b_proj, kv_a_proj_with_mqa, en o_proj — over de 11 sparse lagen op dieptes 3, 7, 11 … 43, plus het MTP-blok, 12 × 4 = 48 tensoren. Al het andere heeft nooit de markering gehad en blijft BF16: de 34 linear_attention lagen, de sparse indexer, en de vision tower. De MTP-laag — laag 45 — is opgenomen in de gekwantiseerde gewichten in plaats van geëxporteerd als een aparte module.

Het punt dat het stelen waard is, is de truc zelf. Een modelrelease die zijn gewichten upstream kwantiseert, heeft al een groot deel van het werk gedaan om te bepalen wat er gekwantiseerd kan worden; de _scale_invmarker is die beslissing, geserialiseerd in het bestandsformaat. OrcaSAQ leest het terug. Dat is wat de pijplijn deterministisch en overdraagbaar maakt — elk model dat FP8-gewichten met schaalmetadata levert, kan met dezelfde regel worden afgehandeld, zonder enige datapijplijn.

De valkuil: configuratie per module, niet top-level bits.

Als je je eigen MLX-quantizer schrijft — en dat is de doelgroep van dit gedeelte — is het nuttigste wat in de modelkaart staat een waarschuwing: de top-level bits en group_size in config.json zijn niet genoeg.

In totaal worden er 37.338 tensoren gekwantiseerd. De toewijzing is vastgelegd in config.json → quantization als per-module {group_size, bits} overrides met het MLX-modulepad als sleutel — bijvoorbeeld model.layers.3.mlp.switch_mlp.down_proj. Omdat MLX de gerouteerde experts van een laag fuseert tot één enkele switch_mlp, dekken 173 vermeldingen alle 37.338 tensoren.

En de loader leest die items tijdens het laden. Als je het hele bestand op de basisbreedte kwantiseert, komt elke tensor met verhoogde precisie — de gedeelde expert op basis +2, elke down-projectie op basis +1 — uit op de verkeerde breedte, en het model wordt in de verkeerde vorm geladen. De per-modulemapping is geen optimalisatie die je kunt overslaan; het is het laadpad. Wanneer je je eigen kwantisator schrijft, genereer dan de overrides voor elke tensor die het beleid verhoogt, en controleer ze tegen de top-level standaard voordat je uitbrengt.

Betaalt de polis zichzelf terug?

Het bewijs is van onszelf, gemeten op één model: GLM-5.3-Flash, elke build gedekwantiseerd en uitgevoerd via de identieke glm5_next forward, zodat de enige variabele de kwantisering is. De onderstaande cijfers komen uit de modelkaart en zijn geen leveranciersbenchmarks of cijfers van een derde partij — beschouw ze als een enkel datapunt, niet als een wet.

• Perplexiteit, vergeleken met de FP8-referentie van 2.7797: 6-bit 2.7864 (+0.24%), 4-bit 2.8620 (+2.96%), 3-bit 3.0566 (+9.96%), 2-bit 4.3622 (+56.9%).

• Top-1 tokenovereenstemming met de referentie, in dezelfde volgorde: 97.76%, 96.13%, 92.06%, 86.56%.

De lezing is precies wat het beleid voorspelt. Alles tot en met 3-bit degradeert zachtjes — dat is de handtekening van een bitbudget dat aan de juiste tensoren is besteed — en 2-bit is een klif, omdat onder een bepaald punt de rolgebaseerde verhogingen de schade niet meer dekken. Bij 4-bit is +2,96% perplexity voor een build die ruwweg 38% kleiner is dan de FP8-referentie een echt goede ruil, en het is hetzelfde beleid, agressiever toegepast, dat de 102 GB 2bit-lite build überhaupt laat laden. Onafhankelijke beoefenaars die dezelfde basis kwantiseren rapporteren dezelfde volgorde — de bovenste treden dicht bij de ruisvloer, 4-bit reëel maar bescheiden — met verschillende absolute getallen van een ander evaluatiecorpus.

Wat er naar je eigen MoE overgaat

De herbruikbare redenering, voor een model dat niet van ons is:

• Vind de altijd-actieve experts. Wat op elk token afvuurt — meestal een gedeelde of altijd-gerouteerde expert — krijgt je royaalste bits. Zijn fout wordt overal herhaald.

• Zoek de knelpunten in de residustroom. De projectie die naar de residustroom schrijft (doorgaans de downprojectie van elk MLP-blok) krijgt basis +1. Fouten daar worden door elke diepere laag gezien.

• Laat de expansie- en gating-paden op de basiswaarde staan. Als een uitvoer elementsgewijs binnen een activatiefunctie wordt vermenigvuldigd, wordt de kwantisatiefout erin gedeeltelijk geabsorbeerd.

• Nooit-gekwantiseerd upstream betekent nooit door jou gekwantiseerd. Als de basisrelease die tensoren in volledige precisie bevatte, geef ze dan in volledige precisie door.

• Gebruik de schaalmetadata van de upstream-release als selectieregel.Als het basismodel zijn gewichten kwantiseert, vormen de schaal-/inverse-schaalmarkeringen die het achterlaat een gratis kaart van wat kwantiseerbaar is — geen gevoeligheidsanalyse vereist.

• Leg per-module overschrijvingen vast. Een globale bitbreedte zal bij het laden elke aangemaakte tensor misvormen. Schrijf de modulepadkaart.

En als je überhaupt een kalibratieset kunt krijgen, gebruik die om het beleid te auditen — niet om het te vervangen. Voer een kalibratiegestuurde kwantisatie uit met hetzelfde gemiddelde aantal bits en controleer of de volgorde van de role prior overeenkomt met wat de data zeggen. Bij een dicht model of een gloednieuwe architectuur is die audit het verschil tussen een verdedigbare standaard en een gok.

Waar OrcaSAQ de verkeerde keuze is

Dit is het gedeelte dat de methode eerlijk zou moeten houden, omdat de kalibratievrije afweging reëel is.

• Wanneer kwaliteitsplafond belangrijker is dan pijplijnsnelheid, en je beschikt over een kalibratieset. GPTQ- of AWQ-achtige methoden passen zich aan de werkelijke activatiestatistieken van je model en je data aan, en bij gelijke gemiddelde bits presteren ze meestal beter dan een vast rolgebaseerd beleid. Als je één model één keer kwantiseert en nooit opnieuw kwantiseert, zijn de extra uren kalibratie een eenmalige uitgave die meetbare kwaliteit oplevert.

• Niet-MoE dichte modellen. De rolprior — gedeelde expert, gate/up/down — bestaat niet, dus het beleid verliest de structuur die het betrouwbaar maakt. Je blijft achter met: "alles wat stroomopwaarts gekwantiseerd is, blijft gekwantiseerd", wat een zwakkere claim is.

• Modellen zonder FP8-upstreamrelease. De _scale_inv selectieregel heeft niets om op af te gaan. U moet de kwantiseerbare set op een andere manier bepalen, en het argument van mechanische overdraagbaarheid stort in.

• Gloednieuwe architecturen.De priors zijn precies de aannames die mogelijk niet kloppen. Een kalibratiegestuurde methode zou een fragiele tensor detecteren die een rolgebaseerd beleid had gemist; OrcaSAQ zal dat niet doen, omdat het nooit kijkt.

• Sub-3-bit-doelen. Het beleid redt je niet. Bij 2-bit zit het model op +56,9% perplexiteit, ongeacht waar de extra bits naartoe gingen; de 2bit-lite-build bestaat om te passen, niet voor kwaliteit.

• Wanneer je garanties nodig hebt.Per-tensor garanties, budgetten voor quantization-aware training (QAT), of de best mogelijke kwaliteit voor een vaste grootte zonder rekening te houden met de pipelinekosten vallen allemaal onder het kalibratiedomein.

De bottom line

Gevoeligheidsbewuste kwantisering is de praktijk; OrcaSAQ is een deterministisch, kalibratievrij recept daarvoor. De blijvende lessen zijn de verhogingen van de gedeelde expert en de down-projectie, de mechanische _scale_inv selectieregel, en de per-module configuratie die de loader daadwerkelijk leest. Voor een MoE van 320 miljard parameters zoals GLM-5.3-Flash, produceert dat recept een 4-bit MLX-build met +2,96% perplexity — en de orcarouter/GLM-5.3-Flash-MLX repo levert dezelfde werkwijze in 2, 3, 4 en 6 bits, met een aparte 2bit-lite-build voor 128 GB-machines. Onze GLM-5.3-Flash-MLX walkthrough behandelt welke build je op welke machine moet draaien, stap voor stap.

Als je prioriteit het laatste beetje kwaliteit bij een vast formaat is en je een kalibratiecorpus kunt samenstellen, gebruik dan de kalibratiegestuurde tools en laat ze zich aanpassen. Als je prioriteit een reproduceerbare, snelle, datavrije kwantisering is die overdraagbaar is naar de volgende architectuur — of je simpelweg helemaal geen datapipeline wilt bouwen — dan is het op rollen gebaseerde beleid een verdedigbare standaard. En als je in de eerste plaats liever niet kwantiseert, is de volledige-precisie-GLM-5.3-Flash via OrcaRouter beschikbaar als z-ai/glm-5.3-flash. De keuze gaat over hoeveel pipeline je bereid bent te draaien, niet over de vraag of gevoeligheidsbewuste kwantisering de moeite waard is.

Liever helemaal niets kwantiseren? z-ai/glm-5.3-flash is het full-precision model dat op OrcaRouter wordt aangeboden tegen de prijs van de provider, met 0% opslag.