Z.ai ha descritto la realizzazione di un servizio di inferenza completo per GLM-5.3-Flash costruito da zero su un cluster composto da oltre 100.000 acceleratori AI prodotti in Cina. L’intera inferenza in produzione del modello viene eseguita su questa infrastruttura e, secondo l’azienda, una parte significativa del lavoro di adattamento e ottimizzazione non è stata svolta esclusivamente dagli ingegneri, ma anche da un Infra Agent basato su GLM-5.3. Z.ai indica questa installazione come il primo caso noto di utilizzo operativo di acceleratori cinesi su una scala superiore alle 100.000 unità, in un contesto reso particolarmente complesso dalla capacità e dalla larghezza di banda relativamente limitate della memoria on-chip, dalla nuova architettura del modello, dalla finestra di contesto da un milione di token, dalla gestione delle richieste multimodali e da un ecosistema software ancora incompleto sotto il profilo del supporto ai kernel e della documentazione tecnica.
GLM-5.3-Flash è stato lanciato il 26 agosto 2026 come primo modello nativamente multimodale della serie GLM-5. Dispone di 320 miliardi di parametri complessivi, dei quali 18 miliardi attivi, e utilizza un’architettura ibrida che combina sparse attention e linear attention. Prima del lancio commerciale era stato distribuito in forma anonima con il nome ox-alpha su OpenCode e OpenRouter. Z.ai afferma che nell’arco di una settimana il modello sia diventato il più utilizzato su entrambe le piattaforme e che abbia elaborato più di 62 mila miliardi di token in sei giorni.
Uno degli aspetti centrali del lavoro sull’infrastruttura riguarda il metodo definito dall’azienda “dense feedback”. Il punto di partenza è che le sole metriche end-to-end non permettono di identificare con precisione la causa di un problema: un test di accuratezza fallito, un aumento del 30% del time to first token oppure una riduzione del 20% dell’output throughput segnalano un peggioramento, ma non indicano quale componente dello stack debba essere modificato. Z.ai ha quindi organizzato correctness test, log di runtime, execution trace, eventi del runtime, microbenchmark e metriche end-to-end in workflow ripetibili, permettendo all’agente di verificare localmente ogni ipotesi senza dover attendere una nuova distribuzione completa e un successivo load test.
Il feedback utilizzato dal sistema viene progettato secondo tre criteri. Deve essere il più possibile locale e quindi collegabile a specifici parametri di lancio, modifiche del codice, kernel, condizioni di input, thread, intervalli di esecuzione o code path; deve poter essere ottenuto in tempi brevi e con costi contenuti; infine deve essere verificabile in maniera oggettiva attraverso implementazioni di riferimento ed esperimenti controllati, evitando di interpretare semplici correlazioni come dimostrazioni della causa principale del problema. Nel ciclo di sviluppo descritto da Z.ai gli ingegneri mantenevano la definizione degli obiettivi, dei limiti del sistema e la revisione delle modifiche critiche legate alla semantica numerica, alla concorrenza e ai rischi di produzione, mentre l’agente eseguiva l’analisi, formulava ipotesi e proponeva o implementava modifiche al codice.
Lo stack ottimizzato combina tensor parallelism intra-node per la linear attention e il LM Head, ReplaySSM, quantizzazione W8A8, quantizzazione della cache a precisione mista INT8, FP8 e BF16 e una tecnica denominata Layer Split. Questi componenti operano all’interno di un’architettura di inferenza disaggregata Encode-Prefill-Decode, nella quale le diverse fasi di elaborazione vengono separate per consentire una gestione più efficiente delle risorse e una maggiore specializzazione dei nodi coinvolti.
Un primo caso di ottimizzazione ha riguardato la correttezza numerica. Il confronto tra l’esecuzione partizionata e non partizionata dei kernel ha individuato un problema nel percorso Context Parallelism del kernel KDA. L’operazione tl.dot utilizzava infatti di default calcoli TF32 anche quando gli input erano FP32, causando l’accumulo di errori durante la fusione degli stati e un peggioramento progressivo all’aumentare della lunghezza del contesto. La correzione ha imposto esplicitamente la precisione di input tf32x3, che utilizza tre operazioni TF32 Tensor Core per ottenere un risultato più preciso. La modifica è stata successivamente integrata a monte nel progetto Flash Linear Attention attraverso una pull request aperta e approvata il 27 agosto 2026. L’intervento applica una catena affine tf32x3 come percorso opzionale ad accuratezza maggiore nei kernel di state update e transformation merging, aggiunge test specifici per il Context Parallelism e prevede il fallback esplicito alla precisione IEEE sulle piattaforme prive di supporto TF32, comprese GPU AMD, NPU e GPU NVIDIA precedenti alla compute capability 8.0.
Un secondo problema riguardava invece la concorrenza durante il trasferimento della KV cache. Gli ingegneri avevano stabilito come criterio di accettazione che, a parità di workload, Prefill e KV Transfer dovessero essere eseguiti con una differenza inferiore al 5% rispetto al solo Prefill. In alcuni scenari il divario superava però il 20%. L’Infra Agent ha ricondotto il problema a DeepEP 1.2.1, dove le chiamate intranode_dispatch e intranode_combine non rilasciavano esplicitamente il Python Global Interpreter Lock. Finché queste operazioni mantenevano il GIL, il thread Python di Mooncake Transfer eseguito nello stesso processo non riusciva ad acquisirlo tempestivamente, ritardando la pianificazione e l’invio delle attività di trasferimento e riducendo la sovrapposizione tra comunicazione e calcolo. La chiamata internode_dispatch della stessa versione rilasciava invece già il GIL, con un commento nel codice che indicava esplicitamente la necessità di evitare il blocco del KV Transfer negli altri thread. Dopo aver modificato le chiamate interessate affinché il GIL venisse rilasciato durante gli intervalli di esecuzione C++, Z.ai riferisce che il divario sia sceso al di sotto dell’1% nelle stesse condizioni di test.
Il terzo caso riguarda l’ottimizzazione diretta dei kernel. L’agente è stato utilizzato per estrarre tecniche presenti in kernel scritti manualmente all’interno di progetti come SGLang, Flash Linear Attention e DeepGEMM, trasformandole in schemi riutilizzabili che comprendono condizioni di applicabilità, trasformazioni da eseguire, vincoli sulle risorse e modalità di verifica. In un kernel KDA Decode rappresentativo, Z.ai indica che una prima ottimizzazione delle operazioni di divisione abbia ridotto il tempo di esecuzione del 9,6%. Un successivo ciclo di feedback ha identificato il calcolo come principale collo di bottiglia e ha portato alla fusione dei tile lungo la dimensione V, che in precedenza ripetevano quattro volte gli stessi calcoli FP32 di normalizzazione e gating. L’elaborazione è stata concentrata in un singolo thread block, mantenendo i risultati intermedi nei registri ed eseguendo una sola riduzione a livello di warp; secondo Z.ai, questa modifica ha prodotto uno speedup di 1,71 volte rispetto alla versione precedente.
Dal primo adattamento del modello alla disponibilità in produzione sarebbero trascorse meno di due settimane. Al termine dell’ottimizzazione, Z.ai dichiara un throughput end-to-end triplicato rispetto alla baseline iniziale e livelli di efficienza nell’utilizzo dell’hardware e di costo per token paragonabili a quelli ottenuti con GPU NVIDIA mainstream. Questi ultimi valori vengono presentati dall’azienda come risultati dell’infrastruttura sviluppata e non come benchmark indipendenti condotti da terze parti.
Z.ai considera inoltre il progetto un primo esempio di modello AI coinvolto direttamente nell’ottimizzazione dell’infrastruttura sulla quale viene eseguito. L’azienda parla in questo senso di una possibile direzione verso sistemi di miglioramento ricorsivo, ma precisa che il risultato raggiunto con GLM-5.3-Flash non costituisce ancora un processo di recursive self-improvement completo. La scelta degli obiettivi, la definizione dei confini operativi e la valutazione dei rischi restano infatti compiti affidati agli esseri umani e Z.ai afferma che tali responsabilità dovrebbero continuare a rimanere sotto controllo umano anche con l’aumento dell’autonomia degli agenti dedicati all’ingegneria dell’infrastruttura.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)