GLM-5: Architecture, Training and Deployment

GLM-5 is Z.ai's (formerly Zhipu AI) Apache 2.0 open-weight family purpose-built for coding, reasoning and long-horizon agentic work. Its architecture descends from the DeepSeek Sparse Attention lineage, is trained with asynchronous reinforcement learning and repo-level code pretraining using real issue-and-pull-request data, and is refined in the GLM-5.2 release with IndexShare, improved multi-token prediction and a one-million-token context window.

Executive summary

GLM-5's design brief is narrower and more deliberate than a general frontier chatbot: it targets software-engineering agents that operate over long horizons — large repositories, many tool calls, extended sessions — rather than optimising primarily for short-form chat quality. Sparse attention (in the DeepSeek Sparse Attention lineage) and IndexShare (GLM-5.2) both target the same problem: keeping long-context computation affordable without discarding retrieval accuracy. Apache 2.0 licensing and open tooling make it one of the more straightforward long-context agent models to adopt.

When to use this page

• Selecting a model specifically for long-horizon, repository-scale coding agents rather than short-form chat.
• Understanding IndexShare and why it matters at million-token context.
• Evaluating repo-level pretraining with real issue/PR data vs generic code-corpus pretraining.
• Pair with DeepSeek for the sparse-attention lineage GLM-5 builds on, Open source models and the AI model landscape.

---

1. What kind of model is GLM-5?

Open-weight (Apache 2.0), decoder-based, sparse-attention Mixture-of-Experts family purpose-built for coding and long-horizon agentic reasoning.

1.1 Apache 2.0 and open tooling

Z.ai releases GLM-5 under Apache 2.0, alongside documentation and tooling (docs.z.ai) aimed specifically at agent-harness integration rather than only chat-completion usage. This "open weights and open tooling" combination is called out explicitly in the wider AI model landscape comparison table as a distinguishing trait of the GLM-5.2 release.

1.2 GLM-5 and GLM-5.2

Release	Notable additions
GLM-5	Sparse attention (DeepSeek Sparse Attention lineage), async RL, repo-level code pretraining
GLM-5.2	Adds IndexShare, improved multi-token prediction (MTP), 1M-token context, on-policy distillation

Treat GLM-5.2 as a refinement of the same architectural family rather than a separate generation — most of what applies to GLM-5's core design (sparse attention, agentic RL, repo-level pretraining) carries forward into 5.2, which layers additional long-context and distillation improvements on top.

1.3 Designed for long-horizon agents specifically

Where a general-purpose chat model is evaluated primarily on single-turn answer quality, GLM-5's training and evaluation emphasis is on sustained, multi-step agentic sessions: exploring an unfamiliar repository, making a sequence of coordinated edits, running and interpreting test output, and continuing to make progress across many tool calls without losing track of earlier context or constraints.

---

2. Model configuration

Component	GLM-5	GLM-5.2
Architecture	Sparse-attention MoE	Sparse-attention MoE
Attention lineage	DeepSeek Sparse Attention lineage	Same lineage + IndexShare
Training	Async RL, repo-level code pretraining	Async RL, repo-level pretraining, on-policy distillation
Context length	Long-context (documented family target)	1,048,576 tokens
Speculative decoding	—	Improved multi-token prediction (MTP)
Licence	Apache 2.0	Apache 2.0

---

3. Architecture

3.1 Sparse attention, DeepSeek Sparse Attention lineage

Full self-attention's roughly quadratic cost in sequence length is the same bottleneck every long-context model in this section addresses differently (Kimi K3's KDA, Qwen 3.5's Gated DeltaNet, Nemotron 3's Mamba-2). GLM-5 addresses it with sparse attention descended from DeepSeek's sparse-attention work: rather than every token attending to every other token, an indexing/selection mechanism identifies which prior tokens are actually relevant for a given query, and full attention is computed only over that reduced candidate set.

This differs philosophically from a purely recurrent/linear-attention approach (Gated DeltaNet, KDA): sparse attention still performs exact attention computation, just over a reduced candidate set, rather than compressing history into a fixed-size recurrent state. The trade-off is different too — sparse attention's cost still depends on how well the indexer selects relevant candidates, while recurrent approaches have a fixed per-step cost regardless of candidate quality.

3.2 IndexShare (GLM-5.2)

At very long context, computing a fresh relevance index for every sparse-attention layer independently is itself expensive. IndexShare reuses a single indexer's output across a group of sparse-attention layers rather than recomputing indexing per layer:

Z.ai reports a substantial reduction in per-token computation at one-million-token length as a result — directly analogous to how KV-cache reuse reduces redundant work in conventional attention, but applied to the indexing step of sparse attention.

