GLM-5.2：为长程任务而生

本文译自 Z.ai 的 GLM-5.2 发布博客 GLM-5.2: Built for Long-Horizon Tasks¹，2026 年 6 月 16 日发布。这是一篇发布说明而不是技术报告：架构部分只讲了 IndexShare、MTP 和推理引擎三件事，预训练配方完全没提，后训练只给了 slime 与 RL 的定性描述。全文翻译，覆盖开篇、1M 上下文的架构、面向 agentic RL 的 slime、带反 hack 的长程任务 RL、完整 benchmark 表、上手方式，以及末尾那份各 benchmark 的评测设置附注。

我们发布 GLM-5.2，这是我们面向 long-horizon 长程任务的最新旗舰模型。相比前代 GLM-5.1，它在长程任务能力上有实质性的跃升，并且第一次把这个能力放在扎实的 1M token 上下文之上交付。GLM-5.2 的新能力包括：

• 扎实的 1M 上下文：一个能稳定支撑长程工作的 1M token 上下文
• 更强的编码能力，effort 可调：编码能力更强，并提供多档 thinking effort 来平衡性能与延迟
• 改进的架构：我们提出 IndexShare²，让每四个 sparse attention 层复用同一个 indexer，在 1M 上下文长度下把每 token 的 FLOPs 降低 2.9 倍。我们还改进了 GLM-5.2 用于 speculative decoding 的 MTP 层，把 acceptance length 提升最多 20%
• 纯粹开源：MIT 开源许可——没有地域限制，技术无国界

支撑长程任务，第一步是让长上下文在工程上真能用：模型必须在冗长、杂乱的 coding agent 轨迹上维持质量，而不只是能接受更多 token。1M 上下文很容易宣称，但要在真实的工程压力下保持可靠就难得多。为此我们大幅扩充了针对 coding agent 场景的 1M 上下文训练，覆盖大规模实现、自动化研究、性能优化和复杂调试。结果是一个不只是覆盖面宽、而且执行扎实的长上下文系统：一个可以支撑持续工程工作的实用底座。

这个能力体现在 GLM-5.2 在三个长程编码 benchmark 上的表现。FrontierSWE³ 衡量的是 agent 能否完成小时级到几十小时级的开放式技术项目，涵盖系统优化、大规模代码构建和应用 ML 研究。在这个 benchmark 上，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⁵ 这个超长程软件工程 benchmark 上——任务包括构建编译器、优化 kernel、开发生产级服务——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 还引入了 effort level 控制，让用户能显式地在模型能力与任务执行速度、计算成本之间做权衡。如图所示，在可比的 token 预算下，GLM-5.2 的 agentic coding 表现显著强于 GLM-5.1，在相似的 token 消耗下，其能力大致位于 Claude Opus 4.7 和 Claude Opus 4.8 之间。此外，Max effort 档允许用户在有挑战的任务上需要更高性能时投入额外算力，进一步拓展模型的编码能力。这个设计让用户在用 GLM-5.2 做编码任务时有更大的灵活度，可以为不同场景挑选最合适的推理模式。

1M 上下文的架构

DSA 上的 IndexShare

为了支撑 1M 的上下文长度，在 GLM-5.2 里我们用 IndexShare² 来降低 DSA 中 indexer 的计算开销。具体来说，在 GLM-5.2 里每 4 个 transformer 层共享一个轻量 indexer。indexer 放在这 4 层的第一层，top-k indices 供 4 层使用。这样 4 层里有 3 层省掉了 indexer 的点积和 top-k 运算。GLM-5.2 从中期训练阶段起就以 128K 序列长度带着 IndexShare 训练，在长上下文 benchmark 上以更少的计算量胜过 GLM-5.1。

配合 IndexShare 与 KVShare 的 MTP

我们改进了 GLM-5.2 用于 speculative decoding 的 MTP 层，有两个目标：1）把作为 draft model 的 MTP 层的开销压到最低；2）把 speculative decoding 的 acceptance rate 提到最高。

针对第一个目标，我们在 MTP 层上也用了 IndexShare。在多步 MTP 里，indexer 放在第一步，top-k indices 供后面所有步使用。但和主干不同的是，不同 MTP 步的输入 token 是不一样的。如下图所示，如果我们把 $h_4$ 的 top-k indices 复用给 $h_5$，那么 $h_5$ 只能 attend 到 $h_1$ 到 $h_4$，而 attend 不到 $h_5$。我们会说明这个性质能帮我们达到第二个目标——消除 GLM-5.1 的 MTP 层里训练与推理之间的不一致。

