AI Infra Interviews logo

GLM / MoE

GLM-5.1

Longer agent runs need process-level evaluation

Release noteSources checked 2026-09-13

GLM-5.1 is an upgrade candidate for a GLM-5 service whose difficult cases involve sustained engineering tasks. Evaluate progress, failed tools and recovery over a complete run, rather than only final-answer benchmarks.

744Breported total parameters
40Bactive parameters per token
202,752configured token positions

Approximate 744B total / 40B active, as reported in the model-specific vLLM guide; not an exact tensor inventory.

Evaluate it for

Long coding and engineering workflows with recorded tool traces and acceptance tests.

Choose another path when

Treating a publisher’s maximum autonomous-run duration as a reliability guarantee.

Release context

Why this release matters

The release focuses on planning and iterative refinement. The vLLM guide reports the same approximate 744B/40B size class, so deployment scale remains substantial even when post-training changes task behavior.

This is the dated Z.ai release-note event; a separate first weight-upload day has not been certified.

Release evidence · Follow the GLM timeline →

Deployment starting points

Which hardware, how many, at what precision?

Start with an exact artifact and an engine that supports it. A configuration below is evidence of a documented path; its device count does not promise a particular throughput or concurrency.

1,507.73 GB of tensor data in the pinned index

This is the index’s reported tensor payload, in decimal GB. It excludes file headers and runtime memory. Mixed precision, conversion and host/device placement determine how much GPU memory the loaded model needs.

Inspect the exact index metadata →
Capacity screen: would the weights fit?

This estimates inference memory for a hypothetical uniform precision. It is useful for rejecting an allocation that is too small. It does not establish a working deployment or estimate training memory.

Weights only, before requests or runtime buffers. These formats are mathematical scenarios, not claims that each artifact exists.
RepresentationApproximate weight floorWhat remains to budget
16-bit uniform1,488 GBCache, modality state, workspace, quantization metadata and uneven sharding
8-bit uniform744 GBCache, modality state, workspace, quantization metadata and uneven sharding
4-bit uniform372 GBCache, modality state, workspace, quantization metadata and uneven sharding

Enter the total across the whole model replica, not per GPU: KV or recurrent cache for all concurrent requests, image/audio state and execution workspace. There is no universal default. We additionally leave 15% of each GPU unused.

1,488 GB for hypothetical weights

Enter a request-and-buffer budget to calculate the aggregate capacity requirement.

A count of one does not prove the engine supports this GPU. A count above one does not prove the model shards evenly or communicates efficiently. Approximate 744B total / 40B active, as reported in the model-specific vLLM guide; not an exact tensor inventory.

Inspect the GPU and its interconnect →

Architecture in practice

What the serving engine has to do

Store the history. Read the selected parts.

Retained KV historyall state required by the modelIndex / selectionfind relevant blocksSelected KV blocksa subset of the retained historyAttention outputcomputed from selected reads

Fewer bytes read can reduce bandwidth pressure.

That does not prove an equal reduction in stored bytes.

Schematic of block-sparse attention. The indexer selects relevant blocks; attention reads those blocks from retained state. Index sharing can reuse selection work across layers. Read traffic, index work and allocated KV capacity are separate quantities.

Mechanism schematic based on the pinned model card and configuration. It explains a design principle; it is not a full implementation graph.

Inspect the full checkpoint specifications
Inspected fields for this exact revision. KV heads alone do not describe latent, hybrid or shared-cache layouts.
Exact checkpointzai-org/GLM-5.1
Text model typeglm_moe_dsa
Layers78
Hidden width6,144
Attention / KV heads64 / 64
Head dimension64
Routed / selected experts256 / 8
Configured positions202,752
Documented extensionNot recorded for this checkpoint
Inputs → outputtext → text
License metadatamit

Open weights do not imply unrestricted use. Read the applicable license terms linked from the pinned card.

A useful comparison

What else belongs on the shortlist?

The predecessor is the controlled baseline; 5.2 adds the long-context attention development.

12 Feb 2026

GLM-5

A large sparse-attention foundation for the GLM line

744B reported total · text

16 Jun 2026

GLM-5.2

A million-token setting backed by index sharing

743B reported total · text

These are editorial comparison candidates. We have not run a matched quality or serving benchmark, so this is not a ranking.

Prepare to explain it

The interview lesson

Explain a harness that records successful tasks, retries, wall-clock time and total output tokens; then state the stop conditions.

Attention layouts · Quantization · Courses and worked examples

For a deployment evaluation, record exact weights, precision, engine, device count, interconnect, prompt/output lengths and concurrency. Report task success, errors, TTFT, TPOT and useful throughput together.

Sources and citation

Our assessment is editorial judgment based on the linked architecture and deployment evidence. Model facts are publisher-reported or attributed to runtime maintainers; no independent GPU benchmark was run.

AI Infra Interviews, “GLM-5.1: release, architecture and deployment”, checked 2026-09-13. Preserve this date and the exact checkpoint when citing.

Model and research notes as JSON · Z.ai profile