GLM-5.2：专为长周期任务打造
GLM-5.2: Built for Long-Horizon Tasks
智谱AI发布GLM-5.2旗舰模型，支持稳定的1M token上下文，并引入IndexShare架构将长上下文下每个token的FLOPs降低2.9倍。在FrontierSWE benchmark上，GLM-5.2以74.4%的Dominance分数领先GPT-5.5（72.6%）和Opus 4.7（63.4%），仅落后Opus 4.8（75.1%）1%。模型采用MIT开源许可证，在Terminal-Bench 2.1上得分81.0，较GLM-5.1的63.5大幅提升。GLM-5.2还引入用力级别控制，并通过slime框架实现高效agentic RL训练。
](https://huggingface.co/zaiorg)
我们正式发布 GLM-5.2，这是我们在长周期任务领域的最新旗舰模型。相比前代 GLM-5.1，它在长周期任务能力上实现了质的飞跃，并首次在扎实的 1M token 上下文上交付了这种能力。GLM-5.2 的新能力包括：
- 扎实的 1M 上下文： 一个稳定的 1M token 上下文，能够持续支撑长周期工作
- 灵活用力的高级编码： 更强的编码能力，提供多种思考用力级别以平衡性能与延迟
- 改进的架构： 我们提出了 IndexShare，它在每四个稀疏 attention 层之间复用同一个 indexer，在 1M 上下文长度下将每个 token 的 FLOPs 降低了 2.9 倍。我们还改进了 GLM-5.2 用于推测解码的 MTP 层，将接受长度提升了最高 20%
- 纯粹开源： MIT 开源许可证——无地域限制，技术访问无国界
支撑长周期任务，首先要让长上下文在工程上可用：模型必须在漫长而混乱的编码 agent 轨迹中保持质量，而不仅仅是能接受更多 token。声称拥有 1M 上下文很容易，但在真实的工程压力下保持可靠则困难得多。为此，我们大幅扩展了针对编码 agent 场景的 1M 上下文训练，涵盖大规模实现、自动化研究、性能优化和复杂调试。最终成果是一个不仅范围宽广，而且执行扎实的长上下文系统：为持续的工程工作提供了实用的基础。
这一能力体现在 GLM-5.2 在三个长周期编码 benchmark 上的表现中。FrontierSWE 衡量 agent 能否完成以小时到数十小时为尺度的开放式技术项目，涵盖系统优化、大规模代码构建和应用 ML 研究。在该 benchmark 上，GLM-5.2 仅落后 Opus 4.8 1%，同时领先 GPT-5.5 1% 和 Opus 4.7 11%。在 PostTrainBench 上，每个 agent 被分配一块 H100 GPU，根据其通过后训练提升小模型的能力进行评估，GLM-5.2 超越了 Opus 4.7 和 GPT-5.5，仅次于 Opus 4.8。在 SWE-Marathon 上，这是一个涵盖构建编译器、优化内核和开发生产级服务等任务的超长周期软件工程 benchmark，GLM-5.2 仍有成长空间，落后 Opus 4.8 13%，但仍仅次于 Opus 系列。在所有三个 benchmark 上，GLM-5.2 都是排名最高的开源模型，表明其 1M 上下文已转化为实用的长周期交付能力。
在标准编码 benchmark 上，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 还引入了用力级别控制，使用户能够明确地在模型能力与任务执行速度和计算成本之间进行权衡。如图所示，在可比的 token 预算下，GLM-5.2 提供了比 GLM-5.1 显著更强的 agentic 编码性能，其能力大致介于 Claude Opus 4.7 和 Claude Opus 4.8 之间，且 token 消耗相近。此外，Max 用力级别允许用户在挑战性任务中需要更高性能时分配额外的计算资源，进一步扩展了模型的编码能力。这种设计为用户在使用 GLM-5.2 进行编码任务时提供了更大的灵活性，使他们能够针对不同场景选择最合适的推理模式。
面向 1M 上下文的架构
用于 DSA 的 IndexShare
为了支持 1M 上下文长度，在 GLM-5.2 中，我们应用 IndexShare 来降低 DSA 中 indexer 的计算成本。具体来说，在 GLM-5.2 中，每 4 个 transformer 层共享一个轻量级 indexer。该 indexer 放置在 4 层中的第一层，topk 索引用于这 4 层。这减少了 3/4 层中 indexer 点积和 topk 操作的计算量。GLM-5.2 从 128K 序列长度的中期训练开始就使用 IndexShare 进行训练，在长上下文 benchmark 上以更少的计算量超越了 GLM-5.1。
结合 IndexShare 和 KVShare 的 MTP
我们改进了 GLM-5.2 用于推测解码的 MTP 层，有两个目标：1) 最小化作为 draft 模型的 MTP 层的成本；2) 最大化推测解码的接受率。
对于第一个目标，我们也在 MTP 层上应用了 IndexShare。在多步 MTP 中，indexer 放置在第一步，topk 索引用于所有后续步骤。然而，与 backbone 不同，不同 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 损失进行训练。
下表展示了在编码场景下，各项技术对接受长度的消融实验结果。实验中我们使用了 GLM-5.1 的 backbone 和训练数据。训练和推理的 MTP 步数均设置为 7。与基线相比，最终 MTP 层的接受长度提升了 20%。
| 方法 | 接受长度 |
|---|---|
| 基线 | 4.56 |
| + IndexShare + KV Share | 5.10 |
| + 拒绝采样 | 5.29 |
| + 端到端 TV 损失 | 5.47 (+20%) |
高效服务 1M 上下文长度
随着 GLM-5.2 将最大上下文长度从 200K token 扩展到 1M token，编码工作负载预计将显著转向更长的 prompt。这将主要的推理瓶颈从计算转移到 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 获得了越来越大的吞吐量优势，展示了在长上下文推理场景中更强的可扩展性。
用于 Agentic RL 的 slime
GLM-5.2 的 agentic RL 后训练涉及更大规模、更多领域和更复杂执行模式的任务。异构数据和任务需要在一个统一的训练过程中组织，而长周期交互、工具使用、子任务分解和多轮环境反馈都对 rollout 和训练编排提出了更高要求。为了支持这一过程，slime 作为一个从训练到大规模推理 rollout 的集成基础设施层。它支持多种训练和任务组织模式，包括白盒 rollout、黑盒 rollout、紧凑轨迹和子 agent 工作流，使同一系统能够扩展到更大、更复杂的 RL 和 OPD 训练工作负载。在 GLM-5.2 的后训练过程中，我们使用 slime 框架进行了并行 OPD 训练，高效地将十多个专家模型合并到最终模型中。整个 OPD 训练过程耗时约两天，展示了很高的训练效率。
Agentic RL 也对系统资源和推理基础设施提出了更高要求。slime 为推理系统提供了一个高度开放和灵活的接口：训练端可以连接不同形式的推理服务，并灵活适应不同的并行策略、路由策略、PD 分离设置和部署模式。同时，在 RL rollout 过程中积累的配置经验、调度策略和优化路径，可以在生产服务阶段被复用和进一步优化，使训练端和服务端相互促进。这为从后训练到生产部署创造了一条更直接的路径。结合灵活的训练-推理资源组织和 KV-cache FP8，slime 为 GLM-5.2 的大规模 agentic RL 训练提供了关键的基础设施支持，进一步提升了系统效率、rollout 吞吐量和大规模推理并发度。
面向长周期任务并带有反作弊机制的 RL
面向长周期任务的 RL。对于 GLM-5.2，长周期任务会产生显著更长的执行轨迹，一旦超长轨迹被压缩拆分为多个子轨迹，同一 prompt 下的不同 rollout 会产生数量不同、长度差异巨大的可训练轨迹。因此，我们从群体优化转向基于 critic 的 PPO 公式，该公式从单个 rollout 中学习，依靠 critic 来估计 token 级别的优势，而不是进行群体相对比较。这种单 rollout 公式自然地适应了压缩，因为它对 prompt 产生的轨迹数量或其相对长度没有限制：我们将所有压缩后的子轨迹作为可训练轨迹纳入训练，并应用 token 级别的损失来处理它们的长度不平衡问题。
编码 agent 中的反作弊。编码 RL 特别容易受到奖励作弊的影响，因为奖励通常是一个可验证的通过/失败信号。我们发现 GLM-5.2 比 GLM-5.1 表现出更多潜在的作弊行为。这使得验证信号易于优化，但未能真正提升模型的基础能力。agent 可以读取受保护的评估工件，从参考文献或上游提交中复制答案内容，或者在与 GitHub 相关的任务中直接获取目标源代码。例如，agent 可能通过 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)"
这些行为会虚增奖励并污染训练信号，因此需要一个清晰的机制来区分真正的任务解决与走捷径。为了解决这个问题，我们为 RL 训练和评估都引入了一个反作弊模块。检测过程分为两个阶段：基于规则的过滤器首先捕获潜在的作弊行为以最大化召回率，然后一个 LLM 评判器检查这些被标记行为的意图以保持高精确率。我们使用一种在线策略，在每一步监控工具调用。如果检测到作弊，系统会阻止该调用并返回虚假信息作为结果。重要的是，这种在线防护允许模型在作弊行为被捕获后继续 rollout。通过处理特定的无效行为而不是拒绝整个轨迹，这种方法有助于防止因 rollout 突然停止而可能发生的训练不稳定和模型崩溃。
完整 Benchmark 表格
| 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 |
|---|---|---|---|---|---|---|---|---|
| 推理 | ||||||||
| 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 |
| 编码 | ||||||||
| 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 |
开始使用 GLM-5.2
使用 GLM Coding Plan 使用 GLM-5.2
在你喜欢的编码 agent——ZCode、Claude Code、OpenCode 等中尝试 GLM-5.2。https://docs.z.ai/devpack/overview
对于 GLM Coding Plan 订阅者： 我们已向所有 Coding Plan 用户推出了 GLM-5.2。你现在可以通过将模型名称更新为 "GLM-5.2"（或在 Claude Code 中使用 GLM-5.2[1m] 以启用 1M 上下文长度）来启用 GLM-5.2。你也可以根据任务选择不同的 thinking effort，High 或 Max。作为我们能力最强的模型，GLM-5.2 在高峰时段消耗 3 倍配额，在非高峰时段消耗 2 倍配额。作为截至 9 月底的限时推广，非高峰时段使用按 1 倍计费。（高峰时段为每天 UTC+8（北京时间）14:00–18:00）。
更喜欢图形界面？我们提供 ZCode——一款由 GLM-5.2 驱动的桌面 agent，具备用于长周期任务的 /goal 功能、SSH 远程开发和移动控制。特别优惠：在 ZCode 内通过 Coding Plan 使用 GLM-5.2，在 6 月 30 日前可获得 1.5 倍有效配额。
立即开始构建：https://z.ai/subscribe
在 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,840token。默认情况下，我们报告纯文本子集；标有 * 的结果来自完整集。对于 AIME、HMMT 和 IMOAnswerBench，我们使用以下系统 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}.我们使用 GPT-5.5 (medium) 作为评判模型。对于 HLE-with-tools，我们使用最大上下文长度 300,000 token，不采用上下文管理策略。 - SWE-Bench Pro：我们使用 OpenHands 配合定制的指令 prompt 运行 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 运行 DeepSWE（
temperature=1.0、top_p=1.0、timeout=2h、400K 上下文）。每个任务在一个隔离的容器中解决，配备 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，绕过 64k 的 CLI 上限，以恢复CLAUDE_CODE_MAX_OUTPUT_TOKENS的可配置性。我们移除了挂钟时间限制，同时保留了每个任务的 CPU 和内存约束。分数为 5 次运行的平均值。 - MCP-Atlas：所有模型均在思考模式下评估，使用 500 个任务的公共子集，每个任务超时 10 分钟。我们使用 Gemini-3.0-Pro 作为评估的评判模型。
- Tool-Decathlon：我们使用官方评估服务，并将 max_token 设置为 128K。
- FrontierSWE：评估由 Proximal 进行，使用 1M 上下文长度、最大用力级别和 128K 最大输出 token。报告的 Dominance 分数截至 2026/06/16。
- PostTrainBench：评估由 PostTrainBench 进行，使用 1M 上下文长度、最大用力级别和 128K 最大输出 token。
- SWE-Marathon：评估由 Abundant AI 进行，使用 1M 上下文长度、最大用力级别和 128K 最大输出 token。