Z.ai: Das eigene Modell hat den Inferenz-Stack gebaut, auf dem es auf 100.000 chinesischen Chips läuft

Am 17. September 2026 veröffentlichte das chinesische KI-Unternehmen Z.ai einen technischen Bericht über ein Projekt, der sich weniger wie eine Produktankündigung denn wie ein Engineering-Log liest. Das Unternehmen erklärte, es habe einen vollständigen Produktions-Inferenzdienst für sein Modell GLM-5.3-Flash von Grund auf auf einem Cluster aus mehr als 100.000 in China gefertigten KI-Beschleunigern aufgebaut, und ein auf dem Modell laufender KI-Agent habe einen Großteil der Arbeit auf niedriger Ebene erledigt.

Zum Weiterlesen: Ein ChatGPT-Miterfinder sagt: Der KI fehlt ein Modell, das nicht spricht · Die Erbauer der KI warnen vor den Maschinen, die sie bauen.

Z.ai, früher als Zhipu AI bekannt, erklärt, niemand habe zuvor inländische chinesische Beschleuniger in dieser Größenordnung für ein multimodales Frontier-Modell betrieben. Der Bericht, im Blog des Unternehmens veröffentlicht, legt die Hardware-Grenzen dar, die Rolle des Agenten und die konkreten Fehler, die seine Ingenieure und der Agent behoben haben. Es ist ein Unternehmensdokument, kein unabhängiger Benchmark, und die Leistungszahlen stammen von Z.ai selbst. So gelesen ist es dennoch eine der detaillierteren öffentlichen Beschreibungen dessen, was nötig ist, um ein großes Modell auf Silizium zu betreiben, das nicht mit Nvidias Software-Ökosystem im Sinn entworfen wurde.

Was Z.ai nach eigenen Angaben gebaut hat

GLM-5.3-Flash wurde am 26. August 2026 veröffentlicht. Es ist ein Mixture-of-Experts-Modell mit 320 Milliarden Parametern, von denen pro Token etwa 18 Milliarden aktiv sind, eine Mischung aus sparse und linearer Attention, mit einem Kontextfenster von bis zu einer Million Token. Das Unternehmen veröffentlichte es unter der MIT-Lizenz.

Das Serving-Problem lag nicht am Modell allein. Laut Z.ai haben die verwendeten chinesischen Beschleuniger weniger On-Chip-Speicher und Bandbreite als gängige Grafikprozessoren, und das Software-Ökosystem darum sei unreif, mit unvollständiger Kernel-Unterstützung und Verhalten, das hätte dokumentiert sein sollen, aber experimentell entdeckt werden musste. Hinzu kamen eine neue Architektur, ein sehr langes Kontextfenster und multimodale Anfragen.

Die Antwort des Unternehmens verband zwei Dinge: einen Agenten und eine Rückkopplungsschleife.

Ein Agent, der Vorschläge macht, und Ingenieure, die entscheiden

Z.ai beschreibt einen von GLM-5.3 angetriebenen Infra Agent, der Diagnosen, Kernel-Patches und Stack-Änderungen vorschlug. Menschliche Ingenieure setzten die Ziele und die Systemgrenzen und prüften die Änderungen, die echtes Risiko bargen, einschließlich allem, was numerische Genauigkeit, Nebenläufigkeit oder Produktionssicherheit berührte.

Die Methode, die das Unternehmen dense feedback nennt, ist der Teil, der sich zu verstehen lohnt. Eine End-to-End-Metrik kann einem Agenten sagen, dass etwas schlechter geworden ist, aber nicht, warum. Ein fehlgeschlagener Genauigkeitstest, ein Anstieg der Zeit bis zum ersten Token um 30 Prozent oder ein Rückgang des Ausgabe-Durchsatzes um 20 Prozent benennen nicht die verantwortliche Ebene. Der Ansatz von Z.ai fasst Korrektheitstests, Laufzeitprotokolle, Ausführungs-Traces, Microbenchmarks und End-to-End-Metriken zu wiederholbaren Workflows zusammen, damit der Agent eine Hypothese lokal validieren kann, statt nach jeder Änderung auf eine vollständige Bereitstellung und einen Lasttest zu warten.

Drei Eigenschaften machen das laut dem Bericht möglich. Die Rückmeldung muss lokal sein, gebunden an bestimmte Startparameter, Codeänderungen, Kernel oder Eingabebedingungen. Sie muss günstig und schnell zu erhalten sein. Und sie muss eine objektive Überprüfung erlauben, denn eine Korrelation allein begründet keine Grundursache.

