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 il 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 IA fabriqués en Chine. Selon l’entreprise, la majeure partie du travail a été réalisée par un agent d’infrastructure 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 fonctionne 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é et une bande passante de mémoire sur puce relativement limitées, une nouvelle architecture de modèle, une fenêtre contextuelle de 1 M de tokens, ainsi que des requêtes multimodales, en plus d’un écosystème immature où 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 nativement multimodal 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 de façon anonyme 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 son lancement, traitant plus de 62 trillions de tokens en six jours.

La méthode de rétroaction dense

Au cœur du compte 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 hausse de 30 % du temps avant le 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 modifications 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 rapide à obtenir. Enfin, elle doit 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 une cause racine.

Dans la boucle de lancement décrite dans le compte, les ingénieurs ont défini des objectifs et des limites du système et ont examiné les changements critiques concernant 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‑noeud pour l’attention linéaire et la tête LM, ReplaySSM, la quantification W8A8, la quantification de cache à précision mixte INT8/FP8/BF16, ainsi que la division 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 révélé 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 une aggravation à mesure que la longueur du contexte augmentait. La correction a explicitement fixé la précision d’entrée à tf32x3, qui utilise trois opérations Tensor Core TF32 pour fournir un résultat de précision supérieure.

Selon le compte, les correctifs ont été intégré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 ne supportant pas le 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 du transfert KV. Selon le compte, 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 la ligne de base 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 l’intranodedispatch ni l’intranodeappel de combinaison ne libérait explicitement le GIL 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 glissaient et le chevauchement avec le calcul se réduisait. Le compte 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 le blocage du 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++ concernés, le compte rapporte que l’écart est tombé en dessous de 1 % dans 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 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 décrit comme une accélération de 1,71 × par rapport à la version précédente.

Résultats annoncés et amélioration récursive autonome

Z.ai rapporte 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 indique également 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 une 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 que, selon elle, les humains doivent continuer à assumer.