Passa al contenuto principale

GLM-5.2: modello di coding open-weight di frontiera

Intermedio

Il 13 giugno 2026, Z.ai (ex Zhipu AI) ha rilasciato GLM-5.2 — un modello Mixture-of-Experts da 753 miliardi di parametri con contesto da 1 milione di token, pubblicato su Hugging Face sotto una semplice licenza MIT senza restrizioni regionali. Nelle due settimane successive, sono successe tre cose più difficili da ignorare del lancio stesso: è arrivato a ~1 punto da Claude Opus 4.8 sui benchmark di coding long-horizon, la sua API ha tagliato il pricing di frontiera di circa 6×, e il team security di Semgrep ha silenziosamente riportato che GLM-5.2 con quasi zero scaffolding ha superato Claude Code su un benchmark reale di vulnerabilità IDOR.

Questa pagina copre ciò che è davvero non-ovvio su GLM-5.2 — il cambio architetturale IndexShare che rende trattabile l'inferenza a 1M token, il quadro benchmark onesto contro Claude e GPT-5.5, cosa costa oggi self-hostarlo, e dove è genuinamente uno strumento migliore rispetto a puntare su un modello di frontiera closed.

What you'll learn
  • Capire cos'è IndexShare e perché taglia il compute long-context di ~2,9× — non un numero da marketing, uno architetturale
  • Leggere il quadro benchmark onesto: dove GLM-5.2 tiene testa a Claude Opus 4.8, dove no, e di quali punteggi vendor fidarsi
  • Sapere la matematica del costo effettivo: ~$1,20–1,40 / $4,10–4,40 per M input/output vs Claude Opus a prezzi di frontiera
  • Far girare GLM-5.2 via API in tre righe, o self-hosted su vLLM 0.23+ (con i percorsi FP8 e 2-bit spiegati chiaramente)
  • Decidere quando puntare su GLM-5.2 vs Claude — i due task dove vince chiaramente, e i due dove chiaramente perde

La versione in una frase​

GLM-5.2 è un modello Mixture-of-Experts sparso, open-weight (MIT), 753B totali / ~40B attivi, di Z.ai, con contesto da 1M token e output massimo da 131.072 token, costruito per il coding agent long-horizon — con prezzo di circa un sesto delle API di frontiera closed e, sulle valutazioni indipendenti, a un punto da Claude Opus 4.8 sui benchmark di coding che contano per il lavoro con agent autonomi.

Tre cose su GLM-5.2 che non sono ovvie dai titoli​

1. IndexShare è la vera storia architetturale​

Il cambio principale in GLM-5.2 non è "MoE più grande" — è IndexShare. La sparse attention ha bisogno di un indicizzatore che decide a quali token passati ogni query si attiene. Far girare quell'indicizzatore per layer è costoso a contesto da 1M token. L'IndexShare di Z.ai riusa lo stesso indicizzatore attraverso ogni gruppo di quattro layer di sparse attention, tagliando i FLOP per-token di ~2,9× alla finestra completa di 1M.

La conseguenza pratica: GLM-5.2 può servire workload long-context reali a prezzi ai quali fare lo stesso lavoro con un modello ad attention completamente quadratica sarebbe economicamente assurdo. Anche per questo il checkpoint FP8 (pubblicato come zai-org/GLM-5.2-FP8) gira su 8× H200 con spazio per una sessione da 131K token; senza IndexShare, lo stesso hardware si strozzerebbe sulla KV cache molto prima di arrivarci.

GLM-5.2 spedisce anche un layer Multi-Token Prediction (MTP) migliorato per il decoding speculativo, con Z.ai che riporta un ~20% di uplift nella lunghezza di accettazione — si vede come token/sec più veloci nell'inferenza reale, non solo come metrica da paper.

2. La storia dei benchmark è più forte di "batte GPT-5.5" e più debole di "batte Opus"​

Le tabelle vendor e la copertura giornalistica comprimono tutto in slogan. La lettura onesta:

