Requisiti hardware di GLM-5.3 (2026): GPU, VRAM e RAM

State valutando se GLM-5.3 possa girare sulla GPU del vostro desktop? La risposta è no: il checkpoint flagship attuale richiede memoria da server. GLM-5.3-Flash abbassa la soglia d’ingresso, ma resta comunque un modello di grandi dimensioni che richiede più GPU; riuscire a caricare un checkpoint quantizzato non significa poter gestire un coding agent reattivo.

La risposta hardware, in una tabella

Il modello completo GLM-5.3 ha una topologia documentata con 8 GPU in FP8, mentre il contesto completo da 1 milione di token è documentato su 8× B200. Una macchina con 24 GB, 64 GB, 128 GB o 192 GB non è una piattaforma realistica per il modello completo, anche se il routing sparso MoE attiva solo una parte dei parametri per ciascun token.

L’attuale model card su Hugging Face riporta 753.329.940.480 parametri totali, 751.226.191.872 parametri FP8 e una dimensione complessiva dei file safetensors pari a 755.643.409.571 byte. La ricetta vLLM arrotonda il modello a circa 743B di parametri totali e 39B attivi. Le cifre arrotondate differiscono leggermente, ma la conclusione hardware non cambia.

Il semplice calcolo della memoria per i pesi

Si tratta di stime aritmetiche prima di considerare KV cache, attivazioni, buffer del runtime e overhead dell’allocator. Per FP8 e BF16 si assume la scala di circa 753B di parametri del flagship attuale; i valori NVFP4 e 2-bit si riferiscono invece a implementazioni specifiche.

Cosa è cambiato rispetto alle indicazioni hardware pre-release

Il repository di GLM-5.3 è ora disponibile con i file FP8 nativi. Per i metadati del checkpoint fate riferimento alla model card attuale, per topologia e flag alla ricetta ufficiale vLLM, mentre i report community servono a capire l’esperienza concreta di deployment; la ricetta attuale pubblicizza una finestra di contesto da 1.048.576 token.

Scegliete in base alla memoria, non al numero di parametri

Con GLM-5.3 la memoria dei pesi è il primo vincolo, quella del contesto il secondo. I parametri attivi riducono il carico di calcolo, ma non eliminano la necessità di conservare gli esperti instradati e i buffer del runtime.

24–64 GB: lasciate perdere un’installazione locale completa di GLM-5.3

Una singola RTX 4090, RTX 5090 o un’altra scheda della classe da 24 GB non può contenere il checkpoint flagship in FP8 nativo, che nel repository attuale su Hugging Face occupa circa 756 GB di file safetensors. Anche una scheda workstation da 64 GB è ancora molto lontana dalla memoria necessaria per i pesi.

L’offload sulla CPU può permettere di caricare un esperimento quantizzato, ma resta una soluzione da debug, non la configurazione predefinita per un servizio di coding interattivo. Un agent deve comunque completare chiamate ripetute agli strumenti a una velocità accettabile.

128–192 GB: niente flagship; Flash solo in una configurazione precisa

Una macchina con 128 GB o 192 GB di memoria unificata resta al di sotto del requisito FP8 nativo del flagship. Per Flash esiste invece un percorso concreto: un profilo pubblico validato esegue un checkpoint EXL3/TR3 4-bpw fissato su 2× RTX PRO 6000 Blackwell da 96 GB.

Questo profilo utilizza 175,6 GB di dati del checkpoint, circa 220 GB di spazio libero su disco, comunicazione peer-to-peer PCIe e un runtime fissato a una versione specifica. Riporta un limite di 262.144 token per richiesta, ma si tratta di un deployment discreto su due GPU, non di 192 GB di normale RAM di sistema. Per quella precisa configurazione Flash, il profilo indica inoltre un decode da 171,7 token al secondo e un tempo mediano al primo token di 0,059 secondi.

2–4 GPU con molta memoria: valutate Flash, non il flagship

Due o quattro schede con molta memoria sono il primo intervallo sensato da esplorare per Flash, perché precisione, runtime, lunghezza del contesto, batching e input d’immagine modificano tutti il budget necessario. Il profilo validato su due GPU supporta testo, strumenti strutturati e input d’immagine semantico; il video è disabilitato, l’endpoint non offre autenticazione integrata e il template vision incluso richiede una correzione reversibile prima della verifica multimodale. Sono dettagli relativi a quella ricetta fissata, non a ogni build di Flash né al flagship.

8× H200 o H20: la topologia FP8 documentata per il flagship

