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

By TechCompare · Updated · How we check

GLM-5.2 753B at Q4_K_M is a 648 GB resident deployment for 1M context. The 422 GB of weights are the biggest piece, and the 78-layer MLA cache adds 168 GB on top.

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.

GLM-5.2 753B at Q4_K_M with native 1M context needs about 648 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. Those 40B active params don't shrink what has to stay loaded, because different tokens pick different experts.

How this is calculated

GLM-5.2 ships at 753B total parameters on HuggingFace config, close to GLM-5.1's 754B 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 168 GB. Activation and software overhead adds about 59 GB. The cache depends on context length, not on which experts a token picks.

Verdict

Use the official Zhipu API unless data residency is the whole reason for self-hosting. Resident mode needs 9 cards of 80 GB or 5 H200 cards of 141 GB, both with NVLink. The cache is the part you control: at 256K it falls to roughly 42 GB.

More GLM scenarios

Kimi K3.1 Pro at Q4_K_M
A 2.78T expert pool with 24 latent attention layers and fixed state in the other 69.
View details
Mistral Large 4 at Q4_K_M
A 1T expert pool with 63 latent cache owners and 44 layers that also store an index key.
View details
Muse Spark Open at Q4_K_M
Only 16 of its 62 layers grow with context, and the other 46 hold a 2,048 token window.
View details

Frequently asked questions

How much of GLM-5.2's footprint is KV cache at 1M context?
About 168 GB of the 648 GB total. The 78 MLA layers produce that cache at the full 1M window, and it depends on context length, not on which experts a token picks. The 422 GB of Q4 weights are still the biggest piece. Capping context to 256K cuts the cache to about 42 GB.
How is GLM-5.2 different from GLM-5.1?
A near identical parameter pool (753B against 754B) and the same 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 enables a native 1M context window, up from 200K, with a 168 GB cache. GLM-5.1's design would need 550 GB of cache at 1M.
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.