Quantizzazione Basata sulla Sensibilità Spiegata: Come OrcaSAQ Decide Quali Pesi Ottengono Più Bit

La quantizzazione consapevole della sensibilità è la pratica di spendere il proprio budget di bit dove conta: i tensori che la quantizzazione danneggia di più ricevono più bit, e tutto il resto rimane a una larghezza di base inferiore. Questo articolo spiega come OrcaSAQ — il nostro metodo di precisione mista senza calibrazione e consapevole dell'architettura, rilasciato con la GLM-5.3-Flash famiglia di quantizzazione orcarouter/GLM-5.3-Flash-MLX — decide quali dei 37.338 tensori in un modello Mixture-of-Experts da 320 miliardi di parametri meritano bit extra, interamente senza un dataset di calibrazione. La lezione trasferibile per chiunque quantizzi un diverso MoE: gli esperti condivisi e le proiezioni verso il basso guadagnano i bit extra, e puoi trovarli usando niente più che i metadati di quantizzazione della release upstream.

La risposta breve

La quantizzazione che tiene conto della sensibilità è una precisione mista con una politica: la larghezza di bit di ogni tensore segue quanto è sensibile all'errore di quantizzazione, invece di una larghezza per l'intero modello. La letteratura di ricerca misura la sensibilità con hessiane, informazione di Fisher o divergenza tra le uscite degli strati originali e quantizzati, quindi alloca bit agli strati che danneggiano di più. OrcaSAQ appartiene a una famiglia più piccola che salta del tutto la misurazione. Codifica l'ordinamento di sensibilità nell'architettura stessa: usa prior architetturali e sul ruolo dei tensori per decidere quali pesi sono fragili, poi quantizza tutto il resto a una precisione base obiettivo.

Ciò che ottieni è una pipeline veloce, deterministica e senza calibrazione. Non c'è alcun corpus di calibrazione da assemblare, nessuna ricerca di sensibilità per layer e nessuna ri-regolazione per modello, quindi la stessa ricetta si trasferisce a una nuova architettura il giorno stesso in cui i suoi pesi vengono rilasciati. Ciò a cui rinunci è l'adattamento: un metodo basato sulla calibrazione come GPTQ o AWQ osserva l'effettiva distribuzione delle attivazioni del tuo modello e dei tuoi dati, e di solito riesce a spremere più qualità dalla stessa larghezza media di bit. La scommessa di OrcaSAQ è che per i modelli Mixture-of-Experts, il ruolo di un tensore ti dice gran parte di ciò che direbbe una sessione di calibrazione, a una frazione del costo.

Due modi per trovare i pesi sensibili

Prima della policy, la domanda è: come fai a sapere quali tensori la quantizzazione danneggia? Le due risposte costituiscono l'intero spazio di progettazione.

• Basato sulla calibrazione. Si esegue un piccolo corpus attraverso il modello, si misura l'errore causato da ogni tensore o blocco e si allocano i bit per minimizzare l'errore totale di ricostruzione. GPTQ usa un'approssimazione basata sull'Hessiana per l'errore di quantizzazione per layer; AWQ usa le statistiche delle attivazioni per identificare i pesi salienti da proteggere. Il punto di forza è l'adattamento ai tuoi dati reali; i costi sono un corpus curato, passaggi in avanti e risoluzioni dell'inversa dell'Hessiana per ogni layer, e risultati che cambiano quando il set di calibrazione cambia.

• Senza calibrazione. Stabilisci la graduatoria di sensibilità prima di vedere qualsiasi dato, in base all'architettura. In un MoE, conosci già i ruoli portanti: l'esperto che si attiva su ogni token e la proiezione che scrive nel flusso residuo. Codifica quella graduatoria come una politica fissa e applicala meccanicamente.

OrcaSAQ è fermamente nel secondo schieramento, e questo articolo è una difesa di tale schieramento per la quantizzazione MoE — con un resoconto lucido di ciò a cui si rinuncia per ottenerlo.

La policy: quali tensori ottengono più bit

La politica di allocazione dei bit di OrcaSAQ è indicata nella scheda del modello per orcarouter/GLM-5.3-Flash-MLX, e si riduce a tre regole più un'eccezione. La base precisione è la build che stai realizzando — 6, 4, 3 o 2 bit — e la politica eleva ruoli tensoriali specifici al di sopra di essa:

• Esperto condiviso: base +2 bit. L'esperto condiviso viene attivato su ogni token, quindi il suo errore di quantizzazione si ripercuote su ogni singolo output che il modello produce. È il tensore con la maggiore leva del modello, e riceve il maggior numero di bit.

• down_proj: base +1 bit.In un blocco MLP SwiGLU la proiezione down è il collo di bottiglia residuo — il suo output viene aggiunto direttamente al flusso residuo da cui ogni strato più profondo legge. Un errore qui corrompe direttamente tutto ciò che viene letto a valle.

• gate_proj e up_proj: precisione base. Questi sono i percorsi di espansione e gating; i loro output vengono moltiplicati elemento per elemento all'interno dell'attivazione. Un errore modesto qui viene in parte attenuato dal gating, quindi tollerano la larghezza base.

• Mai quantizzati, trasportati in BF16: i 34 strati di attenzione lineare, l'indicizzatore sparso appreso, gli array di iper-connessione, le norme, embed_tokens, lm_head, e l'intera torre visiva. Questi non erano FP8 nella release upstream e rimangono a piena precisione.

I bit vengono arrotondati per eccesso alla più vicina larghezza supportata da MLX, {2,3,4,5,6,8}. Concretamente, su GLM-5.3-Flash — 320B totali / 18B attivi, 288 instradati più 1 esperto condiviso con routing top-8, 45 layer — la build a 4 bit assegna all’esperto condiviso 6 bit, a ogni proiezione down 5 bit, e alle proiezioni gate e up 4 bit. La build a 6 bit arrotonda per eccesso le proiezioni down a 8 bit. La dimensione del gruppo è 64 per le build a 4 e 6 bit, 32 per quelle a 2 e 3 bit, e l’esperto condiviso usa sempre 64.

La regola dell'esperto condiviso vale la pena? {{1}}Con una base a 2 bit l'esperto condiviso si trova a 4 bit, e con una base a 6 bit si trova a 8 — in entrambi i casi i due bit extra costano memoria che gli esperti instradati avrebbero potuto altrimenti utilizzare, e i numeri stessi della scheda del modello, discussi di seguito, suggeriscono che il compromesso ripaga.{{/1}} {{2}}È lo stesso ragionamento che rende la build 2bit-lite degna di essere distribuita: l'esperto sempre attivo è il punto in cui un po' di precisione in più dà i maggiori benefici.{{/2}}

La regola di selezione: _scale_inv come un segnale di sensibilità libero

La politica di allocazione dei bit presuppone che tu sappia già quali tensori sono candidati. È nella scelta di questo insieme che OrcaSAQ dà il meglio di sé, poiché la regola è meccanica e non richiede dati: un tensore viene riquantizzato se e solo se la versione FP8 lo ha fornito con un compagno _scale_inv.

Perché funziona: la base upstream GLM-5.3-Flash è FP8 — a blocchi e4m3, blocchi 128×128, con uno schema di attivazione dinamico. La quantizzazione FP8 a blocchi memorizza una scala per blocco e il suo inverso insieme al peso; la presenza di _scale_inv nel checkpoint è un indicatore persistente che il tensore ha seguito il percorso di quantizzazione upstream. La release upstream ti ha già detto quali tensori sono sicuri da quantizzare — niente Hessiano, niente corpus di calibrazione, nessun forward pass.

Per GLM-5.3-Flash, questo insieme è costituito dai linear MoE e dense-MLP, più le quattro proiezioni di ogni deepseek_sparse_attention blocco — q_a_proj, q_b_proj, kv_a_proj_with_mqa, e o_proj — attraverso gli 11 layer sparsi alle profondità 3, 7, 11 … 43, più il blocco MTP, 12 × 4 = 48 tensori. Tutto il resto non è mai stato contrassegnato e rimane in BF16: i 34 linear_attention layer, l'indicizzatore sparso e la torre di visione. Il layer MTP — layer 45 — è incluso nei pesi quantizzati invece di essere esportato come modulo separato.