La ricetta ufficiale vLLM indica otto GPU H200 o H20 come topologia standard per il modello nativo FP8. La configurazione utilizza tensor parallelism a otto vie, KV cache in FP8, multi-token prediction a cinque token, selezione automatica degli strumenti e parser specifici GLM per ragionamento e tool call.

Questa è la topologia documentata, non una promessa su un determinato risultato in token al secondo. Il throughput effettivo dipende da interconnessione, lunghezza del contesto, dimensione del batch, sequenze concorrenti e build di serving; la pagina vLLM fornisce la configurazione, ma non misura il throughput in produzione.

8× B200: la scelta se vi serve il contesto da 1 milione di token

La ricetta ufficiale prevede otto GPU B200 per la configurazione con contesto completo da 1.048.576 token. Quel contesto aggiuntivo è prima di tutto una questione di VRAM: la KV cache cresce in base alle sequenze attive e al contesto, quindi un deployment funzionante a 32K o 128K token potrebbe non supportare un milione di token mantenendo lo stesso livello di concorrenza.

Partite da un valore più contenuto di --max-model-len e aumentatelo solo dopo aver misurato l’utilizzo della KV cache. Una finestra di contesto così ampia è utile per repository e documenti lunghi, ma non rende automaticamente economica o a bassa latenza ogni richiesta.

Requisiti del sistema host non specificati dalla ricetta ufficiale

La ricetta vLLM indica la topologia delle GPU e i flag di avvio, ma non pubblica requisiti universali per RAM di sistema, consumi, raffreddamento, spazio libero su disco o rete. Questi valori cambiano in base al checkpoint, al runtime, al contesto previsto e alla piattaforma del provider.

Il percorso minimo di serving ufficiale

Il deployment documentato utilizza vLLM 0.28.0 ed espone un endpoint compatibile con OpenAI. È pensato per un nodo multi-GPU: copiare il comando su una macchina più piccola non elimina il requisito di memoria del modello.

Installate il runtime documentato

uv venv
source .venv/bin/activate
uv pip install "vllm==0.28.0" --torch-backend=auto
uv pip install "transformers>=5.15.0"

La ricetta vLLM specifica inoltre che DeepGEMM è necessario per le prestazioni FP8. Prima di attivare un nodo a pagamento, confrontate la ricetta attuale con l’immagine GPU prevista.

Avviate GLM-5.3 nativo FP8

vllm serve zai-org/GLM-5.3 \
  --kv-cache-dtype fp8 \
  --tensor-parallel-size 8 \
  --speculative-config.method mtp \
  --speculative-config.num_speculative_tokens 5 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --enable-auto-tool-choice \
  --served-model-name glm-5.3

I flag hanno funzioni precise:

• --tensor-parallel-size 8 distribuisce il checkpoint su otto GPU.
• --kv-cache-dtype fp8 riduce la pressione sulla cache rispetto a una cache a precisione superiore.
• L’impostazione MTP a cinque token abilita la decodifica speculativa prevista dalla ricetta documentata.
• --tool-call-parser glm47 e --reasoning-parser glm45 formattano l’output del modello per l’uso degli strumenti e il ragionamento.
• --enable-auto-tool-choice permette al server di selezionare gli strumenti quando il client li fornisce.

Verificate l’endpoint prima di collegare un agent

curl -X POST "http://localhost:8000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Write a Python function that reverses a linked list."}
    ],
    "max_tokens": 256
  }'

Una risposta corretta conferma che il modello viene caricato, ma non dimostra il funzionamento dei tool né il comportamento su contesti lunghi. La model card ufficiale documenta anche SGLang come percorso compatibile con OpenAI; questa guida usa però vLLM perché la sua topologia GPU e i relativi flag sono descritti in una ricetta dedicata.

Il budget di memoria nascosto: KV cache e ragionamento sempre attivo

La model card di GLM-5.3 e la ricetta vLLM considerano il thinking sempre attivo. I valori di reasoning effort supportati sono low, high e max; max è il valore predefinito quando non viene indicata un’impostazione inferiore supportata.

Un ragionamento più lungo consuma più token in output, mentre un coding agent può mantenere nella KV cache ampi prefissi di un repository durante chiamate ripetute agli strumenti. Più sequenze concorrenti significano una richiesta di cache maggiore, anche quando i pesi del modello restano invariati.

Usate queste impostazioni come leva di deployment:

• Low: il punto di partenza per coding interattivo, richieste brevi e strumenti sensibili alla latenza.
• High: utile quando il compito richiede più pianificazione, ma il budget di risposta deve restare interattivo.
• Max: da riservare ai compiti difficili e di lunga durata, quando i token aggiuntivi di ragionamento sono giustificati.

