GLM-5 bis GLM-5.3: Was das Repository tatsächlich enthält und was nicht

Ein Repository, vier Modellgenerationen und ein sehr breiter Anspruch

Die README beginnt nicht mit GLM-5. Sie führt GLM-5.3, GLM-5.3-Flash, GLM-5.2, GLM-5.1 und GLM-5 in einem Dokument zusammen. Das ist ungewöhnlich für ein Repository, dessen Name nur eine Generation nennt. Wer hier landet, bekommt keine einzelne Modellkarte, sondern eine Sammlung von Ankündigungstexten mit eingebetteten Benchmark-Grafiken. Die Zielgruppe wird im Text explizit benannt: komplexes Systems Engineering und lang laufende agentische Aufgaben. Der Untertitel der Repository-Beschreibung, from Vibe Coding to Agentic Engineering, markiert denselben Adressaten. Praktisch heißt das: Coding-Assistenten, Terminal-Agenten, Werkzeuge, die über hunderte Runden und tausende Tool-Aufrufe laufen sollen. Wer ein Chat-Modell für kurze Antworten sucht, ist hier nicht die primäre Zielgruppe, und die README unternimmt auch keinen Versuch, ihn zu überzeugen. Die Lizenz ist Apache-2.0, was für gewichtbasierte Modelle eine vergleichsweise offene Ausgangslage ist. Ob diese Lizenz auch die Nutzung der Gewichte selbst abdeckt oder nur den Repository-Inhalt, lässt sich aus dem vorliegenden Material nicht ableiten. Das ist keine Formalie: Bei Modellveröffentlichungen trennen Anbieter häufig Code-Lizenz und Modell-Lizenz. Wer GLM-5 kommerziell einsetzen will, muss diese Frage vor der Integration klären, nicht danach.

Sparse Attention, IndexShare und die Kosten des 1M-Kontexts

Der technisch interessanteste Teil der README betrifft GLM-5.2. Dort wird IndexShare beschrieben: derselbe Indexer wird über je vier Sparse-Attention-Schichten wiederverwendet. Die angegebene Wirkung sind 2.9× weniger FLOPs pro Token bei einer Kontextlänge von 1M. Zusätzlich wird die MTP-Schicht für spekulatives Decoding verbessert, mit einer Steigerung der Acceptance Length um bis zu 20 Prozent. Das sind Angaben aus der Projektbeschreibung, keine unabhängig nachvollzogenen Messwerte. Der Mechanismus ist dennoch nachvollziehbar: Sparse Attention reduziert die Anzahl der Attention-Operationen, und die Wiederverwendung eines gemeinsamen Indexers senkt den Overhead, der beim Aufbau dieser Indexstruktur entsteht. Bei sehr langen Kontexten dominiert genau dieser Overhead zunehmend die Rechnung. GLM-5.3-Flash geht einen anderen Weg und kombiniert erstmals in der GLM-Reihe sparse und lineare Attention. Die README nennt außerdem Manifold-Constrained Hyper-Connections (mHC) und ein multimodales Pre-Training-Korpus mit 30T Token. Für GLM-5 selbst werden 744B Parameter mit 40B aktiven Parametern genannt, gegenüber 355B/32B bei GLM-4.5, sowie ein Anstieg der Pre-Training-Daten von 23T auf 28.5T Token. Eingesetzt wird dort DeepSeek Sparse Attention. Bemerkenswert ist die Verschiebung: Bei GLM-5.3 stammen die Zugewinne laut README ausschließlich aus Post-Training auf demselben Basismodell wie GLM-5.2. Wer erwartet, dass eine neue Versionsnummer auch ein neues Basismodell bedeutet, wird hier eines Besseren belehrt.

Was die gemeldeten Zahlen aussagen und was sie verschweigen