3.3 Multi-token prediction improvements (GLM-5.2)

GLM-5.2 refines its MTP component for faster speculative decoding, following the same general pattern used by DeepSeek V3, Kimi K3, Gemma 4 and Nemotron 3: a lightweight draft mechanism proposes multiple future tokens, verified by the main model in one pass, improving decode throughput without changing the final output distribution when verification succeeds.

---

4. Training and post-training

4.1 Repo-level code pretraining with real issue/PR data

Rather than pretraining primarily on isolated code snippets or files, GLM-5's code pretraining incorporates repository-level context and real issue-and-pull-request data: the model is exposed to how actual codebases evolve — an issue is filed, a PR addresses it, review comments request changes, the PR is revised and merged. This is intended to teach the model the process of software engineering (understanding a problem report, scoping a fix, iterating on review feedback) rather than only how to complete a function signature in isolation.

4.2 Asynchronous reinforcement learning

Long-horizon agentic RL rollouts (a coding agent working through a multi-file task across many tool calls) can take far longer to complete than a short reasoning trace, which creates a bottleneck if a training batch must wait for every rollout in it to finish before updating the policy. Asynchronous RL decouples rollout collection from policy updates: completed rollouts contribute to training as they finish, rather than the whole batch stalling on the slowest in-flight trajectory — the same class of problem Kimi K3 addresses with partial rollouts in its long-horizon RL infrastructure.

4.3 On-policy distillation (GLM-5.2)

GLM-5.2 uses on-policy distillation — training data generated in a manner consistent with the model's own current policy rather than only static, pre-collected datasets — reducing the mismatch between the situations a model was trained on and the situations it actually encounters through its own behaviour during deployment or RL rollout.

---

5. Deployment

5.1 Hardware planning

GLM-5's exact published parameter counts vary by checkpoint size; as a sparse-attention MoE model targeting long-horizon agentic work, plan infrastructure the same way as other large MoE models in this section:

• Confirm the specific checkpoint's total and active parameter counts before sizing GPUs.
• Budget separately for the sparse-attention indexer's memory/compute footprint alongside standard KV-cache sizing.
• Start context length well below the 1M ceiling (GLM-5.2) and raise it only after benchmarking.

5.2 Serving engines

Engine	Notes
vLLM	Documented GLM-5 support
SGLang	RadixAttention prefix caching; sparse-attention-aware serving
Z.ai tooling (docs.z.ai)	Agent-harness-oriented documentation and integration guides

5.3 Example: vLLM server

export HF_TOKEN="your-hugging-face-token"

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  vllm/vllm-openai:latest \
  zai-org/GLM-5 \
  --trust-remote-code \
  --tensor-parallel-size 8 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.9 \
  --enable-auto-tool-choice \
  --tool-call-parser glm

5.4 Calling the endpoint for an agentic coding task

from openai import OpenAI

client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")

tools = [
    {
        "type": "function",
        "function": {
            "name": "run_tests",
            "description": "Run the project's test suite",
            "parameters": {
                "type": "object",
                "properties": {"target": {"type": "string"}},
                "required": ["target"],
                "additionalProperties": False,
            },
        },
    }
]

response = client.chat.completions.create(
    model="zai-org/GLM-5",
    messages=[{"role": "user", "content": "Fix the failing test in payments/invoice_test.py and verify."}],
    tools=tools,
    tool_choice="auto",
)

print(response.choices[0].message)

As with every tool-calling model in this section: never execute a returned tool call blindly against privileged infrastructure — validate arguments, enforce allowlists and sandboxing, and return a matching tool message before continuing the conversation.

5.5 Multi-node deployment for extended context

export HEAD_IP="10.0.0.10"
export IFACE_NAME="ib0"
export HF_TOKEN="your-hugging-face-token"

docker run --rm \
  --gpus all \
  --ipc=host \
  --network=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e NCCL_SOCKET_IFNAME="$IFACE_NAME" \
  vllm/vllm-openai:latest \
  zai-org/GLM-5.2 \
  --trust-remote-code \
  --tensor-parallel-size 16 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.9

Even with sparse attention and IndexShare reducing per-token cost at long context, cross-node communication for a large sparse-attention model still benefits from a high-bandwidth interconnect — do not assume sparsity alone removes the need for InfiniBand-class networking at scale.

5.6 GLM-5 vs GLM-5.2 in deployment terms

Consideration	GLM-5	GLM-5.2
Indexing cost at long context	Per-layer indexing	Shared via IndexShare
Practical context ceiling	Long-context, family-documented	1,048,576 tokens
Speculative decoding	Base MTP	Improved MTP
Recommendation	Adequate for shorter agentic sessions	Preferred default for genuinely million-token workloads

