GLM-5.2 Open Weights: Benchmarks, MIT Licence, and the Hardware to Self-Host a 1.5 TB Model

Z.ai put the weights of GLM-5.2 on Hugging Face yesterday, under the MIT licence and with no access gate. It is Z.ai's new flagship for long-running coding and agent work, with a 1-million-token context, and Artificial Analysis has already ranked it first among open-weights models on its Intelligence Index.

The licence is the easy part. The checkpoint is 1.51 TB in BF16, and the benchmark table arrived without the settings used to produce it. I read the card, the repository, the config and the file listings, and did some arithmetic of my own. Every benchmark below is reported by Z.ai unless I say otherwise, and I have not run the model.

GLM-5.2 specifications, read from the checkpoint

Specification	GLM-5.2
Released on Hugging Face	June 16, 2026, MIT licence, not gated
Parameters in the checkpoint	753,329,940,480
Z.ai's description	744B total, 40B active per token
Layers	78, plus one multi-token prediction (MTP) layer
Experts	75 MoE layers of 256 routed experts plus 1 shared; 8 routed active per token
Context	1,048,576 positions
Files	1.51 TB in BF16; 756 GB for the FP8 release

Source: Hugging Face records, configs and file listings for GLM-5.2 and GLM-5.2-FP8 at their June 17 revisions, and Z.ai's GLM-5 repository.

The two counts differ, and the files explain why. The checkpoint has a 79th layer, the multi-token prediction layer used for speculative decoding, which by my count from the safetensors headers holds 9.95 billion parameters. Without it, 743.4 billion remain, close to Z.ai's 744B.

The licence file is the standard MIT text, copyright Zhipu AI, with no revenue threshold, no display requirement and no regional restriction. For self-hosting, that is as simple as open weights get: run it, fine-tune it, distil it and ship it, keeping the copyright notice.

IndexShare and the 1M-token context

GLM-5.2 keeps the sparse attention GLM-5 adopted in February. A small indexer scores every earlier token, and each query then attends to the top 2,048. The indexer is cheap per token but reads the whole context, so at a million tokens it dominates the work. IndexShare computes that index in a few layers and reuses it in the others. In the published config, 21 of the 78 layers compute their own index and 57 reuse one.

Z.ai says this cuts per-token FLOPs by 2.9 times at a 1M context. A rough check from the config makes that plausible. Scoring a million earlier tokens with 32 indexer heads of 128 dimensions costs about 8.6 GFLOPs per layer for each generated token, or 670 GFLOPs across 78 layers, against roughly 80 for the 40 billion active weights. By my arithmetic, computing the index in 21 layers instead cuts the total by 2.7 to 2.9 times, depending on how much of the attention itself you count.

FLOPs are not latency. The card links IndexShare to a March paper by GLM-5 authors, titled IndexCache, which reports up to 1.82 times faster prefill and 1.48 times faster decoding on a 30B model. I would treat 2.9 as a compute ratio, not a speed-up, and measure throughput before planning capacity.

GLM-5.2 benchmarks: what the vendor table shows, and what it leaves out

Benchmark	GLM-5.2	DeepSeek V4 Pro	GPT-5.5	Claude Opus 4.8
SWE-bench Pro	62.1	55.4	58.6	69.2
DeepSWE	46.2	8	70	58
Terminal Bench 2.1 (Terminus-2)	81.0	64	84	85
MCP-Atlas, public set	76.8	73.6	75.3	77.8
Toolathlon	48.2	52.8	55.6	59.9

Source: Z.ai's GLM-5.2 model card as of June 17. Vendor-run; the card gives no harness, sampling settings or number of runs for any row.

Read across, GLM-5.2 trails Claude Opus 4.8 on every row and beats DeepSeek V4 Pro, downloadable under MIT since April 24, on four of the five. Read down, the two coding benchmarks disagree. On SWE-bench Pro, GLM-5.2 is 3.5 points ahead of GPT-5.5. On DeepSWE, GPT-5.5 is 23.8 points ahead.

When two tests of one skill disagree that much, the tasks and harness are doing much of the work. Datacurve's audit last month estimated, using an LLM judge, that SWE-Bench Pro's verifiers rejected correct patches in 24% of the trials it sampled, so I would not treat a 3.5-point lead on that benchmark as settled. Z.ai's repository says to keep the default, max reasoning effort, to reproduce benchmark results, so I read the table as max-effort numbers.

Two details in the card's history matter if you quote it. GLM-5.2's CritPt score changed from 16.7 to 20.9 between the June 16 and June 17 revisions, with no note. And the card lists DeepSeek V4 Pro at 52.8 on Toolathlon, which it calls Tool-Decathlon, while DeepSeek's own card says 51.8. Neither changes the overall picture. Both are reasons to cite the revision you read.

