Eseguire GLM-5.2 con contesto da 1 milione di token su un singolo nodo 8×H200

GLM-5.2 offre ai modelli di coding a pesi aperti una vera finestra di contesto da 1 milione di token. La parte difficile è servire questa finestra completa sull’hardware che molti team utilizzano già in produzione: Hopper.

Abbiamo quantizzato GLM-5.2-FP8 in W4AFP8 e lo abbiamo validato su un singolo nodo 8×H200 con SGLang. Il checkpoint riduce la memoria occupata dai pesi da 755 GB a 368 GB, liberando 387 GB di HBM per la cache KV da 1 milione di token e per il margine operativo di runtime.

Perché è importante

GLM-5.2 ha già risolto il problema del contesto lungo dal lato del modello: attenzione sparsa, IndexShare, decodifica speculativa MTP, utilizzo di strumenti (tool use), ragionamento e una finestra di 1.048.576 token. Tuttavia, il deployment presenta un secondo problema. Una finestra da 1 milione di token richiede spazio per i pesi del modello, la cache KV, i grafi CUDA, i buffer di runtime e l’overhead del servizio.

Il checkpoint FP8 ufficiale rappresenta una solida base generale per il serving. Su Hopper, però, questa base lascia molto meno margine di memoria quando si spinge verso l’intera finestra di contesto. W4AFP8 modifica il bilancio della memoria senza cambiare la famiglia del modello, il tokenizer, la forma dell’API o il comportamento di GLM-5.2.

Cosa abbiamo modificato

GLM-5.2 è un grande modello MoE (Mixture of Experts). La maggior parte dell’occupazione di memoria dei pesi risiede negli esperti instradati (routed experts), rendendoli il punto con il maggior potenziale di compressione. GLM-5.2-W4AFP8 memorizza i pesi degli esperti MoE instradati come interi a 4 bit con attivazioni FP8. I layer densi, gli esperti condivisi, il meccanismo di attenzione, l’indicizzatore per l’attenzione sparsa e i pesi MTP non appartenenti agli esperti rimangono in FP8 o BF16.

Il risultato è un checkpoint ottimizzato per Hopper e SGLang. Mantiene l’intero conteggio logico dei parametri di GLM-5.2 e serve lo stesso modello con una precisione inferiore dei pesi. Il numero di parametri mostrato nella pagina Hugging Face riflette gli elementi memorizzati in forma compressa, poiché due pesi da 4 bit condividono un singolo byte.

La qualità è rimasta allineata

Abbiamo valutato il checkpoint su 8×H200 con SGLang v0.5.13.post1 utilizzando le impostazioni di campionamento raccomandate per GLM-5.2: temperatura 1.0, top_p 0.95 e ragionamento abilitato. L’obiettivo del benchmark era semplice: dimostrare che il guadagno in memoria preserva la qualità del modello.

GPQA-Diamond ha ottenuto 90,9 contro il riferimento ufficiale di 91,2. IFBench strict ha ottenuto 75,0 contro 74,3. AA-LCR per il ragionamento su contesti lunghi ha ottenuto 76,0 contro 69,7. Nel test needle-in-a-haystack con circa 983.000 token sono stati recuperati correttamente 3 aghi su 3. La chiamata di strumenti (tool calling) BFCL ha mostrato un comportamento identico a quello di riferimento.

Questo definisce il perimetro dell’affermazione: GLM-5.2-W4AFP8 è allineato alla baseline ufficiale di GLM-5.2 nei benchmark eseguiti, mantenendo intatti il recupero delle informazioni su contesti lunghi e il tool calling.

La decodifica speculativa MTP continua a funzionare

GLM-5.2 include un layer Multi-Token Prediction (MTP) per la decodifica speculativa in stile EAGLE. Abbiamo quantizzato e validato anche questo percorso come parte del rilascio. In SGLang, il modello principale continua a verificare ogni token generato in fase di bozza, quindi la decodifica speculativa influisce sulla latenza e sul throughput, non sulla semantica dell’output.

Su un singolo flusso, il throughput di decodifica è aumentato da 75 token/s a 118 token/s con EAGLE. Nel test di serving con input da 8K token, output da 1K token e 16 richieste concorrenti, il throughput aggregato di completamento è aumentato da 658 token/s a 733 token/s.

Come eseguirlo

Il checkpoint è stato validato con SGLang v0.5.13.post1 su GPU Hopper. Utilizzare il percorso di quantizzazione W4AFP8, la cache KV in FP8, i parser di ragionamento e tool calling di GLM e l’intera lunghezza di contesto di 1.048.576 token.

python -m sglang.launch_server \
  --model-path PhalaCloud/GLM-5.2-W4AFP8 \
  --quantization w4afp8 --disable-shared-experts-fusion \
  --tp 8 --kv-cache-dtype fp8_e4m3 \
  --reasoning-parser glm45 --tool-call-parser glm47 \
  --context-length 1048576 --mem-fraction-static 0.85 \
  --trust-remote-code

Per utilizzare il percorso a 118 token/s su singolo stream, aggiungere la decodifica speculativa EAGLE:

--speculative-algorithm EAGLE --speculative-num-steps 1 \
--speculative-eagle-topk 1 --speculative-num-draft-tokens 2

Ambito

• Validato con SGLang v0.5.13.post1.
• Progettato per GPU Hopper: H100 o H200, architettura SM90.
• vLLM e altri motori non sono stati validati per questo checkpoint.
• Il checkpoint eredita capacità, licenza e limitazioni del modello base GLM-5.2.

Considerazioni pratiche

GLM-5.2 ha reso disponibile un contesto da 1 milione di token in un modello open-weight. GLM-5.2-W4AFP8 rende quella finestra praticabile su un singolo nodo 8×H200.

Per i team che dispongono di infrastrutture Hopper, questo trasforma GLM-5.2 da un semplice rilascio di un modello a lungo contesto in un obiettivo di serving realmente distribuibile con contesto da 1 milione di token.

Modello: GLM-5.2-W4AFP8 su Hugging Face