Unless a deployment specifically needs the older checkpoint for compatibility reasons, GLM-5.2 is the more efficient choice for any workload approaching very long context.

---

6. Common misconceptions

6.1 "Sparse attention means the model sees less of the context"

The indexer selects which prior tokens receive full attention computation for a given query, but it is trained to identify the relevant subset, not an arbitrary truncation. In principle any position in the context can be selected if the indexer judges it relevant — sparse attention changes computational cost, not the theoretical reach of the model over its context window.

6.2 "IndexShare is the same as KV-cache sharing"

They target different costs. KV-cache sharing (used by Gemma 4, among others) reduces the memory needed to store keys/values across layers. IndexShare reduces the computation needed to decide which tokens are relevant for sparse attention, by reusing one indexing pass across a group of layers rather than recomputing it per layer. Both are efficiency techniques, but at different points in the pipeline.

6.3 "GLM-5 is primarily a chat model that also happens to code"

The training emphasis is inverted from that assumption: repo-level pretraining with real issue/PR data and asynchronous agentic RL are the model's core design investments, with general chat capability as a secondary benefit rather than the primary target. Evaluate GLM-5 first on multi-step coding-agent benchmarks, not general chat leaderboards, before drawing conclusions about its fit for your use case.

6.4 "Async RL means training is less reliable or more noisy"

Asynchronous RL decouples when a completed rollout contributes to training from the batch boundary, avoiding the whole batch stalling on the slowest trajectory — it does not inherently make individual rollout quality or reward signal noisier. The main engineering challenge is correctly handling policy staleness (a rollout collected under a slightly older policy version), which well-designed async RL pipelines account for explicitly.

---

7. Troubleshooting local deployment

7.1 High latency at long context despite sparse attention

Confirm IndexShare (GLM-5.2) is actually enabled in the serving configuration — a fallback to per-layer indexing at million-token context can produce correct output at substantially higher latency than expected, and this regression is easy to miss without directly profiling indexer overhead.

7.2 Agent loses track of earlier repository context mid-session

Check whether the harness is correctly preserving and resending the accumulated context (or relying on server-side prefix caching) across the session — this is an agent-harness integration issue in the majority of cases rather than a model-capability issue, and is worth ruling out before concluding the model itself is the limitation.

7.3 Tool calls malformed or inconsistent

As with every tool-calling model in this section, validate the tool-call parser version matches the deployed GLM-5 checkpoint, and always validate returned arguments against your tool's schema before execution regardless of parser correctness.

7.4 Uneven GPU utilisation in expert-parallel serving

If GLM-5's specific checkpoint uses MoE (verify against the exact model card, since parameter counts vary by release), apply the same expert-load-balance diagnostics recommended for DeepSeek and Kimi K3 — check per-expert load distribution directly rather than assuming balance is automatic.

---

8. Licence

GLM-5 and GLM-5.2 are released under Apache 2.0, the same permissive baseline as Qwen 3.5, Gemma 4, Mistral and GPT-OSS — no field-of-use restriction, no usage-threshold clause. Combined with Z.ai's open tooling, this makes GLM-5 relatively low-friction to adopt for a long-horizon agentic coding use case compared with custom-licensed alternatives such as Llama 4.

---

9. Engineer reading checklist

• Sparse attention (indexer + selective full attention) vs recurrent/linear attention (KDA, Gated DeltaNet)
• IndexShare: amortising indexer cost across a group of sparse-attention layers
• Repo-level pretraining with real issue/PR data vs generic code-file pretraining
• Asynchronous RL: why long-horizon rollouts need decoupled collection and policy updates
• On-policy distillation and why it reduces train/deploy behavioural mismatch
• Sizing infrastructure for a sparse-attention model's indexer overhead, not just its KV cache

---

References

• GitHub: github.com/zai-org/GLM-5
• GLM-5 paper — arXiv:2602.15763
• docs.z.ai — deployment and agent-integration documentation
• Hugging Face: zai-org/GLM-5
• GLM-4.5 Technical Report — arXiv:2508.06471 (architectural lineage)

Key takeaways

• GLM-5 is purpose-built for long-horizon coding agents, not primarily short-form chat — evaluate it on multi-step task completion, not single-turn benchmarks alone.
• Sparse attention with IndexShare (GLM-5.2) amortises indexing cost across layers to make million-token context more affordable.
• Repo-level pretraining with real issue/PR data and asynchronous RL both target realistic software-engineering workflows.
• Apache 2.0 plus open agent-harness tooling lowers adoption friction relative to custom-licensed alternatives.

What to do next

Read DeepSeek for the sparse-attention lineage GLM-5 builds on, browse Open source models, or return to the AI model landscape for long-horizon agent selection guidance.