GLM-5.2

Mit einem Gesamtscore von 73.92% präsentiert sich GLM-5.2 als eigensinniger Frontier-Kandidat mit klarer technischer Schlagseite: ein agentisch ausgerichtetes MoE-Modell von Z.AI, 744 Milliarden Parameter gesamt, rund 40 Milliarden aktiv, gebaut für Orchestrierung, Code und lange Arbeitsketten, nicht für charmante Kür. Der Speed-Profile-Badge lautet Interactive DevOps Expert, und genau so arbeitet dieses kommerzielle Cloud-Modell auch: zügig genug für ernsthafte Entwicklungsarbeit, aber mit jener Nachdenklichkeit im Unterbau, die nicht immer elegant, oft aber nützlich ist. Extended Thinking wäre per API grundsätzlich zuschaltbar, im Benchmark lief GLM-5.2 jedoch im Standardmodus ohne explizites Thinking-Budget. Sovereign Risk: HIGH — Z.AI unterliegt chinesischer Jurisdiktion, verarbeitet API-Anfragen in China, und ein DSGVO-taugliches DPA ist laut vorliegenden Provider-Daten nicht ersichtlich.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur und Charakter: Was GLM-5.2 sein will

Die vorab vergebene Kategorie passt erstaunlich gut. Als Instruct-Modell folgt GLM-5.2 Anweisungen meist sauber und ohne theatrales Ausschmücken. Als Coder bringt es die nüchterne Disziplin mit, Tabellen, Sicherheitsanalysen und strukturierte Fehlerdiagnosen brauchbar zu liefern. Als Agentic-Orchestrator denkt es sichtbar in Arbeitsschritten, Prioritäten und Ablaufketten. Und als Thinking-Optional-Modell trägt es eine gewisse innere Trägheit selbst dann mit sich herum, wenn der explizite Denkmodus abgeschaltet bleibt. Das erklärt, warum 25.17 Tokens pro Sekunde auf dem Papier ordentlich wirken, sich das Modell in der Praxis aber nicht nach Echtzeit anfühlt.

Wichtiger ist der architektonische Unterbau. GLM-5.2 ist ein Frontier-Modell und damit in der Erwartungsklasse, in der Ausreden knapp werden. Zugleich ist es ein MoE-System, also eine Mixture of Experts. Von den 744 Milliarden Gesamtparametern sind pro Token nur etwa 40 Milliarden aktiv. Diese aktive Kapazität ist die ehrlichere Messlatte. Sie erklärt, warum GLM-5.2 oft spezialisiert und effizient wirkt, aber nicht überall die rohe Wucht eines durchgehend voll aktiven Großmodells entfaltet. Seine Stärke ist nicht universelle Brillanz, sondern die Aufteilung von Kompetenz in brauchbare Fachspuren.

Performance, Tempo und Preis

Der Badge Interactive DevOps Expert ist keine Marketinglyrik, sondern eine brauchbare Kurzbeschreibung. GLM-5.2 fühlt sich nach einem Modell an, das in Entwickler- und Tool-Ketten zu Hause ist: Shell-nah, strukturiert, ordentlich im Ablauf. Die gemessene Generierungsgeschwindigkeit von 25.17 Tokens pro Sekunde liegt für ein Frontier-Cloud-Modell nicht an der Spitze, ist aber ausreichend für interaktive Nutzung, wenn man die problematische Tail-Latenz mitdenkt. Gerade bei agentisch orientierten und optional tiefer denkenden Modellen ist etwas zusätzliche Verzögerung kein Designfehler, sondern der Preis für interne Planung. Nur: Der Nutzer bezahlt diese Planung doppelt, mit Zeit und mit Token.

Preislich ruft Z.AI 1,4 Dollar pro Million Eingabetokens und 4,4 Dollar pro Million Ausgabetokens auf. Das ist nicht absurd teuer, aber auch kein Billigheimer. In Verbindung mit dem Verbosity-Profil ergibt sich ein gemischtes Bild. Wer GLM-5.2 in produktiven Pipelines einsetzt, bekommt solide technische Leistung, sollte aber nicht glauben, die API rechne von allein wirtschaftlich.

Code Quality: technisch stark, aber nicht lückenlos

