Z.ai détaille la construction d’inférence GLM-5.3-Flash sur 100 000 puces chinoises

Z.ai, le 17 septembre 2026, a publié un compte technique décrivant comment elle a construit un service d’inférence de qualité production complet pour son modèle GLM-5.3-Flash à partir de zéro sur un cluster de plus de 100 000 accélérateurs d’IA fabriqués en Chine. Selon l’entreprise, la majeure partie du travail a été réalisée par un Infra Agent alimenté par GLM-5.3 plutôt que par les ingénieurs d’infrastructure seuls, et toute l’inférence en production pour GLM-5.3-Flash s’exécute sur le système.

Z.ai a déclaré que personne n’avait auparavant exploité un cluster d’accélérateurs fabriqués en Chine à cette échelle. L’entreprise a évoqué une capacité de mémoire sur puce et une bande passante relativement limitées, une nouvelle architecture de modèle, une fenêtre contextuelle de 1 M de tokens, et des requêtes multimodales, ainsi qu’un écosystème immature dans lequel le support des noyaux était incomplet et les ingénieurs devaient deviner le comportement qui aurait dû être documenté.

GLM-5.3-Flash lancé le 26 août 2026 en tant que premier modèle multimodal natif de la série GLM-5, avec 320 milliards de paramètres au total et 18 milliards de paramètres actifs sous une architecture hybride combinant attention parcimonieuse et linéaire. Avant la sortie, Z.ai a testé le modèle anonymement sous le nom ox-alpha sur OpenCode et OpenRouter, et l’entreprise a déclaré qu’il était devenu le modèle le plus utilisé sur les deux plateformes dans la semaine suivant le lancement, traitant plus de 62 billion de tokens en six jours.

La méthode de rétroaction dense

Au cœur du récit se trouve un problème système : les métriques de bout en bout peuvent indiquer à un agent que les résultats se sont détériorés, mais pas pourquoi. Un test d’exactitude numérique échoué, une augmentation de 30 % du temps jusqu’au premier token, ou une baisse de 20 % du débit de sortie ne montrent pas quelle couche est responsable ni ce qu’il faut tester ensuite. La réponse de Z.ai, qu’elle appelle rétroaction dense, intègre les tests de correction, les journaux d’exécution, les traces d’exécution, les événements d’exécution, les micro‑benchmarks et les métriques de bout en bout dans des flux de travail répétables qui permettent à l’agent de valider chaque hypothèse localement plutôt que d’attendre un déploiement complet et un test de charge après chaque modification.

L’entreprise définit trois propriétés requises pour ce type de rétroaction. Elle doit être locale, liée autant que possible à des paramètres de lancement spécifiques, des changements de code, des noyaux, des conditions d’entrée, des threads, des intervalles d’exécution ou des chemins de code. Elle doit être peu coûteuse et obtenable rapidement. Elle doit également permettre une vérification objective grâce à des implémentations de référence et à des expériences contrôlées, car les corrélations observées à elles seules n’établissent pas la cause première.

Dans la boucle de lancement décrite dans le récit, les ingénieurs ont défini des objectifs et des limites du système et ont passé en revue les changements critiques impliquant la sémantique numérique, le comportement de concurrence et le risque de production, tandis que l’agent s’occupait de l’analyse, des hypothèses et des modifications de code. La pile qu’ils ont optimisée conjointement combinait le parallélisme tensoriel intra-nœud pour l’attention linéaire et la tête LM, ReplaySSM, la quantification W8A8, la quantification de cache à précision mixte INT8/FP8/BF16, et le découpage de couche, le tout sous une architecture désagrégée Encode‑Prefill‑Decode.

Trois cas d’ingénierie

