GLM-5.2 in locale: Ollama + LM Studio, il gigante MIT

#Perché GLM-5.2 in locale

La maggior parte dei modelli «frontier» (i più grandi e i più capaci) resta accessibile solo tramite un'API: GPT, Gemini o le versioni 100B+ di Qwen e DeepSeek. GLM-5.2 rompe questa logica. Zhipu AI ha pubblicato i pesi completi sotto licenza MIT — la più permissiva in assoluto, senza clausole di attribuzione né di condivisione alle stesse condizioni — e la comunità ha prodotto versioni quantizzate GGUF funzionanti fin dal rilascio. Risultato: puoi ospitare un modello di classe frontier a casa tua, senza account, senza quote, senza divulgazione dei dati.

Il vantaggio non è la velocità — diciamolo chiaramente, un 753B in locale non potrà mai competere con un endpoint cloud in termini di reattività. Il vantaggio è la piena sovranità su un modello che, in termini di qualità pura, è allo stesso livello dei migliori servizi proprietari: ragionamento prolungato, lavoro sul codice di grandi basi di codice, contesto di 1 milione di token. Per un agente di programmazione che lavora per ore su codice proprietario coperto da un NDA, la velocità passa in secondo piano rispetto alla riservatezza.

#Cosa cambia rispetto a GLM-5.1

Se cerchi di installare un GLM di dimensioni ragionevoli su una GPU da 12 a 24 GB, questa guida non è quella giusta: GLM-5.1 (modelli densi da 9B e 32B) è pensato per questo, e la nostra guida dedicata lo tratta in dettaglio. GLM-5.2 si rivolge a un pubblico diverso. La confusione è frequente perché i nomi sono in sequenza, ma i due modelli non rientrano nella stessa categoria di hardware.

Architettura

GLM-5.1 è denso (9B, 32B). GLM-5.2 è un MoE da 753B totali, con una frazione degli esperti attivata per token. Non si può eseguire su una sola GPU consumer.

Licenza

GLM-5.1 è distribuito con la GLM License (variante di Apache con attribuzione). GLM-5.2 passa alla MIT pura: uso commerciale senza vincoli, nessuna clausola virale.

Contesto

128k su GLM-5.1 (1M tramite YaRN, con prestazioni degradate). GLM-5.2 gestisce nativamente 1M token, un vero vantaggio per l'analisi di repository di grandi dimensioni.

Hardware di riferimento

GLM-5.1 : un GPU da 8 a 24 GB. GLM-5.2 : Mac con 256 GB di memoria unificata, o box multi-GPU, o server con molta RAM e offload.

Casi d’uso

GLM-5.1 per un assistente locale reattivo. GLM-5.2 per un modello di riferimento di frontiera, quando la qualità conta più della velocità.

#753B MoE: capire il modello

GLM-5.2 è un Mixture-of-Experts: dei suoi 753 miliardi di parametri, solo una frazione viene attivata a ogni token generato. È questo che rende l'inferenza praticabile in locale — il calcolo per token resta ragionevole — ma l'insidia è altrove: tutti i pesi devono stare in memoria, anche quelli degli esperti che non vengono utilizzati in un dato momento. Il fattore limitante è la memoria, non la potenza di calcolo.

Parametri totali

753B, distribuiti tra un backbone condiviso e un insieme di esperti selezionati dinamicamente tramite routing.

Parametri attivi

Una frazione per token (routing top-k). È ciò che consente una velocità di generazione discreta nonostante le dimensioni totali.

Contesto

Contesto nativo di 1 milione di token. Attenzione: la cache KV con un contesto di 1 milione di token consuma moltissima memoria; riservala ai casi che lo giustificano.

Licenza

MIT. Puoi effettuare il fine-tuning, redistribuire e integrare in un prodotto commerciale senza obblighi.

Formato

Pesi originali in BF16 (~1,5 TB). Inutilizzabile così com'è in locale: è qui che entrano in gioco le versioni quantizzate GGUF.

#Le versioni quantizzate GGUF (unsloth)

La comunità ha prodotto le quantizzazioni che rendono GLM-5.2 utilizzabile. Le quantizzazioni dinamiche di unsloth sono il punto di riferimento: applicano una precisione variabile in base all'importanza degli strati, preservando la qualità meglio di una quantizzazione uniforme a parità di peso. Questo è decisivo a precisioni molto basse, dove ogni bit conta.

Q2_K_XL (unsloth)

~200 GB. Il punto di partenza realistico. Qualità ridotta ma utilizzabile: è la versione che entra nella memoria di un Mac da 256 GB o di una macchina con più RTX 4090.

Q4_K_M

~380-400 GB. Il punto ottimale in termini di qualità, ma riservato ai server con moltissima memoria o a configurazioni multi-GPU potenti.

Q5_K_M

