TechCompare LogoTechCompare

How much VRAM does GLM-5.2 753B (MoE) need at Q4_K_M? Zhipu 1M MLA frontier

GLM-5.2 753B at Q4_K_M is a 650 GB resident deployment for 1M context. Active-only only gets you to 210 GB because the 78-layer MLA cache at full context is the binding constraint, not the weights.

GLM-5.2 753B at Q4_K_M with native 1M context needs about 650 GB of VRAM with all experts resident. Zhipu's successor to GLM-5.1 activates 40B parameters per token from a 753B total pool and rebuilds attention as 78 MLA layers interleaved with DSA IndexShare every 4 layers. Active-expert offload drops the resident footprint to roughly 210 GB, though the key-value cache at full context is the binding constraint rather than the weights.

By TechCompare · Updated

Total VRAM required
648 GB
GLM-5.2 753B (MoE) at Q4_K_M
Weights
422 GB
753B params
KV cache
168 GB
1024K tokens, FP16 KV

Calculator

Estimated VRAM required

648 GB

753B params at Q4_K_M, 1,048,576 token context, batch 1, inference.

Weights
422 GB
KV cache
168 GB
Overhead
58.9 GB

Estimate accuracy: Weights within ~2%. KV cache within ~5% for standard GQA models, ~10% for MLA or hybrid state estimates. Real VRAM may vary with framework (vLLM vs llama.cpp vs Transformers), Flash Attention, and driver overhead.

Hardware that fits

Apple entries show installed unified memory separately from a model budget based on an 8 GB reserve. That budget is a planning heuristic, not a fixed hardware limit.

No single GPU in our catalog has enough memory. Multi-GPU or CPU offload required.

How this is calculated

GLM-5.2 ships at 753B total parameters on HuggingFace config, up slightly from GLM-5.1's 754B-class pool. The attention is rebuilt: 78 MLA layers compressed to a 512-dim latent with 1 effective KV head, plus DSA IndexShare every 4 layers for sequence sparsity. At Q4_K_M the full parameter pool is 422 GB of weights. The MLA key-value cache at the full 1M context window uses a significant 167 GB. Activation and software overhead adds about 59 GB. When you offload cold experts and keep only the active 40B weights in VRAM, weight memory shrinks to 22.4 GB, but the 167 GB key-value cache stays the same. That drops total usage to 210 GB, with the cache accounting for most of it.

Verdict

The 650 GB resident total breaks into 422 GB of Q4 weights, 167 GB of MLA-compressed KV cache at the full 1M context, and 59 GB of overhead. Active-only loading shrinks the weights to about 22.4 GB by routing cold experts through system RAM, but the 167 GB cache is bound by context length rather than expert routing, so the total only drops to 210 GB and the cache dominates. That makes capping context the actual cost lever: at 256K the cache falls to roughly 42 GB and active-only drops to about 85 GB. Hardware-wise resident needs eight 80 GB cards or five 141 GB H200 cards, both with NVLink. Active-only fits dual 80 GB cards or a 192 GB unified-memory workstation. The official Zhipu API is the practical default unless data residency is the entire reason for self-hosting.

More GLM scenarios

DeepSeek V4 Pro 1.6T (MoE) at Q4_K_M
DeepSeek V4 Pro 1.6T at Q4_K_M with the full 1M-token context needs about 1012 GB of VRAM with every expert resident - this is the real shape of the model and the number to plan a deployment against.
View details ➜
Llama 4 Scout (17B/109B) at Q4_K_M
At Q4_K_M and 10,485,760 tokens, this model estimates 2335 GB with all 109B parameters resident.
View details ➜
gpt-oss 20B (MoE) at Q4_K_M
gpt-oss 20B at Q4_K_M with native 128K context needs about 19.4 GB of VRAM with all experts resident, dropping to roughly 9.3 GB with active-only weight loading.
View details ➜

Frequently asked questions

Why does active-only offload barely help GLM-5.2 at 1M context?
The 78 MLA layers produce a 167 GB key-value cache at the full 1M window. Active-only loading only shrinks the weights, from 417 GB to 22 GB. The cache depends on context length, not expert routing, so it stays 167 GB regardless. At 1M context the cache is the binding constraint. Capping context to 256K cuts the cache to about 42 GB and drops active-only total to about 83 GB.
How is GLM-5.2 different from GLM-5.1?
Same 744B parameter pool and 40B active per token. GLM-5.2 rebuilds the attention from GLM-5.1's 64 layers with 16 KV heads at head_dim 128 to 78 MLA layers with a 512-dim latent plus DSA IndexShare every 4 layers. The MLA upgrade roughly triples the key-value cache at full context but enables a native 1M context window, up from 200K.
Is a 1M-token context window worth the VRAM cost?
Only for workloads that actually need it: codebase-scale Q&A, multi-hundred-page document analysis, or agentic loops that accumulate history. The KV cache grows linearly with length, so a 1M window costs roughly 8x the memory of a 128K window at the same quantization. Most production traffic fits fine in 128K, and RAG beats long-context for retrieval-shaped tasks anyway.