Im Code-Quality-Audit erreicht GLM-5.2 72.64%. Das ist ein gutes, aber kein überlegenes Ergebnis. Der qualitative Befund ist klar: Dieses Modell versteht Sicherheitscode deutlich besser, als viele Allrounder es nur behaupten. In der vorliegenden Sicherheitsanalyse lieferte es exakt die geforderte Markdown-Tabelle, hielt Erklärungen knapp und identifizierte 15 von 19 Schwachstellen. Das ist keine Kleinigkeit. Vor allem die impliziten, im Prompt versteckten Sicherheitsprobleme erkannte es weitgehend korrekt: Mail Header Injection, Type Juggling, IDOR, schwache Reset-Tokens und Path-Traversal-Logik. Genau dort trennt sich bei Code-Modellen die Mustererkennung von echtem Verständnis.

Die Schwäche liegt nicht in der Form, sondern in der Vollständigkeit. Wer ausdrücklich „alle Sicherheitslücken“ verlangt, darf nicht vier relevante Punkte auf dem Tisch liegen lassen. Session Fixation, fehlender CSRF-Schutz, Header-Probleme rund um header() und ausbleibende Token-Ablaufkontrollen sind keine Randnotizen. Das sind reale Sicherheitsdefizite. GLM-5.2 arbeitet hier wie ein guter Senior-Reviewer an einem langen Dienstag: sehr brauchbar, meistens wach, aber nicht in jedem Moment gnadenlos vollständig.

Gerade im Security-Kontext ist das wichtig. Das Modell halluziniert in diesem Teil nicht wild herum, sondern bleibt nah am Material. Das ist die gute Nachricht. Die schlechtere lautet: Es kann eine Analyse sehr kompetent aussehen lassen, obwohl einzelne kritische Lücken unentdeckt bleiben. Für einen Erstpass in Reviews, Audits und Patch-Priorisierung ist das wertvoll. Für Freigaben ohne menschliche Nachkontrolle ist es zu riskant.

Reasoning und Logik: korrekt, aber nicht majestätisch

Im Logical-Reasoning-Bereich kommt GLM-5.2 auf 68.87%. Das wirkt nüchtern, und der qualitative Eindruck bestätigt genau das. Die Kernlogik stimmt. In der Wächter-Aufgabe fand das Modell nicht nur die richtige Lösung, sondern skizzierte sogar zwei unterschiedliche Wege dorthin. Das zeigt, dass es nicht bloß eine auswendig gelernte Pointe abspult, sondern Alternativen durchprüft. Für ein Modell mit Agentic-Orchestrator-Tag ist das positiv, denn Planung und Variantenbildung gehören zum Kernversprechen.

Was fehlt, ist die letzte Stufe didaktischer Verdichtung. Die Antwort war richtig, aber nicht brillant organisiert. Tabellen, kleine Logikbilder oder eine besonders klare Entfaltung der Inversionslogik fehlten. Stattdessen wiederholte das Modell Teile seines Gedankengangs in der eigentlichen Antwort nochmals. Man bekommt also korrekte Logik, aber nicht jene elegante Kompression, bei der der Leser nach drei Sätzen denkt: natürlich, so muss es sein.

Das ist für den Alltag weniger schlimm, als die Punktzahl vermuten lässt. In echten Arbeitsprozessen zählt oft zuerst, ob die Schlussfolgerung trägt. Sie trug. Aber GLM-5.2 verkauft seine Einsicht gelegentlich wie ein guter Techniker ohne Gespür für Vortragsdramaturgie: alles Wesentliche da, nur nicht in der schönsten Reihenfolge.

Content Transformation: ideenreich, aber zu langatmig

Mit 78.84% ist die Inhaltsumformung eine der stärkeren Disziplinen von GLM-5.2. Das überrascht auf angenehme Weise, denn Code-lastige Modelle wirken in kreativen Umbauten oft wie jemand, der eine Geburtstagseinladung im Stil eines RFC schreibt. Hier nicht. Das Modell erkannte die Schwächen einer trockenen Video-Outline zuverlässig, baute Hook, Pattern Interrupt, Retention-Hooks, CTA, Troubleshooting und Produktionshinweise sauber ein und lieferte ein funktionales YouTube-Tutorial-Skript mit professioneller Struktur.

Der Haken ist nur leider groß genug, um nicht als Fußnote zu taugen. In einer Aufgabe dieses Moduls antwortete das Modell trotz expliziter Sprachvorgabe nicht konsequent auf Deutsch, sondern mischte englische Produktionsterme und einzelne englische Formulierungen ein. Das ist im Medienalltag nicht exotisch, im Benchmark aber eine klare Schwäche beim Instruction Following.

