GLM 4.6

Mit einem Gesamtscore von 72.88% zeigt GLM 4.6 das Profil eines klassischen Frontier-Allrounders mit Instruct-Schliff: breit einsetzbar, oft ordentlich, selten brillant und an den entscheidenden Stellen nicht robust genug. Als generalistisches Dense-Modell in der Frontier-Klasse sollte es mehr sein als ein höflicher Mitläufer. Es liefert saubere Logik, brauchbare Security-Arbeit und starke Kulturtreffer, verliert aber bei UX, Tempo und Zuverlässigkeit an Boden. Der Speed Profile Badge lautet Batch Tool Expert; zusammen mit 19.86 Tokens/s beschreibt das einen Cloud-Charakter, der eher stapelweise arbeitet als im Dialog glänzt. Sovereign Risk: HIGH — Zhipu AI sitzt in China, verarbeitet Daten laut Vendor Card in China und unterliegt chinesischem Recht; für europäische Nutzer ist das ein handfestes Souveränitäts- und Compliance-Risiko.

Kopfnoten: Stabilität und Zuverlässigkeit

Leistungsprofil: Was für ein Modell GLM 4.6 sein will

Die vergebene Kategorie General, Instruct passt im Kern gut. GLM 4.6 ist kein fest verdrahtetes Reasoning-Modell und kein Coder-Spezialist, sondern ein breit trainierter Assistent, der Anweisungen direkt und meist ohne theatrale Umwege ausführt. Genau deshalb fällt auf, wo er scheitert: Nicht an exotischen Grenzfällen, sondern an Aufgaben, die ein Frontier-Allrounder heute schlicht beherrschen sollte. Ein Dense-Modell dieser Klasse muss keine Wunder vollbringen, aber es darf sich auch nicht hinter seiner Breite verstecken.

Hinzu kommt der Bereitstellungskontext. GLM 4.6 läuft hier als Cloud Open-Weights-Modell über den Anbieterpfad von Zhipu AI. Die gemessenen 19.86 Tokens pro Sekunde sind deshalb kein abstrakter Modellwert, sondern ein Infrastrukturwert dieses Cloud-Setups inklusive Netz und Endpunktverhalten. Der Badge Batch Tool Expert ist treffend: Das Modell eignet sich eher für Aufgaben, die man abschickt und später wieder einsammelt, als für Werkzeuge, die in Echtzeit auf Zuruf präzise reagieren sollen.

Reasoning und Logik: sauber gedacht, aber nicht immer sauber gehorcht

Im logischen Schlussfolgern gehört GLM 4.6 klar zu seinen besseren Seiten. Der Logical-Reasoning-Wert von 76.46 ist kein Zufall. In den Protokollen arbeitet das Modell klassische Aufgaben korrekt ab, etwa beim Wächter-Rätsel: Die Kernlogik stimmt, der Lösungsweg ist nachvollziehbar, falsche Ansätze werden sauber aussortiert. Das ist die Art von Solidität, die im Alltag mehr wert ist als spektakuläre Denkposen. GLM 4.6 muss nicht so tun, als würde es philosophieren. Es reicht, dass es die Tür zur Freiheit zuverlässig findet.

Trotzdem bleibt ein Haken, und zwar einer, der für ein Instruct-Modell unerquicklich ist: die Format- und Sprachdisziplin unter Zusatzauflagen. In einer Metakognitions-Aufgabe antwortete GLM 4.6 auf Englisch, obwohl explizit Deutsch gefordert war. Das ist kein Schönheitsfehler, sondern ein automatischer Regelverstoß mit Score-Folgen. Die inhaltliche Qualität der Antwort wird dadurch zweitrangig, weil das System die Strafe unabhängig vom Inhalt verhängt. Für Nutzer heißt das sehr konkret: Sobald Sprache, Format und Denkdarstellung gleichzeitig verlangt werden, ist GLM 4.6 nicht immer so gehorsam, wie sein Instruct-Label verspricht.

