Z.ai a publié un long essai technique intitulé « Toward Recursive Self-Improvement » (« Vers l'auto-amélioration récursive »), documentant comment un Infra Agent propulsé par GLM-5.3 a contribué à construire et optimiser la pile d'inférence de production qui sert désormais GLM-5.3-Flash. L'essai s'ouvre sur un aveu inhabituel pour un blog d'entreprise : « À mesure que nous développons GLM, le modèle manifeste parfois des capacités qui nous surprennent, et même nous troublent. » Ce qui suit est la méthodologie détaillée derrière une affirmation que la propre couverture de GLM-5.3-Flash par ce blog avait signalée en deux phrases il y a trois semaines — qu'« un agent d'infrastructure propulsé par GLM-5.3 a aidé les ingénieurs à développer et optimiser des kernels » — en l'identifiant explicitement comme un élément à surveiller en attendant une vérification indépendante. Z.ai n'a pas fourni de vérification externe ici ; ce qu'elle a fourni à la place, c'est bien davantage de détails d'ingénierie réels que ce que la plupart des laboratoires divulguent sur la façon dont un modèle a été construit.
Les chiffres phares, réénoncés avec une méthodologie derrière eux
L'affirmation d'échelle : l'Infra Agent a aidé à construire un service d'inférence de qualité production entièrement à partir de zéro, sur un cluster de plus de 100 000 accélérateurs d'IA de fabrication chinoise — Z.ai indique clairement que personne n'avait auparavant déployé un cluster d'accélérateurs domestiques à cette échelle, en composant avec une bande passante mémoire limitée, un écosystème logiciel immature et un support de kernel incomplet. Le résultat : GLM-5.3-Flash est passé de sa première exécution réussie à une disponibilité en production en moins de deux semaines, avec un débit de bout en bout triplé par rapport à la base de référence initiale, atteignant une efficacité matérielle et un coût par token que Z.ai qualifie de « comparables aux GPU Nvidia grand public ». Ce sont les mêmes chiffres — triplement et parité avec Nvidia — que la couverture précédente de ce blog avait déjà signalés comme auto-rapportés face à la propre base de référence antérieure de Z.ai plutôt que comme un benchmark indépendant — l'essai d'aujourd'hui ne change pas ce statut de preuve, mais il montre le travail effectué d'une façon que la divulgation initiale en deux phrases ne faisait pas.
Le « retour dense » : l'affirmation méthodologique qui mérite d'être prise au sérieux
La véritable contribution de l'essai est un argument précis sur les raisons pour lesquelles le travail d'infrastructure piloté par agent réussit ou échoue : les métriques de bout en bout seules (« le débit a chuté de 20 % ») indiquent à un agent que quelque chose s'est dégradé sans lui dire pourquoi, à travers les nombreuses couches — implémentation du kernel, stratégie de parallélisme, communication, gestion mémoire, orchestration du service — où la cause pourrait réellement se situer. La solution de Z.ai a consisté à construire ce qu'elle appelle un environnement de « retour dense » : tests de correction, traces d'exécution, microbenchmarks et métriques de bout en bout intégrés à la boucle d'itération de l'agent, afin qu'il puisse tester une hypothèse précise localement plutôt que d'attendre un cycle de déploiement complet après chaque changement. Les trois propriétés que Z.ai identifie comme rendant un retour réellement exploitable — suffisamment local (rattaché à un kernel ou un chemin de code précis, pas « la précision a chuté »), peu coûteux à obtenir (un test de kernel plutôt qu'un redéploiement complet) et objectivement vérifiable (face à des implémentations de référence, pas seulement des corrélations d'apparence plausible) — constitue un argument d'ingénierie systèmes réellement précis, pas seulement une démonstration de capacité.
Trois études de cas, dont une vérifiable de façon indépendante
Z.ai étaye sa méthodologie avec trois exemples détaillés, et l'un d'eux produit un artefact hors du contrôle de Z.ai elle-même. Dans le cas de correction, l'agent a trouvé un bug de précision numérique dans le chemin de parallélisme de contexte (Context Parallelism) du kernel KDA : une opération matricielle utilisait par défaut un calcul en précision réduite TF32 même sur des entrées FP32, les erreurs s'accumulant sur les longs contextes. Le correctif — fixer explicitement input_precision="tf32x3" pour combiner trois opérations Tensor Core TF32 afin d'obtenir une précision plus élevée — a été fusionné en amont dans la bibliothèque open source Flash Linear Attention sous forme de pull request publique, une trace réelle et vérifiable de l'extérieur, plutôt qu'une affirmation reposant sur la seule parole de Z.ai. Dans le cas du comportement système, l'agent a retracé un écart de performance de KV Transfer dépassant 20 % (contre un seuil d'acceptation de 5 %) jusqu'à un goulot d'étranglement lié au GIL Python : deux appels de dispatch DeepEP retenaient le verrou pendant l'exécution C++ sans le libérer, bloquant un thread Python distinct chargé de planifier les transferts de données — libérer le GIL pendant ces intervalles a ramené l'écart sous 1 %. Dans le cas de performance, l'agent a distillé des « squelettes d'optimisation » à partir de kernels existants issus de SGLang, Flash Linear Attention et DeepGEMM, puis a appliqué un remaniement du tuilage au kernel KDA Decode — fusionnant quatre calculs redondants de normalisation FP32 par tuile en une seule réduction au niveau du warp — pour un gain rapporté de 1,71 fois par rapport à la version précédente.
La réserve sur l'ARS, mesurée face aux deux autres de la même semaine
C'est ici que l'essai fait quelque chose qu'aucune publication antérieure de Z.ai n'avait fait : il invoque explicitement l'auto-amélioration récursive (ARS) et prend position sur son degré d'avancement. Ce blog avait couvert le propre rapport d'OpenAI sur l'ARS il y a onze jours, et ce qui rendait ce rapport notable n'était pas les chiffres de capacité mais la réserve exprimée — OpenAI affirmait directement ne pas encore savoir « comment atteindre en toute sécurité une ARS complète et alignée », distinguant un jalon plus restreint de « stagiaire de recherche automatisé » qu'elle dit avoir déjà atteint d'un problème plus difficile et sans date, celui de l'« ARS complète » — une distinction que cet article opposait directement à l'annonce AIRA₃ de Meta la même semaine, laquelle se terminait par une seule phrase non nuancée sur le déverrouillage de l'auto-amélioration récursive, sans discussion de sécurité comparable. L'essai de Z.ai se rapproche davantage de la posture d'OpenAI que de celle de Meta : « Nous n'y sommes pas encore, mais des formes précoces de cela émergent déjà », suivi d'une déclaration explicite selon laquelle « choisir les objectifs, fixer les limites et évaluer les risques restent des responsabilités humaines » et « nous pensons que les humains devraient continuer à tenir cette ligne pendant longtemps encore ». C'est une réserve authentique, argumentée plutôt que simplement affirmée — ce qui mérite d'être noté précisément parce qu'il s'agit de la première entrée d'un laboratoire chinois dans un débat que ce blog n'avait suivi jusqu'ici qu'à travers des voix américaines et européennes ce mois-ci, depuis l'essai original d'Amodei jusqu'à la réponse de Dorsey en passant par le cadre de désalignement d'OpenAI, publié le même jour que cet essai. La phrase de conclusion nuance toutefois jusqu'à sa propre réserve : « les chiffres — deux semaines, un débit triplé et 100 000 accélérateurs — nous indiquent que les progrès à cette frontière ne ralentiront pas simplement parce que nous le souhaitons » — une déclaration d'inévitabilité placée juste à côté de l'engagement de sécurité, sans être pleinement réconciliée avec lui.
Le fil de la cybersécurité que cet essai rouvre sans le refermer
Le même fil d'annonce indique séparément que Z.ai a commencé à étudier les capacités de cybersécurité de GLM en octobre 2025, et qu'en moins d'un an, ses partenaires de sécurité ont utilisé GLM pour trouver « des milliers de vulnérabilités dans des bases de code réelles », nécessitant ce qu'elle appelle un « programme d'accès de confiance » pour être géré de façon responsable. Ce blog avait couvert le chapitre précédent de cette histoire lors du lancement de GLM-5.3 lui-même il y a un mois : 2 436 vulnérabilités trouvées dans des logiciels de production réels, Z.ai ayant retardé la publication des poids ouverts de deux semaines spécifiquement pour renforcer la sécurité de cette capacité. L'essai d'aujourd'hui donne à ce programme une date de début et un chiffre plus large et arrondi, mais aucun détail sur ce que le programme d'accès de confiance restreint réellement ni sur qui y est éligible — la même lacune que ce blog avait signalée lorsque le retard avait été annoncé pour la première fois.
Mis bout à bout, il s'agit d'un laboratoire divulguant un véritable détail d'ingénierie — y compris un correctif dont la trace est vérifiable de façon indépendante dans un dépôt open source — derrière une affirmation de capacité, tout en employant un terme, l'auto-amélioration récursive, qui pèse lourd dans le débat de sécurité que ce blog suit tout le mois auprès des laboratoires occidentaux. Les chiffres de débit et de parité matérielle restent ceux de Z.ai elle-même ; la réserve qui les accompagne est réelle et précise plutôt qu'une simple phrase de façade. Savoir si cette réserve tiendra la prochaine fois que les chiffres grossiront, et si un benchmark externe testera un jour directement l'affirmation d'efficacité des accélérateurs domestiques, sont les deux fils que cet essai laisse ouverts plutôt que refermés.