Il punto che vale la pena rubare è il trucco stesso. Un rilascio del modello che quantizza i suoi pesi a monte ha già compiuto gran parte del lavoro necessario a decidere cosa può essere quantizzato; il marcatore _scale_invè quella decisione, serializzata nel formato del file. OrcaSAQ lo rilegge. È questo che rende la pipeline deterministica e trasferibile: qualsiasi modello che distribuisca pesi FP8 con metadati di scala può essere gestito dalla stessa regola, senza alcuna pipeline di dati.

L'insidia: configurazione per modulo, non impostazioni di livello superiore.

Se scrivi il tuo quantizzatore MLX — e questo è il pubblico a cui si rivolge questa sezione — la cosa più utile in assoluto nella model card è un avvertimento: i campi di primo livello bits e group_size in config.json non sono sufficienti.

In totale, 37.338 tensori sono quantizzati. L'assegnazione è registrata in config.json → quantization come override per-modulo {group_size, bits} indicizzati per percorso del modulo MLX — ad esempio model.layers.3.mlp.switch_mlp.down_proj. Poiché MLX fonde gli esperti instradati di un layer in un unico switch_mlp, 173 voci coprono tutti i 37.338 tensori.

E il caricatore legge quelle voci al momento del caricamento. Se quantizzi l'intero file alla larghezza di base, ogni tensore con precisione aumentata — l'esperto condiviso a base +2, ogni proiezione verso il basso a base +1 — viene fuori con la larghezza sbagliata e il modello viene caricato con una forma errata. La mappa per modulo non è un'ottimizzazione che puoi saltare; è il percorso di caricamento. Quando scrivi il tuo quantizzatore, emetti gli override per ogni tensore che la policy aumenta e verificali rispetto al predefinito di livello superiore prima di distribuire.

La polizza si ripaga da sola?

Le prove sono nostre, misurate su un modello: GLM-5.3-Flash, ogni build dequantizzata ed eseguita attraverso lo stesso glm5_next forward, quindi l'unica variabile è la quantizzazione. I numeri qui sotto provengono dalla scheda del modello e non sono benchmark del fornitore né dati di terze parti — prendili come un singolo dato, non come una legge.

• Perplessità, rispetto al riferimento FP8 a 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%).

• Accordo token Top-1 con il riferimento, stesso ordine: 97.76%, 96.13%, 92.06%, 86.56%.

La lettura è esattamente quello che la policy prevede. Tutto, fino al 3-bit, degrada dolcemente — questo è il segno di un budget di bit speso sui tensori giusti — e il 2-bit è un precipizio, perché al di sotto di un certo punto gli incrementi basati sui ruoli smettono di coprire il danno. A 4-bit, +2,96% di perplexity per una build più piccola di circa il 38% rispetto al riferimento FP8 è davvero un buon compromesso, ed è la stessa policy, applicata in modo più aggressivo, a rendere caricabile la build 2bit-lite da 102 GB. Professionisti indipendenti che quantizzano la stessa base riportano lo stesso ordinamento — i gradini superiori vicino al rumore di fondo, il 4-bit reale ma modesto — con numeri assoluti diversi da un corpus di valutazione diverso.

Cosa si trasferisce al tuo MoE

Il ragionamento riutilizzabile, per un modello che non è nostro:

• Trova gli esperti sempre attivi. Qualsiasi cosa si attivi su ogni token — di solito un esperto condiviso o sempre instradato — riceve i tuoi bit più generosi. Il suo errore viene riprodotto ovunque.

• Trova i colli di bottiglia residui. La proiezione che scrive nel flusso residuo (tipicamente la down projection di ogni blocco MLP) riceve base +1. L'errore lì viene visto da ogni strato più profondo.

• Mantieni i percorsi di espansione e gating al livello base. Se un output viene moltiplicato elemento per elemento all'interno di un'attivazione, l'errore di quantizzazione in esso viene in parte assorbito.

• Un upstream mai quantizzato significa mai quantizzato da te. Se la release di base conteneva quei tensori in piena precisione, mantienili in piena precisione.

• Usa i metadati di scala della release upstream come regola di selezione.Se il modello base quantizza i suoi pesi, i marcatori di scala/inversa di scala che lascia dietro di sé sono una mappa gratuita di ciò che è quantizzabile — nessuna ricerca di sensibilità richiesta.

