Z.ai: dettagli su GLM-5.3-Flash Inference costruito su 100.000 chip cinesi

Z.ai, il 17 settembre 2026, ha pubblicato una relazione tecnica che descrive come ha costruito da zero un servizio di inferenza di livello produttivo completo per il suo modello GLM-5.3-Flash su un cluster di oltre 100.000 acceleratori AI di fabbricazione cinese. Secondo l’azienda, gran parte del lavoro è stato svolto da un Infra Agent alimentato da GLM-5.3 anziché esclusivamente da ingegneri dell’infrastruttura, e tutta l’inferenza in produzione per GLM-5.3-Flash gira sul sistema.

Z.ai ha affermato che nessuno aveva precedentemente gestito un cluster di acceleratori di fabbricazione cinese a questa scala. L’azienda ha citato una capacità di memoria on-chip e una larghezza di banda relativamente limitate, una nuova architettura del modello, una finestra di contesto di 1 milione di token e richieste multimodali, insieme a un ecosistema immaturo in cui il supporto dei kernel era incompleto e gli ingegneri dovevano indovinare comportamenti che avrebbero dovuto essere documentati.

GLM-5.3-Flash lanciato il 26 agosto 2026 come il primo modello nativamente multimodale della serie GLM-5, con 320 miliardi di parametri totali e 18 miliardi di parametri attivi sotto un’architettura ibrida che combina attenzione sparsa e lineare. Prima del rilascio, Z.ai ha testato il modello in forma anonima come ox-alpha su OpenCode e OpenRouter, e l’azienda ha affermato che è diventato il modello più utilizzato su entrambe le piattaforme entro una settimana dal lancio, elaborando più di 62 trilioni di token in sei giorni.

Il metodo di feedback denso

Al centro della relazione vi è un problema di sistema: le metriche end‑to‑end possono indicare a un agente che i risultati sono peggiorati, ma non spiegano il motivo. Un test di accuratezza numerica fallito, un aumento del 30 % del tempo al primo token o una diminuzione del 20 % della velocità di output non mostrano quale livello sia responsabile né cosa testare successivamente. La risposta di Z.ai, che chiama feedback denso, integra test di correttezza, log di runtime, tracce di esecuzione, eventi di runtime, microbenchmark e metriche end‑to‑end in flussi di lavoro ripetibili, consentendo all’agente di convalidare localmente ogni ipotesi anziché attendere un’implementazione completa e un test di carico dopo ogni modifica.

L’azienda definisce tre proprietà necessarie per tale feedback. Deve essere locale, collegato, per quanto possibile, a parametri di lancio specifici, modifiche al codice, kernel, condizioni di input, thread, intervalli di esecuzione o percorsi di codice. Deve essere poco costoso e rapido da ottenere. Inoltre, deve supportare una verifica oggettiva tramite implementazioni di riferimento e esperimenti controllati, poiché le sole correlazioni osservate non stabiliscono una causa radice.

Nell’ambito del ciclo di lancio descritto nella relazione, gli ingegneri hanno definito obiettivi e limiti di sistema e hanno esaminato modifiche critiche relative alla semantica numerica, al comportamento della concorrenza e al rischio di produzione, mentre l’agente si è occupato di analisi, ipotesi e modifiche al codice. Lo stack ottimizzato congiuntamente ha combinato il parallelismo tensoriale intra‑node per l’attenzione lineare e l’LM Head, ReplaySSM, la quantizzazione W8A8, la quantizzazione della cache a precisione mista INT8/FP8/BF16 e il Layer Split, all’interno di un’architettura disaggregata Encode‑Prefill‑Decode.

Tre casi di ingegneria

Il primo caso riguarda la correttezza numerica. La validazione che confronta i percorsi di esecuzione del kernel partizionato e non partizionato ha evidenziato un problema di accuratezza nel percorso Context Parallelism del kernel KDA: l’operazione tl.dot impostava per impostazione predefinita il calcolo TF32 anche quando i suoi input erano FP32, così gli errori si accumulavano durante la fusione dello stato e si aggravavano con l’aumento della lunghezza del contesto. La correzione ha impostato esplicitamente la precisione di input a tf32x3, che utilizza tre operazioni TF32 Tensor Core per ottenere un risultato a precisione più elevata.