Le premier cas concerne la justesse numérique. La validation comparant les chemins d’exécution du noyau partitionné et non partitionné a mis en évidence un problème de précision dans le chemin de parallélisme contextuel du noyau KDA : l’opération tl.dot utilisait par défaut le calcul TF32 même lorsque ses entrées étaient en FP32, ce qui a entraîné une accumulation d’erreurs lors de la fusion d’états et les a amplifiées à mesure que la longueur du contexte augmentait. La correction a explicitement fixé la précision d’entrée à tf32x3, qui utilise trois opérations TF32 Tensor Core pour fournir un résultat de précision supérieure.

Selon le récit, les correctifs ont été fusionnés en amont dans Flash Linear Attention. La demande de tirage, ouverte et fusionnée le 27 août 2026, applique la chaîne affine tf32x3 dans les noyaux de mise à jour d’état et de fusion de transformation comme un chemin de précision optionnel, ajoute des tests de parallélisme contextuel, et revient explicitement à la précision IEEE sur les plateformes sans prise en charge du tf32 (AMD, NPU et GPU NVIDIA antérieurs à la capacité de calcul 8.0).

Le deuxième cas concerne un goulot d’étranglement de concurrence lors du transfert KV. Selon le récit, les ingénieurs ont fixé un critère d’acceptation selon lequel, sous la même charge de travail, le préremplissage plus le transfert KV devraient s’exécuter à moins de 5 % de l’indice de référence du préremplissage seul. L’agent a constaté des écarts dépassant 20 % dans certains scénarios et les a attribués à DeepEP v1.2.1, dans lequel ni le intranode_dispatch ni le intranode_combine l’appel a explicitement libéré le GIL de Python. Tant que ces appels détenaient le verrou, le thread Python Mooncake Transfer dans le même processus ne pouvait pas acquérir le GIL à temps, de sorte que la planification et la soumission des tâches de transfert ont glissé et le chevauchement avec le calcul a diminué. Le récit indique que internode_dispatch dans la même version libérait déjà le GIL, avec un commentaire de code précisant que l’intention était d’éviter de bloquer le transfert KV dans d’autres threads pendant que le CPU attendait. Après que la correction a libéré le GIL pendant les intervalles d’exécution C++ pertinents, le récit rapporte que l’écart est tombé en dessous de 1 % sous les mêmes conditions de test.

Le troisième cas porte sur les performances du noyau. Z.ai a fait en sorte que l’agent distille les techniques issues de noyaux écrits à la main dans des projets tels que SGLang, Flash Linear Attention et DeepGEMM en squelettes d’optimisation réutilisables contenant les conditions d’applicabilité, les méthodes de transformation, les contraintes de ressources et les preuves de validation. Sur un noyau KDA Decode représentatif, l’entreprise indique que l’optimisation de division de l’agent a réduit le temps d’exécution de 9,6 %. Après que les retours ont identifié le calcul comme le principal goulot d’étranglement, l’agent a fusionné les tuiles de la dimension V du noyau, qui répétaient les mêmes calculs de normalisation FP32 et de gating quatre fois, en un seul bloc de threads avec des résultats intermédiaires résidents dans les registres et une réduction au niveau d’un warp, produisant ce que l’entreprise rapporte comme une accélération de 1,71 × par rapport à la version précédente.

Résultats déclarés et amélioration récursive autonome

Z.ai indique que GLM-5.3-Flash est passé de l’adaptation initiale du modèle à la mise en production en moins de deux semaines, la bande passante de bout en bout ayant finalement triplé par rapport à la référence initiale. L’entreprise ajoute que l’efficacité d’utilisation du matériel et le coût par jeton ont atteint des niveaux comparables à ceux des GPU NVIDIA grand public.

L’entreprise présente cet effort comme un premier exemple d’amélioration récursive autonome, soulignant que le modèle a participé à l’optimisation du système d’inférence sur lequel il s’exécute. En même temps, Z.ai précise qu’il n’a pas encore atteint l’amélioration récursive autonome, et que le choix des objectifs, la définition des limites et l’évaluation des risques restent des responsabilités humaines qu’elle estime que les humains doivent continuer à assumer.