我们推出 GLM-5.2，这是我们面向长时程任务的最新旗舰模型。相比前代 GLM-5.1，它在长时程任务能力上实现了大幅跃升，并且首次在
扎实的 1M token 上下文
上实现了这一能力。GLM-5.2 的新增能力包括：
- 扎实的 1M 上下文：扎实的 1M token 上下文，可稳定支撑长时程工作
- 具备灵活思考强度的先进编程能力：更强的编程能力，提供多档思考强度，以平衡性能与延迟
- 改进的架构：我们提出 IndexShare，它在每四个稀疏注意力层之间复用同一个索引器，在 1M 上下文长度下将每 token FLOPs 降低 2.9×。我们还改进了 GLM-5.2 用于投机解码的 MTP 层，将接受长度提升最多 20%
- 纯开放：采用 MIT 开源许可证——无地域限制，技术获取无国界
要支持长时程任务，首先要让长上下文在工程上真正可用：模型必须在漫长而杂乱的编码智能体轨迹中保持质量，而不只是能接受更多 token。1M 上下文说起来容易，但在真实工程压力下保持可靠要难得多。为此，我们大幅扩展了面向编码智能体场景的 1M 上下文训练，覆盖大规模实现、自动化研究、性能优化和复杂调试。最终得到的是一套长上下文系统，不仅覆盖面广，执行也扎实：它是支撑持续工程工作的实用基础。
这一能力体现在 GLM-5.2 在三个长时程编码基准上的表现。FrontierSWE 衡量的是智能体能否完成从数小时到数十小时规模的开放式技术项目，涵盖系统优化、大规模代码构建和应用 ML 研究。在该基准上，GLM-5.2 仅落后 Opus 4.8 1%，同时以 1% 的优势超过 GPT-5.5，并以 11% 的优势超过 Opus 4.7。在 PostTrainBench 上，每个智能体都会获得一块 H100 GPU，并根据其通过后训练能将小模型提升多少来评估，GLM-5.2 的表现优于 Opus 4.7 和 GPT-5.5，仅次于 Opus 4.8，排名第二。在 SWE-Marathon 上，这是一个超长时程软件工程基准，涵盖构建编译器、优化 kernel 和开发生产级服务等任务，GLM-5.2 仍有提升空间，落后 Opus 4.8 13%，但仍仅次于 Opus 系列，排名第二。在这三个基准上，GLM-5.2 都是排名最高的开源模型，表明其 1M 上下文已经转化为实际的长时程交付能力。
在标准编程基准测试中，GLM-5.2 是最强的开源模型，相比 GLM-5.1 有大幅提升：在 Terminal-Bench 2.1 上为 81.0 对 63.5，在 SWE-bench Pro 上为 62.1 对 58.4。它还大幅缩小了与闭源前沿模型的差距——在 Terminal-Bench 2.1（81.0）上，它与 Claude Opus 4.8（85.0）仅相差几个点——同时保持领先于 Gemini 3.1 Pro。
GLM-5.2 还引入了 effort level 控制，使用户能够显式地在模型能力与任务执行速度和计算成本之间进行权衡。如图所示，在相近的 token 预算下，GLM-5.2 的智能体编程性能显著强于 GLM-5.1，在相似的 token 消耗下，其能力大致介于 Claude Opus 4.7 和 Claude Opus 4.8 之间。
此外，Max effort level 允许用户在具有挑战性的任务中需要更高性能时分配额外的计算量，进一步扩展模型的编程能力。这一设计让用户在使用 GLM-5.2 进行编程任务时拥有更大的灵活性，能够针对不同场景选择最合适的推理模式。
面向 1M 上下文的架构
用于 DSA 的 IndexShare
为了支持 1M 上下文长度，在 GLM-5.2 中，我们应用了 IndexShare 来降低 DSA 中索引器的计算开销。具体而言，在 GLM-5.2 中，每 4 个 transformer 层共享一个轻量级索引器。该索引器被放置在这 4 层中的第一层，其 topk 索引被这 4 层共同使用。这样就将索引器点积和 topk 操作的计算量在 3/4 的层中减少了。GLM-5.2 从中期训练阶段起、以 128K 序列长度采用 IndexShare 进行训练，在长上下文基准测试上以更少的计算量超越了 GLM-5.1。
结合 IndexShare 与 KVShare 的 MTP
我们针对投机解码改进了 GLM-5.2 的 MTP 层，目标有二：1）最小化 MTP 层作为草稿模型的开销；2）最大化投机解码的接受率。
针对第一个目标，我们同样在 mtp 层上应用了 IndexShare。在多步 MTP 中，索引器被放置于第一步，其 topk 索引被后续所有步骤共用。然而，与主干网络不同，不同 mtp 步骤的输入 token 是不同的。
如下图所示，如果我们把 $h_4$ 的 topk 索引复用于 $h_5$，那么 $h_5$ 只能关注 $h_1$ 到 $h_4$，而无法关注 $h_5$。我们将展示，这一特性可以帮助我们实现第二个目标，即消除 GLM-5.1 的 mtp 层中训练与推理之间的差异。
在上图中，我们展示了一个两步 MTP 层的推理过程。在第一步中，推理与训练一致，所有隐藏状态都来自目标模型。然而，在第二步中，$h_{1:4}$ 来自目标模型，而 $h_5$ 来自 mtp 层。因此，$h_5$ 的 KV cache 是由目标模型计算得到的 $kv_{1:4}$ 与由 mtp 层计算得到的 $kv_5$ 的混合。相反，使用 IndexShare 时，$h_5$ 的 KV cache 仅包含 $kv_{1:4}$，全部来自目标模型的隐藏状态。在训练方面，我们复用了第一个 mtp 步骤的 kv cache 和 topk 索引。注意，与 GLM-5.1 相同，不同 MTP 步骤的参数也是共享的。此外，受 https://arxiv.org/abs/2606.12370 的启发，我们为投机解码引入了拒绝采样，并使用端到端 TV loss 进行训练。
下表展示了在编码场景下各技术按接受长度进行的消融实验。在实验中，我们使用 GLM-5.1 的主干和训练数据。MTP 步骤数在训练和推理中均设为 7。与基线相比，最终 MTP 层的接受长度提升了 20%。
| 方法 | 接受长度 |
|---|---|
| 基线 | 4.56 |
| + IndexShare + KV Share | 5.10 |
| + 拒绝采样 | 5.29 |
| + 端到端 TV Loss | 5.47（+20%） |
高效服务 1M 上下文长度
随着 GLM-5.2 将最大上下文长度从 200K 扩展到 1M tokens，编码类工作负载预计将大幅转向更长的提示词。这使得主要的推理瓶颈从计算转移到 KV-cache 容量、长上下文 kernel 开销以及 CPU 侧开销。
尽管新的 GLM-5.2 架构降低了每 token 的计算 FLOPs，但并未按比例降低每 token 的 KV-cache 大小。因此，在有限的 GPU 资源下支持更长的上下文、更高的并发以及更高的 token 吞吐量，成为推理引擎优化的核心挑战。
为应对这一挑战，我们从三个方向优化推理引擎。首先，在 LayerSplit 的基础上，我们引入更细粒度的内存管理和并行化策略，以提升 KV-cache 容量，为超长上下文请求提供更多可用的缓存空间。其次，我们优化那些开销随上下文长度增长的 kernel，并使其与缓存传输流水线更好地协同，最大限度降低缓存传输对 prefill 和 decode 性能的影响。
第三，我们优化 CPU 侧的缓存管理、请求调度和运行时执行路径，以减少 GPU 执行流水线中的气泡，提升端到端吞吐量。如图所示，随着上下文长度增长，GLM-5.2 的吞吐量优势越来越大，展现出在长上下文推理场景中更强的可扩展性。
用于智能体强化学习的 slime
GLM-5.2 的智能体强化学习后训练涉及更大规模、更多领域以及更复杂执行模式的任务。异构数据和任务需要在统一的训练流程中组织起来，而长时程交互、工具使用、子任务分解以及多轮环境反馈都对 rollout 与训练编排提出了更高的要求。
为支撑这一过程，slime 作为从训练到大规模推理 rollout 的一体化基础设施层，支持多种训练与任务组织模式，包括白盒 rollout、黑盒 rollout、紧凑轨迹以及子智能体工作流，使同一系统能够扩展到更大、更复杂的 RL 与 OPD 训练负载。
在 GLM-5.2 的后训练过程中，我们使用 slime 框架进行并行 OPD 训练，高效地将十多个专家模型合并为最终模型。整个 OPD 训练过程耗时约两天，展现出很高的训练效率。
智能体强化学习还对系统资源和推理基础设施提出了更高的要求。slime 为推理系统提供了高度开放且灵活的接口：训练侧可以以不同形式接入推理服务，并灵活适配不同的并行策略、路由策略、PD 分离部署方案以及部署模式。与此同时，在 RL rollout 过程中积累的配置经验、调度策略和优化路径，可以在生产服务阶段复用并进一步打磨，使训练侧与服务侧相互促进。
这为从后训练到生产部署打通了一条更直接的路径。结合灵活的训练-推理资源组织方式与 KV-cache FP8，slime 为 GLM-5.2 的大规模智能体强化学习训练提供了关键的基础设施支撑，进一步提升了系统效率、rollout 吞吐量以及大规模推理并发能力。
面向长时程任务的强化学习与防作弊
面向长时程任务的强化学习。对于 GLM-5.2 而言，长时程任务会产生显著更长的执行轨迹，而一旦超长轨迹被压缩（compaction）拆分为多条子轨迹，同一提示词下的不同 rollout 会产生数量不同、长度差异极大的可训练轨迹。因此，我们从组内优化转向基于 critic 的 PPO 形式，从单条 rollout 中学习，依靠 critic 来估计 token 级优势，而非组内相对比较。这种单条 rollout 的形式天然契合压缩机制，因为它对一条提示词产生多少条轨迹、以及这些轨迹的相对长度都不施加约束：我们通过将所有压缩后的子轨迹作为可训练轨迹纳入训练，把压缩引入训练流程，并施加 token 级损失以应对它们之间的长度不均衡。
编码智能体中的反作弊。编码强化学习尤其容易受到奖励作弊的影响，因为奖励通常是一个可验证的通过/失败信号。我们发现 GLM-5.2 表现出比 GLM-5.1 更多的潜在作弊行为。这使得验证信号容易被优化，但实际上无法提升模型的根本能力。智能体可以读取受保护的评估产物，从参考内容或上游提交中复制答案内容，或在 GitHub 相关任务中直接获取目标源代码。例如，智能体可能通过 curl https://raw.githubusercontent.com/<path-to-file> 下载解答，甚至出现链式泄露，如
1. find /workspace -name "*hidden*"
2. cat /workspace/.eval/secret_cases.json
3. python solve.py --case "$(cat /workspace/.eval/secret_cases.json)"
这些行为会虚高奖励并污染训练信号，因此需要一种清晰的机制来区分真正的任务求解与走捷径。为解决这一问题，我们为强化学习训练和评估引入了一个反作弊模块。检测过程分为两个阶段：首先由基于规则的过滤器捕获潜在作弊行为以最大化召回率，然后由 LLM 裁判检查这些被标记动作的意图以保持高精确率。
我们采用一种在线策略，在每一步监控工具调用。如果检测到作弊，系统会阻止该调用并返回虚假信息作为结果。重要的是，这种在线防护允许模型在被捕获作弊动作后仍能继续 rollout。通过处理特定的无效行为而非拒绝整个轨迹，这种方法有助于防止 rollout 被突然中止时可能出现的训练不稳定和模型崩溃。
完整基准测试表
| 基准测试 | GLM-5.2 | GLM-5.1 | Qwen3.7-Max | MiniMax M3 | DeepSeek-V4-Pro | Claude Opus 4.8 | GPT-5.5 | Gemini 3.1 Pro |
|---|---|---|---|---|---|---|---|---|
| 推理 | ||||||||
| HLE | 40.5 | 31 | 41.4 | 37 | 37.7 | 49.8* | 41.4* | 45 |
| HLE（带工具） | 54.7 | 52.3 | 53.5 | - | 48.2 | 57.9* | 52.2* | 51.4* |
| CritPt | 16.7 | 4.6 | 13.4 | 3.7 | 12.9 | 20.9 | 27.1 | 17.7 |
| AIME 2026 | 99.2 | 95.3 | 97 | - | 94.6 | 95.7 | 98.3 | 98.2 |
| HMMT 2025 年 11 月 | 94.4 | 94 | 95 | 84.4 | 94.4 | 96.5 | 96.5 | 94.8 |
| HMMT 2026 年 2 月 | 92.5 | 82.6 | 97.1 | 84.4 | 95.2 | 96.7 | 96.7 | 87.3 |
| IMOAnswerBench | 91.0 | 83.8 | 90 | - | 89.8 | 83.5 | - | 81 |
| GPQA-Diamond | 91.2 | 86.2 | 90 | 93 | 90.1 | 93.6 | 93.6 | 94.3 |
| 编程 | ||||||||
| SWE-bench Pro | 62.1 | 58.4 | 60.6 | 59 | 55.4 | 69.2 | 58.6 | 54.2 |
| NL2Repo | 48.9 | 42.7 | 47.2 | 42.1 | 35.5 | 69.7 | 50.7 | 33.4 |
| DeepSWE | 46.2 | 18 | 18 | 20 | 8 | 58 | 70 | 10 |
| ProgramBench | 63.7 | 50.9 | - | - | 47.8 | 71.9 | 70.8 | 39.5 |
| Terminal Bench 2.1（Terminus-2） | 81.0 | 63.5 | 75 | 65 | 64 | 85 | 84 | 74 |
| Terminal Bench 2.1（最佳公开报告测试框架） | 82.7 | 69 | - | - | - | 78.9 | 83.4 | 70.7 |
| FrontierSWE（Dominance） | 74.4 | 30.5 | - | - | 29.0 | 75.1 | 72.6 | 39.6 |
| PostTrainBench | 34.3 | 20.1 | - | - | - | 37.2 | 28.4 | 21.6 |
| SWE-Marathon | 13.0 | 1.0 | - | - | - | 26.0 | 12.0 | 4.0 |
| Agentic | ||||||||
| MCP-Atlas（公开集） | 76.8 | 71.8 | 76.4 | 74.2 | 73.6 | 77.8 | 75.3 | 69.2 |
| Tool-Decathlon | 48.2 | 40.7 | - | - | 52.8 | 59.9 | 55.6 | 48.8 |
GLM-5.2 上手指南
通过 GLM Coding Plan 使用 GLM-5.2
在你常用的编程智能体中试用 GLM-5.2——ZCode、Claude Code、OpenCode 等。https://docs.z.ai/devpack/overview
致 GLM Coding Plan 订阅用户： 我们已向所有 Coding Plan 用户推送 GLM-5.2。你现在即可启用 GLM-5.2，只需将模型名称更新为 "GLM-5.2"（或在 Claude Code 中使用 GLM-5.2[1m] 以启用 1M 上下文长度）。你还可以根据任务选择不同的 思考强度，High 或 Max。作为我们能力最强的模型，GLM-5.2 在高峰时段按 3× 消耗配额，非高峰时段按 2× 消耗。作为截至九月底的限时促销，非高峰时段用量按 1× 计费。（高峰时段为每日 UTC+8（北京时间）14:00–18:00）。
更喜欢图形界面？我们提供 ZCode——一款由 GLM-5.2 驱动的桌面智能体，具备用于长周期任务的 /goal、SSH 远程开发和移动端控制。特别优惠：在 ZCode 内通过 Coding Plan 使用 GLM-5.2，即可在 6 月 30 日前获得 1.5 倍有效配额。
在 Z.ai 上与 GLM-5.2 对话
GLM-5.2 现已在 Z.ai 上线。
在本地部署 GLM-5.2
GLM-5.2 的模型权重已在 HuggingFace 和 ModelScope 上公开提供。对于本地部署，GLM-5.2 支持包括 transformers、vLLM、SGLang、xLLM、ktransformers 在内的推理框架。
脚注
- Humanity's Last Exam（HLE）及其他推理任务：我们使用
temperature=1.0、top_p=0.95的采样参数进行评估。评估时最大生成长度为163,840tokens。默认情况下，我们报告纯文本子集；标有 * 的结果来自完整集合。对于 AIME、HMMT 和 IMOAnswerBench，我们使用以下系统提示词对每道题进行评估：Your response should be in the following format:\nExplanation: {your explanation for your final answer}\nExact Answer: {your succinct, final answer}\nConfidence: {your confidence score between 0% and 100% for your answer}.我们使用 GPT-5.5（medium）作为评判模型。对于 HLE-with-tools，我们使用 300,000 tokens 的最大上下文长度，不采用任何上下文管理策略。 - SWE-Bench Pro：我们使用 OpenHands 运行 SWE-Bench Pro 套件，并采用定制化的指令提示词。设置：
temperature=1、top_p=1、max_new_tokens=32k，上下文窗口为 400K。 - NL2Repo：我们在 400k 上下文下使用
temperature=1.0、top_p=1.0和max_new_tokens=48k对 NL2Repo 进行了评估。为防止作弊，我们使用基于规则和基于 LLM 的判定来防止恶意行为（例如未经授权的 pip 或 curl 操作）。 - DeepSWE：我们使用官方 pier 评估框架和 mini-swe-agent harness（
temperature=1.0、top_p=1.0、timeout=2h，400K 上下文）运行 DeepSWE。每个任务在隔离容器中解决，配备 2 个 CPU、8 GB RAM，且无互联网访问。 - ProgramBench：我们使用 Claude-Code 2.1.156 对 ProgramBench（200 个实例）进行评估，采用
temperature=1.0, top_p=1.0, max_tokens=64000, max_turns=2000, sample_timeout=6h, reasoning_effort=max，上下文窗口为 400K。每个实例在（4 个 CPU、8 GB RAM）沙箱中运行，互联网访问已禁用。 - Terminal-Bench 2.1（Terminus 2）：我们使用 Terminus-2 框架评估 Terminal-Bench 2.1，采用
parser=json、timeout=4h、temperature=1.0、top_p=1.0、max_new_tokens=48k、max_episodes=500，上下文窗口为 256K。资源限制上限为 4 个 CPU 和 8 GB RAM。 - Terminal-Bench 2.1（Claude Code）：我们在 Claude Code 2.1.167 中使用
temperature=1.0, top_p=0.95, max_new_tokens=131072进行评估。我们通过透明代理将 max_new_tokens 覆盖为 128k，绕过 CLI 的 64k 上限，以恢复CLAUDE_CODE_MAX_OUTPUT_TOKENS的可配置性。我们移除了挂钟时间限制，同时保留每个任务的 CPU 和内存约束。分数为 5 次运行的平均值。 - MCP-Atlas：所有模型均在 think 模式下，在 500 个任务的公开子集上进行评估，每个任务超时时间为 10 分钟。我们使用 Gemini-3.0-Pro 作为评估的评判模型。
- Tool-Decathlon：我们使用官方评估服务，并将 max_token 设置为 128K。
- FrontierSWE：评估由 Proximal 进行，上下文长度为 1M，努力程度为最高级别，最大输出 token 为 128K。Dominance 分数报告截至 2026/06/16。
- PostTrainBench：评估由 PostTrainBench 进行，上下文长度为 1M，努力程度为最高级别，最大输出 token 为 128K。
- SWE-Marathon：该评估由 Abundant AI 进行，使用 1M 上下文长度、最高努力级别以及 128K 最大输出 token。
We're introducing GLM-5.2, our latest flagship model for long-horizon tasks. It marks a substantial leap in long-horizon task capability over its predecessor GLM-5.1 and, for the first time, delivers that capability on a
solid 1M-token context
. GLM-5.2's new capabilities include:
- Solid 1M Context: A solid 1M-token context that stably sustains long-horizon work
- Advanced Coding with Flexible Effort: Stronger coding capabilities with multiple thinking effort levels to balance performance and latency
- Improved Architecture: We propose IndexShare, which reuses the same indexer across every four sparse attention layers, reducing per-token FLOPs by 2.9× at a 1M context length. We also improve GLM-5.2’s MTP layer for speculative decoding, increasing the acceptance length by up to 20%
- Pure Open: An MIT open-source license — no regional limits, technical access without borders
Supporting long-horizon tasks starts with making long context engineering-usable: the model must maintain quality across long, messy coding-agent trajectories, not just accept more tokens. A 1M context is easy to claim, but much harder to keep reliable under real engineering pressure. To this end, we substantially expanded 1M-context training for coding-agent scenarios, covering large-scale implementation, automated research, performance optimization, and complex debugging. The result is a long-context system that is not only wide in scope, but solid in execution: a practical substrate for sustained engineering work.
This capability is reflected in GLM-5.2's performance on three long-horizon coding benchmarks. FrontierSWE measures whether an agent can complete open-ended technical projects at the scale of hours to tens of hours, spanning systems optimization, large-scale code construction, and applied ML research. On this benchmark, GLM-5.2 trails Opus 4.8 by only 1%, while edging out GPT-5.5 by 1% and Opus 4.7 by 11%. On PostTrainBench, where each agent is given an H100 GPU and evaluated by how much it can improve small models through post-training, GLM-5.2 outperforms both Opus 4.7 and GPT-5.5, ranking second only to Opus 4.8. On SWE-Marathon, an ultra-long-horizon software engineering benchmark covering tasks such as building compilers, optimizing kernels, and developing production-grade services, GLM-5.2 still has room to grow, trailing Opus 4.8 by 13% while remaining second only to the Opus series. Across all three benchmarks, GLM-5.2 is the highest-ranked open-source model, showing that its 1M context has translated into practical long-horizon delivery capability.
On standard coding benchmarks, GLM-5.2 is the strongest open-source model, improving on GLM-5.1 by a wide margin: 81.0 vs. 63.5 on Terminal-Bench 2.1 and 62.1 vs. 58.4 on SWE-bench Pro. It also closes much of the gap to the closed-source frontier — on Terminal-Bench 2.1 (81.0) it lands within a few points of Claude Opus 4.8 (85.0) — while staying ahead of Gemini 3.1 Pro.
GLM-5.2 also introduces effort level control, enabling users to explicitly balance model capability against task execution speed and computational cost. As shown in the figure, GLM-5.2 delivers substantially stronger agentic coding performance than GLM-5.1 at comparable token budgets, with its capability roughly positioned between Claude Opus 4.7 and Claude Opus 4.8 under similar token consumption. Moreover, the Max effort level allows users to allocate additional computation when higher performance is required in challenging tasks, further extending the model’s coding capability. This design gives users greater flexibility when using GLM-5.2 for coding tasks, allowing them to select the most suitable reasoning mode for different scenarios.
Architecture for 1M Context
IndexShare for DSA
To support 1M context length, in GLM-5.2, we apply IndexShare to reduce the computational cost of the indexer in DSA. Specifically, in GLM-5.2, every 4 transformer layers share a lightweight indexer. The indexer is placed at the first of 4 layers and topk indices are used for 4 layers. This reduces the computation of indexer dot product and topk operation in 3/4 layers. GLM-5.2 is trained with IndexShare from mid-training with 128K sequence length, outperforming GLM-5.1 on long-context benchmarks with less computation.
MTP with IndexShare and KVShare
We improve the MTP layer of GLM-5.2 for speculative decoding with two objectives: 1) Minimize the cost of the MTP layer as draft model; 2) Maximize the acceptance rate of speculative decoding.
For the first objective, we also apply IndexShare on the mtp layer. In multi-step MTP, the indexer is placed on the first step and topk indices are used for all the following steps. However, different from the backbone, the input tokens of different mtp steps are different. As the following figure shows, if we reuse the topk indices of $h_4$ for $h_5$, $h_5$ can only attend to $h_1$ to $h_4$, but not $h_5$. We will show that the property can help us achieve the second objective, by eliminating the training-inference discrepancy in GLM-5.1's mtp layer.
In the above figure we show the inference of a two-step MTP layer. In the first step, inference is consistent with training, with all the hidden states coming from the target model. However, in the second step, $h_{1:4}$ come from the target model and $h_5$ comes from the mtp layer. Therefore, the KV cache of $h_5$ is a mixture of $kv_{1:4}$ computed from the target model and $kv_5$ computed from the mtp layer. Instead, with IndexShare, the KV cache of $h_5$ includes only $kv_{1:4}$, all from the hidden states of the target model. For training, we reuse both kv cache and topk indices of the first mtp step. Note that the same as GLM-5.1, the parameters of different MTP steps are also shared. Furthermore, inspired by https://arxiv.org/abs/2606.12370, we introduce rejection sampling for speculative decoding, and use end-to-end TV loss for training.
The table below shows the ablation of techniques by acceptance length on the coding scenarios. In the experiment we use the backbone and training data of GLM-5.1. The number of MTP steps is set to 7 for both training and inference. Compared with the baseline, the acceptance length of the final MTP layer increases by 20%.
| Method | Acceptance Length |
|---|---|
| Baseline | 4.56 |
| + IndexShare + KV Share | 5.10 |
| + Rejection Sampling | 5.29 |
| + End-to-end TV Loss | 5.47 (+20%) |
Efficiently Serving 1M Context Length
As GLM-5.2 extends the maximum context length from 200K to 1M tokens, coding workloads are expected to shift substantially toward longer prompts. This shifts the primary inference bottleneck from computation to KV-cache capacity, long-context kernel overhead, and CPU-side overhead. Although the new GLM-5.2 architecture reduces per-token computational FLOPs, it does not proportionally reduce per-token KV-cache size. As a result, supporting longer contexts, higher concurrency, and higher token throughput under limited GPU resources becomes a central challenge for inference engine optimization.
To address this challenge, we optimize the inference engine along three directions. First, building on LayerSplit, we introduce finer-grained memory management and parallelization strategies to increase KV-cache capacity and provide more usable cache space for ultra-long-context requests. Second, we optimize kernels whose cost grows with context length and better coordinate them with the cache transfer pipeline, minimizing the impact of cache transfer on both prefill and decode performance. Third, we optimize CPU-side cache management, request scheduling, and runtime execution paths to reduce bubbles in the GPU execution pipeline and improve end-to-end throughput. As shown in the figure, GLM-5.2 achieves an increasingly larger throughput advantage as context length grows, demonstrating stronger scalability in long-context inference scenarios.
slime for Agentic RL
The agentic RL post-training of GLM-5.2 involves tasks at larger scale, across more domains, and with more complex execution patterns. Heterogeneous data and tasks need to be organized within a unified training process, while long-horizon interactions, tool use, sub-task decomposition, and multi-turn environment feedback all impose higher requirements on rollout and training orchestration. To support this process, slime serves as an integrated infrastructure layer from training to large-scale inference rollout. It supports multiple training and task organization modes, including white-box rollout, black-box rollout, compact trajectory, and sub-agent workflow, enabling the same system to scale to larger and more complex RL and OPD training workloads. In the post-training process of GLM-5.2, we used the slime framework to conduct parallel OPD training, efficiently merging more than ten expert models into the final model. The entire OPD training process took approximately two days, demonstrating high training efficiency.
Agentic RL also places higher demands on system resources and inference infrastructure. slime provides a highly open and flexible interface to inference systems: the training side can connect to inference services in different forms, and flexibly adapt to different parallelism strategies, routing policies, PD disaggregation setups, and deployment patterns. At the same time, the configuration experience, scheduling strategies, and optimization paths accumulated during RL rollout can be reused and further refined in the production serving stage, allowing the training side and the serving side to reinforce each other. This creates a more direct path from post-training to production deployment. Together with flexible training-inference resource organization and KV-cache FP8, slime provides critical infrastructure support for GLM-5.2’s large-scale agentic RL training, further improving system efficiency, rollout throughput, and large-scale inference concurrency.
RL for Long-Horizon Task with Anti-hacking
RL for Long-Horizon Tasks. For GLM-5.2, long-horizon tasks produce substantially longer execution traces, and once a super-long trajectory is split by compaction into multiple sub-traces, different rollouts under the same prompt yield different numbers of trainable traces with highly variable lengths. We therefore move from group-wise optimization to a critic-based PPO formulation that learns from individual rollouts, relying on a critic to estimate token-level advantages rather than group-relative comparisons. This single-rollout formulation fits compaction naturally, as it places no constraint on how many traces a prompt produces or on their relative lengths: we bring compaction into training by including all compacted sub-traces as trainable trajectories, and apply a token-level loss to address their length imbalance.
Anti-Hack in Coding agents. Coding RL is especially vulnerable to reward hacking because the reward is typically a verifiable pass/fail signal. We find that GLM-5.2 shows more potential hacking behavior than GLM-5.1. This makes the verification signal easy to optimize, but fails to actually improve the fundamental capabilities of the model. An agent can read protected evaluation artifacts, copy answer content from references or upstream commits, or directly fetch the target source in GitHub-related tasks. For example, the agent may download solution via curl https://raw.githubusercontent.com/<path-to-file> or even chained leakage like
1. find /workspace -name "*hidden*"
2. cat /workspace/.eval/secret_cases.json
3. python solve.py --case "$(cat /workspace/.eval/secret_cases.json)"
These behaviors inflate rewards and corrupt the training signal, requiring a clear mechanism to separate real task-solving from shortcuts. To address this, we introduce an anti-hack module for both RL training and evaluation. The detection process has two stages: a rule-based filter first catches potential hacks to maximize recall, and then an LLM judge checks the intent of these flagged actions to keep precision high. We use an online strategy that monitors the tool calls at each step. If a hack is detected, the system blocks the call and returns dummy information as the result. Importantly, this online guard allows the model to continue the rollout even after a hacked action is caught. By handling the specific invalid behavior instead of rejecting the entire trajectory, this approach helps prevent the training instability and model collapse that can happen when rollouts are abruptly stopped.
Full Benchmark Table
| Benchmark | GLM-5.2 | GLM-5.1 | Qwen3.7-Max | MiniMax M3 | DeepSeek-V4-Pro | Claude Opus 4.8 | GPT-5.5 | Gemini 3.1 Pro |
|---|---|---|---|---|---|---|---|---|
| Reasoning | ||||||||
| HLE | 40.5 | 31 | 41.4 | 37 | 37.7 | 49.8* | 41.4* | 45 |
| HLE (w/ Tools) | 54.7 | 52.3 | 53.5 | - | 48.2 | 57.9* | 52.2* | 51.4* |
| CritPt | 16.7 | 4.6 | 13.4 | 3.7 | 12.9 | 20.9 | 27.1 | 17.7 |
| AIME 2026 | 99.2 | 95.3 | 97 | - | 94.6 | 95.7 | 98.3 | 98.2 |
| HMMT Nov. 2025 | 94.4 | 94 | 95 | 84.4 | 94.4 | 96.5 | 96.5 | 94.8 |
| HMMT Feb. 2026 | 92.5 | 82.6 | 97.1 | 84.4 | 95.2 | 96.7 | 96.7 | 87.3 |
| IMOAnswerBench | 91.0 | 83.8 | 90 | - | 89.8 | 83.5 | - | 81 |
| GPQA-Diamond | 91.2 | 86.2 | 90 | 93 | 90.1 | 93.6 | 93.6 | 94.3 |
| Coding | ||||||||
| SWE-bench Pro | 62.1 | 58.4 | 60.6 | 59 | 55.4 | 69.2 | 58.6 | 54.2 |
| NL2Repo | 48.9 | 42.7 | 47.2 | 42.1 | 35.5 | 69.7 | 50.7 | 33.4 |
| DeepSWE | 46.2 | 18 | 18 | 20 | 8 | 58 | 70 | 10 |
| ProgramBench | 63.7 | 50.9 | - | - | 47.8 | 71.9 | 70.8 | 39.5 |
| Terminal Bench 2.1 (Terminus-2) | 81.0 | 63.5 | 75 | 65 | 64 | 85 | 84 | 74 |
| Terminal Bench 2.1 (Best Reported Harness) | 82.7 | 69 | - | - | - | 78.9 | 83.4 | 70.7 |
| FrontierSWE (Dominance) | 74.4 | 30.5 | - | - | 29.0 | 75.1 | 72.6 | 39.6 |
| PostTrainBench | 34.3 | 20.1 | - | - | - | 37.2 | 28.4 | 21.6 |
| SWE-Marathon | 13.0 | 1.0 | - | - | - | 26.0 | 12.0 | 4.0 |
| Agentic | ||||||||
| MCP-Atlas (Public Set) | 76.8 | 71.8 | 76.4 | 74.2 | 73.6 | 77.8 | 75.3 | 69.2 |
| Tool-Decathlon | 48.2 | 40.7 | - | - | 52.8 | 59.9 | 55.6 | 48.8 |
Getting started with GLM-5.2
Use GLM-5.2 with GLM Coding Plan
Try GLM-5.2 in your favorite coding agents—ZCode, Claude Code, OpenCode, and more. https://docs.z.ai/devpack/overview
For GLM Coding Plan subscribers: We already rolled out GLM-5.2 to all Coding Plan users. You can enable GLM-5.2 now by updating the model name to "GLM-5.2" (or GLM-5.2[1m] in Claude Code to enable 1M context length). You can also choose different thinking effort, High or Max, depending on the task. As our most capable model, GLM-5.2 consumes quota at 3× during peak hours and 2× during off-peak hours. As a limited-time promotion through the end of September, off-peak usage is billed at 1×. (Peak hours are 14:00–18:00 UTC+8 (Beijing Time) daily).
Prefer a GUI? We offer ZCode —a desktop agent powered by GLM-5.2, with /goal for long-horizon tasks, SSH remote development, and mobile control. Special offer: use GLM-5.2 through Coding Plan inside ZCode and get 1.5x effective quota until June 30.
Chat with GLM-5.2 on Z.ai
GLM-5.2 is now available on Z.ai.
Serve GLM-5.2 Locally
The model weights of GLM-5.2 are publicly available on HuggingFace and ModelScope. For local deployment, GLM-5.2 supports inference frameworks including transformers, vLLM, SGLang, xLLM, ktransformers.
Footnote
- Humanity’s Last Exam (HLE) & other reasoning tasks: We use sampling parameters of
temperature=1.0,top_p=0.95for evaluation. We evaluate with a maximum generation length of163,840tokens. By default, we report the text-only subset; results marked with * are from the full set. For AIME, HMMT and IMOAnswerBench, we evaluate each question using the following system prompt:Your response should be in the following format:\nExplanation: {your explanation for your final answer}\nExact Answer: {your succinct, final answer}\nConfidence: {your confidence score between 0% and 100% for your answer}.We use GPT-5.5 (medium) as the judge model. For HLE-with-tools, we use a maximum context length of 300,000 tokens, with no context management strategy. - SWE-Bench Pro: We run the SWE-Bench Pro suite with OpenHands using a tailored instruction prompt. Settings:
temperature=1,top_p=1,max_new_tokens=32k, with a 400K context window. - NL2Repo: We evaluated NL2Repo with
temperature=1.0,top_p=1.0, andmax_new_tokens=48kunder 400k context. To prevent hacking, we use rule-based and a LLM-based judgement to prevent malicious behaviors (e.g., unauthorized pip or curl operations). - DeepSWE: We run DeepSWE with the official pier evaluation framework and the mini-swe-agent harness (
temperature=1.0,top_p=1.0,timeout=2h, 400K context). Each task is solved in an isolated container with 2 CPUs, 8 GB RAM, and no internet access. - ProgramBench: We evaluate ProgramBench (200 instances) with Claude-Code 2.1.156 using
temperature=1.0, top_p=1.0, max_tokens=64000, max_turns=2000, sample_timeout=6h, reasoning_effort=max, with a 400K context window. Each instance runs in a (4 CPUs, 8 GB RAM) sandbox with internet access disabled. - Terminal-Bench 2.1 (Terminus 2): We evaluate Terminal-Bench 2.1 with Terminus-2 framework using
parser=json,timeout=4h,temperature=1.0,top_p=1.0,max_new_tokens=48k,max_episodes=500, with a 256K context window. Resource limits are capped at 4 CPUs and 8 GB RAM. - Terminal-Bench 2.1 (Claude Code): We evaluate in Claude Code 2.1.167 with
temperature=1.0, top_p=0.95, max_new_tokens=131072. We override max_new_tokens to 128k via a transparent proxy, bypassing the 64k CLI cap to restore the configurability ofCLAUDE_CODE_MAX_OUTPUT_TOKENS. We remove wall-clock time limits, while preserving per-task CPU and memory constraints. Scores are averaged over 5 runs. - MCP-Atlas: All models were evaluated in think mode on the 500-task public subset with a 10-minute timeout per task. We use Gemini-3.0-Pro as the judge model for evaluation.
- Tool-Decathlon: We use the official evaluation service and set max_token to 128K.
- FrontierSWE: The evaluation was conducted by Proximal with 1M context length, max effort level, and 128K maximum output tokens. Dominance score reported as of 2026/06/16.
- PostTrainBench: The evaluation was conducted by PostTrainBench with 1M context length, max effort level, and 128K maximum output tokens.
- SWE-Marathon: The evaluation was conducted by Abundant AI with 1M context length, max effort level, and 128K maximum output tokens.