Ein Diagramm auf einem Bildschirm zeigt eine Kurve, die erst flach verläuft und dann in deutlichen Stufen nach oben steigt. Aufgetragen ist der Durchsatz eines Inferenzdienstes, gemessen über die Wochen seit dem ersten erfolgreichen Probelauf auf neuer Hardware. Die Ingenieure davor haben einen großen Teil der Änderungen, die zu dieser Kurve geführt haben, nicht selbst geschrieben. Ein Teil der Arbeit kam von einem Agenten, der auf genau jenem Modell läuft, das dieser Dienst später ausliefern soll. Darum geht es in einem Bericht, den das GLM-Team über den Start von GLM-5.3-Flash veröffentlicht hat.
Darin beschreiben die Entwickler etwas, das mehr ist als Werkzeuggebrauch. Ein Modell hilft, die Infrastruktur zu bauen, auf der das nächste Modell trainiert und betrieben wird. Der Text ist offen: Er spricht von Momenten, die das eigene Team überrascht und verunsichert haben, und von einer Entwicklung, die es selbst als schrittweise Ersetzung beschreibt. Wer wissen will, was hinter dem Schlagwort rekursive Selbstverbesserung steckt, findet hier einen konkreten Zwischenstand.
Von der Codeanalyse zur KI-gestützten Cybersicherheit
Im Oktober 2025 begann das Team, die Sicherheitsfähigkeiten von GLM gezielt zu stärken. Die Überlegung dahinter war nüchtern: Wer komplexen Code versteht, sollte auch dessen Schwachstellen verstehen. Cybersicherheit erschien den Entwicklern als Verlängerung des Programmierens, nicht als eigenes Forschungsfeld. Was dann passierte, hatte niemand geplant.
Nach Angaben des Teams fanden Sicherheitspartner in weniger als einem Jahr Tausende Schwachstellen in real genutzten Codebasen. Das verändert die Praxis der KI-gestützten Cybersicherheit. Zugleich entstehen Gefahren, die es vorher in dieser Form nicht gab, weil dieselbe Fähigkeit auch Angreifern offensteht. Um den Zugang zu kontrollieren, mussten die Entwickler ein Programm für vertrauenswürdige Nutzer entwerfen.
Die Zahl der Funde ist das eine. Interessanter ist, wie sich die Rolle verschiebt: Aus einem Modell, das Text erzeugte, wird ein Prüfwerkzeug für fremde Systeme. Sobald eine Fähigkeit dieser Art existiert, lässt sie sich nicht mehr zurücknehmen. Sie lässt sich nur einhegen. Darum geht es im zweiten Teil des Berichts.
Ein Agent erledigt, wofür früher ein ganzes Team Wochen brauchte
Die größere Überraschung kam aus einer anderen Richtung. GLM hilft zunehmend dabei, KI selbst zu bauen. Die Entwickler beschreiben eine Infrastrukturaufgabe, die ein Team erfahrener Ingenieure früher mehrere Wochen gekostet hätte; das Modell erledigte sie deutlich schneller. Als klar wurde, dass diese Arbeit beeinflusst, wie die nächste Modellgeneration trainiert wird, wurde eine Einsicht greifbar: Die eigenen Nachfolger sind die Systeme, die man selbst baut.
Der Bericht ist auch in diesem Punkt offen. Vor GLM-4.7, räumen die Autoren ein, war der interne Einsatz des Modells beim Programmieren eine Pflichtübung. Es war das eigene Produkt, und der Markt für Coding-Assistenten war noch nicht so weit. Heute nennt das Team GLM-5.3 einen täglichen Partner und stellt fest, dass es sich beständig auf die Ablösung der eigenen Rolle zubewegt.
Dieser Endpunkt hat einen Namen. Wenn ein System mit genügend Rechenleistung und Zeit seine eigene Nachfolgeversion entwerfen und trainieren kann, nennt man das Recursive Self-Improvement, kurz RSI. So weit sei es noch nicht, schreiben die Entwickler, aber frühe Formen zeichneten sich ab. Der restliche Artikel dokumentiert eine solche frühe Form.
Produktionsbetrieb auf über 100.000 chinesischen KI-Beschleunigern
Ein Modell vom ersten erfolgreichen Lauf auf neuer Hardware bis zu einem Dienst zu bringen, der echten Produktionsverkehr zuverlässig trägt, ist schwere Systemarbeit. Für GLM-5.3-Flash bedeutete das, eine vollständige Inferenz-Infrastruktur auf einem Cluster aus mehr als 100.000 chinesischen KI-Beschleunigern aufzubauen. Der gesamte Produktionsbetrieb des Modells läuft auf diesem System.
Einfach war das nicht. Niemand hatte zuvor einen Cluster dieser Größenordnung mit chinesischen Beschleunigern in Betrieb genommen. Die Speicherkapazität und die Bandbreite der Chips waren begrenzt, während gleichzeitig eine neue Modellarchitektur, ein Kontextfenster von einer Million Token und multimodale Anfragen unterstützt werden mussten. Das Ökosystem war unreif, die Kernel-Unterstützung lückenhaft, und vieles, was dokumentiert sein sollte, musste erraten werden.
Ein großer Teil dieser Arbeit wurde nicht von einem Team aus Infrastruktur-Ingenieuren erledigt, sondern von einem Infra Agent, der auf GLM-5.3 läuft. Anschließend wurde GLM-5.3-Flash unter dem anonymen Namen Ox-Alpha auf OpenCode und OpenRouter getestet. Innerhalb einer Woche war es auf beiden Plattformen das meistgenutzte Modell und verarbeitete in sechs Tagen mehr als 62 Billionen Token.
Warum End-to-End-Metriken den Agenten im Dunkeln lassen
Hier lohnt ein Bild aus der Medizin. Eine Waage zeigt, dass jemand an Gewicht verloren hat, aber sie sagt nicht, warum. Genauso verhält es sich mit den klassischen Kennzahlen eines Inferenzsystems. Wenn nach einer Änderung die Zeit bis zum ersten Token um 30 Prozent steigt oder der Durchsatz um 20 Prozent fällt, weiß der Agent zwar, dass etwas schlechter geworden ist. Er weiß aber nicht, welche Schicht dafür verantwortlich ist.
Inference-Optimierung bringt reichlich Tests, Logs, Profiler und Microbenchmarks mit sich. Nur sind diese Werkzeuge meist über verschiedene Arbeitsphasen verstreut. Erfahrene Ingenieure nutzen das Ergebnis eines Lasttests, um zu entscheiden, was sie als Nächstes ansehen, und verknüpfen dabei Kernel-Ausgaben, Ausführungs-Zeitachsen, Kommunikationsereignisse und Thread-Zustände. Für einen Agenten bleibt dieser Zusammenhang unsichtbar, solange er nicht in direkt aufrufbare, wiederholbare Abläufe gegossen wird.
Ein Codebestand liefert nur statischen Kontext. Numerische Abweichungen und Leistungseinbrüche eines Inferenzsystems entstehen dagegen aus dem Zusammenspiel mehrerer Ebenen: Kernel-Implementierungen, Parallelisierungsstrategien, Kommunikationsverhalten, Speicherverwaltung und Serving-Orchestrierung. Selbst wenn ein Agent den gesamten Code versteht, sagt ihm die Rückmeldung „Genauigkeitstest fehlgeschlagen“ nicht, warum seine Hypothese falsch war und was er als Nächstes prüfen sollte. Das ist der Kern des Berichts.
Dichtes Feedback: lokal, günstig, überprüfbar
Die Antwort der Entwickler heißt dense feedback, also dichtes Feedback. Damit ist nicht gemeint, dem Agenten möglichst viele Logs und Kennzahlen um die Ohren zu schlagen. Gemeint sind drei Eigenschaften. Erstens muss die Rückmeldung lokal genug sein: Sie sollte an konkrete Startparameter, Codeänderungen, Kernel, Eingabeformen, Threads oder Codepfade gebunden sein, damit der Agent den Suchraum eingrenzen kann.
Zweitens muss sie günstig und schnell zu bekommen sein. Wer eine Hypothese aufstellt oder eine Änderung vornimmt, sollte sie mit einem Kernel-Test oder einem lokalen Microbenchmark prüfen können, ohne jedes Mal einen vollständigen Dienst auszurollen und einen Lasttest zu fahren. Kürzere Prüfschleifen erlauben es, frühzeitig zu korrigieren und weniger Zeit in aussichtslose Annahmen zu stecken.
Drittens muss sie objektiv nachprüfbar sein. Ob eine Änderung korrekt ist und ob sie schneller läuft, entscheiden Referenzimplementierungen, Testergebnisse und vergleichbare Messwerte. Laufzeitsignale können Hinweise geben, aber eine Korrelation ist noch keine Ursache. Kontrollierte Experimente bleiben nötig, um zu belegen, dass eine Änderung an einem bestimmten Pfad den erwarteten Effekt hat. Dazu gehört auch, den Unterschied zwischen lokaler Prüfung und End-to-End-Test klar zu halten: Die lokale Prüfung sortiert früh aus und findet Kandidaten, der Gesamttest bestätigt, ob daraus echter Gewinn wird.
Tensor Parallelismus, EPD und der dreifache Durchsatz
Auf dieser Grundlage entstand eine Optimierungsschleife aus Ingenieuren, Infra Agent und Versuchsumgebung. Die Ingenieure setzten Ziele und Systemgrenzen, der Agent übernahm Analyse, Hypothesen und Codeänderungen, die Umgebung lieferte geschichtetes und prüfbares Feedback. So wurde ein Diagnoseprozess, den früher die Erfahrung einzelner Personen zusammenhielt, zu einem Ablauf, den der Agent durchgehend ausführen konnte.
Technisch kamen mehrere Maßnahmen zusammen. Der Stack nutzte Tensor Parallelismus innerhalb eines Knotens für lineare Attention und den LM Head, dazu ReplaySSM, W8A8-Quantisierung, gemischte Cache-Quantisierung mit INT8, FP8 und BF16 sowie einen Layer Split. Darauf setzte eine disaggregierte Encode-Prefill-Decode-Architektur, kurz EPD, die die drei Phasen der Verarbeitung voneinander trennt und getrennt skaliert.
Die Entwickler beschreiben aggressive Speicheroptimierungen, bei denen Rechenleistung gegen Bandbreite und Kommunikation gegen Gerätespeicher getauscht wurde. Unterm Strich verbesserte sich die Ende-zu-Ende-Leistung des Dienstes um etwa das Dreifache. Hardware-Auslastung und Kosten pro Token erreichten nach Angaben des Teams ein Niveau, das mit gängigen NVIDIA-GPUs vergleichbar ist. Vom ersten Anpassen des Modells bis zur Produktionsreife vergingen weniger als zwei Wochen.
Was das konkret bedeutet
Man kann diesen Bericht als Marketing lesen, und ein Teil davon ist er sicher auch. Interessanter ist die technische Aussage in der Mitte. Der Engpass beim Einsatz von KI-Agenten in komplexen Systemen liegt nicht allein in der Fähigkeit, Code zu schreiben. Er liegt darin, ob die Umgebung Rückmeldungen liefert, die sich auf konkrete Ursachen zurückführen lassen. Ein Agent ohne dichtes Feedback stochert im Nebel, egal wie gut er formuliert.
Für die weitere Entwicklung heißt das: Wer KI-Agenten in Infrastruktur einsetzen will, muss in Beobachtbarkeit investieren, nicht nur in Modellgröße. Dieser Punkt lässt sich auf andere Felder übertragen, von der KI-gestützten Cybersicherheit bis zur klassischen Softwarewartung. Die Frage ist überall dieselbe: Bekommt das System genug verwertbare Signale, um seine nächste Handlung zu begründen?
Vollständige rekursive Selbstverbesserung ist weiter entfernt, als die Schlagzeilen nahelegen. Was hier beschrieben wird, ist ein Zwischenschritt: ein Agent, der unter Aufsicht von Menschen einen Produktionsdienst mitgebaut hat, auf Hardware, für die es kaum Erfahrungswerte gab. Das ist weniger als eine sich selbst verbessernde Maschine und mehr als ein Autovervollständiger.
Quelle: z.ai