BenchmarkGLM-5.2Claude Opus 4.8GPT-5.5Note
Terminal-Bench 2.181,0~85,0—Shell/agent long-horizon; gap di 4 punti
SWE-bench Pro62,1—58,6Fix repo-level autonomi; davanti a GPT-5.5, davanti a GLM-5.1 (58,4)
GPQA Diamond91,2——QA scientifico difficile; forte
AIME 202699,2——Vendor-reported; numero estremo, trattare con cautela
Artificial Analysis Intelligence Index51——Punteggio più alto per qualsiasi modello open-weight al lancio
Code Arena (globale)#2——Dietro un solo modello closed

Due cose da interiorizzare:

  • Sui benchmark di coding che mappano al lavoro agent (SWE-bench Pro, Terminal-Bench 2.1, Code Arena), GLM-5.2 è più vicino a Claude Opus 4.8 che a GPT-5.5. È una prima per qualsiasi modello open-weight.
  • Sui task di ragionamento più difficili e conoscenza open-ended, i modelli di frontiera closed sono ancora in testa. Il titolo AIME 99,2 è vendor-reported e va letto insieme alle eval indipendenti — il punteggio Artificial Analysis Index di 51 di Z.ai è un riassunto più calibrato.
Pro tip

Quando qualcuno linka "GLM-5.2 batte Claude Opus" o "GLM-5.2 batte GPT-5.5", controlla quale benchmark e chi ha misurato. Sul coding long-horizon: a un punto da Opus, chiaramente davanti a GPT-5.5. Sul ragionamento generale: ancora dietro alla frontiera closed. Entrambe le affermazioni sono vere.

3. È stato addestrato su NPU Huawei Ascend, non Nvidia​

GLM-5.2 sarebbe stato addestrato su acceleratori Huawei Ascend anziché H100/H200 Nvidia. Non è un dettaglio di benchmark — è un fatto di supply-chain. Insieme al fatto che Z.ai è nell'Entity List USA e che l'API hosted passa per infrastruttura cinese, ciò modella tre decisioni reali:

  • Ambienti regolamentati dovrebbero valutare l'API hosted rispetto alla policy di export-control prima di cablarla in produzione. I pesi MIT sono senza restrizioni; l'API non è un sostituto per una review di compliance.
  • Workload sensibili sui dati dovrebbero preferire il percorso self-hosted (vedi sotto) piuttosto che mandare prompt agli endpoint API di Z.ai.
  • Aggregatori (OpenRouter, NVIDIA Build, OpenRelay) offrono GLM-5.2 tramite infrastruttura non-Z.ai — se vuoi il modello ma non il routing d'origine, è la strada.

Matematica del costo effettivo​

Il pricing API di Z.ai sta a circa $1,20–$1,40 per milione di token in input e $4,10–$4,40 per milione di token in output tra i provider. Confrontalo con il territorio di Claude Opus 4.8 ($15/M input, $75/M output a prezzi di frontiera) e il rapporto è di circa 1:6 su input e 1:15+ su output. Il benchmark IDOR di Semgrep ha piazzato il costo per vulnerabilità a ~$0,17 per GLM-5.2 vs diversi dollari per equivalenti di frontiera.

Il trucco facile da mancare: GLM-5.2 gira con thinking effort "high" o "max" a livello di modello, quindi i conteggi di token in output sono più alti di un modello non-thinking per lo stesso task. Il costo per task è comunque più basso, ma il rapporto non è così estremo come suggerirebbero i prezzi per-token — stai pagando più token per risposta, a un prezzo più basso ciascuno.

Iniziare via API​

GLM-5.2 parla chat completions OpenAI-compatibili. Gli URL degli endpoint e i model ID variano per provider — scegline uno:

ProviderBase URLModel IDEnv
Z.ai (diretto)https://api.z.ai/api/paas/v4/glm-5.2ZAI_API_KEY
OpenRouterhttps://openrouter.ai/api/v1z-ai/glm-5.2OPENROUTER_API_KEY
NVIDIA Buildhttps://integrate.api.nvidia.com/v1z-ai/glm-5.2NVIDIA_API_KEY
OpenRelayhttps://inference.openrelay.inc/v1openrelay/glm-5.2OPENRELAY_API_KEY
Guided walkthrough1 of 3
  1. Per l'accesso diretto, registrati su z.ai e crea una key. Per l'accesso via aggregatore (consigliato se sei dal lato Entity List USA della barriera), usa OpenRouter o NVIDIA Build.

