Mentre gli altri modelli AI esauriscono le idee dopo pochi tentativi, GLM-5.1 continua a ottimizzare per centinaia di iterazioni. E no, non è il solito hype da comunicato stampa.
Il problema dei modelli che si arrendono presto
Avete presente quando un modello AI risolve un problema di coding in 10 minuti e poi… basta? Applica le tecniche standard, ottiene un risultato decente, e si ferma lì. Dargli più tempo non serve a niente – ha già sparato tutte le cartucce.
GLM-5.1 funziona diversamente. Tipo: davvero diversamente.
600 iterazioni per ottimizzare un database vettoriale
Prendete VectorDBBench – un benchmark dove devi costruire un database per ricerca vettoriale approssimata. Il record precedente era 3.547 QPS (query per secondo), ottenuto da Claude Opus 4.6 in 50 turni di tool-call.
GLM-5.1? Ha continuato per 600+ iterazioni. Non per testardaggine algoritmica, ma perché continuava a trovare margini di miglioramento reali:
- Iterazione ~90: passa da scansione completa a cluster IVF con compressione f16 → 6.4k QPS
- Iterazione ~240: introduce pipeline a due stadi (prescoring u8 + reranking f16) → 13.4k QPS
- Risultato finale: 21.5k QPS – circa 6× il record precedente
Il grafico mostra un pattern a scalini: periodi di tuning incrementale, interrotti da salti strutturali quando il modello capisce che serve cambiare approccio. Le croci rosse? Momenti in cui il recall scende sotto il 95% – succede quando esplora nuove direzioni, poi aggiusta per recuperare il vincolo.
1000+ turni per ottimizzare kernel GPU
KernelBench chiede: prendi un’implementazione PyTorch di riferimento e producine una più veloce. Torch.compile con max-autotune? Speedup 1.49×.
I risultati dopo 1000+ turni:
- GLM-5 parte bene ma si appiattisce presto
- Claude Opus 4.5 dura un po’ di più ma anche lui rallenta
- GLM-5.1 arriva a 3.6× e continua a migliorare
- Claude Opus 4.6 domina a 4.2× con ancora margine alla fine
La differenza non è nella velocità iniziale – è in quanto a lungo il modello riesce a restare produttivo. GLM-5.1 estende quell’orizzonte ben oltre GLM-5.
8 ore per costruire un desktop Linux (nel browser)
Qui non c’è un numero da ottimizzare. Il prompt: “costruisci un ambiente desktop in stile Linux come web app”. Niente codice di partenza, niente mockup, niente guida intermedia.
La maggior parte dei modelli – incluse le versioni precedenti di GLM – producono uno scheletro base (taskbar statica, un paio di finestre placeholder) e dichiarano finito.
GLM-5.1 con un loop di auto-revisione? Ha girato per 8 ore. Il risultato:
- Fase iniziale: layout base, finestre semplici (come qualsiasi sessione breve)
- Ore successive: file browser, terminal, text editor, system monitor, calcolatrice, giochi
- Dettagli finali: styling consistente, interazioni fluide, edge case gestiti
Alla fine hai un desktop environment completo e visivamente coerente che gira nel browser. Non perché il modello sia “più intelligente” in senso astratto, ma perché riesce a continuare a migliorare invece di fermarsi arbitrariamente.
Benchmark tecnici (se vi piacciono i numeri)
Su SWE-Bench Pro – task complessi di software engineering – GLM-5.1 raggiunge 58.4%, stato dell’arte. Batte GLM-5 (55.1%), GPT-5.4 (57.7%), Opus 4.6 (57.3%), Gemini 3.1 Pro (54.2%).
Su NL2Repo (generazione di repository completi): 42.7% vs 35.9% di GLM-5.
Su Terminal-Bench 2.0 (task reali da terminale): 63.5% con framework Terminus-2, 66.5% con Claude Code.
CyberGym (cybersecurity): 68.7% vs 48.3% di GLM-5.
Le sfide che restano
Allunghare l’orizzonte di ottimizzazione non risolve tutto. I problemi aperti:
- Uscire prima da ottimi locali quando il tuning incrementale smette di pagare
- Mantenere coerenza su trace di esecuzione che spannano migliaia di tool-call
- Sviluppare auto-valutazione affidabile per task senza metriche numeriche
Il gap con Claude Opus 4.6 su KernelBench mostra che c’è ancora strada. Ma GLM-5.1 è il primo passo verso modelli che non si arrendono dopo il primo plateau.
Come provarlo
GLM-5.1 è rilasciato open-source con licenza MIT. Disponibile su:
- HuggingFace e ModelScope per deployment locale
- API via api.z.ai e BigModel.cn
- Compatibile con Claude Code, OpenClaw, e altri agent di coding
Per gli utenti GLM Coding Plan: il modello è disponibile ora (consuma quota 3× nelle ore di punta, 2× fuori punta – 1× fino a fine aprile come promozione). Ore di punta: 14:00-18:00 UTC+8.
Se preferite GUI: Z Code offre interfaccia unificata con agent multipli, supporto SSH per macchine remote, possibilità di avviare task da mobile.
Note tecniche
Qualche dettaglio per chi vuole replicare i risultati:
- HLE: max 163.840 token di generazione, temp=1.0, top_p=0.95
- SWE-Bench Pro: OpenHands, temp=1, top_p=0.95, max 32.768 token, context window 200K
- KernelBench Level 3: container Docker isolati con H100, limite 1200 turni di tool-use, audit indipendenti da Claude Opus 4.6 e GPT-5.4 per verificare assenza di exploit
- Terminal-Bench con Claude Code: timeout rimossi (mantenuti solo limiti CPU/RAM per task), fix per problemi ambientali introdotti dal framework
La cosa interessante di GLM-5.1 non è che sia “il migliore” su ogni benchmark – non lo è. È che continua a lavorare quando gli altri hanno già mollato. E per task complessi che richiedono iterazione profonda, quella persistenza fa la differenza tra un risultato base e uno che funziona davvero.