Per la configurazione B200 con contesto completo, la ricetta ufficiale consiglia --max-num-seqs 32 e utilizza impostazioni della cache in FP8. Considerate quel valore un punto di partenza: riducete la concorrenza se il server esaurisce la memoria e non dichiarate il supporto a un milione di token finché una richiesta reale non raggiunge quella dimensione senza troncamento della cache.

Quando l’API è la scelta hardware più razionale

L’hosting in proprio riserva capacità GPU anche quando nessuno sta inviando richieste. In caso di traffico intermittente, bassa concorrenza o mentre il team sta ancora valutando GLM-5.3, l’API evita l’acquisto o il noleggio continuo di un nodo a otto GPU; il compromesso riguarda la gestione dei dati presso il provider e la dipendenza dal servizio.

La pagina dei prezzi attuali di Z.ai indica per GLM-5.3 $1.40 per 1M di token in input, $0.26 per 1M di token in input memorizzati in cache e $4.40 per 1M di token in output. Per GLM-5.3-Flash indica il prezzo di listino $0.15 / $0.03 / $0.50, con una promozione del 50% indicata fino al 9 settembre 2026; prima di preparare il budget, verificate la pagina di fatturazione aggiornata.

Si tratta di esempi basati sul costo dei token, non di un calcolo del punto di pareggio rispetto all’hosting in proprio. Un confronto valido deve includere il prezzo orario del nodo, i token al secondo sostenuti, il livello di utilizzo, l’elettricità, lo storage, il tempo d’ingegneria e le esecuzioni fallite o ripetute dell’agent. Per una spiegazione dettagliata delle singole tariffe, consultate la guida di AIReiter ai prezzi dell’API GLM-5.3-Flash.

La scelta è questa:

• Scegliete l’API hosted di GLM-5.3 se vi serve il flagship, ma la domanda è irregolare o moderata.
• Scegliete GLM-5.3-Flash se contano di più il costo ridotto per token, gli input multimodali o una piattaforma self-hosting più contenuta rispetto alla capacità del flagship.
• Scegliete il flagship GLM-5.3 in self-hosting quando privacy, controllo o utilizzo continuativo giustificano un deployment a otto GPU.

FAQ sui requisiti hardware di GLM-5.3

GLM-5.3 può girare su una RTX 4090, RTX 5090 o GPU da 24 GB?

No, non nella sua versione completa. Il repository attuale in FP8 nativo contiene circa 756 GB di file safetensors, quindi una scheda da 24 GB può partecipare soltanto a un esperimento estremo con offload o quantizzazione, non contenere il modello per il serving normale.

Bastano 128 GB o 192 GB di RAM?

Non per il deployment flagship in FP8 nativo. Il profilo Flash validato utilizza due GPU discrete da 96 GB, un checkpoint 4-bpw fissato e spazio di archiviazione aggiuntivo; non è equivalente a un laptop con 192 GB o a una workstation con memoria unificata da 192 GB.

Qual è la differenza tra GLM-5.3 e GLM-5.3-Flash?

Sono due modelli distinti: la model card del flagship riporta circa 753B di parametri totali, mentre Z.ai descrive Flash come un modello da 320B di parametri totali e 18B attivi, con un’impostazione multimodale nativa. Flash è più piccolo ed economico, ma resta un modello da server, non un modello desktop da 18B.

Quale precisione dovrei scegliere?

Usate FP8 nativo quando è disponibile la topologia documentata a otto GPU. Scegliete BF16 per valutazioni di riferimento o specialistiche quando la memoria da ambiente multi-node è accettabile; prendete in considerazione NVFP4 solo su hardware Blackwell compatibile e ricordate che il checkpoint NVFP4 indicato è una requantizzazione community, non il pacchetto originale predefinito.

Posso collegare GLM-5.3 a un coding agent?

Sì. La ricetta ufficiale vLLM abilita un endpoint compatibile con OpenAI, oltre ai parser per tool call e ragionamento, quindi i client che supportano questa interfaccia possono collegarsi dopo la verifica del server. Testate l’harness effettivo, lo schema degli strumenti e il comportamento durante sessioni lunghe: una chat completion riuscita non dimostra da sola la compatibilità con un agent.

Cosa fare adesso

Se avete un desktop o un host con meno di 192 GB, provate prima l’API hosted. Noleggiate la topologia documentata a otto GPU per un carico rappresentativo oppure valutate Flash su una macchina multi-GPU con molta memoria; passate al self-hosting solo dopo aver misurato un livello di utilizzo tale da giustificare il costo dell’infrastruttura in cambio di controllo e privacy.