TechCompare LogoTechCompare

How much VRAM does GLM-5.1 754B (MoE) need at Q4_K_M? Zhipu 200K frontier

Self-hosting GLM-5.1 in resident mode requires a substantial hardware setup. You'll need at least eight 80 GB datacenter cards with NVLink, or four 141 GB H200 cards. For typical applications, the official API is the most economical starting point.

GLM-5.1 754B at Q4_K_M with native 200K context needs about 580 GB of VRAM with all experts resident in GPU memory. That's the baseline you'll size production cluster deployments against. This giant Mixture of Experts from Zhipu activates 40B parameters per token from its 754B total parameter pool. That doesn't shrink what has to stay loaded, because different tokens pick different experts. Moving expert weights to system RAM cuts VRAM, but the host then has to hold them and every token gets slower.

By TechCompare · Updated

Total VRAM required
580 GB
GLM-5.1 754B (MoE) at Q4_K_M
Weights
422 GB
754B params
KV cache
105 GB
195.3125K tokens, FP16 KV

Calculator

Estimated VRAM required

580 GB

754B params at Q4_K_M, 200,000 token context, batch 1, inference.

Weights
422 GB
KV cache
105 GB
Overhead
52.7 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

Zhipu built GLM-5.1 with 64 layers, hidden size 8192, and 16 key-value heads. The 754B parameter pool at Q4_K_M requires 422 GB of weights regardless of routing. At the maximum native context window of 200K tokens, the FP16 key-value cache uses a significant 105 GB of memory. Standard activation and software overhead scale with model size, adding about 53 GB. You'll need high-bandwidth hardware to run this MoE at acceptable speeds.

Verdict

The 580 GB resident total breaks into 422 GB of Q4 weights, 105 GB of FP16 KV cache at the 200K native context (16 KV heads at head_dim 128 across 64 layers, no MLA compression), and 53 GB of overhead. That's eight 80 GB cards with NVLink, or four 141 GB H200 cards with headroom. The 40B active count doesn't lower the resident total, because any token can route to any expert. Capping context is the lever you control: at 64K the cache falls to about 34 GB. The full 200K resident case is for serious infrastructure budgets and almost never beats the hosted API on cost.

More GLM scenarios

MiMo-V2.6-Pro at Q4_K_M
Budget a 1.02T expert pool, hybrid attention, and a 1M text context.
View details ➜
MiMo-V2.6-Flash at Q4_K_M
309B total weights and separate global and sliding cache widths.
View details ➜
GLM-5.3-Flash at Q4_K_M
Model the 34 KDA layers, 11 sparse layers, and indexer storage.
View details ➜

Frequently asked questions

What hardware is best to run GLM-5.1 in full resident mode?
You'll need a cluster of eight GPU cards with at least 80 GB of memory each, such as H100 or A100. Linking them with NVLink is required to handle expert routing communication without bottlenecks. Four 141 GB H200 cards also provide enough memory.
Can I run this model on consumer hardware?
Not in any practical way. The Q4 weights alone are 422 GB, far beyond consumer cards. Moving expert weights to system RAM cuts VRAM, but the host then has to hold most of those weights and every token gets slower.
Can I run GLM-5.1 754B on consumer hardware?
Not in resident mode. The 422 GB Q4 weight footprint plus KV cache easily exceeds any single GPU or consumer workstation. Moving expert weights to system RAM trades that VRAM for a lot of host memory and slower tokens. Most users will self-host GLM-5.2 instead, which uses compression tricks to run similar capacity at a smaller footprint.
What does expert offload feel like in practice?
Every token gets slower. llama.cpp's --cpu-moe keeps all expert weights in system RAM, and --n-cpu-moe N does that for the first N layers. How much slower depends on how many layers you offload and how fast your system RAM is.