Secondo la relazione, le correzioni sono state integrate a monte in Flash Linear Attention. La richiesta di pull, aperta e unita il 27 agosto 2026, applica la catena affine tf32x3 nei kernel di aggiornamento dello stato e di fusione delle trasformazioni come percorso di accuratezza opzionale, aggiunge test di Context Parallelism e ricade esplicitamente alla precisione ieee su piattaforme senza supporto tf32 (AMD, NPU e GPU NVIDIA con capacità di calcolo inferiore a 8.0).

Il secondo caso riguarda un collo di bottiglia di concorrenza nel KV Transfer. Secondo la relazione, gli ingegneri hanno stabilito un criterio di accettazione secondo cui, con lo stesso carico di lavoro, Prefill più KV Transfer dovrebbero funzionare entro il 5 % del baseline solo Prefill. L’agente ha rilevato scostamenti superiori al 20 % in alcuni scenari e li ha ricondotti a DeepEP v1.2.1, in cui né dispatch né l’intranodecombine rilasciava esplicitamente il GIL di Python. Finché quelle chiamate mantenevano il lock, il thread Python Mooncake Transfer nello stesso processo non poteva acquisire il GIL in tempo, così la programmazione e l’invio dei task di trasferimento slittavano e la sovrapposizione con il calcolo si riduceva. La relazione osserva che internode_dispatch nella stessa versione rilasciava già il GIL, con un commento al codice che indicava che l’intento era evitare il blocco del KV Transfer in altri thread mentre la CPU attendeva. Dopo che la correzione ha rilasciato il GIL durante gli intervalli di esecuzione C++ pertinenti, la relazione riporta che lo scostamento è sceso al di sotto dell’1 % nelle stesse condizioni di test.

Il terzo caso riguarda le prestazioni del kernel. Z.ai ha fatto sì che l’agente distillasse tecniche da kernel scritti a mano in progetti tra cui SGLang, Flash Linear Attention e DeepGEMM in scheletri di ottimizzazione riutilizzabili contenenti condizioni di applicabilità, metodi di trasformazione, vincoli di risorse e prove di validazione. Su un kernel KDA Decode rappresentativo, l’azienda riferisce che l’ottimizzazione di divisione dell’agente ha ridotto il tempo di esecuzione del 9.6%. Dopo che il feedback ha identificato il calcolo come collo di bottiglia principale, l’agente ha fuso le tile della dimensione V del kernel, che ripetevano le stesse operazioni di normalizzazione FP32 e gating quattro volte, in un unico blocco di thread con risultati intermedi residenti nei registri e una riduzione a livello di warp, producendo quello che l’azienda riporta come un’accelerazione di 1.71× rispetto alla versione precedente.

Risultati dichiarati e auto‑miglioramento ricorsivo

Z.ai riferisce che GLM-5.3-Flash è passato dall’adattamento iniziale del modello alla prontezza per la produzione in meno di due settimane, con il throughput end‑to‑end che alla fine è triplicato rispetto alla baseline iniziale. L’azienda ha inoltre dichiarato che l’efficienza di utilizzo dell’hardware e il costo per token hanno raggiunto livelli comparabili a quelli delle GPU NVIDIA di uso comune.

L’azienda inquadra lo sforzo come un primo esempio di auto‑miglioramento ricorsivo, osservando che il modello ha partecipato all’ottimizzazione del sistema di inferenza su cui gira. Allo stesso tempo, Z.ai afferma di non aver ancora raggiunto l’auto‑miglioramento ricorsivo, e che la scelta degli obiettivi, la definizione dei limiti e la valutazione del rischio rimangono responsabilità umane che ritiene debbano continuare a essere gestite dagli esseri umani.