GLM-5.2's 744B MoE Costs More to Self-Host Than the MIT License Suggests

Zhipu shipped GLM-5.2 in mid-June 2026 as a 744B-parameter mixture-of-experts model under an MIT license, and both halves of that sentence are real: the BF16 weights and FP8 weights are on HuggingFace, and the model card calls the release “Pure Open” with “no regional limits, technical access without borders”. The catch is arithmetic. A 744B-parameter model needs about 1.5 TB of accelerator memory in BF16, and the FP8 build still needs roughly 744 GB, which is more than a fully loaded eight-card 80 GB server can hold before a single token of KV cache. The MIT license gives you the right to run this model on your own machines. It does not supply the machines.

The benchmark story earned the attention: 62.1 on SWE-bench Pro and 81.0 on Terminal-Bench 2.1 made GLM-5.2, in Zhipu’s README, “the strongest open-source model” on standard coding benchmarks at launch. Five months on, the same repository headlines GLM-5.3 and GLM-5.3-Flash, and both GLM-5.2 model cards now carry a “newer version of this model is available” banner. That matters to anyone still deciding whether to host this model, so the numbers below reflect where things stand as of early November 2026.

What GLM-5.2 actually is

The GLM-5 repository lists GLM-5.2 with the size designation 744B-A40B, the same label it applies to GLM-5, GLM-5.1 and GLM-5.3. The README spells out what the notation means for GLM-5, which “scales from 355B parameters (32B active) to 744B parameters (40B active)”: 744B total weights, about 40B active per forward pass. Sparse routing is what lets those two numbers coexist. It is also what makes the memory bill brutal.

Two architecture pieces matter for cost. IndexShare, Zhipu’s name for reusing the same indexer across every four sparse attention layers, cuts per-token FLOPs by 2.9× at 1M context. An improved MTP layer adds speculative decoding, with acceptance length up 20% over the previous generation. Context is 1M input tokens with a 128K output cap, served under the model id glm-5.2 (official docs); the README notes GLM-5.2 accepts only high and max for reasoning_effort.

Deployment is supported through SGLang (v0.5.13.post1+), vLLM (v0.23.0+), Transformers (v0.5.12+), KTransformers (v0.5.12+) and Unsloth (v0.1.47-beta+), with vLLM-Ascend, xLLM and SGLang available for Ascend NPUs (model card).

On lineage: Zhipu, listed as 02513.HK, announced GLM-5.2 in a voluntary filing on June 15, 2026, and the model cards are dated June 16 (announcement coverage). It is a point release on the GLM-5 base rather than a new architecture. GLM-5.3 “uses the same base model as GLM-5.2” and “every gain comes from post-training”, per the README, including a claimed 50% jump on Zhipu’s in-house Z.ai Code Bench. GLM-5.3-Flash is the one genuinely new build in the repo: a 320B-A18B model with a hybrid sparse-and-linear attention design aimed, in Zhipu’s words, at “sharply reducing long-context serving costs while preserving precise long-context capabilities.”

What the benchmarks actually show

From the GLM-5.2 model card:

Zhipu’s README rounds GLM-5.1’s Terminal-Bench score to 62.0 while the card table lists 63.5; either way, the generational jump on terminal work is the headline, and the SWE-bench Pro gain is a steadier 3.7 points.

Read the right-hand column honestly. The gap to Claude Opus 4.8 is 4.0 points on Terminal-Bench 2.1, 7.1 on SWE-bench Pro, 0.7 on FrontierSWE (a long-horizon benchmark evaluated at 1M context) and 13 on SWE-Marathon. The pattern is neither parity nor collapse: the gap widens and narrows with the shape of the task. Zhipu also places GLM-5.2 ahead of Gemini 3.1 Pro on the coding rows. A team evaluating this model for agent loops should weight the four coding rows over the math evals, and note the card’s harness footnotes: Terminal-Bench ran at 256K context, SWE-bench Pro at 400K, and the long-horizon rows at 1M.

Why the MIT license does not make self-hosting cheap

MIT imposes no per-token fee, no usage cap, no commercial restriction. That is the accurate description of what the license does. What it cannot do is change mixture-of-experts inference: the full 744B parameter set must be resident in memory even though roughly 40B fire per token. In BF16 that is about 1.5 TB of weights; in FP8 about 744 GB. A standard eight-card 80 GB node provides 640 GB, which falls 104 GB short of the FP8 weights alone. A ten-card 80 GB setup covers the weights with roughly 56 GB left for KV cache across the whole fleet, and a 1M-token context window will not respect that margin. BF16 asks for about nineteen 80 GB cards before any cache.

IndexShare reduces per-token FLOPs, and FLOPs are not the binding constraint. Weight residency is. The 2.9× FLOP reduction shows up as throughput once the hardware exists; it does not shrink the memory requirement by a byte.