Drei Korrekturen und was sie zeigen

Der Bericht führt durch drei Engineering-Fälle, und jeder zeigt, wie wenig glamourös Serving-Arbeit ist.

Der erste ist ein numerisches Problem. Als Z.ai partitionierte und unpartitionierte Kernel-Pfade verglich, fand es ein Genauigkeitsproblem im Kontextparallelismus-Pfad des KDA-Kernels. Die Operation tl.dot fiel standardmäßig auf TF32-Berechnung zurück, selbst wenn ihre Eingaben FP32 waren, sodass sich Fehler beim Zusammenführen von Zuständen ansammelten und mit der Kontextlänge wuchsen. Die Korrektur setzte die Eingabepräzision auf tf32x3, was drei TF32-Tensor-Core-Operationen nutzt, um ein präziseres Ergebnis zu erzeugen. Z.ai zufolge wurde die Änderung upstream in Flash Linear Attention übernommen, in einem Pull Request, der am 27. August 2026 geöffnet und zusammengeführt wurde.

Der zweite ist ein Nebenläufigkeitsengpass. Das Team setzte ein Abnahmekriterium: Prefill plus KV-Transfer sollten innerhalb von 5 Prozent einer reinen Prefill-Basislinie laufen. Der Agent fand in manchen Szenarien Abweichungen über 20 Prozent und führte sie auf DeepEP v1.2.1 zurück, wo zwei interne Aufrufe den globalen Python-Interpreter-Lock nicht freigaben. Solange diese Aufrufe den Lock hielten, konnte der Transfer-Thread im selben Prozess ihn nicht rechtzeitig erwerben, sodass die Planung ins Rutschen geriet und die Überlappung mit der Berechnung schrumpfte. Nachdem die Korrektur den Lock in den relevanten Intervallen freigab, sank die Abweichung laut Z.ai unter denselben Bedingungen auf unter 1 Prozent.

Der dritte ist ein Leistungsgewinn bei einem Kernel. Z.ai ließ den Agenten Techniken aus handgeschriebenen Kernels in Projekten wie SGLang, Flash Linear Attention und DeepGEMM zu wiederverwendbaren Optimierungsmustern destillieren. Bei einem KDA-Decode-Kernel senkte eine Divisionsoptimierung die Ausführungszeit um 9,6 Prozent. Die Rückmeldung deutete dann auf die Berechnung als Engpass hin, und der Agent führte vier wiederholte FP32-Normalisierungs- und Gating-Operationen in einem einzigen Thread-Block zusammen, was laut Unternehmen eine Beschleunigung um den Faktor 1,71 gegenüber der vorherigen Version ergab.

Keine davon ist für sich genommen ein Durchbruch. Zusammen sind sie die Art von Arbeit, die Nvidias Softwarevorteil über Jahre haltbar gemacht hat: nicht der Chip allein, sondern die Tausenden kleinen Korrekturen, die einen Chip im großen Maßstab nutzbar machen. Ein Agent, der einen Teil dieser Last tragen kann, verändert die Kosten, ein Modell auf neues Silizium zu portieren.

Die Geschwindigkeitsstufe FlashX

Zusätzlich zur Infrastrukturarbeit eröffnete Z.ai um den 18. September 2026 eine Serving-Stufe namens GLM-5.3-FlashX in seiner API. Das Unternehmen bewirbt sie als Hochgeschwindigkeitsvariante der Flash-Familie und gibt an, die Spitzengenerierung erreiche etwa 200 Token pro Sekunde, wobei Kapazität aus demselben inländischen Beschleuniger-Cluster genutzt werde. Pandaily berichtete, die Stufe positioniere die Arbeit als Produkt für Produktionslatenz statt als neues Basismodell.

Der Zeitpunkt ist wichtig. Eine schnellere Serving-Stufe ist ein kommerzielles Versprechen über Kapazität, nicht nur ein Benchmark. Sie sagt Entwicklern, dass der Cluster keine einmalige Demonstration ist, sondern ein System, mit dem das Unternehmen verkaufen will.

Was rekursive Selbstverbesserung hier bedeutet

Z.ai rahmt das Projekt als frühes Beispiel rekursiver Selbstverbesserung, der Idee, dass ein Modell die Systeme verbessern kann, die es trainieren oder bedienen. Dann nimmt das Unternehmen von dem Begriff Abstand. Es stellt klar, dass es rekursive Selbstverbesserung nicht erreicht habe und dass die Wahl der Ziele, das Setzen von Grenzen und die Risikobewertung weiterhin menschliche Aufgaben bleiben, die nach seiner Auffassung Menschen tragen sollten.