~480 GB. Poco miglioramento percepibile rispetto a Q4 per questo tipo di modello; raramente giustificato in locale.

Q8_0 / BF16

Da 800 GB a 1,5 TB. È un ambito riservato ai server GPU professionali, fuori dalla portata di una macchina consumer.

# huggingface-cli doit être installé : pip install -U huggingface_hub
# Q2_K_XL est réparti en plusieurs shards GGUF
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "*Q2_K_XL*" \
  --local-dir ./glm-5.2-gguf

#Requisiti hardware realistici

Non esiste una configurazione «leggera» per GLM-5.2. Ecco i due profili che funzionano davvero, senza barare sui numeri.

Mac Apple Silicon 256 GB

Un Mac Studio della serie M con 256 GB di memoria unificata può ospitare il Q2_K_XL con margine per il contesto. La memoria unificata è qui un vantaggio decisivo: nessuna separazione CPU/GPU.

Mac 192 GB

Fattibile, ma con poco margine: il Q2_K_XL ci sta, ma riduci la finestra di contesto e chiudi tutto il resto. 128 GB sono al di sotto della soglia praticabile.

Box multi-GPU

Più RTX 4090 (24 GB ciascuna) + molta RAM di sistema per l'offload sulla CPU. Non si fanno stare 200 GB nella sola VRAM: si distribuisce il carico tra GPU e RAM.

Archiviazione

Almeno 200 GB liberi per il Q2, un SSD NVMe veloce (il caricamento iniziale legge centinaia di GB).

RAM di sistema (macchina)

Almeno 128 GB di RAM se trasferisci parte degli esperti sulla CPU tramite offload, 256 GB per lavorare comodamente.

#1. Installazione con LM Studio

LM Studio è spesso la soluzione più semplice per un modello di queste dimensioni, soprattutto su Mac: il suo motore MLX e la gestione della memoria sono ben collaudati e l'interfaccia mostra in tempo reale quanta memoria richiede il modello prima di caricarlo. È prezioso quando ci si avvicina al limite.

1. 01
   1. Installare LM Studio

   Scarica LM Studio dal sito ufficiale (lmstudio.ai) e installalo. Su Mac, usa la versione nativa per Apple Silicon.
2. 02
   2. Cercare il modello

   Nella scheda di ricerca, digita «GLM-5.2» e individua il repository unsloth GGUF. LM Studio mostra per ogni quantizzazione se è compatibile con la RAM disponibile (badge verde/arancione/rosso).
3. 03
   3. Scegliere la variante quantizzata Q2_K_XL

   Seleziona la variante Q2_K_XL. LM Studio scarica automaticamente tutti gli shard — metti in conto una lunga attesa, a seconda della tua connessione (200 GB).
4. 04
   4. Imposta il contesto

   Prima di caricare, riduci la lunghezza del contesto a un valore ragionevole (8k-16k per testare). Non impostare subito 1M: il KV-cache farebbe esplodere il consumo di memoria.
5. 05
   5. Caricare e testare

   Clicca su «Load». Tieni d'occhio l'indicatore della memoria. Una volta caricato il modello, invia un primo prompt e misura la velocità di generazione visualizzata in tok/s.

#2. Installazione con Ollama

Ollama può anche servire GLM-5.2 a partire da un GGUF, tramite un Modelfile che punta ai file scaricati. È la soluzione da preferire se vuoi esporre il modello ad altri strumenti (agenti, IDE, Open WebUI) tramite un'API compatibile con OpenAI.

# Fichier : Modelfile
FROM ./glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf

PARAMETER num_ctx 16384
PARAMETER temperature 0.6

# Créer l'entrée Ollama à partir du Modelfile
ollama create glm-5.2 -f Modelfile

# Lancer
ollama run glm-5.2

Una volta creato, GLM-5.2 viene servito come qualsiasi modello Ollama sull'endpoint predefinito http://localhost:11434. Qualsiasi client compatibile con OpenAI può quindi interrogarlo puntando a questo indirizzo.

# Dans un autre terminal, après le premier prompt
ollama ps

#3. Configurazione Mac da 256 GB

È la configurazione più elegante per GLM-5.2. La memoria unificata di Apple Silicon significa che GPU e CPU condividono lo stesso pool di memoria: nessun trasferimento costoso, nessuna suddivisione manuale. Un Mac Studio con 256 GB carica il Q2_K_XL e lascia spazio per un contesto sufficientemente ampio.

Modello caricato

Q2_K_XL (~200 GB) entra in memoria, lasciando circa 40-50 GB per la cache KV e il sistema.

Velocità attesa

Circa 5–12 tok/s in generazione, a seconda della lunghezza del contesto. Comodo per il lavoro asincrono, frustrante per una chat interattiva veloce.

Contesto utilizzabile

