- GLM-4.5 ist ein Open-Source-Mixture-of-Experts-(MoE)-Large-Language-Model mit hervorragender Leistung bei Agentenfähigkeit, Reasoning und Coding
- Das Modell wurde mit 23T Token durch mehrstufiges Training, Iteration von Expertenmodellen und Reinforcement Learning weiterentwickelt
- In verschiedenen zentralen Benchmarks wie TAU-Bench, AIME 24, SWE-bench Verified erzielt es Spitzenplatzierungen
- Es liefert auch mit einer geringen Zahl an Parametern effiziente Leistung und kommt an wichtige kommerzielle Modelle heran oder übertrifft sie
- GLM-4.5 und die kleinere Version GLM-4.5-Air wurden veröffentlicht und können für Forschung und die Entwicklung von AI-Systemen genutzt werden
Überblick
- GLM-4.5 ist ein Open-Source-Mixture-of-Experts-(MoE)-Large-Language-Model mit 355 Milliarden Gesamtparametern und 32 Milliarden aktiven Parametern
- Es verwendet einen hybriden Reasoning-Ansatz und unterstützt sowohl einen Modus für tiefes Nachdenken (Thinking) als auch einen Modus für sofortige Antworten (Direct Response)
- Es durchlief mehrstufiges Training mit 23 Billionen Token, Iterationen von Expertenmodellen sowie Post-Training auf Basis von Reinforcement Learning
- Dadurch erzielt es hohe Werte in den Aufgabenbereichen Agentenfähigkeit (Agentic), Reasoning und Coding (Coding·ARC)
- TAU-Bench 70.1%, AIME 24 91.0%, SWE-bench Verified 64.2%
- Im Vergleich zu Konkurrenzmodellen belegt GLM-4.5 mit weniger Parametern Rang 3 insgesamt und Rang 2 bei Agenten-Benchmarks
- Veröffentlicht wurden sowohl das große Modell GLM-4.5 (355 Milliarden Parameter) als auch das kompaktere GLM-4.5-Air (106 Milliarden Parameter)
- Der vollständige Code, die Modelle und detaillierte Informationen sind im offiziellen GitHub verfügbar: https://github.com/zai-org/GLM-4.5
LLM-Leistungsbewertung: Benchmarks für Agentenfähigkeit, Reasoning und Coding
- GLM-4.5 und wichtige globale Modelle wurden in 12 repräsentativen Benchmarks getestet, darunter MMLU-Pro, AIME 24 und SWE-Bench Verified
- GLM-4.5 erreichte Rang 3 im Gesamtdurchschnitt, GLM-4.5-Air Rang 6
- Nach Agentenfähigkeits-Score liegt es hinter OpenAI o3 auf Rang 2 und erreichte auch in Coding-Benchmarks mit Rang 3 ein Niveau nahe Claude Sonnet 4
- GLM-4.5 zeigt ähnliche Leistung mit der Hälfte der Parameter von DeepSeek-R1 und einem Drittel der Parameter von Kimi K2
- Gemessen an der Zahl der Parameter im Verhältnis zur Leistung bei SWE-bench Verified liegen GLM-4.5 und GLM-4.5-Air auf der Pareto Frontier
- Die Leistungsdaten gelten mit Stand vom 28. Juli 2025
Einleitung
- Large Language Models (LLMs) entwickeln sich schnell von allgemeinen Datenspeichern zu universellen Problemlösern
- AGI (Artificial General Intelligence) als Endziel der künstlichen Intelligenz zielt auf Modelle mit kognitiven Fähigkeiten auf menschlichem Niveau in vielen Bereichen
- Dafür sind integrierte Fähigkeiten zur Lösung komplexer Probleme, zur Generalisierung und zur Selbstverbesserung erforderlich
- Die drei zentralen Fähigkeiten, die für reale Arbeit und die Lösung komplexer Fachprobleme wichtig sind, sind:
- Agentenfähigkeit: Interaktion mit Werkzeugen und der Außenwelt
- Komplexes Reasoning: mehrstufige Lösung komplexer Probleme etwa in Mathematik und Naturwissenschaften
- Fortgeschrittenes Coding: Fähigkeit zu praktischer Softwareentwicklung
- Bestehende kommerzielle SOTA-Modelle von OpenAI und Anthropic zeigen spezialisierte Spitzenleistungen in einzelnen Bereichen, doch unter Open-Source-Modellen gibt es nur wenige veröffentlichte Modelle, die in allen drei Kernbereichen gleichermaßen stark sind
Einführung in GLM-4.5 und GLM-4.5-Air
- GLM-4.5 und GLM-4.5-Air zeigen Open-Source-Leistung auf Spitzenniveau in Agentenfähigkeit, Reasoning und Coding
- Beide Modelle unterstützen hybride Reasoning-Modi
- Thinking Mode ist besonders stark bei komplexem Reasoning und Agentenfähigkeit
- Non-thinking Mode ist auf schnelle Antworten spezialisiert
- Die wichtigsten Ergebnisse von GLM-4.5:
- Agentenfähigkeit: TAU-Bench 70.1%, BFCL v3 77.8%, BrowseComp 26.4% (überlegen gegenüber konkurrierenden kommerziellen Modellen)
- Reasoning: AIME 24 91.0%, GPQA 79.1%, LiveCodeBench 72.9%, HLE 14.4%
- Coding: SWE-bench Verified 64.2%, Terminal-Bench 37.5% (überlegen gegenüber GPT-4.1 und Gemini-2.5-pro, nahe an Claude Sonnet 4)
- GLM-4.5-Air verfügt über 106 Milliarden Parameter und ist unter Modellen in der 100-Milliarden-Klasse Qwen3-235B-A22B und MiniMax-M1 ebenbürtig oder überlegen
Benchmark-Status und Merkmale
- In 12 wichtigen Benchmarks insgesamt erzielten sowohl GLM-4.5 als auch GLM-4.5-Air hohe Platzierungen
- GLM-4.5 zeigt ausgewogene Leistung in den Bereichen Agentenfähigkeit, Reasoning und Coding sowie eine auffällige Parametereffizienz
- Gemessen an SWE-bench Verified erreicht es den effizientesten Bereich in Bezug auf Parameterzahl, also die Pareto Frontier
- Es wurden präzise Leistungsvergleiche mit verschiedenen kommerziellen und Open-Source-Modellen durchgeführt
Veröffentlichung und Open-Source-Unterstützung
- Die Modelle GLM-4.5 und GLM-4.5-Air wurden nicht nur bei Z.ai und BigModel.cn, sondern auch auf Huggingface veröffentlicht: https://huggingface.co/zai-org/GLM-4.5
- Für die Reproduzierbarkeit der Benchmarks wurde sogar das Evaluierungs-Toolkit als Open Source bereitgestellt: https://github.com/zai-org/glm-simple-evals
Vortraining
Architektur
- Die GLM-4.5-Serie nutzt eine Mixture-of-Experts-(MoE)-Architektur und erhöht damit die Recheneffizienz von Training und Inferenz deutlich
- In den MoE-Layern werden loss-free balance routing und Sigmoid-Gating eingesetzt
- Anders als DeepSeek-V3 und Kimi K2 wird die Breite des Modells (Hidden-Dimension, Zahl der Routing-Experten) reduziert und die Tiefe (Zahl der Layer) erhöht. Tiefere Modelle sind für das Wachstum der Reasoning-Fähigkeiten effektiver
- Bei Self-Attention werden Grouped-Query Attention und partielles RoPE eingesetzt; mit 96 Attention Heads ergibt sich bei einer Hidden-Dimension von 5120 eine 2,5-fache Attention-Head-Konfiguration
- Es wurde bestätigt, dass eine höhere Zahl an Heads keinen Einfluss auf den Trainingsverlust hat, aber die tatsächliche Inferenz- und Benchmark-Leistung positiv beeinflusst
- Durch den Einsatz von QK-Norm wird die Stabilität der Attention-Logit-Werte verbessert
- Sowohl GLM-4.5 als auch GLM-4.5-Air ergänzen MTP-(Multi-Token Prediction)-Layer auf Basis von MoE-Layern und unterstützen dadurch speculative decoding bei der Inferenz
- Bei der Zusammenfassung der Architekturparameter werden die Parameter der MTP-Layer einbezogen, Word-Embeddings und Output-Layer jedoch nicht
Fazit und erwartete Wirkung
- GLM-4.5 und GLM-4.5-Air sind Sprachmodelle der nächsten Generation, die im Open-Source-AI-Markt hohe Leistung, Effizienz und Vielseitigkeit vereinen
- Sie zeichnen sich durch integrierte Fähigkeiten über mehrere Bereiche hinweg, durch die Lösung anspruchsvoller Probleme, Wettbewerbsfähigkeit gegenüber kommerziellen Modellen und Parametereffizienz aus
- In Wissenschaft, Industrie und der gesamten Entwicklerforschung können sie die Grundlage für weitere Innovationen bei Open-Source-Large-Language-Models erweitern
2 Kommentare
Auch in den Hacker-News-Kommentaren und im Reddit-Forum LocalLLaMA gibt es etliche Stimmen, dass GLM ziemlich gut sein soll
GLM 4.5 AIR IS SO FKING GOODDD
Hacker-News-Kommentare
Es ist wirklich erfreulich, dass dieses Paper im Gegensatz zu den üblichen Modellankündigungs-Blogposts deutlich in die Tiefe geht.
Das Zhipu-/Tsinghua-Team erklärt nicht nur das „Was“, sondern auch das „Wie“ sehr detailliert, was besonders interessant für Leute ist, die solche Modelle selbst bauen oder einsetzen wollen.
Besonders beeindruckend ist die Post-Training-Methodik in Abschnitt 3.
Der Ansatz, zunächst spezialisierte „Expertenmodelle“ für Reasoning/Agenten/Chat zu bauen und deren Fähigkeiten dann in das endgültige integrierte Modell zu destillieren, ist sehr attraktiv.
Das ist ein deutlich systematischerer Versuch, die Grenzen eines Generalistenmodells zu lösen, das alles nur halbwegs abdeckt.
Statt einfach nur Daten zusammenzumischen, wurde das Modell so angelegt, dass ein allgemeines Modell von einer Gruppe von Experten lernt.
Ein interessanter Punkt in den RL-Ergebnissen ist, dass RL über den gesamten 64K-Kontext auf einmal besser abschnitt als stufenweises RL (siehe Abb. 6).
Viele Teams würden vermutlich das Gegenteil erwarten, aber die tatsächlichen Resultate zeigen etwas anderes.
Und die kleine, aber kluge Entscheidung, für das Function-Calling-Format eine XML-Vorlage zu verwenden, vermeidet JSON-Escaping-Probleme (siehe Abb. 4).
In der Praxis ist es sehr mühsam, Code innerhalb von JSON zu escapen.
Auch die Leistung auf SWE-bench ist beachtlich und kann mit deutlich größeren oder kommerziellen Modellen mithalten.
Was mich künftig interessiert, ist, ob diese hybride Trainingsmethode auch außerhalb von ARC-artigen Evaluierungen funktioniert.
Zum Beispiel frage ich mich, ob die Agentenleistung auch in komplexen Workflows stabil bleibt, wie sie in realer Arbeit vorkommen: ohne API-Dokumentation, mit häufigen Fehlern und mehrdeutigen Eingaben.
Ich frage mich, ob solche Post-/Mid-Training-Tweaks wirklich notwendig sind, wenn man ein bestimmtes Fachgebiet trainiert, in dem bereits reichlich gut validierte Daten und Labels vorhanden sind.
Mich würde interessieren, ob ein kleines Team schon weit kommt, wenn es einfach nur den neuesten skalierbaren Trainings-Stack sauber nachbaut, oder ob solche Methoden einen großen Unterschied machen.
Ich hoffe, das klingt nicht kleinlich, aber der Schreibstil wirkt sehr stark nach typischem LLM-Ton.
Ich habe denselben Hinweis schon früher gesehen Link.
Ich denke, auf so etwas hinzuweisen hilft dabei, das Online-Umfeld gesund zu halten.
Ich habe das GLM-4.5-Coding-Modell ziemlich lange verwendet, und die Leistung ist wirklich hervorragend.
Beim Einsatz von GLM-4.5 in meinem Coding-Agenten Octofriend habe ich es zeitweise sogar mit Claude 4 verwechselt.
Meiner Erfahrung nach ist Claude etwas stärker in Situationen, in denen der gesamte Codebestand als Kontext dient und Systeminteraktionen berücksichtigt werden müssen.
GLM-4.5 wirkt dagegen „ehrlicher“ und neigt nicht so dazu wie Claude, Probleme stillschweigend zu umgehen, etwa indem Testcode angepasst wird.
Beide sind auf hohem Niveau, aber GLM-4.5 hat bei mir auch schon Bugs gefunden, die Claude 4 Sonnet oder 4.1 Opus nicht entdeckt haben.
Beim reinen Debugging gewinnt Claude zwar minimal häufiger, aber der Unterschied ist nicht groß.
Im Vergleich zu GPT-5 sind sowohl Claude als auch GLM konsistenter.
GPT-5 liefert zwar manchmal wirklich beeindruckende Ergebnisse, aber wenn es einmal vom Weg abkommt, ist es frustrierend schwer, es wieder auf Kurs zu bringen.
Siehe Octofriend: https://github.com/synthetic-lab/octofriend
Nach diesem Kommentar habe ich GLM-4.5 in Kilocode getestet.
Ich hatte den ganzen Tag versucht, mit Gemini CLI einen kniffligen Bug in Compiler-Code zu finden, aber ohne Erfolg.
GLM-4.5 hat dagegen sofort das Kernproblem erkannt.
Gemini CLI verdächtigte nur die falsche Funktion und wiederholte halbherzige Änderungen, obwohl das am Ende überhaupt nichts damit zu tun hatte.
Die Fähigkeit von GLM-4.5, sich auf das eigentliche Problem zu konzentrieren, sticht definitiv hervor.
Ich habe ebenfalls gute Erfahrungen mit GLM-4.5 bei kleineren Projekten oder kurzen Anfragen gemacht.
Leider habe ich den Eindruck, dass die Leistung mit längerem Kontext nachlässt, daher nutze ich es derzeit als Backup für Sonnet 4.
Ich nutze im aider den Architect-Modus.
Ich verwende eine Kombination aus Deepseek R1 (für die High-Level-Architektur) und Qwen3 480B (für Low-Level-Coding, alternativ über die qwen code API).
Dieses Setup funktioniert wirklich gut.
Es löst 99,99 % der Probleme praktisch allein.
Da die Rollentrennung in aider noch nicht perfekt ist, will ich ein eigenes Tool bauen, das den Workflow verbessert.
Ich stimme dem ersten Punkt zu.
Auch bei mir funktioniert Claude umso besser, je mehr Kontext vorhanden ist, während GLM-4.5 in solchen Situationen schwächere Ergebnisse liefert.
Die GLM-4.5-Serie zählt bei den gesamten/aktiven Parametern die Embedding- und Output-Layer nicht mit, sondern nur die MTP-Layer.
Das passt zu meiner eigenen Berechnung (355B A32B).
Die GPT-OSS-Serie zählt Embedding und Output beide zu den Gesamtparametern, bei den aktiven Parametern aber nur den Output.
Die Qwen3-Serie zählt sowohl bei Gesamt- als auch bei aktiven Parametern Embedding und Output jeweils mit.
Da die Berechnung der Parameterzahlen je nach Modell unterschiedlich ist, frage ich mich, warum es dafür keinen Standard gibt und welche Methode sinnvoller ist.
Bei den aktiven Parametern sollte man berücksichtigen, dass die Unembedding-Parameter bei jeder Tokengenerierung vollständig verwendet werden, während beim Embedding nur eine Spalte genutzt wird. Nur so lässt sich der Zusammenhang mit Bandbreite und Latenz korrekt verstehen.
Ich glaube, dass man innerhalb der nächsten paar Jahre auf einem Workstation-PC für rund 2000 Dollar mit einem lokalen offenen Modell auf Sonnet-4-Niveau coden können wird.
Die heutigen Cloud-basierten Modelle sind zwar nützlich, aber bei einem Tool, das für die Developer Experience so zentral ist, möchte ich es lokal ausführen können.
Meiner Meinung nach braucht es dafür keine 2 Jahre, sondern es reicht schon bis Ende dieses Jahres.
Aus Open-Source-Sicht sind solche Modelle unverzichtbar.
Andernfalls könnte Open-Source-Entwicklung selbst auf Dauer untragbar werden.
Ich würde sogar eher erwarten, dass man innerhalb von 2 Jahren auf einem 2000-Dollar-PC Leistung auf Sonnet-4-Niveau oder darüber bekommt.
Dieses Modell fühlt sich wie das erste offene Modell an, das man den bisherigen kommerziellen Frontier-Modellen fast ebenbürtig gegenüberstellen kann.
Schon allein an der Parametereffizienz sieht man, dass es beim Training echte Innovationen gegeben hat.
Mich würden auch unabhängige Leistungsvalidierungen im Aider-LLM-Leaderboard interessieren.
Für Leute wie mich, die zuerst den Abstract des Papers lesen möchten, hier der Link: https://www.arxiv.org/abs/2508.06471
Dass die Veröffentlichung auch noch unter Apache-Lizenz steht, ist großartig.
Es freut mich wirklich, zu sehen, wie Open-Source-Modelle ihre Grenzen immer weiter verschieben.
In diesem Paper gibt es so viele Beobachtungen, dass man über jede einzelne fast ein eigenes Paper schreiben könnte.
Besonders die Erfahrungen mit dem Trainingsprozess sowie mit Datensammlung und -synthese sind sehr reichhaltig.
Weiß jemand, ob die Autoren früher schon ähnlich starke Papers veröffentlicht haben?
Die Metriken in den Diagrammen des Papers verwirren mich.
In der ersten Abbildung liegt der SWE-bench-Wert von Sonnet 4 bei ungefähr 53, in der nächsten dann fast bei 70.
Der tatsächliche Wert scheint näher bei 70 zu liegen Referenz
Ich frage mich, warum Qwen3 bei den Coding-Benchmarks fehlt, aber in anderen Benchmarks enthalten ist.
In Abschnitt 4.3.2 ist Qwen3-Coder enthalten.
Qwen ist beim Verständnis großer Codebasen noch nicht ausgereift.