Noch gravierender ist das Längenproblem. Das Modell zielte auf ein Skript, das 600 bis 900 Wörter haben sollte, und landete bei mehr als dem Doppelten. Das System verhängte hier keinen bloßen Geschmacksabzug, sondern eine regelbasierte Strafe: Die explizite Wortvorgabe wurde massiv überschritten, und die inhaltliche Qualität rettet das nicht. Wer in einem Produktionsworkflow auf feste Längen, Sprecherzeiten oder Formatvorgaben angewiesen ist, erlebt genau an solchen Stellen, warum gute Ideen allein nicht genügen.

Das Längenproblem ist kein isolierter Schönheitsfehler. Über mehrere Aufgaben in inhaltsnahen Modulen zeigt GLM-5.2 ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es das Wortlimit als erste Bedingung. Es will liefern und liefert dann zu viel. Das ist sympathisch im Essay, fatal in Templates.

Cultural Intelligence: solide Sensibilität, etwas zu mechanisch

Im Bereich Cultural Intelligence steht GLM-5.2 bei 75.32%. Die Auszüge zeigen ein Modell, das toxische, gendercodierte oder exkludierende Sprache zuverlässig entschärft. Formulierungen wie „Ninja“, martialische Wettbewerbssprache oder plumpe Geschlechtermarker wurden sauber entfernt oder sinnvoll neutralisiert. Das ist keine kleine Leistung, weil solche Aufgaben häufig an der Schnittstelle von Ton, Kultur und impliziter Erwartung scheitern.

Die Schwäche ist feiner. GLM-5.2 trifft die inhaltliche Richtung, aber nicht immer die stilistisch beste Temperatur. Im vorliegenden Beispiel blieb es professionell, aber etwas kühler und knapper als die Referenz. Außerdem griff es mit „Handwerker:in“ zu einer gegenderten Form, wo eine vollständig neutrale Lösung eleganter gewesen wäre. Das ist kein grober Fehler, eher ein Signal für seinen Charakter: Das Modell räumt Probleme weg, ohne den Raum anschließend besonders liebevoll einzurichten.

Gerade bei kulturell sensiblen Textumbauten ist das akzeptabel, solange man weiß, wofür man es benutzt. Für erste Säuberung und Entschärfung taugt GLM-5.2 gut. Für fein abgestimmte Arbeitgeberkommunikation oder hochpolierte externe Texte braucht es ein redaktionelles Finish.

UX Writing und Documentation Quality: brauchbar, aber nicht die Parade-Disziplin

Die nackten Werte sprechen eine deutliche Sprache: 72.81% bei UX Writing, 65.47% bei Documentation Quality. Das ist verwendbar, aber nicht berauschend. Für ein Modell mit Coder- und Agentic-Fokus ist das keine Katastrophe, sondern ein bekanntes Profil. Solche Systeme sind oft stärker darin, korrekte Strukturen zu erzeugen, als darin, Nutzerführung sprachlich auf den Punkt zu bringen.

Der Tokenverbrauch unterstreicht das. In UX Writing und Dokumentation formuliert GLM-5.2 nicht knapp genug, um als besonders wirtschaftlich zu gelten. Es schreibt nicht schlecht, aber häufig etwas zu breit. Für Entwicklerdokumentation ist das noch verzeihlich. Bei Microcopy, knappen Interface-Texten oder präziser Hilfedokumentation ist es ein Bremsklotz. Gute UX-Sprache ist selten lang. GLM-5.2 hat daran noch nicht ganz geglaubt.

CLI und Tool-Use: stark in der Maschinenlogik, nicht frei von Risiko

Im CLI-Benchmark erreicht GLM-5.2 starke 93.0%, beim ToolUse Score 72.79%. Das passt hervorragend zur Kategorie Agentic-Orchestrator. Das Modell kann Arbeitsabläufe strukturieren, Werkzeuge einordnen und technische Aufgaben in eine brauchbare Reihenfolge bringen. Es wirkt hier wesentlich sicherer als in weichen Sprachdisziplinen. Wer Shell-nahe Hilfe, DevOps-Vorbereitung oder technische Task-Zerlegung sucht, bekommt genau das Profil, das der Badge verspricht.

Aber hier sitzt auch der gravierendste rote Strich im Protokoll. In einer Tool-Use-Aufgabe halluzinierte GLM-5.2 Inhalte, die nicht aus dem tatsächlichen Tool-Ergebnis stammten. Der Score wurde deshalb durch ein Halluzinations-Cap begrenzt. Für content-kritische Aufgaben wie Recherche, Faktenberichte oder jede Form von Tool-gestützter Verifikation ist das disqualifizierend. Ein Agent, der Werkzeuge benutzt, darf ihre Resultate nicht frei weiterschreiben wie einen Wunschzettel. Sonst ist er kein Orchestrator, sondern ein Improvisateur mit Root-Zugriff.