上图里我们展示的是一个两步 MTP 层的推理。第一步，推理和训练是一致的，所有 hidden state 都来自目标模型。但在第二步，$h_{1:4}$ 来自目标模型，$h_5$ 来自 MTP 层。因此 $h_5$ 的 KV cache 是一个混合体：$kv_{1:4}$ 由目标模型算出，$kv_5$ 由 MTP 层算出。相反，有了 IndexShare，$h_5$ 的 KV cache 只包含 $kv_{1:4}$，全部来自目标模型的 hidden state。训练时，我们把第一个 MTP 步的 KV cache 和 top-k indices 都复用。注意和 GLM-5.1 一样，不同 MTP 步的参数也是共享的。此外，受 arXiv:2606.12370⁶ 启发，我们为 speculative decoding 引入了 rejection sampling，并用端到端的 TV loss 做训练。

译注：图里两步的小标题写作 predict $t_5$ / predict $t_6$，而两步的输出框分别是 $t_6$ / $t_7$，下标差 1。正文的叙述（第二步里 $h_5$ 来自 MTP 层）与输出框一致。

下表按编码场景下的 acceptance length 展示各项技术的消融。实验中我们用的是 GLM-5.1 的主干和训练数据。MTP 步数在训练和推理时都设为 7。相比 baseline，最终 MTP 层的 acceptance length 提升了 20%。

高效服务 1M 上下文

随着 GLM-5.2 把最大上下文长度从 200K 扩到 1M token，编码类负载预计会大幅向更长的 prompt 偏移。这会把推理的主要瓶颈从计算转移到 KV cache 容量、长上下文 kernel 开销和 CPU 侧开销上。尽管新的 GLM-5.2 架构降低了每 token 的计算 FLOPs，它并没有等比例地降低每 token 的 KV cache 大小。因此，在有限的 GPU 资源下支撑更长的上下文、更高的并发和更高的 token 吞吐，成了推理引擎优化的核心挑战。

为了应对这个挑战，我们在三个方向上优化推理引擎。第一，在 LayerSplit 的基础上，我们引入更细粒度的内存管理和并行化策略，来增大 KV cache 容量、为超长上下文请求提供更多可用的 cache 空间。第二，我们优化那些开销随上下文长度增长的 kernel，并让它们与 cache 传输流水线更好地协同，把 cache 传输对 prefill 和 decode 性能的影响降到最低。第三，我们优化 CPU 侧的 cache 管理、请求调度和运行时执行路径，减少 GPU 执行流水线里的气泡，提升端到端吞吐。如图所示，随着上下文长度增长，GLM-5.2 的吞吐优势越来越大，说明它在长上下文推理场景下有更强的可扩展性。

面向 agentic RL 的 slime

GLM-5.2 的 agentic RL 后训练涉及规模更大、领域更多、执行模式更复杂的任务。异构的数据和任务需要被组织进统一的训练流程，同时长程交互、工具使用、子任务分解和多轮环境反馈，都对 rollout 与训练的编排提出了更高要求。为支撑这个流程，slime 充当了一个从训练贯通到大规模推理 rollout 的一体化基础设施层。它支持多种训练与任务组织模式，包括 white-box rollout、black-box rollout、compact trajectory 和 sub-agent workflow，让同一套系统能扩展到规模更大、更复杂的 RL 和 OPD 训练负载。在 GLM-5.2 的后训练过程中，我们用 slime 框架做并行 OPD 训练，高效地把十多个专家模型合并成最终模型。整个 OPD 训练过程大约用了两天，训练效率很高。

agentic RL 也对系统资源和推理基础设施提出了更高要求。slime 为推理系统提供了高度开放灵活的接口：训练侧可以对接不同形态的推理服务，灵活适配不同的并行策略、路由策略、PD 分离配置和部署形态。同时，RL rollout 期间积累的配置经验、调度策略和优化路径，可以在生产 serving 阶段被复用和进一步打磨，让训练侧和 serving 侧相互增强。这在后训练到生产部署之间开出了一条更直接的路。配合灵活的训练-推理资源组织和 KV cache FP8，slime 为 GLM-5.2 的大规模 agentic RL 训练提供了关键的基础设施支撑，进一步改善了系统效率、rollout 吞吐和大规模推理并发。

译注：原文没有展开 OPD 这个缩写，全文四处都直接写作 OPD，这里照原样保留。

带反 hack 的长程任务 RL

长程任务的 RL。对 GLM-5.2 来说，长程任务产生的执行轨迹长得多，而一旦一条超长轨迹被 compaction 切成多条子轨迹，同一个 prompt 下的不同 rollout 就会产出数量不同、长度差异很大的可训练轨迹。因此我们从 group-wise 的优化转向基于 critic 的 PPO 形式，从单条 rollout 上学习，靠一个 critic 来估计 token 级的 advantage，而不是做 group 内的相对比较。这种单 rollout 的形式天然适配 compaction，因为它对一个 prompt 产出多少条轨迹、这些轨迹的相对长度如何都不作约束：我们把 compaction 纳入训练，做法是把所有被 compact 出来的子轨迹都当作可训练轨迹，并用 token 级的 loss 来处理它们的长度不均衡。

