GLM-5, rilasciato l’11 febbraio 2026 da Zhipu AI (Z.ai), rappresenta un grande salto architetturale rispetto a GLM-4.7: scala MoE più ampia (≈744B vs ~355B parametri totali), maggiore capacità di parametri attivi, allucinazione misurata inferiore e chiari progressi nei benchmark agentici e di coding — a costo di una maggiore complessità di inferenza e (talvolta) latenza.
Che cos’è GLM-5 e perché il suo rilascio è importante?
Che tipo di modello è GLM-5?
GLM-5 è il più recente modello linguistico di frontiera con pesi aperti di Zhipu AI (Z.ai), rilasciato il 11 febbraio 2026. È un trasformatore Mixture-of-Experts (MoE) che scala la famiglia GLM fino a ~744 miliardi di parametri totali, attivandone circa 40 miliardi per inferenza (cioè il routing MoE del modello mantiene il compute attivo molto inferiore al conteggio totale dei parametri). Il modello è offerto con licenza MIT ed è ottimizzato per carichi di lavoro agentici — attività di lunga durata e multi-step come orchestrazione di strumenti, scrittura e raffinamento del codice, ingegneria dei documenti e lavoro complesso di conoscenza.
Quali sono i miglioramenti principali rispetto alle varianti GLM precedenti?
Elenco sintetico dei cambiamenti più rilevanti:
- Scaling dei parametri: GLM-5 ≈ 744B totali (40B attivi) vs GLM-4.7 ~355B totali / 32B attivi — circa un salto di 2× nella scala del modello.
- Benchmark & factualità: Forte incremento su benchmark indipendenti (Artificial Analysis Intelligence Index: GLM-5 = 50 vs GLM-4.7 = 42), e grande riduzione dell’allucinazione sulla metrica AA Omniscience (riportata riduzione di 56 punti percentuali rispetto a GLM-4.7).
- Capacità agentica: Maggiore affidabilità per tool-calling, decomposizione dei piani ed esecuzione a lungo orizzonte (Z.ai posiziona GLM-5 per “agentic engineering”).
- Deployment & chip: Costruito e benchmarkato per girare su hardware di inferenza domestico cinese (Huawei Ascend e altri), riflettendo il movimento di Z.ai verso stack di chip diversificati.
Perché è importante: GLM-5 riduce il divario tra modelli a pesi aperti e modelli proprietari di frontiera su attività agentiche e di conoscenza — rendendo i modelli open-source ad alta capacità un’opzione realistica per le imprese che necessitano di deployment controllabili e flessibilità di licenza.
Novità in GLM-5 (dettagli)
Posizionamento: “Agentic engineering” su larga scala
GLM-5 è esplicitamente posizionato da Z.ai come un modello per “agentic engineering”: una classe di casi d’uso in cui il modello pianifica, emette chiamate a strumenti, ispeziona i risultati e itera autonomamente su molti passaggi (ad esempio, costruire una pipeline CI, gestire il triage e correggere suite di test fallite, o integrare microservizi). Questo è un cambiamento strategico rispetto alla pura generazione di codice single-turn verso modelli progettati per eseguire e ragionare su tracce di esecuzione e output degli strumenti.
Modalità di pensiero, ragionamento preservato/interlacciato
GLM-5 introduce modalità di “pensiero” perfezionate (a volte denominate nei documenti come interleaved thinking, preserved thinking), cioè il modello può emettere — e poi riutilizzare — tracce di ragionamento interne nei turni successivi e nelle chiamate agli strumenti. Praticamente, questo riduce i costi di ri-derivazione in workflow lunghi e migliora la coerenza quando un agente deve mantenere lo stato del piano attraverso i risultati degli strumenti. GLM-4.7 ha introdotto varianti precedenti di “pensiero” e comportamento tool-aware; GLM-5 affina la meccanica e le ricette di training per rendere queste tracce più affidabili e riutilizzabili.
Ingegneria del long-context e stabilità del sistema
Il training e il fine-tuning di GLM-5 testano esplicitamente la generazione con contesti molto lunghi (202.752 token durante le sessioni di SFT/valutazione). È un aumento pratico che conta quando serve che il modello veda più repository, log di test e output di orchestrazione in un unico prompt. Setup di valutazione che spingono le lunghezze di generazione fino a 131.072 token per alcuni carichi di ragionamento. Si tratta di un notevole sforzo ingegneristico per mitigare l’instabilità tipica quando si condiziona su contesti enormi.
Architettura e scaling (MoE)
Segnalazioni pubbliche indicano che GLM-5 utilizza una grande architettura MoE (mixture-of-experts) con diverse centinaia di miliardi di parametri in totale (conteggi pubblici elencano ~744–745B). GLM-4.7 ha varianti MoE e Flash ottimizzate per diversi compromessi di deployment (ad esempio, varianti “Flash” con conteggi di parametri attivi più piccoli per inferenza locale o a basso costo). Il design MoE aiuta GLM-5 a spingere la capacità di picco consentendo scelte di configurazione (conteggi di parametri attivi più bassi per inferenza più economica). Aspettatevi profili di inferenza diversi (latenza, VRAM) a seconda della variante distribuita.
Come Z.ai ha scalato e addestrato GLM-5 rispetto a GLM-4.7?
Differenze architetturali fondamentali
| Caratteristica | GLM-5 | GLM-4.7 |
|---|---|---|
| Data di rilascio | Feb 2026 (di punta) | Dic 2025 |
| Famiglia di modelli | Ultima generazione | Generazione precedente |
| Parametri totali | ~744B | ~355B |
| Parametri attivi (MoE) | ~40B (per passata forward) | ~32B (per passata forward) |
| Architettura | Mixture-of-Experts più attenzione sparsa | MoE con modalità di “pensiero” |
| Finestra di contesto | ~200K token (stessa dimensione di base) | ~200K token |
Conclusione: GLM-5 quasi raddoppia la capacità totale rispetto a GLM-4.7 e aumenta i parametri attivi, contribuendo a migliori capacità di ragionamento e sintesi, soprattutto per contenuti tecnici long-form, pipeline di ragionamento estese e complesse attività di ingegneria del codice.
Architettura: cosa è cambiato?
GLM-4.7 è un design mixture-of-experts (MoE) nelle sue varianti più grandi (documentato come ~355B parametri totali con un set attivo per token più piccolo). GLM-5 mantiene le idee di sparsità in stile MoE ma stratifica un nuovo meccanismo di attenzione sparsa — il report lo chiama DeepSeek Sparse Attention (DSA) — che alloca dinamicamente risorse di attenzione ai token ritenuti importanti. L’affermazione è che DSA riduce i costi di inferenza/training preservando (o migliorando) il ragionamento su lunghi contesti, permettendo al modello di gestire contesti molto più lunghi rispetto ai checkpoint legacy mantenendo il compute gestibile.
Scala: parametri e dati
- GLM-4.7: documentato come circa 355 miliardi di parametri totali per la versione principale MoE (con un set di parametri attivi per passata forward molto più piccolo per efficienza).
- GLM-5: riportato a ~744 miliardi di parametri e addestrato con ~28,5 trilioni di token nel budget di pretraining, con un’enfasi di training su codice e sequenze agentiche. Questa combinazione mira a migliorare la sintesi del codice e la pianificazione agentica sostenuta.
Il salto nei parametri, insieme all’espansione del budget di token e agli aggiornamenti architetturali, è la principale ragione lato input per cui GLM-5 mostra risultati numerici migliori su classifiche di codice e agentiche.
Strategia di training e post-training (RL)
Dove GLM-4.7 ha introdotto modalità di “pensiero” interlacciate o mantenute per migliorare il ragionamento multi-step e l’uso degli strumenti, GLM-5 formalizza quella pipeline:
- Espande la lunghezza del contesto attraverso un programma di metà training (il team riporta estensione progressiva del contesto fino a 200K token).
- Implementa una pipeline di post-training RL sequenziale (Reasoning RL → Agentic RL → General RL) insieme a distillazione cross-stage on-policy per evitare l’oblio catastrofico.
- Aggiunge RL asincrona e motori di rollout disaccoppiati per scalare le traiettorie agentiche durante l’RL senza colli di bottiglia di sincronizzazione.
Questi metodi mirano specificamente a migliorare il comportamento agentico a lungo orizzonte — per esempio, mantenere uno stato interno stabile in sessioni lunghe in cui il modello esegue molte chiamate a strumenti e modifiche al codice dipendenti.
Come si confrontano GLM-5 e GLM-4.7 in prestazioni e capacità?
Benchmark e misure di intelligenza
| Area di valutazione | GLM-5 | GLM-4.7 |
|---|---|---|
| Coding (SWE-bench) | ~77.8% (open model SOTA) | ~73.8% su SWE-bench Verified |
| Task Tool & CLI | ~56% su Terminal Bench 2.0 | ~41% su Terminal Bench 2.0 |
| Ragionamento (HLE & extended) | Punteggio ~30.5 → ~~50 con strumenti (benchmark interno) | ~24.8 → ~42.8 su HLE con strumenti |
| Task agentici e multi-step | Significativamente più forte (catene più lunghe) | Forte (modalità di “pensiero”) ma meno profondo di GLM-5 |
Interpretazione:
- GLM-5 supera GLM-4.7 in modo ampio su benchmark core di coding e ragionamento con margini misurabili. Ciò è particolarmente evidente in automazione multi-step, decomposizione dei problemi e task logici profondi.
- I miglioramenti sono non banali: ad es., la capacità su Terminal Bench passa da ~41% a 56%, un grande guadagno relativo nell’affidabilità dell’automazione agentica.
- Nei test di ragionamento (come metriche HLE interne), GLM-5 mostra output di ragionamento più forti, sia grezzi sia con strumenti.
- Mostra progressi misurabili su test agentici reali: nel CC-Bench-V2, metrica frontend HTML ISR, GLM-5 ha registrato 38.9% vs 35.4% di GLM-4.7 su un sottoinsieme di task frontend. (È una delle metriche valutate automaticamente usate per mostrare la competenza nello sviluppo front-end pratico.)
Dimensione del contesto e attività long-form
- Entrambi i modelli supportano contesti ampi (~200k token) — cioè possono consumare e ragionare su documenti, codebase o dialoghi più lunghi.
- Report aneddotici reali suggeriscono che deployment di GLM-5 hanno talvolta mostrato percepite problematiche di gestione del contesto su alcune piattaforme — ma ciò potrebbe riflettere limiti specifici dell’host più che del design del modello.
Chiamata a tool e funzioni
Entrambi supportano invocazioni strutturate di funzioni/strumenti; GLM-5 esegue semplicemente logiche di script più complesse con maggior fedeltà, specialmente su rami estesi di operazioni.
Esempi: come differiscono i risultati dei task
Esempio di coding (concettuale)
- GLM-4.7: Produce script single-file competenti con sintassi corretta e logica leggibile.
- GLM-5: Eccelle nella generazione di codice multi-file, suggerimenti di debug profondi e lunghi loop di feedback con minima troncatura del contesto.
Ragionamento & pianificazione
- GLM-4.7: Buon ragionamento multi-step ma occasionalmente si blocca su catene molto profonde.
- GLM-5: Migliore nel suddividere il ragionamento, richiamare i passaggi precedenti e navigare catene lunghe — utile per sintesi di dati e strategie multi-dominio.
Come cambiano latenza e costo passando da GLM-4.7 a GLM-5?
Compromessi di latenza e dove GLM-4.7 resta preferibile
Messaggi brevi e interfacce reattive: benchmark di practitioner mostrano che GLM-5 può aggiungere una piccola latenza fissa su risposte brevi (bookkeeping di routing e selezione degli esperti) che può manifestarsi come latenza leggermente più alta per payload minuscoli. Per UI a latenza ultra-bassa e messaggi piccoli, GLM-4.7 o varianti Flash restano interessanti.
Confronto GLM-5 vs GLM-4.7:
- GLM-4.7: input $0.60/1M token, output $2.20/1M token.
- GLM-5: input $1.00/1M token, output $3.20/1M token.
Compromesso costo vs. editing umano
Un prezzo modello più alto può essere giustificato quando GLM-5 riduce significativamente il tempo umano a valle (p.es., editing di merge request, triage di fix automatizzati, o evitare chiamate ripetute al modello). Regola decisionale semplice:
Se GLM-5 riduce il tempo di editing manuale di > X% (X dipende dal costo del lavoro umano e dal numero di token per workflow), può risultare conveniente nonostante il costo per token più alto. Diverse analisi su blog hanno modellato tali condizioni di break-even e hanno trovato che GLM-5 spesso ripaga per workflow agentici pesanti e ripetitivi (p.es., riparazione automatizzata di codice su larga scala).
Latenza e hardware
VRAM di inferenza & latenza dipendono dalla variante (Flash, FlashX, MoE pieno). Guide della community mostrano che GLM-4.7 FlashX e le varianti 30B Flash sono distribuibili su GPU da 24GB; le varianti MoE complete richiedono setup multi-GPU di grandi dimensioni. Le configurazioni complete di GLM-5 richiederanno risorse materialmente più elevate per la stessa throughput, sebbene la sparsità MoE aiuti a ridurre il compute attivo per token. Aspettatevi investimento ingegneristico per ottimizzare quantizzazione, memory-mapping e streaming per la produzione.
Quando conviene aggiornare da GLM-4.7 a GLM-5?
Aggiorna se:
- Ti serve migliore ragionamento su codice multi-file, orchestrazione agentica long-context o tassi di successo end-to-end più elevati degli agenti.
- I tuoi task sono ad alto valore e giustificano maggiore complessità e costo per richiesta di infrastruttura.
Rimani con GLM-4.7 se:
- Il tuo carico è ad alto volume, prompt brevi (classificazione, tagging), dove prevedibilità di costo e latenza contano più di miglioramenti marginali di qualità.
- Casi d’uso che favoriscono restare con GLM-4.7
- Alto throughput, payload brevi: chatbot, autosuggest, piccoli job di parafrasi — GLM-4.7 (soprattutto le varianti Flash) sarà spesso più economico e a latenza inferiore.
- Budget vincolati e task a volume: per tagging, classificazione o micro-task eseguiti su scala, l’efficienza di GLM-4.7 e il prezzo per token inferiore sono convincenti.
- Ti manca l’infrastruttura o il budget per gestire sharding MoE / autoscaling complesso.
Come scelgo il modello nelle chiamate API? (esempi)
cURL — cambia l’ID del modello (esempio compatibile CometAPI/OpenAI):
# GLM-4.7
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-4.7","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":800}'
# GLM-5
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-5","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":1200}'
Python (requests): modifica il campo model per instradare verso GLM-4.7 o GLM-5 — il resto del codice client può rimanere invariato.
Valutazione finale:
GLM-5 appare evolutivo con importanti punti di inflessione:
- Evolutivo perché porta avanti il design MoE e “reasoning-first” della famiglia GLM e prosegue nel pattern di miglioramenti iterativi (4.5 → 4.6 → 4.7 → 5).
- Inflessione perché aumenta materialmente la scala, introduce DSA e adotta un curriculum RL specificamente mirato a task agentici a lungo orizzonte — tutti elementi che producono miglioramenti concreti e misurabili su una gamma di benchmark pratici.
Se valuti solo per posizionamento in classifica, GLM-5 rivendica leadership open-weights su diverse metriche e riduce i gap con i sistemi proprietari top in task agentici e di coding. Se valuti per developer experience e uso sensibile alla latenza, pro e contro pratici restano da dimostrare in deployment più ampi e nel tempo. Ciò significa che GLM-5 è convincente dove il caso d’uso richiede competenza agentica sostenuta; GLM-4.7 resta una scelta matura, più veloce e più conveniente per molte esigenze produttive attuali.
Gli sviluppatori possono accedere a GLM-5 e GLM-4.7 tramite CometAPI ora. Per iniziare, esplora le capacità del modello nel Playground e consulta la API guide per istruzioni dettagliate. Prima di accedere, assicurati di aver effettuato l’accesso a CometAPI e di aver ottenuto la chiave API. CometAPI offre un prezzo molto inferiore rispetto al prezzo ufficiale per aiutarti nell’integrazione.
Pronti a partire?→ Iscriviti a GLM-5 oggi !
Se vuoi conoscere più consigli, guide e notizie sull’AI seguici su VK, X e Discord!
