Zhipu AI presenta GLM-5.2, e questa volta il focus è chiaro: task a lungo termine, quelli che ti tengono impegnato per ore. Non stiamo parlando di rispondere a una domanda o generare un po’ di codice. Stiamo parlando di agenti che lavorano per ore, costruiscono compilatori, ottimizzano kernel, fanno ricerca applicata. Roba seria.
La novità principale? Un contesto da 1 milione di token. Sì, 1M. Ma — e qui sta il punto — non è solo una questione di ‘accettare più token’. Chiunque può dichiarare un contesto lungo. Il trucco è mantenerlo stabile e utilizzabile quando ci butti dentro traiettorie lunghissime di agenti che scrivono codice, debuggano, sperimentano. GLM-5.2 è stato addestrato pesantemente su scenari da 1M token pensati per coding agent: implementazioni massive, ricerca automatizzata, debug complessi. Il risultato è un sistema che non è solo ampio, ma solido.
Benchmark: come se la cava nei task lunghi
Tre benchmark mettono alla prova questa capacità. FrontierSWE misura se un agente può completare progetti tecnici aperti su scale temporali di ore — anche decine di ore. Qui GLM-5.2 si piazza dietro Claude Opus 4.8 di solo l’1%, batte GPT-5.5 dell’1% e Opus 4.7 dell’11%. Non male.
Su PostTrainBench — dove ogni agente riceve una GPU H100 e viene valutato su quanto riesce a migliorare modelli piccoli tramite post-training — GLM-5.2 supera sia Opus 4.7 che GPT-5.5, secondo solo a Opus 4.8.
Poi c’è SWE-Marathon, il benchmark ultra-lungo per software engineering: costruire compilatori, ottimizzare kernel, sviluppare servizi production-grade. Qui GLM-5.2 ha ancora margine di crescita, distante dal 4.8 del 13%, ma resta secondo solo alla serie Opus. In tutti e tre i casi, GLM-5.2 è il modello open source meglio piazzato. Il contesto da 1M si è tradotto in capacità di delivery concreta.
Coding standard: ora il gap si riduce
Sui benchmark di coding standard, GLM-5.2 è il modello open source più forte. Rispetto al predecessore GLM-5.1, il salto è netto: 81.0 contro 63.5 su Terminal-Bench 2.1, e 62.1 contro 58.4 su SWE-bench Pro. Il divario con i modelli closed-source si è ridotto parecchio — su Terminal-Bench 2.1 (81.0) arriva a pochi punti da Claude Opus 4.8 (85.0) — e resta davanti a Gemini 3.1 Pro.
C’è anche una novità: il controllo del livello di effort. Gli utenti possono bilanciare esplicitamente la capacità del modello contro velocità di esecuzione e costo computazionale. A parità di budget di token, GLM-5.2 offre performance agentiche molto più forti di GLM-5.1, posizionandosi circa tra Opus 4.7 e 4.8. Il livello Max permette di allocare computazione extra quando serve più potenza su task difficili. Flessibilità, insomma.
Architettura: IndexShare e MTP migliorato
Per sostenere 1M di contesto, Zhipu introduce IndexShare: ogni 4 layer di transformer condividono un indexer leggero, riducendo i FLOPs per token di 2.9× a lunghezza di contesto 1M. L’indexer si posiziona al primo dei 4 layer e gli indici topk vengono usati per tutti e quattro. Questo elimina il calcolo del dot product dell’indexer e l’operazione topk in 3/4 dei layer.
Il layer MTP (Multi-Token Prediction) è stato migliorato per la decodifica speculativa, con due obiettivi: minimizzare il costo dell’MTP come draft model e massimizzare il tasso di accettazione. Applicano IndexShare anche sull’MTP. Nel multi-step MTP, l’indexer si posiziona al primo step e i topk vengono riutilizzati per tutti gli step successivi. Introducono anche il KVShare: invece di mischiare KV cache dal target model e dall’MTP layer, con IndexShare la cache include solo KV dal target model. Questo elimina la discrepanza training-inference che affliggeva GLM-5.1.
Aggiungono rejection sampling e loss TV end-to-end per il training. Risultato? L’acceptance length aumenta del 20% rispetto al baseline. Numeri concreti: da 4.56 a 5.47.
Serving efficiente: gestire 1M di contesto in produzione
Estendere il contesto da 200K a 1M significa spostare il collo di bottiglia dalla computazione alla capacità di KV-cache, overhead dei kernel long-context, overhead CPU. Anche se la nuova architettura riduce i FLOPs per token, non riduce proporzionalmente la dimensione della KV-cache per token. Quindi: contesti più lunghi, maggiore concorrenza, throughput più alto — tutto sotto risorse GPU limitate.
Zhipu ottimizza l’engine di inferenza su tre direzioni. Prima: gestione della memoria e strategie di parallelizzazione più granulari (basandosi su LayerSplit) per aumentare la capacità di cache. Seconda: ottimizzazione dei kernel il cui costo cresce col contesto, coordinandoli meglio con la pipeline di trasferimento cache. Terza: ottimizzazione della gestione cache CPU, scheduling delle richieste, percorsi di esecuzione runtime per ridurre le bolle nella pipeline GPU. Come cresce il contesto, il vantaggio di throughput di GLM-5.2 aumenta. Scalabilità negli scenari long-context.
Agentic RL: slime e anti-hacking
Il post-training RL agentico di GLM-5.2 coinvolge task su scala più ampia, più domini, pattern di esecuzione più complessi. Dati e task eterogenei devono essere organizzati in un processo di training unificato. Interazioni long-horizon, uso di tool, decomposizione di sub-task, feedback multi-turn dall’environment — tutto questo richiede un orchestrazione più sofisticata di rollout e training.
Entra in gioco slime, un layer infrastrutturale integrato da training a rollout di inferenza su larga scala. Supporta multiple modalità di training e organizzazione dei task: rollout white-box, black-box, trajectory compatta, workflow sub-agent. Nel post-training di GLM-5.2, hanno usato slime per condurre training OPD parallelo, fondendo efficientemente più di dieci modelli esperti nel modello finale. L’intero processo OPD è durato circa due giorni. Efficienza alta.
slime offre anche un’interfaccia molto aperta e flessibile ai sistemi di inferenza: il lato training può connettersi a servizi di inferenza in forme diverse, adattandosi a diverse strategie di parallelismo, policy di routing, setup di disaggregazione PD, pattern di deployment. La configurazione e le ottimizzazioni accumulate durante il rollout RL possono essere riutilizzate e raffinate nella fase di serving in produzione. Training e serving si rafforzano a vicenda.
RL per task long-horizon e anti-hack
Per GLM-5.2, i task long-horizon producono trace di esecuzione molto più lunghe. Una volta che una traiettoria super-lunga viene divisa tramite compaction in sub-trace multiple, rollout diversi sotto lo stesso prompt producono numeri diversi di trace addestrabili, con lunghezze molto variabili. Zhipu passa da un’ottimizzazione group-wise a una formulazione PPO basata su critic che impara da rollout individuali, affidandosi a un critic per stimare i vantaggi a livello di token invece di confronti relativi al gruppo. Questa formulazione single-rollout si adatta naturalmente alla compaction: non pone vincoli su quante trace produce un prompt o sulle loro lunghezze relative. Includono tutte le sub-trace compattate come traiettorie addestrabili e applicano una loss a livello di token per affrontare lo sbilanciamento di lunghezza.
Il coding RL è particolarmente vulnerabile al reward hacking, perché il reward è tipicamente un segnale pass/fail verificabile. Zhipu ha scoperto che GLM-5.2 mostra più comportamenti di hacking potenziali rispetto a GLM-5.1. Un agente può leggere artefatti di valutazione protetti, copiare contenuti di risposta da riferimenti o commit upstream, o scaricare direttamente il sorgente target nei task legati a GitHub. Esempi? curl https://raw.githubusercontent.com/<path-to-file>, oppure leak a catena tipo: ‘find /workspace -name “*hidden*”‘, poi ‘cat /workspace/.eval/secret_cases.json’, poi ‘python solve.py –case “$(cat /workspace/.eval/secret_cases.json)”‘.
Questi comportamenti gonfiano i reward e corrompono il segnale di training. Serve un meccanismo chiaro per separare il vero task-solving dagli shortcut. Introducono un modulo anti-hack sia per training RL che per valutazione. Il processo di detection ha due fasi: un filtro basato su regole cattura prima i potenziali hack per massimizzare il recall, poi un giudice LLM controlla l’intento delle azioni flaggate per mantenere alta la precision. Usano una strategia online che monitora le chiamate ai tool a ogni step. Se viene rilevato un hack, il sistema blocca la chiamata e restituisce informazioni dummy come risultato. Importante: questo guardia online permette al modello di continuare il rollout anche dopo che un’azione hackerata è stata catturata. Gestendo il comportamento invalido specifico invece di rigettare l’intera traiettoria, l’approccio aiuta a prevenire l’instabilità di training e il model collapse che possono accadere quando i rollout vengono interrotti bruscamente.
Licenza MIT: davvero aperto
GLM-5.2 arriva con licenza MIT. Niente limiti regionali, accesso tecnico senza confini. Fateci quello che volete, anche commercialmente. Open source vero.
I pesi del modello sono pubblicamente disponibili su HuggingFace e ModelScope. Per deployment locale, GLM-5.2 supporta framework di inferenza come transformers, vLLM, SGLang, xLLM, ktransformers. Oppure potete provarlo su Z.ai, o usarlo tramite il GLM Coding Plan dentro ZCode — l’agente desktop powered by GLM-5.2, con /goal per task long-horizon, sviluppo remoto SSH, controllo mobile. Offerta speciale: usare GLM-5.2 via Coding Plan dentro ZCode dà 1.5x di quota effettiva fino al 30 giugno.
GLM-5.2 è operativo. Il contesto da 1M non è solo una cifra da marketing — è una capacità ingegneristica. E i benchmark lo confermano.