The offloading escape hatch, measured

The obvious workaround is to not hold every expert on the GPU. KTransformers is one of the frameworks in Zhipu’s official deployment list, and independent work documents it as a CPU-GPU hybrid serving system: a paper on MoE offloading for local PCs groups KTransformers with llama.cpp as layer-wise hybrid frameworks that execute each MoE layer exclusively on one device, which prevents the CPU and GPU from working in parallel, and notes that moving expert weights over consumer PCIe connections can “incur considerable inference latency”.

Speculative decoding compounds the problem, and GLM-5.2 ships with it. The AcceptMoE paper from Imperial College London and Tile-AI measured MoE speculative decoding under expert offloading on Qwen3-30B-A3B (Instruct and Coder variants) and GPT-OSS-120B with EAGLE-3 drafts, at batch size one in SGLang, on a single RTX 5090 with a 48-slot expert pool per layer. Standard speculative decoding spent 65–78% of wall time waiting for expert weights, was slower than plain autoregressive decoding on seven of eight Qwen pairs, and moved 2,394 MiB of expert weights per output token against 888 for autoregressive decoding on the Instruct target. The mechanism: verifying a draft tree in one pass can activate the union of experts selected by every node in the tree, so in the authors’ words, “token count, activated-expert union size, and expert-weight traffic are therefore distinct cost measures”. Their commitment-weighted expert selection cuts host-to-device traffic by 73.6–77.1% and reaches 2.06× throughput under offloading, at a mean accuracy cost of 0.27 points across 12 model-task pairs.

The scope limit matters: these are measurements of other models with EAGLE-3 drafters, not GLM-5.2. The model card documents GLM-5.2’s MTP layer “for speculative decoding” with acceptance length up 20%, and a metric like acceptance length only means something if several draft tokens are verified per pass; multi-token verification is exactly the shape AcceptMoE found expensive under offloading. That bridge is inference, not a measurement of GLM-5.2 itself. It is reason to benchmark with speculation enabled and disabled before buying hardware, if you plan to host this model by streaming experts from host RAM. The evidence gives cause to expect an off-the-shelf offloaded deployment to be memory-bandwidth-bound rather than compute-bound.

What hosted access costs

Zhipu sells model access through the GLM Coding Plan, a subscription (plan page). The page now bills itself as powered by GLM-5.3, GLM-5.3-Flash and a GLM-5.3-FlashX-Legal variant, and the README points API users at GLM-5.3 services. The plan page’s FAQ names the two constraints an agent team actually hits: “What is the usage limit for the plan?” and “How many concurrent connections does the plan support, and why does it sometimes feel like there’s only one concurrent connection?” Both deserve written answers before you point parallel agent sessions at the plan; usage limits and concurrency caps, more than list price, are what a long-horizon workflow stresses.

Zhipu’s own June filing framed the open-source release as a way to grow open-platform and API call volume (announcement coverage), which is a candid account of why a company gives away 744B of weights while selling subscriptions.

For the hardware side of the comparison there is a usable price anchor: the offloading paper’s hardware table lists an H100 80 GB server at $200k–$400k+ against a $2k–$5k local PC. That is the class of machine the FP8 weights require. So the self-host-versus-subscribe question still reduces to one test: do you already operate multi-GPU inference infrastructure? If yes, the MIT weights turn your marginal cost into electricity and amortized hardware, and 744 GB of FP8 weights becomes a scheduling problem. If no, you are pricing a ten-card 80 GB deployment, in a bracket the literature puts at $200k–$400k+ for the server class, against a subscription. Check the plan’s current price and quota terms, but I would not expect that comparison to be close.

Where the decision sits now

The weights remain up and in active use: as of November 9, 2026, the BF16 card shows 324,229 downloads in the last month and the FP8 card shows 133,831. Both now point readers to GLM-5.3 as the newer version, and the README’s superlative has moved with it: GLM-5.3 is “the most capable open-weights model for coding”, achieved from post-training alone on the same base.

Two readings follow. If you want open weights specifically to self-host, the repository now contains a better-fitting answer than GLM-5.2: GLM-5.3-Flash at 320B-A18B works out to roughly 320 GB in FP8 by the same arithmetic, which fits inside a single eight-card 80 GB node with real room for cache, and its hybrid attention is explicitly aimed at long-context serving costs. If you want maximum coding capability per dollar and the license was only ever a proxy for that, the subscription or API on GLM-5.3 delivers the same 744B base plus months of additional post-training, with none of the memory bill.

The MIT license remains genuinely valuable for what licenses govern: fine-tuning, offline deployment, data control, no regional limits. It has never governed the memory bus. The repository’s 744B-A40B label tells you more about your hosting bill than the license file does.