GLM baut eigene Inferenz-Infrastruktur: 100.000 chinesische Acceleratoren und ein Agent, der mitoptimiert

Z.ai hat für die Produktion von GLM-5.3-Flash eine komplette Inferenz-Infrastruktur von Grund auf neu gebaut - auf einem Cluster mit über 100.000 chinesischen AI-Beschleunigern. Damit ist GLM eines der ersten Unternehmen, das chinesische Acceleratoren in dieser Größenordnung produktiv einsetzt. Der eigentliche Knackpunkt des Blogposts ist aber ein anderer: Einen Großteil der Systems-Arbeit hat nicht nur ein Ingenieursteam erledigt, sondern ein von GLM-5.3 angetriebener “Infra Agent”. Z.ai deutet das als frühe Form von Recursive Self-Improvement - das Modell hilft mit, die Infrastruktur aufzubauen, auf der es selbst läuft.

Warum das schwierig war

Bisher hatte niemand chinesische Beschleuniger in dieser Skalierung deployed. Dazu kamen: begrenzter Chip-Speicher und Bandbreite, eine neue Modellarchitektur (GLM-5.3-Flash nutzt lineare Aufmerksamkeit), ein 1M-Token-Kontextfenster, multimodale Requests und ein unreifes Okosystem mit unvollständigem Kernel-Support - vieles musste ausprobiert statt nachgelesen werden.

Der Stack der Optimierungen

Das Team (Mensch plus Agent) setzte auf aggressive Speicheroptimierungen, die Rechenzeit gegen Bandbreite und Kommunikation gegen Device-Speicher tauschten:

• Intra-Node Tensor-Parallelität für lineare Attention und den LM Head
• ReplaySSM: Compute gegen Speicherzugriffe tauschen
• W8A8-Quantisierung plus gemischte Cache-Quantisierung (INT8/FP8/BF16)
• Layer Split
• Encode-Prefill-Decode (EPD) disaggregierte Architektur

Ergebnis: rund 3x End-to-End-Serving-Performance gegenüber demselben Hardware-Baseline. Effizienz und Kosten pro Token erreichen laut z.ai Niveau vergleichbar mit mainstream NVIDIA-GPUs. Von der ersten Modell-Adaption bis Production-Readiness vergingen weniger als zwei Wochen. GLM-5.3-Flash war zuvor unter dem anonymen Namen “Ox-Alpha” auf OpenCode und OpenRouter live getestet worden und wurde dort binnen einer Woche zum meistgenutzten Modell - 62 Billionen Token in sechs Tagen.

“Dense Feedback”: Warum der Agent überhaupt arbeiten konnte

Der interessanteste Teil ist die Methode. Z.ai argumentiert: Ein Agent, der nur End-to-End-Metriken sieht (“Throughput -20%”), weiß nicht, welche Schicht schuld ist. Die Lösung nennen sie “dense feedback” - Feedback, das drei Eigenschaften haben muss:

• Lokal genug: bezogen auf konkrete Kernel, Parameter, Threads oder Codepfade statt auf das ganze System
• Günstig und schnell: per Kernel-Test oder Microbenchmark validierbar, nicht erst per komplettem Deployment
• Objektiv verifizierbar: Referenzimplementierungen und kontrollierte Experimente statt bloßer Korrelation

Konkrete Beispiele aus dem Artikel: Der Agent fand einen Numerik-Bug im KDA-Kernel im Context-Parallelism-Pfad, indem er partitionierte gegen unpartitionierte Ausführungen verglich. Er diagnostizierte einen KV-Transfer-Bottleneck bis hinunter zum Python GIL: DeepEP v1.2.1 gab bei intra-node dispatch/combine den GIL nicht frei, blockierte damit den Mooncake-Transfer-Thread - nach dem Fix sank die Performance-Lücke von über 20% auf unter 1%. Und er optimierte einen KDA-Decode-Kernel um 1.71x, indem er Redundanz in der FP32-Normalisierung eliminierte, die durch V-dimensionales Tiling vierfach berechnet wurde.

Einordnung

Z.ai betont, RSI sei noch nicht erreicht: Ziele, Grenzen und Risiko-Bewertung bleiben Menschen vorbehalten - und sollen es ihrer Aussage nach lange bleiben. Aber die Zahlen (zwei Wochen, 3x Durchsatz, 100.000 Acceleratoren) zeigen, wie schnell sich System Engineering verändert, wenn Modelle im Feedback-Loop mitarbeiten. Für den Westen ist das auch industriepolitisch relevant: US-Exportkontrollen zwangen chinesische Anbieter, die Software-Optimierung für eigene Chips massiv zu beschleunigen - mit sichtbarem Erfolg.

Link: z.ai Blog