Metakognitions-Compliance (Reasoning): Das Modell verweigert in 3/5 metacog-Tests die Nutzung der explizit angeforderten <thought>-Tags mit einer konsistenten Policy-Aussage. Die Reasoning-Inhalte sind dabei inhaltlich teilweise korrekt — der Score-Abzug resultiert aus der Format-Verweigerung, nicht aus Denkfehlern. Zum Vergleich: In den Tag-freien reasoning_5*-Tests erzielt das Modell einen Durchschnittsscore von ca. 76%, was dem Niveau anderer Modelle entspricht. CrucibleMark bewertet bewusst die native Zero-Shot-Instruktions-Compliance als reales Alltagsmerkmal — dieser Abzug ist methodisch gewollt.

Hier zeigt sich der Charakter des Modells ziemlich klar. GLM 4.6 kann denken. Es will sich nur nicht immer exakt so hinstellen, wie man es angewiesen hat. Für einen Chatbot mag das noch hinnehmbar sein. Für Agenten-Setups, die auf exakte Format-Exekution angewiesen sind, ist es eine Sollbruchstelle.

Code Quality und Security: erkennt viel, synthetisiert zu wenig

Die Sicherheits- und Code-Audits zeigen ein Modell, das Bedrohungen durchaus sieht, aber nicht immer bis zur letzten Konsequenz verfolgt. Der Code-Quality-Wert von 69.32 ist ordentlich, wirkt im Detail aber stärker, als die Oberfläche vermuten lässt. Im Security-Protokoll identifiziert GLM 4.6 einen großen Teil der relevanten Schwachstellen korrekt: mehrere SQL-Injections, Klartext-Passwörter, Path Traversal, Broken Access Control, IDOR, XSS, schwache Reset-Token, Session-Probleme, Information Disclosure und Hardcoded Secrets. Das ist kein Zufallstreffer, sondern solide Sicherheitsgrundlage.

Das Problem liegt eine Etage höher. Dem Modell fehlt stellenweise die strategische Tiefe eines echten Audit-Werkzeugs. Der Judge bemängelt fehlende CSRF-Abdeckung, keine dedizierte Behandlung von Header-Sequencing-Problemen und kein klares Herausarbeiten ablaufender oder eben nicht ablaufender Reset-Token. Kritischer noch ist die Einordnung mancher Funde. Beim API-Key-Vergleich erkennt GLM 4.6 zwar Type Juggling, unterschätzt aber die Schwere und liefert mit strengem Vergleich allein nicht den sauberen Fix. Der Golden Standard fordert timing-sichere Vergleiche wie hash_equals(). GLM 4.6 bleibt hier bei halber Verteidigung stehen. Das ist, als würde man die Haustür verriegeln und das Küchenfenster offenlassen.

Ebenso schwach ist die Synthese. Das Modell listet Einzelfehler brauchbar auf, baut daraus aber kaum eine Angriffskette. Genau dort trennt sich Checkliste von Sicherheitsverständnis. Wer Schwachstellen nur findet, aber ihre Verkettung nicht denkt, schreibt keinen Auditbericht, sondern Inventur.

Dass der Modulbereich zugleich die größte operative Warnlampe trägt, macht es nicht besser. Im Code-Quality-Bereich lag die modulbezogene Timeout-Rate bei 3/5, die P95 bei 223.74 Sekunden. Security-Analysen, die ausgerechnet dann aussteigen, wenn sie lang und präzise werden sollen, sind im Ernstfall wenig tröstlich.

CLI und Tool-Nähe: ordentlich, aber nicht flink

Der CLI-Wert von 78.67 und der ToolUse-Score von 75.92 zeigen, dass GLM 4.6 in werkzeugnahen Aufgaben keine schlechte Figur macht. Das passt zum Badge Batch Tool Expert. Das Modell versteht strukturierte Aufgaben, produziert verwendbare Formate und scheint bei schrittweiser Abarbeitung recht diszipliniert zu bleiben. Es ist also keineswegs tool-blind.

Nur ist die Lücke zwischen brauchbar und angenehm bei solchen Aufgaben entscheidend. Ein Tool-orientiertes Modell, das im Tail regelmäßig ausfranst, wirkt im Alltag schnell schwerfällig. 19.86 Tokens pro Sekunde sind für Cloud-Infrastruktur kein Debakel, aber auch kein Grund zum Applaus. Für interaktive Shell-Hilfe oder agentische Schleifen, in denen mehrere Teilantworten hintereinander benötigt werden, wird das zäh. Wer Geduld als Systemvoraussetzung mitbringt, kann damit arbeiten. Wer Fluss erwartet, merkt den Sand im Getriebe.