Die README nennt eine Reihe konkreter Werte. GLM-5.2 erreicht 81.0 auf Terminal-Bench 2.1 gegenüber 62.0 bei GLM-5.1, und 62.1 gegenüber 58.4 auf SWE-bench Pro. Der Abstand zu Claude Opus 4.8 wird mit 85.0 auf Terminal-Bench 2.1 angegeben. GLM-5.3 soll auf dem hauseigenen Z.ai Code Bench 50 Prozent über GLM-5.2 liegen. Für GLM-5 wird ein Ergebnis von 4.432 Dollar Endkontostand in Vending Bench 2 genannt, einem Benchmark, in dem ein simuliertes Vending-Maschinen-Geschäft über ein Jahr geführt wird. Diese Zahlen stammen aus der Projektdarstellung. Ein Teil davon bezieht sich auf eine hauseigene Evaluierung, die naturgemäß nicht unabhängig überprüfbar ist. Die öffentlichen Benchmarks sind besser einzuordnen, aber auch dort gilt: Die README liefert keine Angaben zu Decoding-Parametern, Wiederholungszahlen oder Kontextkonfiguration, unter denen die Werte entstanden sind. Wer diese Werte als Einkaufsargument verwendet, sollte wissen, dass er die Messbedingungen nicht kennt. Auffällig ist außerdem die Formulierung zu Cyber-Fähigkeiten: Beim Skalieren des Post-Trainings sei Cyber-Kompetenz schneller gewachsen als erwartet, mit den größten Zugewinnen weiter oben in der Exploitation-Kette. Das ist eine ungewöhnlich offene Aussage über einen Nebeneffekt, der bei einem Coding-Agenten mit Shell-Zugriff praktische Relevanz hat. Wer solche Modelle in eine Umgebung mit Netzwerkzugriff und Credentials stellt, sollte diesen Absatz nicht überlesen.

Installation: was das Material hergibt und was nicht

Die README enthält einen Abschnitt Download Model mit einer Tabelle aus Modellnamen, Download-Links, Modellgröße und Precision. Der Abschnitt ist im vorliegenden Material abgeschnitten, sodass die konkreten URLs, Dateinamen und Größenangaben nicht sichtbar sind. Es gibt keinen Abschnitt zu Installation, keinen zu Abhängigkeiten, keine requirements-Datei, keinen Docker-Befehl, keinen Aufruf eines Inference-Servers. Wer das Modell betreiben will, muss sich daher an anderer Stelle informieren, etwa bei der verlinkten API-Plattform oder in der Dokumentation der Inference-Engines, die das Format der Gewichte unterstützen. Für GLM-5.3 und GLM-5.3-Flash wird auf die Z.ai API Platform verwiesen, mit einem entsprechenden docs.z.ai-Link. Der Weg über die API ist damit der einzige im Material belegte Nutzungspfad. Lokales Serving ist nicht ausgeschlossen, aber auch nicht beschrieben. Bei 744B Parametern im Fall von GLM-5 ist das eine relevante Lücke: Wer diese Gewichte selbst hosten will, braucht eine Hardware-Planung, für die die README keine Anhaltspunkte liefert. Für kleinere Varianten oder Flash-Versionen kann die Rechnung anders aussehen, doch auch dort fehlen Angaben zu Precision und Speicherbedarf im sichtbaren Teil.

Der Trainings-Stack liegt in einem anderen Repository

Ein Punkt, der beim Lesen leicht untergeht: Die README verweist für die Reinforcement-Learning-Infrastruktur auf ein separates Projekt, THUDM/slime, beschrieben als asynchrones RL-Setup, das den Trainingsdurchsatz verbessert und feinere Post-Training-Iterationen ermöglicht. Das ist konsistent mit der Aussage, dass GLM-5.3 seine Fortschritte allein aus Post-Training zieht. Wer die Modellreihe nicht nur nutzen, sondern nachtrainieren will, findet den relevanten Code also nicht in diesem Repository. Das ist eine bewusste Aufteilung und keine Nachlässigkeit, aber sie hat Konsequenzen für die Erwartungshaltung. Dieses Repository ist eine Verteilungs- und Dokumentationsstelle für Gewichte und Ankündigungen, kein Entwicklungs-Repository. Wer Issues zu Trainingsverhalten, Speicherbedarf oder Konvergenz einreichen will, ist hier vermutlich an der falschen Adresse. Umgekehrt bedeutet es, dass Änderungen an diesem Repository eher neue Modellversionen und Textupdates widerspiegeln als Codeänderungen. Für die Bewertung der Wartungslast ist das wichtig: Ein Update kann hier eine neue Gewichtsversion bedeuten, nicht einen Patch.

Die eigentliche Einschränkung: Long-Horizon-Agenten brauchen eine Umgebung