GLM-5.2 via OpenAI SDK (Python), attraverso OpenRouter

import openai

client = openai.OpenAI(
  api_key="YOUR_OPENROUTER_KEY",
  base_url="https://openrouter.ai/api/v1",
)

response = client.chat.completions.create(
  model="z-ai/glm-5.2",
  messages=[
      {"role": "user", "content": "Refactor this 800-line auth module for testability. Preserve behavior; return a unified diff."},
  ],
)
print(response.choices[0].message.content)

GLM-5.2 via endpoint diretto Z.ai (Python)

import openai

client = openai.OpenAI(
  api_key="YOUR_ZAI_API_KEY",
  base_url="https://api.z.ai/api/paas/v4/",
)

response = client.chat.completions.create(
  model="glm-5.2",
  messages=[
      {"role": "system", "content": "You are a careful staff engineer."},
      {"role": "user", "content": "Review this repo and list the top 5 risks, with file:line references."},
  ],
)
print(response.choices[0].message.content)

Self-hosting: tre percorsi realistici​

La licenza MIT e i pesi FP8 pubblicati fanno del self-hosting il punto centrale per molti team. Ci sono tre percorsi pratici, dal più hardware al meno:

Percorso A — FP8 su 8× H200 con vLLM (production-grade)​

Il deployment di riferimento. Scarica il checkpoint FP8 ufficiale e servi con vLLM 0.23.0+ (o SGLang 0.5.13.post1+). Questa è la config più vicina a quella dell'inferenza di Z.ai; ti dà il pieno max output di 131K token e throughput stabile.

Deploy GLM-5.2 FP8 su 8× H200 con vLLM

# 1) Download the FP8 weights (~750 GB)
huggingface-cli download zai-org/GLM-5.2-FP8 \
--local-dir /models/glm-5.2-fp8

# 2) Serve with vLLM 0.23.0+
python -m vllm.entrypoints.openai.api_server \
--model /models/glm-5.2-fp8 \
--served-model-name glm-5.2-fp8 \
--tensor-parallel-size 8 \
--quantization fp8 \
--enable-expert-parallel \
--max-model-len 131072 \
--kv-cache-dtype fp8_e5m2 \
--gpu-memory-utilization 0.92 \
--enable-chunked-prefill \
--max-num-seqs 32 \
--port 8000

Percorso B — GGUF a 2-bit su un Mac Studio o GPU da 24 GB + 256 GB di RAM​

