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

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

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

By TechCompare · Updated

Total VRAM required
643 GB
GLM-5.2 744B (MoE) at Q4_K_M
Weights
417 GB
744B params
KV cache
168 GB
1024K tokens, FP16 KV

Calculator

Estimated VRAM required

643 GB

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

Weights
417 GB
KV cache
168 GB
Overhead
58.4 GB

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

Hardware that fits

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

How this is calculated

GLM-5.2 keeps the 744B parameter pool from GLM-5.1 but upgrades the attention: 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 417 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 58 GB. When you offload cold experts and keep only the active 40B weights in VRAM, weight memory shrinks to 22 GB, but the 167 GB key-value cache stays the same. That drops total usage to 209 GB, with the cache accounting for most of it.

Verdict

Resident mode needs eight 80GB datacenter cards with NVLink or five 141GB H200 cards. Active-only offload fits on dual 80GB cards, but the 1M-context key-value cache dominates. Capping context is the fastest way to shrink the footprint. For most workloads the official Zhipu API is the economical starting point.

More GLM scenarios

DeepSeek V4 Pro 1.6T (MoE) at Q4_K_M
1600B - Q4_K_M - 1024K ctx
View details ➜
Llama 4 Scout (17B/109B) at Q4_K_M
109B - Q4_K_M - 10240K ctx
View details ➜
gpt-oss 20B (MoE) at Q4_K_M
20B - Q4_K_M - 128K ctx
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.