智谱发布 GLM-5.2：面向长程任务，1M 上下文与 MIT 开源

我们推出 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 开源许可证——没有地域限制，技术访问无边界

支撑长时程任务，首先要让长上下文在工程上可用：模型必须在冗长、杂乱 coding-agent 轨迹中保持质量，而不只是接受更多 token。1M 上下文说起来容易，但在真实工程压力下保持可靠要难得多。为此，我们大幅扩展了面向 coding-agent 场景的 1M 上下文训练，覆盖大规模实现、自动化研究、性能优化和复杂调试。最终得到的是一套不仅覆盖面广、而且执行扎实的长上下文系统：一个支撑持续工程工作的实用基座。

这一能力体现在 GLM-5.2 于三个长时程编码基准上的表现。FrontierSWE 衡量 agent 能否完成从数小时到数十小时规模的开放式技术项目，涵盖系统优化、大规模代码构建和应用 ML 研究。在该基准上，GLM-5.2 仅落后 Opus 4.8 1%，同时以 1% 领先 GPT-5.5、以 11% 领先 Opus 4.7。在 PostTrainBench 上，每个 agent 获得一块 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 的 agentic coding 性能大幅强于 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 中 indexer 的计算成本。具体而言，在 GLM-5.2 中，每 4 个 transformer 层共享一个轻量级 indexer。该 indexer 被放置在这 4 层中的第一层，topk 索引被用于这 4 层。这减少了 3/4 层中 indexer 点积和 topk 操作的计算量。GLM-5.2 从 128K 序列长度的 mid-training 阶段开始采用 IndexShare 进行训练，以更少的计算量在长上下文基准测试上超越了 GLM-5.1。

带 IndexShare 和 KVShare 的 MTP

我们改进了 GLM-5.2 中用于投机解码的 MTP 层，目标有两个：1）最小化 MTP 层作为 draft model 的成本；2）最大化投机解码的接受率。

对于第一个目标，我们也在 mtp 层上应用了 IndexShare。在多步 MTP 中，indexer 被放置在第一步，topk 索引被用于所有后续步骤。然而，与主干网络不同，不同 mtp 步骤的输入 token 是不同的。如下图所示，如果我们把 $h_4$ 的 topk 索引复用于 $h_5$，$h_5$ 只能关注 $h_1$ 到 $h_4$，而无法关注 $h_5$。我们将展示这一特性可以帮助我们实现第二个目标，即消除 GLM-5.1 的 mtp 层中的训练-推理差异。

在上图中，我们展示了一个两步 MTP 层的推理过程。在第一步中，推理与训练一致，所有 hidden states 均来自目标模型。然而，在第二步中，$h_{1:4}$ 来自目标模型，而 $h_5$ 来自 mtp 层。因此，$h_5$ 的 KV cache 是由来自目标模型计算得到的 $kv_{1:4}$ 与来自 mtp 层计算得到的 $kv_5$ 混合而成。相反，使用 IndexShare 后，$h_5$ 的 KV cache 只包含 $kv_{1:4}$，全部来自目标模型的 hidden states。在训练时，我们复用第一个 mtp 步骤的 kv cache 和 topk 索引。注意，与 GLM-5.1 相同，不同 MTP 步骤的参数也是共享的。此外，受 https://arxiv.org/abs/2606.12370 启发，我们为投机解码引入了拒绝采样，并使用端到端 TV loss 进行训练。

下表展示了在编码场景下各技术按接受长度的消融实验。在实验中我们使用 GLM-5.1 的主干网络和训练数据。训练和推理的 MTP 步数均设为 7。与基线相比，最终 MTP 层的接受长度提升了 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 的吞吐量优势越来越大，在长上下文推理场景中展现出更强的可扩展性。

用于 Agentic RL 的 slime

GLM-5.2 的 agentic RL 后训练涉及更大规模、更多领域以及更复杂执行模式的任务。异构数据和任务需要在统一的训练流程中组织起来，而长时程交互、工具使用、子任务分解和多轮环境反馈都对 rollout 和训练编排提出了更高要求。为支持这一过程，slime 作为从训练到大规模推理 rollout 的一体化基础设施层。它支持多种训练和任务组织模式，包括白盒 rollout、黑盒 rollout、紧凑轨迹和子代理工作流，使同一系统能够扩展到更大、更复杂的 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 被突然中断时可能出现的训练不稳定和模型崩溃。

完整基准测试表

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"（或在 Claude Code 中使用 GLM-5.2[1m] 以启用 1M 上下文长度）来启用 GLM-5.2。你还可以根据任务选择不同的 思考强度，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 倍有效配额。

立即开始构建： 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,840 tokens。默认情况下，我们报告纯文本子集；标有 * 的结果来自完整集。对于 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 测试框架（temperature=1.0、top_p=1.0、timeout=2h，400K 上下文）运行 DeepSWE。每个任务在隔离容器中解决，配备 2 个 CPU、8 GB RAM，且无互联网访问。
• ProgramBench：我们使用 Claude-Code 2.1.156 配合 temperature=1.0, top_p=1.0, max_tokens=64000, max_turns=2000, sample_timeout=6h, reasoning_effort=max 评估 ProgramBench（200 个实例），上下文窗口为 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：所有模型均在 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，最高努力级别，最大输出 token 为 128K。