Il laboratorio cinese di intelligenza artificiale Z.ai ha pubblicato un resoconto tecnico dettagliato di come imposta i modelli GLM per migliorare i sistemi stessi che li servono, descrivendo un "agente Infra" che trova e risolve i colli di bottiglia prestazionali nell'infrastruttura di inferenza dell'azienda con un intervento umano limitato.
Il post sul blog, intitolato "Verso l'auto-miglioramento ricorsivo: come GLM ha costruito la propria infrastruttura di inferenza", è apparso sul sito dell'azienda mercoledì ed è diventato rapidamente una delle storie tecnologiche più discusse su Hacker News, dove ha ottenuto più di 200 punti dalla comunità degli sviluppatori. Per maggiori informazioni su questa storia, consulta la nostra ultimi sviluppi nell'IA.
"Mentre sviluppiamo GLM, il modello a volte mostra capacità che ci sorprendono e addirittura ci inquietano", ha scritto l'azienda nelle righe di apertura del post.
Dalla ricerca sulla sicurezza informatica ai sistemi di auto-ottimizzazione
Il lavoro risale all'ottobre 2025, quando Z.ai iniziò a ricercare come rafforzare le capacità di sicurezza informatica di GLM. Il ragionamento, afferma l’azienda, era semplice: la sicurezza informatica è un’estensione naturale della codifica e i modelli in grado di navigare in grandi basi di codice possono alla fine navigare nel codice di sistema di basso livello che la maggior parte degli ingegneri evita.
Quella fondazione si è evoluta in qualcosa di più ambizioso. Invece di utilizzare i modelli semplicemente per scrivere codice, Z.ai ha deciso di rispondere a una domanda di ingegneria dei sistemi: può un agente di intelligenza artificiale assumersi la responsabilità delle prestazioni di uno stack di inferenza di produzione, il livello di coordinamento software e hardware che trasforma i pesi del modello in risposte rapide ed economiche?
La risposta dell'azienda prevedeva la riformulazione del problema. Le sole metriche end-to-end, sostiene il post, non possono guidare un agente di ottimizzazione. Un rapporto secondo cui il time-to-first-token è aumentato del 30% o che il throughput di output è diminuito del 20% dice a un agente che qualcosa è peggiorato, ma non quale livello è responsabile, perché la sua ipotesi è fallita o cosa testare successivamente.
"Come possiamo trasformare i risultati scarsi end-to-end in feedback ingegneristici dettagliati e attribuibili che guidano direttamente l'azione successiva?" si chiede l'azienda nel post, descrivendo la domanda come chiave dell'intero sforzo.
Tre regole per un feedback leggibile dagli agenti
La risposta di Z.ai è una disciplina di feedback costruita su tre caratteristiche. Innanzitutto, il feedback deve essere sufficientemente locale, legato a specifici parametri di avvio del motore, modifiche al codice, kernel, condizioni di input, thread, intervalli di esecuzione o percorsi del codice, in modo che l'agente possa restringere l'ambito di qualsiasi problema. In secondo luogo, deve essere poco costoso e tempestivo da ottenere: una domanda a cui è possibile rispondere tramite un test del kernel o un microbenchmark locale non dovrebbe richiedere l'implementazione completa del servizio. In terzo luogo, la validazione dovrebbe corrispondere all’ipotesi attuale, con ogni esperimento progettato per rispondere a una domanda specifica piuttosto che seguire una sequenza fissa.
L'azienda afferma che questo denso ciclo di feedback è ciò che consente all'Infra Agent di comportarsi meno come un completamento automatico per gli ingegneri e più come un collega che può eseguire esperimenti dall'oggi al domani.
Tre casi di studio, dalla numerica a un bug di threading
Il post illustra tre episodi concreti dell'ottimizzazione dello stack di servizio dell'azienda per GLM-5.3-Flash, il modello a peso aperto Z.ai rilasciato sotto la licenza MIT in agosto.
Il primo riguarda la correttezza. Poiché le ottimizzazioni dell'inferenza riorganizzano il modo in cui i calcoli vengono parallelizzati, l'agente doveva verificare che i kernel producessero gli stessi risultati in condizioni partizionate e non partizionate. In un caso, il team ha combinato tre operazioni del TF32 Tensor Core per produrre un risultato di maggiore precisione, riducendo l’errore numerico accumulato e preservando la maggior parte del vantaggio prestazionale del Tensor Core. I test comparativi tra le strategie di partizionamento hanno evidenziato le discrepanze che hanno motivato la correzione.
La seconda è una storia di debug dei sistemi che risulterà familiare a qualsiasi tecnico delle prestazioni. I criteri di accettazione richiedevano che l'aggiunta del trasferimento della cache KV al percorso di servizio non riducesse le prestazioni di precompilazione di oltre il 5% con carichi di lavoro identici. L'agente ha riscontrato che il divario superava il 20% in alcuni scenari, il che ha ristretto l'indagine al comportamento simultaneo del trasferimento KV stesso. Esaminando le tempistiche di esecuzione, l'agente ha identificato un'anomalia: negli scenari problematici, l'esecuzione del trasferimento KV lato Python non si è mai sovrapposta agli intervalli di invio e combinazione della libreria di comunicazione DeepEP. La soluzione consisteva nel rilasciare il blocco globale dell'interprete di Python durante i relativi intervalli di esecuzione del C++, consentendo al thread di trasferimento che serve Mooncake, l'archivio della cache KV, di procedere in parallelo con il calcolo. Successivamente il divario di prestazione è rientrato nella soglia di accettazione.
Il terzo episodio mostra l'ottimizzazione iterativa del kernel. L'introduzione di ReplaySSM, una tecnica che scambia il calcolo con la memoria, ha inizialmente aumentato il tempo di esecuzione di un kernel di decodifica KDA. L'ottimizzazione della divisione dell'agente ha poi ridotto il tempo di esecuzione del kernel del 9,6%. Dopo aver ricevuto feedback sul fatto che il calcolo rimaneva il collo di bottiglia principale, l'agente ha scoperto l'implementazione originale affiancata lungo la dimensione V, causando la ripetizione inutilmente identica di normalizzazione FP32 e di calcoli di gating.
Lo stack dietro GLM-5.3-Flash
Le ottimizzazioni si basano su un'architettura di servizio aggressiva che Z.ai descrive nel post: parallelismo del tensore intra-nodo per l'attenzione lineare e la testa del modello linguistico, scambio di calcolo per memoria ReplaySSM, quantizzazione W8A8, quantizzazione della cache a precisione mista utilizzando i formati INT8, FP8 e BF16, uno schema Layer Split e un'architettura disaggregata Encode-Prefill-Decode che esegue le fasi di servizio su risorse separate.
L’azienda inquadra l’accumulo di queste tecniche, scoperte e convalidate in gran parte dall’agente stesso, come un passo verso l’auto-miglioramento ricorsivo: i sistemi di intelligenza artificiale migliorano l’infrastruttura che li rende più veloci ed economici da gestire, il che a sua volta rende più accessibile il prossimo ciclo di miglioramento guidato dall’agente.
Perché è importante
Il costo dell’inferenza è uno degli aspetti economici decisivi del settore dell’intelligenza artificiale. I laboratori che possono servire modelli di frontiera a un costo per token inferiore possono fissare prezzi aggressivi, sovvenzionare agenti che effettuano migliaia di chiamate per attività e finanziare ulteriori corsi di formazione dalle entrate del servizio. Z.ai è stata particolarmente aggressiva su tutti e tre i fronti e le informazioni finanziarie provvisorie della società all'inizio di quest'anno hanno mostrato ricavi in forte crescita anche se le perdite si sono ridotte.
Il post è anche un segnale sulla direzione che sta prendendo l’ingegneria in laboratorio. La tradizionale divisione del lavoro, con ingegneri delle prestazioni umane che mettono a punto kernel e scheduler mentre i modelli gestiscono le richieste degli utenti, viene sostituita in Z.ai da un ciclo in cui il modello propone modifiche, esperimenti economici li convalidano e un denso feedback indirizza il tentativo successivo.
Le affermazioni di auto-miglioramento completamente autonomo dovrebbero essere lette con attenzione. Il post stesso chiarisce che gli ingegneri umani hanno definito gli scenari di test, stabilito i criteri di accettazione e costruito gli ambienti di feedback all’interno dei quali opera l’agente. Ciò che l'azienda descrive è l'automazione di un ciclo di ottimizzazione ben strumentato, non un sistema non supervisionato che si riprogetta.
Anche così, la direzione è chiara. Se l’economia dell’intelligenza artificiale nei prossimi anni sarà decisa da chi potrà servire l’intelligenza a un prezzo inferiore, i laboratori che insegnano i loro modelli a ottimizzare la propria infrastruttura potrebbero stabilire il ritmo, e Z.ai vuole che l’industria sappia che intende essere uno di loro.
---
Rimani Aggiornato sull'IALe ultime notizie, analisi e scoperte sull'intelligenza artificiale — tutto in un posto.
Leggi altre notizie sull'IA →