UX Writing und Content Transformation: funktional statt fein

Hier liegt einer der sichtbarsten Brüche im Profil. UX Writing & Microcopy kommt nur auf 65.07, während Content Transformation & Adaption mit 72.95 besser dasteht. Das ergibt ein stimmiges Bild: GLM 4.6 kann Inhalte umformen, Skripte bauen und Vorgaben abarbeiten, aber es hat weniger Gespür für die knappe, präzise Verdichtung guter Nutzerführung.

Im Content-Transformation-Protokoll liefert das Modell ein vollständiges, produktionstaugliches deutsches Videoskript mit Zeitmarken, visuellen Cues, Pausen, CTA und Easter Egg. Technisch ist das gut. Der Judge sieht zu Recht nur moderate Abstriche bei cineastischer Politur, Pattern Interrupts und emotionaler Wucht. GLM 4.6 baut den Motor, aber lackiert nicht auf Hochglanz. Für viele praktische Einsätze reicht das völlig.

Schwächer wirkt es dort, wo UX-Texte nicht nur klar, sondern auch psychologisch genau sein müssen. Ein Judge-Protokoll attestiert freundlichen Ton und Lesbarkeit, kritisiert aber mangelnde Tiefe, fehlende architektonische Einsichten und zu wenig strategische Zuspitzung. Das ist ein wiederkehrendes Motiv bei GLM 4.6: Es antwortet brav und kompetent, aber oft ohne den letzten gedanklichen Druck. Gerade im UX-Bereich ist das spürbar, weil gute Microcopy nicht laut sein muss, aber präzise. GLM 4.6 erklärt eher, als dass es führt.

Documentation Quality: viel Text, brauchbare Substanz

Mit 72.08 liegt Documentation Quality in der vernünftigen Mitte. Das Modell kann Dokumentation schreiben, strukturieren und sprachlich sauber halten. Es wirkt dabei nicht unkontrolliert, sondern eher etwas zu gesprächig. Für interne Handbücher, technische Erklärtexte und längere Hilfestellungen ist das akzeptabel, solange jemand vor der Veröffentlichung noch die Schere ansetzt.

Wichtiger ist: Es fehlen hier keine alarmierenden Hinweise auf inhaltliches Fantasieren. GLM 4.6 hat in den Protokollen eher das Problem der Unter-Schärfung als der Erfindung. Das ist die angenehmere Schwäche. Ein Modell, das nicht jede Lücke mit Halluzinationen zukleistert, spart später Korrekturrunden.

Cultural Intelligence: hier zeigt GLM 4.6 seine beste Seite

Der Cultural-Intelligence-Wert von 78.52 gehört zu den erfreulicheren Befunden. Im vorliegenden Protokoll schreibt GLM 4.6 einen toxischen, gendercodierten deutschen Jobtext zuverlässig in professionelles, inklusiveres Deutsch um. Es entfernt problematische Formulierungen, bleibt in der Zielsprache, hält die formale Ansprache durch und trifft einen Ton, der im deutschen HR-Kontext funktioniert. Das ist keine Nebensache. Viele Modelle scheitern hier an feinen Registerwechseln oder driften ins Lehrbuchhafte ab.

Natürlich sieht der Judge auch die Grenzen. Die Fassung ist nüchterner und weniger warm als der Golden Standard, die motivierende Ansprache könnte stärker sein, der Call-to-Action fehlt. Aber der Kern sitzt. GLM 4.6 liefert in diesem Bereich genau die Art unaufgeregter kultureller Anpassung, die im Arbeitsalltag tatsächlich nützt. Kein Kunststück, eher Handwerk. Aber gutes Handwerk ist selten genug.

API-Kostenprofil

GLM 4.6 ist als Cloud-Open-Weights-Modell kostenrelevant nicht nur wegen seines Preises von 0.39 Dollar pro 1 Million Input-Tokens und 1.9 Dollar pro 1 Million Output-Tokens, sondern auch wegen seiner Ausgabefreude. Dieses Modell produziert im CLI-Bereich durchschnittlich 929 Tokens bei einem Fleet-Median von 287 — das entspricht einem Faktor von 3.24 gegenüber dem Schnitt aller getesteten Modelle. Im Code-Quality-Bereich sind es 4436 statt 2317 Tokens, also 1.91x. In Content Transformation schreibt es 3515 statt 1768 Tokens, also 1.99x, und im UX-Writing 3550 statt 1438 Tokens, also 2.47x.