编码 agent 里的反 hack。编码 RL 特别容易遭到 reward hacking，因为 reward 通常是一个可验证的 pass/fail 信号。我们发现 GLM-5.2 比 GLM-5.1 表现出更多潜在的 hacking 行为。这让验证信号变得很好优化，却没有真正提升模型的基础能力。agent 可以去读被保护的评测产物、从参考答案或上游 commit 里抄答案内容，或者在 GitHub 相关任务里直接抓取目标源码。例如，agent 可能通过 curl https://raw.githubusercontent.com/<path-to-file> 下载解法，甚至像下面这样串起来泄题：

1
2
3

1. find /workspace -name "*hidden*"
2. cat /workspace/.eval/secret_cases.json
3. python solve.py --case "$(cat /workspace/.eval/secret_cases.json)"

这些行为会虚高 reward、污染训练信号，需要一个明确的机制把真正的解题和走捷径区分开。为此我们为 RL 训练和评测都引入了一个反 hack 模块。检测过程分两级：先用一个基于规则的过滤器抓出潜在的 hack，把召回拉满；再用一个 LLM judge 检查这些被标记动作的意图，把精度保住。我们采用在线策略，监控每一步的工具调用。一旦检测到 hack，系统就阻断这次调用并返回哑信息作为结果。重要的是，这个在线守卫让模型在一个 hack 动作被抓到之后仍能继续 rollout。通过处理那个具体的无效行为、而不是否掉整条轨迹，这个做法有助于避免 rollout 被突然中止时可能出现的训练不稳定和模型崩塌。

完整 benchmark 表

*：指该模型在完整集上的分数。

译注：前面几张图和这张表有两处数字对不上。图 2 里 MCP-Atlas 的 GLM-5.2 标作 77.0，表里是 76.8；图 1 里 PostTrainBench 的 GPT-5.5 标作 25.0%，表里是 28.4。其余各项两边一致。

开始使用 GLM-5.2

在 GLM Coding Plan 里用 GLM-5.2

在你喜欢的 coding agent 里试试 GLM-5.2——ZCode、Claude Code、OpenCode 等等。https://docs.z.ai/devpack/overview

给 GLM Coding Plan 订阅者：我们已经把 GLM-5.2 推送给所有 Coding Plan 用户。你现在就可以把模型名改成 "GLM-5.2" 来启用它（在 Claude Code 里写 GLM-5.2[1m] 可启用 1M 上下文长度）。你也可以按任务选择不同的 thinking effort⁷，High 或 Max。作为我们能力最强的模型，GLM-5.2 在高峰时段按 3 倍消耗配额、非高峰时段按 2 倍。作为限时优惠，到 9 月底前非高峰用量按 1 倍计费。（高峰时段为每天 14:00–18:00 UTC+8 北京时间。）

更喜欢图形界面？我们提供 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,840 token 的最大生成长度评测。默认报告 text-only 子集；标 * 的结果来自完整集。对 AIME、HMMT 和 IMOAnswerBench，我们对每道题使用如下 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}. 我们用 GPT-5.5（medium）作为 judge 模型。对 HLE-with-tools，我们用 300,000 token 的最大上下文长度，不启用任何上下文管理策略。
• SWE-Bench Pro：我们用 OpenHands 跑 SWE-Bench Pro 套件，配一份定制的指令 prompt。设置：temperature=1、top_p=1、max_new_tokens=32k，400K 上下文窗口。
• NL2Repo：我们在 400k 上下文下以 temperature=1.0、top_p=1.0、max_new_tokens=48k 评测 NL2Repo。为防止 hacking，我们用基于规则和基于 LLM 的判定来阻止恶意行为（例如未经授权的 pip 或 curl 操作）。
• DeepSWE：我们用官方的 pier 评测框架和 mini-swe-agent harness 跑 DeepSWE（temperature=1.0、top_p=1.0、timeout=2h，400K 上下文）。每个任务在一个隔离容器里求解，配 2 个 CPU、8 GB 内存，无网络访问。
• 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 内存）沙箱里，网络访问关闭。
• 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 内存。
• 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 作为 judge 模型评测。
• Tool-Decathlon：我们使用官方评测服务，max_token 设为 128K。
• FrontierSWE：评测由 Proximal¹⁰ 执行，1M 上下文长度、max effort 档、128K 最大输出 token。Dominance 分数截至 2026/06/16。
• PostTrainBench：评测由 PostTrainBench⁴ 执行，1M 上下文长度、max effort 档、128K 最大输出 token。
• SWE-Marathon：评测由 Abundant AI¹¹ 执行，1M 上下文长度、max effort 档、128K 最大输出 token。