• Registra gli override per modulo. Una larghezza di bit globale distorcerà ogni tensore creato al caricamento. Scrivi la mappa dei percorsi dei moduli.

E se puoi disporre di un set di calibrazione, usalo per verificare la policy, non per sostituirla. Esegui una quantizzazione guidata dalla calibrazione allo stesso numero medio di bit e controlla se l'ordinamento del prior sul ruolo corrisponde a ciò che dicono i dati. Su un modello denso o su un'architettura completamente nuova, questa verifica fa la differenza tra un default difendibile e una congettura.

Dove OrcaSAQ è la scelta sbagliata

Questa è la sezione che dovrebbe mantenere onesto il metodo, perché il trade-off senza calibrazione è reale.

• Quando il tetto di qualità supera la velocità della pipeline e disponi di un set di calibrazione. I metodi stile GPTQ o AWQ si adattano alle statistiche di attivazione effettive del tuo modello e dei tuoi dati e, a parità di bit medi, di solito superano una policy fissa basata sui ruoli. Se quantizzi un modello una sola volta e non lo ri-quantizzi mai, le ore extra di calibrazione sono un costo una tantum che si traduce in qualità misurabile.

• Modelli densi non-MoE. Il prior di ruolo — esperto condiviso, gate/up/down — non esiste, quindi la policy perde la struttura che la rende affidabile. Ti rimane solo "tutto ciò che è quantizzato a monte rimane quantizzato", che è un'affermazione più debole.

• Modelli senza release upstream FP8. La _scale_inv non ha nulla su cui basarsi. È necessario decidere l'insieme quantizzabile in qualche altro modo, e l'argomento della trasferibilità meccanica crolla.

• Architetture completamente nuove.I prior sono esattamente le assunzioni che potrebbero non reggere. Un metodo basato sulla calibrazione rileverebbe un tensore fragile che una policy basata sui ruoli non ha individuato; OrcaSAQ non lo farà, perché non guarda mai.

• Obiettivi sub-3-bit.La policy non ti salva. A 2 bit il modello ha una perplexity di +56,9% indipendentemente da dove sono finiti i bit extra; la build 2bit-lite esiste per il fit, non per la qualità.

• Quando hai bisogno di garanzie. Le garanzie per-tensor, i budget di quantization-aware training (QAT) o la migliore qualità possibile per una dimensione fissa senza considerare il costo della pipeline rientrano tutti nell'ambito della calibrazione.

La conclusione

La quantizzazione consapevole della sensibilità è la pratica; OrcaSAQ è una ricetta deterministica e senza calibrazione per essa. Le lezioni durature sono gli aumenti di shared-expert e down-projection, la meccanica _scale_inv regola di selezione, e la configurazione per modulo che il loader legge effettivamente. Per un MoE con 320 miliardi di parametri come GLM-5.3-Flash, quella ricetta produce una build MLX a 4 bit con +2.96% di perplessità — e il orcarouter/GLM-5.3-Flash-MLX repo offre la stessa policy a 2, 3, 4 e 6 bit, con una build 2bit-lite separata per macchine da 128 GB. Il nostro GLM-5.3-Flash-MLX walkthrough copre quale build eseguire su quale macchina, passo dopo passo.

Se la tua priorità è l'ultimo briciolo di qualità a una dimensione fissa e puoi assemblare un corpus di calibrazione, usa gli strumenti basati sulla calibrazione e lascia che si adattino. Se la tua priorità è una quantizzazione riproducibile, veloce e senza dati che si trasferisca alla prossima architettura — o semplicemente non vuoi costruire affatto una pipeline di dati — la policy basata sui ruoli è un default difendibile. E se preferisci non quantizzare affatto, la versione full-precision GLM-5.3-Flash viene servita tramite OrcaRouter come z-ai/glm-5.3-flash. La scelta riguarda quanta pipeline sei disposto a eseguire, non se la quantizzazione consapevole della sensibilità valga la pena.

Preferiresti non quantizzare proprio nulla? z-ai/glm-5.3-flash è il modello a piena precisione servito su OrcaRouter al prezzo del provider, con ricarico 0%.