Forschung · 2026-10-24 · Alle Beiträge

Wir haben ein 321B-Coding-Modell halbiert, damit es auf einem Heim-PC läuft. Was dabei kaputtging und wie wir es repariert haben.

GLM-5.3-Flash hat in jeder Schicht 288 Experten. Wir haben 152 behalten, ausgewählt per Optimierung, und das Ergebnis als Open Weights veröffentlicht. Unterwegs hat unser erstes Release die Arithmetik zerstört, und die kleineren Dateien gerieten in eine Denkschleife, die eine einzige Einstellung beseitigt.

Photo: Jakub Pabis / Pexels

GLM-5.3-Flash ist eines der stärksten Open-Weight-Modelle für Programmierung und agentische Arbeit. Es hat aber auch 321 Milliarden Parameter: 341 GB bei 8 Bit. Kaum jemand kann das zu Hause betreiben.

Es ist ein Mixture-of-Experts-Modell. Jede Schicht enthält 288 Experten, und für jedes Token nutzt der Router nur wenige davon. Die meisten Experten werden für Code selten gebraucht. Die Frage ist also einfach: Wie viele können wir entfernen, und welche, bevor das Modell nicht mehr dasselbe Modell ist?

Unsere Antwort ist GLM-5.3-Flash-Coder-RCO-152E: 152 der 288 Experten in jeder Schicht, veröffentlicht als Open Weights unter derselben MIT-Lizenz wie das Original. Die 3-Bit-Datei ist 75 GB groß und läuft auf einer 24-GB-GPU mit 64 GB RAM.

Der erste Versuch und warum wir ihn ersetzt haben

Unser erstes Release behielt 144 Experten pro Schicht, ausgewählt mit einem veröffentlichten Saliency-Score (REAP), gemessen auf Python-Agent-Sessions. Bei Python-Agent-Aufgaben hielt es sich gut.

Dann haben wir einen breiteren Regressionstest durchgeführt, und es scheiterte auf eine Weise, die ein Coding-Benchmark nicht zeigt. Es konnte 17 x 23 falsch ausrechnen. Bei Fragen in anderen Programmiersprachen geriet es in Schleifen. Die Ursache war die Kalibrierung: Die Experten für Arithmetik, andere Sprachen und allgemeines Denken wurden in Python-Agent-Sessions selten genutzt, also stufte der Score sie niedrig ein, und wir haben sie entfernt.

Wir haben das auf der Modellseite offen gesagt, die Dateien zurückgezogen und neu gebaut. Die Lehre ist allgemein: Ein beschnittenes Modell behält, woran Sie es messen, und verliert stillschweigend den Rest. Wenn der Testdatensatz eine Fähigkeit nicht abdeckt, schützt das Pruning sie nicht.

Wie wir die Experten diesmal ausgewählt haben

Zwei Änderungen.

Die Kalibrierungsdaten. Statt einer einzigen Art von Session eine Mischung: agentische Coding-Sessions, die vom vollständigen Modell geschrieben wurden, Code in 21 Programmiersprachen, Mathematik und 15% allgemeiner Text. Alles außerhalb unserer Evaluierungsdatensätze.

Die Auswahlmethode. Statt jeden Experten einzeln zu bewerten, haben wir RCO verwendet, eine Optimierungsmethode von IST Austria. Sie behandelt die Menge der behaltenen Experten als eine einzige Entscheidung und minimiert direkt den Unterschied zwischen der Ausgabe des beschnittenen Modells und der des vollständigen Modells auf den Kalibrierungsdaten.

Bei denselben 152 Experten erreichte die optimierte Maske bei Code und agentischem Text das Niveau der score-basierten Maske, hatte bei allgemeinem Text einen um 22% geringeren Fehler und erzeugte weit weniger Schleifen: 4 Aufgaben in unserem Schleifentest mit 30 Läufen, gegenüber 22 beim ersten Release.

Es folgte ein kurzer Heilungsschritt: ein kleiner Adapter auf den Attention- und Shared-Expert-Gewichten, trainiert darauf, die Ausgabeverteilung des vollständigen Modells nachzubilden.

Was es behält

Bei 8 Bit, im Vergleich zum vollständigen Modell mit denselben Prompts und Standard-Sampling:

Arithmetik, ausgeführter Code und Tool-Aufrufe bestehen bei jeder veröffentlichten Größe.

Die Schleife, die erst nach der Quantisierung auftritt

Das 8-Bit-Modell war sauber. Die 4-Bit- und 3-Bit-Dateien nicht, und es dauerte eine Weile, den Fehler zu verstehen.

Bei schwierigeren Programmierübungen begann das Modell normal zu denken, zögerte, schrieb "hmm" und hörte dann nicht mehr auf, "hmm" zu schreiben, bis ihm die Tokens ausgingen. Überhaupt kein Code. Schlimmer noch: Sobald ein Versuch in eine Schleife geraten war, gerieten auch die folgenden Versuche, die das vorherige Denken in ihrem Verlauf sehen, innerhalb weniger tausend Zeichen erneut in eine Schleife.

Bei Aider Polyglot, mit bis zu zehn Versuchen pro Übung, die Übungen, bei denen jede Datei in eine Schleife geriet:

Die naheliegenden Lösungen funktionierten nicht. Eine Presence Penalty stoppte die Wiederholung, aber dann dachte das Modell weiter, ohne je zum Ende zu kommen. Eine Begrenzung der Denklänge half bei einer von drei Übungen, weil die Schleife oft lange vor der Grenze begann.

Was funktionierte, war viel gezielter: die drei "hmm"-Tokens dieses Tokenizers zu verbieten. Mit dieser einen Einstellung löste das 3-Bit-Modell alle drei Übungen, bei denen es in Schleifen geraten war, zwei davon beim ersten Versuch. Die genaue Einstellung steht auf der Modellseite; es ist ein einzelnes --logit-bias-Flag in llama.cpp.

Wir vermuten als eigentliche Ursache, dass das quantisierte Modell nie auf seinen eigenen Ausgaben trainiert wurde: Sobald es in einen Zustand des Zögerns abdriftet, holt es nichts zurück. Genau das testen wir als Nächstes, indem wir die 2-Bit-Version auf ihren eigenen Generierungen trainieren, mit dem vollständigen Modell als Lehrer.

Probieren Sie es aus

• Gewichte: huggingface.co/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E-GGUF
• Rezept, Maske, Skripte und Evaluierungs-Harness: github.com/lapadatbogdan/GLM-5.3-Flash-Coder-RCO-152E

Diese Forschung nutzte Rechenleistung aus Zuteilungen der EuroHPC JU AI Factory auf dem Supercomputer LUMI. RCO und GSQ sind Methoden von IST Austria; REAP stammt von Lasby et al., 2025.