Die README positioniert GLM-5.1 und die Nachfolger ausdrücklich für Aufgaben, die über hunderte Runden und tausende Tool-Aufrufe laufen. Genau dort liegt die praktische Grenze. Ein Modell, das lange Sessions durchhält, verschiebt das Problem von der Antwortqualität zur Umgebungsgestaltung: Sandboxing, Dateisystemzugriff, Abbruchbedingungen, Kostenkontrolle pro Sitzung. Nichts davon adressiert die README. Der Satz, dass das Modell ambiguere Probleme mit besserem Urteilsvermögen behandelt und über längere Sitzungen produktiv bleibt, beschreibt eine Eigenschaft, die man erst in einer laufenden Umgebung bewerten kann. Wer GLM-5 für einen einzelnen Codierungs-Prompt einsetzt, nutzt einen erheblichen Teil des beworbenen Profils gar nicht. Umgekehrt ist es das falsche Werkzeug, wenn die Anforderung deterministisches Verhalten oder kurze Latenz bei einfachen Klassifikationsaufgaben ist. Die README nennt für GLM-5.2 mehrere Thinking-Effort-Stufen, die Leistung gegen Latenz abwägen. Das ist der einzige im Material sichtbare Hebel für Latenzkontrolle, und er setzt voraus, dass die verwendete Serving-Schicht diese Stufen überhaupt durchreicht. Ob das bei einer selbst gehosteten Variante der Fall ist, lässt sich aus der README nicht beantworten.

Alternativen: offene Gewichte gegen offenen Stack

Der naheliegende Vergleich ist DeepSeek, und die README liefert selbst den Anknüpfungspunkt: GLM-5 integriert DeepSeek Sparse Attention. Der Unterschied liegt nicht in der Attention-Technik, sondern im Veröffentlichungsumfang. DeepSeek veröffentlicht zu seinen Modellen üblicherweise Inference-Code und Gewichte zusammen, mit dokumentierten Beispielen für lokales Serving. GLM-5 trennt das: Gewichte und Modellkarten hier, Trainingsinfrastruktur unter THUDM/slime, API-Zugang über Z.ai. Wer einen vollständigen, selbst betreibbaren Stack sucht, muss bei GLM-5 mehrere Quellen zusammenführen. Der zweite Vergleichspunkt sind die geschlossenen Frontier-Modelle, die die README selbst als Messlatte verwendet. Claude Opus 4.8 wird mit 85.0 auf Terminal-Bench 2.1 genannt, GLM-5.2 mit 81.0. Der Unterschied ist klein genug, dass er für viele Anwendungen keine Rolle spielt, und groß genug, dass er bei Grenzfällen sichtbar werden kann. Der eigentliche Unterschied liegt ohnehin woanders: Bei offenen Gewichten kontrolliert man Deployment, Datenfluss und Versionierung selbst. Das ist der Grund, dieses Repository einem API-Zugang vorzuziehen, und es ist ein Grund, der nichts mit Benchmark-Punkten zu tun hat.

Wartung, Versionierung und was vor dem Einstieg zu klären ist

Der letzte Push liegt laut Repository-Metadaten im September 2026, das Repository ist nicht archiviert. Es wurden keine Releases abgerufen, was zu einem Repository passt, das Gewichte über Download-Links statt über Release-Artefakte verteilt. Die Versionslage ist der auffälligste Punkt: Die README behandelt GLM-5.3-Flash, GLM-5.3, GLM-5.2, GLM-5.1 und GLM-5 in einem Dokument, während das Repository GLM-5 heißt. Wer eine bestimmte Generation ansteuert, muss im Text selbst herausfinden, welche Absätze für ihn gelten, und die Download-Tabelle ist im vorliegenden Material abgeschnitten. Für die Wartungslast heißt das: Ein Upgrade bedeutet in der Regel den Wechsel auf eine neue Gewichtsversion mit eigenen Fähigkeitsprofil, nicht das Einspielen eines Patches. Ob zwischen den Versionen Serving-Kompatibilität besteht, sagt die README nicht. Bei Apache-2.0 ist die Weitergabe erlaubt, sofern die Lizenzbedingungen eingehalten werden, üblicherweise durch Beibehaltung der Copyright-Hinweise. Ob die Gewichte derselben Lizenz unterliegen, bleibt offen und ist vor kommerzieller Nutzung zu klären. Das ist keine Rechtsberatung, sondern der Hinweis auf eine offene Stelle im Material. Wer GLM-5 einsetzen will, sollte zuerst prüfen, ob die Download-Tabelle eine Precision-Angabe für die benötigte Variante enthält, und ob die Serving-Schicht die Thinking-Effort-Stufen von GLM-5.2 unterstützt.

Redaktionelles Fazit

Wer offene Gewichte für Coding- und Long-Horizon-Agenten unter Apache-2.0 sucht, findet hier eine dokumentierte Modellreihe und einen Download-Pfad. Wer dagegen eine reproduzierbare Serving- oder Trainingsumgebung erwartet, sollte vor dem Einstieg prüfen, ob das Repository über die Modellkarten hinaus Code, Konfigurationsdateien und Versionsangaben enthält. Ohne diese Prüfung bleibt die Entscheidung eine Entscheidung über Gewichte, nicht über ein nutzbares System.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. zai-org/GLM-5 on GitHub