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ă:
| Benchmark | RCO-152E | Modelul complet |
|---|---|---|
| AIME 2025 (20 de probleme) | 19 | 20 |
| Subset MATH-500 | 6/6 | 6/6 |
| Subset LiveCodeBench | 6/6 | 6/6 |
Aritmetica, codul executat și apelurile de unelte trec la fiecare dimensiune publicată.
| Fișier | Dimensiune | Rulează pe (GPU + RAM) | Diferența față de 8 biți (KLD) |
|---|---|---|---|
| Q8_0 | 180 GB | mai multe GPU-uri | 0 |
| Q4_K_M | 103 GB | 24 GB + 96 GB | 0.024 |
| Q3_K | 75 GB | 24 GB + 64 GB | 0.045 |
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șier | Exerciții cu buclă |
|---|---|
| 8 biți | 0 din 19 |
| 4 biți | 2 din 15 |
| 3 biți | 4 din 14 |
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
- Ponderi: huggingface.co/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E-GGUF
- Rețetă, mască, scripturi și harness de evaluare: github.com/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E
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.
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