Il GGUF dinamico a 2-bit di Unsloth comprime GLM-5.2 da ~1,51 TB fino a ~239 GB — abbastanza piccolo da starci in un Mac Studio (Ultra) da 256 GB o una workstation con una GPU da 24 GB più 256 GB di RAM di sistema (il routing MoE tiene solo pochi expert caldi alla volta, quindi l'offload su DRAM è praticabile). È il percorso "farlo girare davvero su hardware che compri in negozio". Aspettati token/sec più lenti di un rack H200 ma utilizzabile per workload agent da singolo utente.

Percorso C — quantizzazioni AWQ/W4A16 dalla community​

Quantizzazioni di terze parti (es. QuantTrio/GLM-5-AWQ, PhalaCloud/GLM-5.2-W4AFP8) puntano a percorsi weight a 4-bit compatibili con il kernel AWQ di vLLM. Sono utili quando vuoi footprint di memoria più piccoli di FP8 ma più margine del GGUF a 2-bit. Z.ai non ha pubblicato una variante AWQ ufficiale a fine luglio 2026 — verifica la calibrazione della versione community prima di usarla in produzione.

Watch out

Self-hostare GLM-5.2 a qualsiasi tier richiede comunque attenzione al tokenizer e al chat template. La model card di Hugging Face spedisce entrambi; usa apply_chat_template con add_generation_prompt=True piuttosto che assemblare il prompt a mano. Template disallineati sono la causa più comune dei report "perché il mio modello open-weight è così peggio dell'API?".

Quando puntare su GLM-5.2 vs Claude​

Due task dove è genuinamente lo strumento migliore:

  • Coding autonomo long-horizon su una codebase privata. FP8 self-hostato ti dà un punteggio SWE-bench Pro vicino alla frontiera senza codice o contesto che lasci la tua infrastruttura. Claude Opus 4.8 è un pelo più affilato su Terminal-Bench 2.1, ma la vittoria di compliance dell'inferenza on-prem spesso pesa più di 4 punti percentuali.
  • Ricerca security su payload adversarial. L'esperimento IDOR di Semgrep (F1 39% con un harness a prompt nudo, davanti a Claude Code al 37%) suggerisce che GLM-5.2 è significativamente meno incline al refusal su task di security difensiva dove il training di safety di Claude fa scattare falsi positivi.

Due task dove Claude è ancora lo strumento migliore:

  • Ragionamento open-ended e domande di conoscenza fattuale. GLM-5.2 arranca dietro ai modelli di frontiera closed su conoscenza generale e ragionamento aperto; Claude Opus/Sonnet 5 e Fable 5 restano avanti qui.
  • Ovunque conti la sfumatura in modalità refusal. L'harm-avoidance di Claude è più sfumato (meno over-refusal su lavoro legittimo, stop più netti su harm genuino). Il layer di safety di GLM-5.2 è più sottile e meno calibrato per casi limite.
Pro tip

Cross-link: per il panorama open-weight più ampio, vedi DeepSeek, Qwen e la Ondata Open-Weight e Kimi K3: il modello open-weight più grande al mondo. Per la decisione "questo va fatto girare in locale?", vedi Locale vs Claude agent.

Il risultato IDOR di Semgrep in un paragrafo​

Semgrep ha tenuto costanti il dataset di vulnerabilità (bug IDOR reali in open-source), lo scoring F1 e il system prompt, e ha variato il modello + l'harness circostante. Il loro rig custom Semgrep Multimodal con GPT-5.5 ha segnato 61% F1; lo stesso rig con Opus 4.8 ha segnato 53%. Quando hanno testato GLM-5.2 con nient'altro che il prompt (un harness Pydantic AI a prompt nudo, senza enumerazione degli endpoint, senza navigazione guidata), ha segnato 39% F1 — battendo Claude Code sullo stesso task (37% F1) a circa $0,17 per vulnerabilità trovata, circa un sesto del costo di frontiera. Il loro titolo: "We have Mythos at home." Il caveat importante: un task, un dataset, un run — il finding è direzionale, non una promessa che generalizzi su SSRF, XSS o altre classi.

Quiz​

Check yourself

0/5
  1. Cosa fa davvero il meccanismo IndexShare di GLM-5.2?
  2. Come si confronta GLM-5.2 con Claude Opus 4.8 su Terminal-Bench 2.1?
  3. Vuoi far girare GLM-5.2 privatamente su hardware tuo ma non hai un rack 8× H200. Qual è un percorso realistico?
  4. Su quale task il benchmark di Semgrep ha trovato specificamente GLM-5.2 superare Claude Code?
  5. Il pricing API di GLM-5.2 è circa $1,20–$1,40 per milione di token in input. Perché il risparmio di costo totale non è esattamente il rapporto dei prezzi per-token vs Claude Opus 4.8?
Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.
1 / 10
Key takeaways
  • GLM-5.2 (13 giugno 2026) è il primo modello open-weight con licenza MIT ad arrivare entro un punto da Claude Opus 4.8 sul coding long-horizon — un punto di svolta vero per il tier open-weight.
  • IndexShare è la storia architetturale: indicizzatore di sparse-attention riusato ogni 4 layer, riduzione di ~2,9× del compute per-token a contesto 1M — rende economico il serving long-context.
  • Il costo effettivo è ~1/6 di Claude Opus per token in input, compensato in parte da conteggi di output più alti (thinking high/max attivo di default). Semgrep ha misurato ~$0,17 per vulnerabilità IDOR trovata.
  • Tre percorsi di self-hosting: FP8 su 8× H200 con vLLM (produzione), GGUF dinamico a 2-bit su Mac Studio / box 24 GB + 256 GB (accessibile), o quantizzazioni AWQ/W4 della community (via di mezzo).
  • Punta su GLM-5.2 su coding long-horizon privato e ricerca security difensiva; tieni Claude per ragionamento open-ended, conoscenza fattuale e i bordi sfumati di safety.

Fonti e approfondimenti​