Die Unterscheidung ist ehrlich und wichtig. Ein Agent, der Kernels unter menschlicher Prüfung patcht, ist weit entfernt von einem System, das seine eigenen Ziele setzt. Die engere, konkretere Aussage lautet, dass Systemengineering auf niedriger Ebene, eine Kategorie von Arbeit, die sich der Automatisierung widersetzt hat, teilweise automatisierbar sein könnte, wenn das Modell dichte, lokale und überprüfbare Rückmeldungen über die Maschine hat, auf der es läuft.

Warum Nicht-Nvidia-Inferenz die eigentliche Geschichte ist

Die größere Bedeutung betrifft die Frage, woher Inferenzkapazität kommen kann. Wenn ein multimodales Modell im Frontier-Maßstab zu wettbewerbsfähigen Kosten pro Token auf chinesischen Beschleunigern betrieben werden kann, dann geht es bei der Einschränkung der chinesischen KI-Industrie weniger um den Zugang zu Nvidias schnellsten Chips und mehr um die Reife inländischer Hard- und Software. Z.ai erklärte, Hardware-Auslastung und Kosten pro Token hätten Werte erreicht, die mit gängigen Nvidia-GPUs vergleichbar seien, was, falls es Bestand hat, eine direkte Herausforderung der Annahme ist, dass modernstes KI-Serving Nvidia-Hardware erfordert.

Diese Behauptung verdient Prüfung. Z.ai vergleicht seinen eigenen Cluster mit einer Nvidia-Wirtschaftlichkeit, die es nicht kontrolliert, und hat den Vergleich Workload für Workload nicht veröffentlicht, der die Frage klären würde. Das Basismodell selbst wurde vor der Veröffentlichung als ox-alpha anonym auf OpenCode und OpenRouter getestet, und Z.ai erklärte, es sei innerhalb einer Woche zum meistgenutzten Modell auf beiden Plattformen geworden und habe in sechs Tagen mehr als 62 Billionen Token verarbeitet.

Der Kontext ist eine wachsende Anstrengung in China, die Abhängigkeit von amerikanischen Chips zu verringern. Inländische Beschleunigerhersteller, Speicherlieferanten und Cloud-Anbieter drängen alle darauf, die Lücke zu füllen, und die Softwareebene war der schwierigste Teil. Ein funktionierender, agentenunterstützter Serving-Stack ist ein Beleg für diese Anstrengung, auch wenn seine Wirtschaftlichkeit noch nicht unabhängig bestätigt ist.

Vorbehalte und worauf man achten sollte

Nahezu jede Zahl hier stammt von Z.ai. Der Durchsatzgewinn um den Faktor 3, der Zeitrahmen von unter zwei Wochen, die Kernel-Beschleunigung um den Faktor 1,71 und der Vergleich mit der Nvidia-Wirtschaftlichkeit sind Unternehmensangaben. Der GitHub-Pull-Request ist öffentlich und überprüfbar, was dem Fall der numerischen Genauigkeit eine gewisse unabhängige Grundlage gibt, doch der Rest wurde außerhalb des Unternehmens nicht reproduziert.

Drei Dinge wären in den kommenden Monaten wichtig. Erstens, ob unabhängige Nutzer die Durchsatz- und Kostenbehauptungen auf derselben oder ähnlicher Hardware reproduzieren. Zweitens, ob die von Z.ai beschriebenen Optimierungen über andere chinesische Beschleuniger hinweg wiederverwendbar oder spezifisch für den eigenen Cluster sind. Drittens, ob FlashX die versprochene Latenz im großen Maßstab hält, sobald echter Verkehr statt eines Startwochen-Profils ankommt.

Vorerst ist die Geschichte ein Datenpunkt in einer Debatte, die das ganze Jahr über läuft: wie schnell sich die Softwarelücke rund um Nicht-Nvidia-KI-Hardware schließen lässt und wie viel dieser Arbeit die Modelle selbst erledigen können. Die Antwort von Z.ai lautet, dass ein bedeutender Teil davon bereits möglich ist. Die Beweislast liegt nun bei den Benchmarks, die folgen.

Titelbild: Die Wortmarke von Zhipu AI (Z.ai). Das Logo ist gemeinfrei, via Wikimedia Commons.