GLM-5.2: 753B MoE, 1M Context, MIT License Self-Hosting Guide
⏱️ Estimated reading time: 7 min
What Makes GLM-5.2 Different
GLM-5.2, released by Z.ai (formerly Zhipu AI), is a MoE model with 753B total parameters. It is available at the HuggingFace repository zai-org/GLM-5.2 under the MIT license.
The most notable aspect of this model is how it handles 1M token context at a practical FLOPs level. Many models claim “1M context support,” but actual inference cost becomes the bottleneck. GLM-5.2 tackles this head-on with DSA (Dynamic Sparse Attention).
Architecture: DSA and IndexShare
The core of GLM-5.2 is the glm_moe_dsa architecture. DSA uses an IndexShare scheme where groups of 4 adjacent sparse attention layers share a single indexer.
Traditional dense self-attention has $O(L^2)$ complexity with respect to sequence length $L$. Beyond 128K tokens this cost grows rapidly, whereas sparse attention reduces it by having each token attend only to selected positions rather than the full sequence. GLM-5.2’s DSA achieves 2.9x per-token FLOPs savings at 1M context, as stated in the HF model card.
The model also includes speculative decoding improvements. MTP (Multi-Token Prediction) raises the acceptance rate by up to 20%, which directly benefits serving throughput.
Supported dtypes are BF16 and F32. The number of active parameters is not explicitly stated in the public model card.
Benchmarks
Numbers from the HF model card:
| Benchmark | GLM-5.2 |
|---|---|
| HLE | 40.5 |
| HLE w/Tools | 54.7 |
| AIME 2026 | 99.2 |
| SWE-bench Pro | 62.1 |
| Terminal Bench 2.1 | 82.7 |
| MCP-Atlas (Public) | 76.8 |
AIME 2026 at 99.2 is a very high score for mathematical reasoning. SWE-bench Pro 62.1 reflects performance on real software engineering tasks, and MCP-Atlas 76.8 covers tool-use scenarios.
HLE (Humanity’s Last Exam) w/Tools at 54.7 is a meaningful step up from the 40.5 without tools. This suggests pairing the model with coding agents or tool-use pipelines is effective.
Serving and Deployment
Supported Frameworks
Officially supported serving frameworks:
- vLLM v0.23.0 or later
- SGLang v0.5.13.post1 or later
- Transformers v0.5.12 or later (HF)
- KTransformers (quantized serving on consumer-grade GPUs)
- Unsloth (including fine-tuning)
- Ascend NPU (Huawei NPU support)
Quantization Variants
29 quantization variants including GGUF are available on HF Hub. Options such as Q4_K_M and Q8_0 cover a range of bit widths, letting you choose based on available GPU memory. Combined with KTransformers, inference is possible on consumer GPUs like the RTX 4090. Running full BF16 753B on a single node is, of course, a separate challenge.
Minimum Requirements
Full 753B in BF16 requires approximately 1.5 TB of VRAM. Practical on-premises deployment assumes quantization. Q4 quantization brings this down to roughly 375 GB, and Q8 to roughly 750 GB. Multi-node tensor parallelism (TP) is required; a starting configuration of 8 or more NVIDIA H100/A100 GPUs is typical.
API serving through the Z.ai API is also an option.
ThakiCloud Perspective
Three things stand out from a ThakiCloud standpoint:
MIT license. A 753B-class model released under MIT is rare. For commercial on-premises builds, the absence of license review overhead lowers the enterprise adoption barrier. This contrasts with Llama and Qwen series models, which carry their own “Llama Community License” or separate conditions.
DSA implications for Kueue GPU cost estimation. If per-token FLOPs drop 2.9x on 1M context tasks, the number of sequences processed within the same GPU budget increases. In environments where GPU quotas are managed via Kueue, the cost projection for long-context batch jobs changes. GPU budgets calculated against traditional dense attention models need to be recalculated using GLM-5.2 as the baseline.
29 GGUF variants plus the KTransformers path. If on-premises GPUs are RTX-class rather than H100-class, the combination of KTransformers and GGUF quantization is a realistic serving path. All 29 quantization variants are already on HF Hub, so no separate conversion work is needed. The entry barrier for small teams wanting to test 1M context capability on limited hardware is low.
For organizations looking to deploy on-premises models on long-context, long-horizon tasks (full contract analysis, large codebase comprehension, extended report generation), GLM-5.2 is worth evaluating. Full BF16 753B serving still requires a large GPU cluster, so choosing the right quantization strategy for the target deployment scale is critical.