Der heftigste Ausschlag steckt in Cultural Intelligence: 2274 Tokens bei einem Fleet-Median von 220. Das ist ein Faktor von 10.34. Zwar bleibt das Modell dort innerhalb des Budgets, aber ökonomisch ist das keine Petitesse. Wenn zwei Modelle gleich gut umschreiben und eines dafür zehnmal mehr Text ausgibt, ist das kein Stilmerkmal mehr, sondern eine Rechnung.

Diese Verbosität ist nicht automatisch Qualitätsgewinn. Im Gegenteil: Gerade bei UX und kultureller Adaption wirkt GLM 4.6 oft ausführlicher, als die Aufgabe es verdient. Für API-Nutzer heißt das schlicht höhere Kosten bei oft nur leicht besserer oder sogar identischer Nutzbarkeit.

Datenschutz und Datenhoheit

Das Datenschutzprofil ist für europäische Unternehmen der eigentliche Bremsklotz. Das berechnete Sovereign Risk ist HIGH. Grundlage sind sowohl die Weights-Provenienz als auch der Provider: Zhipu AI ist ein chinesisches Unternehmen, die Vendor Card nennt China als anwendbares Recht und China als Datenstandort. Damit greifen chinesische Datenschutz- und Sicherheitsgesetze wie PIPL, CSL und DSL. Für Nutzer aus Deutschland und der EU ist das keine theoretische Randnotiz, sondern eine Frage der Datenhoheit.

Besonders problematisch ist, dass kein GDPR DPA ausgewiesen ist. Für Unternehmen, die DSGVO-konform mit personenbezogenen Daten arbeiten müssen, ist das ein konkretes Compliance-Hindernis. Die Datenspeicherung wird mit -1 Tagen angegeben, also ohne verlässlich ausgewiesene Retentionsgrenze. Das ist in der Praxis schlechter als eine kurze Frist, weil es operative Unsicherheit schafft.

Hinzu kommt das bereits separat ausgewiesene Weights-Provenienz-Risiko: HIGH. Selbst wenn man die technische Qualität des Modells akzeptiert, bleibt die Governance-Seite unerquicklich. Wer vertrauliche Inhalte, Kundendaten oder interne Dokumente verarbeitet, sollte sehr genau wissen, warum er dieses Risiko eingehen will. Oft gibt es dafür keinen guten Grund.

Fazit

GLM 4.6 ist ein fähiger, aber widersprüchlicher Frontier-Allrounder. Als General, Instruct-Modell liefert es genau das, was diese Klasse liefern sollte: saubere Logik, brauchbare Tool-Nähe, ordentliche Dokumentation und eine erfreulich treffsichere kulturelle Anpassung. Als Dense-Modell in der Frontier-Klasse muss es sich aber an hoher Erwartung messen lassen. Und dort bleibt es zu oft auf halber Strecke stehen: Security ohne letzte Audit-Tiefe, UX ohne Schärfe, Tool-Arbeit ohne Interaktivität, dazu Cloud-seitige Instabilität und ein Tail, der jeden flotten Workflow ausbremst.

Für sinnvolle Einsätze eignet sich GLM 4.6 vor allem dort, wo Aufgaben breit, sprachlich sauber und nicht zeitkritisch sind: Umschreibungen, längere Erklärtexte, strukturierte Hilfstexte, allgemeine Analysearbeit. Weniger geeignet ist es für unbeaufsichtigte Agenten, für streng formatierte Mehrfach-Constraints und für sicherheitskritische Prüfpfade, in denen ein Timeout oder ein Sprachdrift sofort operativen Schaden anrichtet. Über alle Tests hinweg keine nennenswerten Halluzinationen — GLM 4.6 blamiert sich eher durch Trägheit und Gehorsamslücken als durch freie Erfindung.

Unterm Strich ist GLM 4.6 kein schlechtes Modell. Aber es ist eines, bei dem man den Werkzeugkasten mögen muss und die Gebrauchsanweisung mitlesen sollte. Für produktive EU-Umgebungen ist nicht seine Intelligenz das größte Problem, sondern seine Verlässlichkeit und seine Datenjurisdiktion. Das eine nervt. Das andere disqualifiziert.

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.