Ricerca · 2026-10-24 · Tutta la ricerca

Abbiamo dimezzato un modello di programmazione da 321B per farlo girare su un PC di casa. Ecco cosa si è rotto, e come l'abbiamo sistemato.

GLM-5.3-Flash ha 288 esperti in ogni layer. Ne abbiamo tenuti 152, scelti tramite ottimizzazione, e abbiamo pubblicato il risultato come open weights. Lungo la strada la nostra prima versione ha perso l'aritmetica, e i file più piccoli cadevano in un loop di ragionamento che un'unica impostazione elimina.

Photo: Jakub Pabis / Pexels

GLM-5.3-Flash è uno dei modelli open-weight più forti per la programmazione e il lavoro agentico. Ha anche 321 miliardi di parametri: 341 GB a 8 bit. Quasi nessuno può farlo girare a casa.

È un modello mixture-of-experts. Ogni layer contiene 288 esperti, e per ogni token il router ne usa solo alcuni. La maggior parte degli esperti serve raramente per il codice. Quindi la domanda è semplice: quanti possiamo rimuoverne, e quali, prima che il modello smetta di essere lo stesso modello?

La nostra risposta è GLM-5.3-Flash-Coder-RCO-152E: 152 dei 288 esperti in ogni layer, pubblicato come open weights con la stessa licenza MIT dell'originale. Il file a 3 bit pesa 75 GB e gira su una GPU da 24 GB con 64 GB di RAM.

Il primo tentativo, e perché l'abbiamo sostituito

La nostra prima versione teneva 144 esperti per layer, scelti con un punteggio di salienza pubblicato (REAP) misurato su sessioni di agenti Python. Sui compiti agentici in Python reggeva bene.

Poi abbiamo eseguito un test di regressione più ampio, e ha fallito in modi che un benchmark di programmazione non mostra. Poteva sbagliare 17 x 23. Andava in loop su domande in altri linguaggi di programmazione. La causa era la calibrazione: gli esperti che gestiscono l'aritmetica, gli altri linguaggi e il ragionamento generale venivano usati di rado nelle sessioni di agenti Python, quindi il punteggio li classificava in basso e noi li abbiamo tagliati.

Lo abbiamo scritto sulla pagina del modello, abbiamo ritirato i file e lo abbiamo ricostruito. La lezione è generale: un modello potato conserva ciò su cui lo misuri, e perde silenziosamente il resto. Se il set di test non copre una capacità, la potatura non la proteggerà.

Come abbiamo scelto gli esperti questa volta

Due cambiamenti.

I dati di calibrazione. Invece di un solo tipo di sessione, un mix: sessioni di programmazione agentica scritte dal modello completo, codice in 21 linguaggi di programmazione, matematica e 15% di testo generale. Tutto al di fuori dei nostri set di valutazione.

Il metodo di selezione. Invece di valutare ogni esperto singolarmente, abbiamo usato RCO, un metodo di ottimizzazione di IST Austria. Tratta l'insieme degli esperti conservati come un'unica decisione e minimizza direttamente la differenza tra l'output del modello potato e quello del modello completo sui dati di calibrazione.

A parità di 152 esperti, la maschera ottimizzata ha eguagliato quella basata sul punteggio su codice e testo agentico, ha avuto un errore inferiore del 22% sul testo generale e ha prodotto molti meno loop: 4 problemi nel nostro test di loop da 30 esecuzioni, contro 22 della prima versione.

È seguita una breve fase di recupero: un piccolo adapter sui pesi dell'attention e degli esperti condivisi, addestrato a riprodurre la distribuzione di output del modello completo.

Cosa conserva

A 8 bit, contro il modello completo con gli stessi prompt e il campionamento predefinito:

BenchmarkRCO-152EModello completo
AIME 2025 (20 problemi)1920
Sottoinsieme di MATH-5006/66/6
Sottoinsieme di LiveCodeBench6/66/6

Aritmetica, codice eseguito e chiamate a strumenti passano a ogni dimensione pubblicata.

FileDimensioneGira su (GPU + RAM)Differenza rispetto a 8 bit (KLD)
Q8_0180 GBmulti-GPU0
Q4_K_M103 GB24 GB + 96 GB0.024
Q3_K75 GB24 GB + 64 GB0.045
Modello completo341 GBQ8_0180 GBQ4_K_M103 GBQ3_K75 GB

Il loop che compare solo dopo la quantizzazione

Il modello a 8 bit era pulito. I file a 4 e 3 bit no, e ci è voluto un po' per capire il problema.

Sugli esercizi di programmazione più difficili il modello iniziava a ragionare normalmente, esitava, scriveva "hmm", e poi non smetteva più di scrivere "hmm" finché non esauriva i token. Nessun codice. Peggio ancora, una volta che un tentativo era andato in loop, i tentativi successivi, che vedono il ragionamento precedente nella cronologia, ricadevano nel loop nel giro di qualche migliaio di caratteri.

Su Aider Polyglot, con fino a dieci tentativi per esercizio, gli esercizi su cui ciascun file è andato in loop:

FileEsercizi con un loop
8 bit0 su 19
4 bit2 su 15
3 bit4 su 14
8 bit0%4 bit13%3 bit29%

Le soluzioni ovvie non hanno funzionato. Una presence penalty fermava la ripetizione, ma poi il modello continuava a ragionare senza mai concludere. Un limite alla lunghezza del ragionamento aiutava in un esercizio su tre, perché il loop spesso iniziava molto prima del limite.

Ciò che ha funzionato era molto più mirato: vietare i tre token "hmm" di questo tokenizer. Con questa sola impostazione, il modello a 3 bit ha risolto tutti e tre gli esercizi su cui era andato in loop, due dei quali al primo tentativo. L'impostazione esatta è sulla pagina del modello; si tratta di un unico flag --logit-bias in llama.cpp.

Pensiamo che la causa di fondo sia che il modello quantizzato non è mai stato addestrato sui propri output: una volta che scivola in uno stato di esitazione, niente lo riporta indietro. È ciò che stiamo testando ora, addestrando la versione a 2 bit sulle proprie generazioni con il modello completo come insegnante.

Provalo

Questa ricerca ha usato potenza di calcolo da allocazioni EuroHPC JU AI Factory sul supercomputer LUMI. RCO e GSQ sono metodi di IST Austria; REAP è di Lasby et al., 2025.

Vuoi un modello specializzato come questo, privato, sui tuoi server?

Addestriamo con fine-tuning, potiamo e valutiamo modelli aperti per il tuo codice, i tuoi documenti o il tuo settore, e li installiamo su un'infrastruttura che controlli tu.

Parliamone
Usiamo i cookie per far funzionare il sito. Politica sui cookie