Da 32k a 64k senza problemi. Salire a 128k o più è possibile, ma il KV-cache consuma rapidamente la memoria disponibile.

Strumento consigliato

LM Studio per la semplicità, oppure Ollama se ci colleghi degli agenti.

#4. Box RTX 4090 a 2 bit

Su PC, bisogna fare i conti con la separazione tra VRAM e RAM. Una sola RTX 4090 (24 GB) ovviamente non basta a contenere 200 GB: la strategia consiste nel caricare il maggior numero possibile di esperti in VRAM e trasferire il resto nella RAM di sistema tramite llama.cpp. La velocità di generazione dipende quindi direttamente dal rapporto GPU/CPU e dalla velocità della tua RAM.

./llama-server \
  -m glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf \
  -c 16384 \
  -ngl 99 \
  --n-cpu-moe 40 \
  -fa \
  --host 0.0.0.0 --port 8080

-ngl 99

Tenta di collocare il maggior numero possibile di layer sulla GPU. llama.cpp riempie la VRAM disponibile e trasferisce il resto alla CPU.

--n-cpu-moe 40

Mantiene sulla CPU i layer MoE indicati. È la leva fondamentale per un MoE: si colloca il backbone denso nella VRAM e si trasferiscono gli esperti nella RAM. Regola il numero in base alla tua VRAM.

-fa

Flash attention, riduce il consumo di memoria del KV-cache. Tenere attivato.

Multi-GPU

Con da 2 a 4 RTX 4090, llama.cpp distribuisce automaticamente il carico (--split-mode). Più VRAM = meno offload sulla CPU = maggiore velocità di elaborazione.

#5. Agenti di programmazione di lunga durata

È qui che GLM-5.2 in locale acquista tutto il suo senso, nonostante la sua lentezza. Un agente di programmazione che esegue il refactoring di una grande base di codice, legge decine di file e ragiona per ore non si preoccupa di una latenza di pochi secondi per token: lavora in background. Ciò che conta è la qualità del ragionamento e il contesto di 1M che gli permette di tenere a mente l'intero repository, il tutto senza che una riga di codice proprietario lasci la tua macchina.

Contesto molto ampio

Un milione di token permette di inserire un'intera base di codice nel prompt anziché frammentarla, migliorando così la coerenza delle modifiche su più file.

Tool calling

GLM-5.2 gestisce le chiamate agli strumenti nel formato OpenAI, indispensabile per un agente che legge, scrive ed esegue.

Endpoint OpenAI

Attraverso Ollama (localhost:11434) o llama.cpp (localhost:8080), collega Aider, Cline o qualsiasi agente che utilizzi l'API OpenAI.

Lavoro asincrono

Avvia l'attività e fai altro. A 5-10 tok/s, un refactoring importante richiede tempo, ma procede senza supervisione.

#Aspettative realistiche e risoluzione dei problemi

Nessun manuale serio affermerà che eseguire un 753B localmente sia fluido. Ecco i problemi reali e i loro rimedi.

Swap su disco = morte

Se il modello non entra in RAM e finisce nello swap su disco, la velocità scende al punto da richiedere secondi per token. Riduci il contesto, scegli una versione quantizzata più piccola o chiudi le altre applicazioni che consumano molta RAM.

Caricamento molto lento

Caricare 200 GB da un SSD richiede diversi minuti. È normale. Un SSD NVMe veloce fa una vera differenza; un disco esterno USB va evitato.

OOM al caricamento

Su Mac, regola il limite GPU (iogpu.wired_limit_mb). Su PC, aumenta --n-cpu-moe per inviare più esperti in RAM.

Qualità in calo

A 2 bit, il modello può produrre più allucinazioni. Riduci la temperatura (0.6 o meno) e preferisci le quantizzazioni dinamiche unsloth a un Q2 uniforme.

Throughput deludente

È normale. Un modello delle dimensioni di quelli di frontiera eseguito in locale non è veloce. Se vuoi velocità, GLM-5.1 32B o un Qwen3 saranno molto più reattivi.

#Per approfondire

GLM-5.2 è un caso estremo che riguarda la quantizzazione, l'hardware e il deployment degli agenti. Queste guide coprono i fondamenti da padroneggiare in questi ambiti.

Il fratello minore ragionevole

«GLM 5.1 in locale: l'alternativa open-weight da conoscere» — se il tuo hardware è limitato a 24 GB, è il modello GLM che fa per te, molto più reattivo.

Capire le quantizzazioni

«Scegliere la quantizzazione (Q4, Q5, Q8, FP16)» — indispensabile per capire perché la quantizzazione dinamica a 2 bit rende GLM-5.2 accessibile senza distruggerlo.

Programmare con un agente locale

«Aider + Ollama: programmare nel terminale con un agente 100% locale» — il punto di partenza per collegare GLM-5.2 a un vero workflow di sviluppo.