The independent view comes from Artificial Analysis, which on June 16 placed GLM-5.2 first among open-weights models on its Intelligence Index v4.1.

Artificial Analysis, June 16	GLM-5.2	DeepSeek V4 Pro (max)
Intelligence Index v4.1	51	44
Output tokens per index task	43k, of which 37k reasoning	37k
Cost per index task	About $0.46	$0.05
GDPval-AA v2 (Elo)	1,524	1,328

Source: Artificial Analysis, June 16, 2026, independent evaluation. In the same article, MiniMax-M3 ties DeepSeek V4 Pro at 44, and GPT-5.5 at xhigh effort scores 1,514 on GDPval-AA v2.

By my arithmetic, most of that ninefold gap in cost per task is price per token, since the token counts differ by only about a sixth. Artificial Analysis lists Z.ai's own API at $1.40 per million input tokens and $4.40 per million output tokens. Self-hosting removes the price per token and keeps the token count. GLM-5.2 produced the most output per task of the open models compared, and on your own GPUs those tokens are generation time you pay for.

The memory arithmetic for self-hosting GLM-5.2

This section is my arithmetic, from the file sizes, the config and NVIDIA's listed GPU memory. It covers weights and attention cache only; engines also need room for activations and buffers, so treat each figure as a ceiling.

BF16 weights, 1.51 TB. They do not fit on a server of eight H200s at 141 GB each, 1,128 GB in total. A DGX B200, at 1,440 GB, has no room to spare either. At full precision, plan on two servers.
FP8 weights, 756 GB. They do not fit on eight 80 GB H100s, 640 GB in total. On eight H200s they leave about 372 GB.
Attention cache. The config implies a DeepSeek-style compressed cache of 576 values per layer for each token. If the engine stores that in BF16, one full 1,048,576-token sequence needs about 94 GB across 78 layers, and roughly half with an FP8 cache.
Full-length concurrency. On eight H200s with FP8 weights, the 372 GB left over holds three full-length sequences with a BF16 cache, or about seven with FP8, before activations take their share.

So one server can offer a 1M-token context to a handful of sessions at a time. Shorter requests pack far more densely, but if you promise long context, plan capacity for the long sessions, not the average one.

DeepSeek V4 Pro shows that the parameter count is not the memory bill. It has 1.6 trillion parameters, more than twice GLM-5.2's, but DeepSeek released it with FP4 expert weights, and its files total 865 GB. Precision decides the hardware as much as size does.

For teams without NVIDIA hardware, Z.ai updated its Ascend guide for GLM-5.2 on June 17, covering vLLM-Ascend, xLLM and SGLang with a hybrid W8A8 quantisation scheme. The card also lists SGLang, vLLM, KTransformers and Transformers. I have seen no independent throughput figures for any of them.

Self-hosting is a model change, so prove it like one

The usual reasons to self-host a model like this are cost, control and where the data may go. All three are good reasons, and all three tempt teams to switch on the strength of a benchmark table. It is the opposite choice to renting a managed agent runtime: you own every part, including the parts that fail.

In the work behind Auto-RAG and MerlinX, I found that the orchestrator model was 75% of our agent workflow cost. The cheaper orchestrator model was first shown on a frozen evaluation suite, at 95% confidence, to be not worse than the model it replaced; the rollout then cut cost per conversation by 73% across 840 agents with no measurable quality loss. It shipped with a guarded apply and a one-command rollback.

Moving to self-hosted open weights is the same decision with more moving parts. The model changes, and so do the quantisation, the serving engine, the sampling settings and the context limit. I would want the same proof before rollout, on my own suite, with the hosted API kept as the rollback.

Language needs its own check. Auto-RAG went to production for 7 to 10 enterprise customers, including Gulf-region government ministries, and each brought a different corpus, a different language mix and a different tolerance for a wrong answer. GLM-5.2's card lists English and Chinese. Nothing in its table tells you how it handles an Arabic question over a ministry's documents.

What I would test before adopting GLM-5.2

Your harness, your repositories. Run the agent setup you use, several times per task.
FP8 against BF16. If FP8 is what fits, evaluate FP8. Do not borrow the BF16 table.
Quality and memory along the context. Measure answers and cache use at 128K, 512K and 1M tokens on your documents, and count the sessions one server holds.
Effort settings. Compare max and high on tokens per task and quality.
Speculative decoding. Z.ai says its improved MTP layer lengthens acceptance by up to 20%. Measure it on your own traffic.
Answers that are not in the context. Artificial Analysis reports a 28.1% hallucination rate on AA-Omniscience, against 29.4% for GLM-5.1. Run the unanswerable-question test on your own corpus before anyone relies on it.

The weights are free, and the licence asks for little more than a copyright notice. The second server is sold separately.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and model cost and evaluation.