Recherche · 2026-10-24 · Toutes les recherches

Nous avons coupé en deux un modèle de code de 321B pour le faire tourner sur un PC domestique. Voici ce qui a cassé, et comment nous l'avons réparé.

GLM-5.3-Flash compte 288 experts dans chaque couche. Nous en avons gardé 152, choisis par optimisation, et publié le résultat en poids ouverts. En chemin, notre première version a cassé l'arithmétique, et les fichiers plus petits tombaient dans une boucle de raisonnement qu'un seul réglage supprime.

Photo: Jakub Pabis / Pexels

GLM-5.3-Flash est l'un des meilleurs modèles à poids ouverts pour le code et le travail agentique. Il compte aussi 321 milliards de paramètres : 341 GB en 8 bits. Presque personne ne peut le faire tourner chez soi.

C'est un modèle à mélange d'experts. Chaque couche contient 288 experts, et pour chaque token le routeur n'en utilise que quelques-uns. La plupart des experts servent rarement pour le code. La question est donc simple : combien peut-on en retirer, et lesquels, avant que le modèle cesse d'être le même modèle ?

Notre réponse est GLM-5.3-Flash-Coder-RCO-152E : 152 des 288 experts de chaque couche, publiés en poids ouverts sous la même licence MIT que l'original. Le fichier 3 bits pèse 75 GB et tourne sur un GPU de 24 GB avec 64 GB de RAM.

La première tentative, et pourquoi nous l'avons remplacée

Notre première version gardait 144 experts par couche, choisis avec un score de saillance publié (REAP) mesuré sur des sessions d'agent Python. Sur les tâches d'agent Python, elle tenait bien.

Puis nous avons lancé un test de régression plus large, et elle a échoué d'une manière qu'un benchmark de code ne montre pas. Elle pouvait se tromper sur 17 x 23. Elle bouclait sur des questions dans d'autres langages de programmation. La cause était la calibration : les experts qui gèrent l'arithmétique, les autres langages et le raisonnement général étaient rarement utilisés dans les sessions d'agent Python, donc le score les classait bas et nous les avons coupés.

Nous l'avons signalé sur la page du modèle, retiré les fichiers et tout reconstruit. La leçon est générale : un modèle élagué conserve ce sur quoi on le mesure, et perd discrètement le reste. Si le jeu de test ne couvre pas une compétence, l'élagage ne la protégera pas.

Comment nous avons choisi les experts cette fois

Deux changements.

Les données de calibration. Au lieu d'un seul type de session, un mélange : des sessions de code agentique écrites par le modèle complet, du code dans 21 langages de programmation, des mathématiques et 15% de texte général. Le tout en dehors de nos jeux d'évaluation.

La méthode de sélection. Au lieu de noter chaque expert isolément, nous avons utilisé RCO, une méthode d'optimisation d'IST Austria. Elle traite l'ensemble des experts conservés comme une seule décision et minimise directement l'écart entre la sortie du modèle élagué et celle du modèle complet sur les données de calibration.

À nombre égal de 152 experts, le masque optimisé a égalé le masque fondé sur le score pour le code et le texte agentique, avec une erreur inférieure de 22% sur le texte général, et a produit beaucoup moins de boucles : 4 problèmes dans notre test de boucle sur 30 exécutions, contre 22 pour la première version.

Une courte étape de récupération a suivi : un petit adaptateur sur les poids d'attention et de l'expert partagé, entraîné à reproduire la distribution de sortie du modèle complet.

Ce qu'il conserve

En 8 bits, face au modèle complet avec les mêmes prompts et l'échantillonnage par défaut :

L'arithmétique, le code exécuté et les appels d'outils passent à toutes les tailles publiées.

La boucle qui n'apparaît qu'après la quantification

Le modèle 8 bits était propre. Les fichiers 4 bits et 3 bits ne l'étaient pas, et il nous a fallu du temps pour comprendre la panne.

Sur les exercices de code plus difficiles, le modèle commençait à raisonner normalement, hésitait, écrivait « hmm », puis ne cessait plus d'écrire « hmm » jusqu'à épuiser ses tokens. Aucun code. Pire, dès qu'une tentative avait bouclé, les tentatives suivantes, qui voient le raisonnement précédent dans leur historique, bouclaient à nouveau en quelques milliers de caractères.

Sur Aider Polyglot, avec jusqu'à dix tentatives par exercice, voici les exercices sur lesquels chaque fichier a bouclé :

Les corrections évidentes n'ont pas fonctionné. Une pénalité de présence arrêtait la répétition, mais le modèle continuait alors à raisonner sans jamais conclure. Un plafond sur la longueur du raisonnement a aidé sur un exercice sur trois, car la boucle commençait souvent bien avant le plafond.

Ce qui a fonctionné était beaucoup plus ciblé : interdire les trois tokens « hmm » de ce tokenizer. Avec ce seul réglage, le modèle 3 bits a résolu les trois exercices sur lesquels il avait bouclé, dont deux dès la première tentative. Le réglage exact figure sur la page du modèle ; il s'agit d'un unique flag --logit-bias dans llama.cpp.

Nous pensons que la cause profonde est que le modèle quantifié n'a jamais été entraîné sur ses propres sorties : une fois qu'il dérive vers un état d'hésitation, rien ne le ramène. C'est ce que nous testons ensuite, en entraînant la version 2 bits sur ses propres générations avec le modèle complet comme professeur.

Essayez-le

• Poids : huggingface.co/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E-GGUF
• Recette, masque, scripts et banc d'évaluation : github.com/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E

Cette recherche a utilisé de la puissance de calcul issue d'allocations EuroHPC JU AI Factory sur le supercalculateur LUMI. RCO et GSQ sont des méthodes d'IST Austria ; REAP est issu de Lasby et al., 2025.