Cercetare · 2026-10-24 · Toate cercetările

Am tăiat la jumătate un model de programare de 321B ca să ruleze pe un PC de acasă. Iată ce s-a stricat și cum am reparat.

GLM-5.3-Flash are 288 de experți în fiecare strat. Am păstrat 152, aleși prin optimizare, și am publicat rezultatul ca open weights. Pe parcurs, prima noastră versiune a stricat aritmetica, iar fișierele mai mici au intrat într-o buclă de raționament pe care o elimină o singură setare.

Photo: Jakub Pabis / Pexels

GLM-5.3-Flash este unul dintre cele mai puternice modele open-weight pentru programare și sarcini agentice. Are însă și 321 de miliarde de parametri: 341 GB la 8 biți. Aproape nimeni nu îl poate rula acasă.

Este un model de tip mixture-of-experts. Fiecare strat conține 288 de experți, iar pentru fiecare token routerul folosește doar câțiva dintre ei. Majoritatea experților sunt rar necesari pentru cod. Așa că întrebarea e simplă: câți putem scoate, și pe care, înainte ca modelul să nu mai fie același model?

Răspunsul nostru este GLM-5.3-Flash-Coder-RCO-152E: 152 din cei 288 de experți din fiecare strat, publicat ca open weights sub aceeași licență MIT ca originalul. Fișierul pe 3 biți are 75 GB și rulează pe un GPU de 24 GB cu 64 GB de RAM.

Prima încercare și de ce am înlocuit-o

Prima noastră versiune păstra 144 de experți pe strat, aleși cu un scor de importanță publicat (REAP), măsurat pe sesiuni de agent în Python. Pe sarcinile de agent în Python s-a descurcat bine.

Apoi am rulat un test de regresie mai larg și a eșuat în moduri pe care un benchmark de programare nu le arată. Putea să greșească 17 x 23. Intra în buclă la întrebări în alte limbaje de programare. Cauza era calibrarea: experții care se ocupă de aritmetică, de alte limbaje și de raționamentul general erau folosiți rar în sesiunile de agent în Python, așa că scorul i-a clasat jos și noi i-am tăiat.

Am spus asta pe pagina modelului, am retras fișierele și am refăcut totul. Lecția este generală: un model tăiat păstrează ce măsori pe el și pierde pe tăcute restul. Dacă setul de test nu acoperă o abilitate, tăierea nu o va proteja.

Cum am ales experții de data aceasta

Două schimbări.

Datele de calibrare. În locul unui singur tip de sesiune, un amestec: sesiuni de programare agentică scrise de modelul complet, cod în 21 de limbaje de programare, matematică și 15% text general. Totul în afara seturilor noastre de evaluare.

Metoda de selecție. În loc să notăm fiecare expert separat, am folosit RCO, o metodă de optimizare de la IST Austria. Ea tratează setul de experți păstrați ca pe o singură decizie și minimizează direct diferența dintre ieșirea modelului tăiat și ieșirea modelului complet pe datele de calibrare.

La aceiași 152 de experți, masca optimizată a egalat masca bazată pe scor la cod și la text agentic, a avut o eroare cu 22% mai mică pe text general și a produs mult mai puține bucle: 4 probleme în testul nostru de bucle cu 30 de rulări, față de 22 la prima versiune.

A urmat un scurt pas de recuperare: un adaptor mic pe ponderile de atenție și pe cele ale expertului comun, antrenat să reproducă distribuția de ieșire a modelului complet.

Ce păstrează

La 8 biți, comparat cu modelul complet, cu aceleași prompturi și eșantionarea implicită:

BenchmarkRCO-152EModelul complet
AIME 2025 (20 de probleme)1920
Subset MATH-5006/66/6
Subset LiveCodeBench6/66/6

Aritmetica, codul executat și apelurile de unelte trec la fiecare dimensiune publicată.

FișierDimensiuneRulează pe (GPU + RAM)Diferența față de 8 biți (KLD)
Q8_0180 GBmai multe GPU-uri0
Q4_K_M103 GB24 GB + 96 GB0.024
Q3_K75 GB24 GB + 64 GB0.045
Modelul complet341 GBQ8_0180 GBQ4_K_M103 GBQ3_K75 GB

Bucla care apare doar după cuantizare

Modelul pe 8 biți era curat. Fișierele pe 4 și pe 3 biți nu erau, iar eșecul ne-a luat ceva timp să-l înțelegem.

La exercițiile de programare mai grele, modelul începea să raționeze normal, ezita, scria „hmm” și apoi nu se mai oprea din scris „hmm” până nu rămânea fără tokeni. Niciun rând de cod. Mai rău, odată ce o încercare intrase în buclă, următoarele încercări, care văd raționamentul anterior în istoric, intrau și ele în buclă în câteva mii de caractere.

Pe Aider Polyglot, cu până la zece încercări pe exercițiu, exercițiile la care fiecare fișier a intrat în buclă:

FișierExerciții cu buclă
8 biți0 din 19
4 biți2 din 15
3 biți4 din 14
8 biți0%4 biți13%3 biți29%

Remediile evidente nu au funcționat. O penalizare de prezență a oprit repetiția, dar apoi modelul continua să raționeze fără să încheie vreodată. O limită pentru lungimea raționamentului a ajutat la un exercițiu din trei, pentru că bucla pornea adesea cu mult înainte de limită.

Ce a funcționat a fost ceva mult mai țintit: interzicerea celor trei tokeni „hmm” ai acestui tokenizer. Doar cu această setare, modelul pe 3 biți a rezolvat toate cele trei exerciții la care intrase în buclă, două dintre ele din prima încercare. Setarea exactă se află pe pagina modelului; este un singur flag --logit-bias în llama.cpp.

Credem că, la bază, cauza este că modelul cuantizat nu a fost niciodată antrenat pe propriile ieșiri: odată ce alunecă într-o stare de ezitare, nimic nu îl mai trage înapoi. Asta testăm în continuare, antrenând versiunea pe 2 biți pe propriile generări, cu modelul complet drept profesor.

Încearcă-l

Această cercetare a folosit putere de calcul din alocări EuroHPC JU AI Factory pe supercomputerul LUMI. RCO și GSQ sunt metode de la IST Austria; REAP provine de la Lasby et al., 2025.

Vrei un model specializat ca acesta, privat, pe propriile servere?

Adaptăm prin fine-tuning, tăiem și evaluăm modele deschise pentru codul, documentele sau domeniul tău și le punem în funcțiune pe o infrastructură pe care o controlezi tu.

Vorbește cu noi
Folosim cookie-uri ca site-ul să funcționeze. Politica de cookies