Das ist der Punkt, an dem man streng werden muss. Halluzination nach Tool-Abruf ist nicht derselbe Fehler wie eine vage Wissensbehauptung in freier Konversation. Es ist ein Bruch der Verfahrensdisziplin. In agentischen Ketten ist genau das die Stelle, an der Vertrauen technisch kollabiert.

API-Kostenprofil

GLM-5.2 ist kein sparsames Modell, wenn man es reden lässt. Besonders auffällig ist der Overhead in mehreren Modulen. Im Bereich Content Transformation produziert es durchschnittlich 3038 Tokens bei einem Fleet-Median von 1768. Das entspricht einem Faktor von 1.72 gegenüber dem Schnitt aller getesteten Modelle. In UX Writing liegen 2993 Tokens einem Median von 1438 gegenüber, also Faktor 2.08. Noch markanter wird es in Cultural Intelligence: 1409 Tokens statt 220 im Median, ein Faktor von 6.4. Auch Code Quality ist mit 3531 gegenüber 2317 Tokens deutlich ausladender und liegt bei Faktor 1.52.

Für ein Cloud-Modell mit 4,4 Dollar pro Million Ausgabetokens ist das kein akademischer Befund. Wer GLM-5.2 in produktiven API-Workflows einsetzt, bezahlt diese Weitschweifigkeit direkt. Das Modell ist nicht verschwenderisch im Sinn sinnloser Wiederholung, aber es ist häufig großzügiger als nötig. Qualität und Kosten laufen hier nicht immer im Gleichschritt.

Datenschutz und Datenhoheit

Für europäische Unternehmen ist GLM-5.2 heikel. Der Provider Zhipu AI sitzt in Beijing, API-Anfragen werden laut Vendor Card in China verarbeitet, und anwendbar ist chinesisches Recht, konkret PIPL, CSL und DSL. Ein DSGVO-taugliches DPA ist in den geprüften Quellen nicht ersichtlich. Für Unternehmen, die personenbezogene Daten DSGVO-konform verarbeiten müssen, ist das ein sehr konkretes Compliance-Hindernis.

Das berechnete Sovereign Risk liegt bei HIGH. Die Begründung ist klar: Z.AI ist ein chinesisches Unternehmen und unterliegt damit auch den dortigen sicherheitsrechtlichen Zugriffsmöglichkeiten. Das BSI hat am 04.02.2025 ausdrücklich vor der Nutzung chinesischer KI-Cloud-Dienste gewarnt; diese Risikologik lässt sich auf Z.AI sachlich übertragen. Die Datenspeicherungsdauer ist mit -1 Tagen angegeben, also nicht verlässlich ausgewiesen. Hinzu kommt ein separates Weights-Provenienz-Risiko von HIGH, das hier nicht von der Deployment-Situation abweicht, sondern sie bestätigt. Für deutsche und europäische Organisationen heißt das: ohne strikte Datenminimierung und ohne unkritische Datenklassen besser nicht.

Fazit

GLM-5.2 ist ein leistungsfähiges, technisch ernst zu nehmendes Frontier-Modell mit klar erkennbarem Berufsprofil. In Code, CLI und agentischer Aufgabenstruktur liefert es häufig genau die Sorte Substanz, die man in Entwicklungsumgebungen sucht. Sein 1M-Kontextfenster und die MoE-Architektur sprechen dafür, dass Z.AI hier kein Chatspielzeug gebaut hat, sondern ein Werkzeug für lange Arbeitsstrecken. Gleichzeitig fehlt dem Modell in mehreren Bereichen die letzte Disziplin: Reasoning ist korrekt, aber nicht makellos aufbereitet; Content-Transformation ist ideenreich, aber zu lang; Tool-Use ist stark, bis es in einem kritischen Moment Fakten aus dem Nichts ergänzt.

Für den Einsatz heißt das: gut geeignet für technische Assistenz, Code-Reviews, Sicherheits-Erstanalysen, CLI-nahe Hilfe und agentische Vorstrukturierung. Weniger geeignet für streng formatgebundene Ausgaben, hochpolierte UX-Texte und jede produktive Tool-Pipeline, in der erfundene Zwischenfakten nicht tolerierbar sind. GLM-5.2 ist kein Blender. Aber es ist auch kein Modell, dem man blind den Schlüsselbund überlässt. Die Halluzinationsresistenz ist insgesamt nicht sauber genug für bedenkenlose Faktenarbeit, und genau deshalb bleibt es ein starkes Werkzeug mit Aufsichtspflicht.

Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT 4.5 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.