GLM-5.2：为长周期任务而生

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:

• 扎实的 1M 上下文：一个扎实的 100 万 token 上下文窗口，能够稳定支撑长周期工作
• 高级编程与灵活思考：更强的编码能力，配合多个思考努力级别，以平衡性能与延迟
• 架构改进：我们提出 IndexShare，在每四个稀疏注意力层中复用同一个索引器，在 1M 上下文长度下将每个 token 的 FLOPs 降低 2.9 倍。我们还改进了 GLM-5.2 的 MTP 层以实现推测解码，使接受长度提升最多 20%
• 完全开源：采用 MIT 开源许可证——无地域限制，技术访问无国界

支持长周期任务，首先需要让长上下文在工程上可用：模型必须在冗长、混乱的编程智能体轨迹中保持质量，而不仅仅是接受更多 token。声称拥有 1M 上下文很容易，但在真实的工程压力下保持可靠则困难得多。为此，我们大幅扩展了面向编程智能体场景的 1M 上下文训练，覆盖大规模实现、自动研究、性能优化和复杂调试。其结果是，这一长上下文系统不仅范围宽广，而且执行扎实：为持续工程工作提供了实用的基础。

这一能力体现在 GLM-5.2 在三个长周期编码基准测试上的表现。FrontierSWE 衡量智能体能否完成数小时到数十小时量级的开放式技术项目，涵盖系统优化、大规模代码构建以及应用机器学习研究。在该基准上，GLM-5.2 仅落后 Opus 4.8 一个百分点，同时领先 GPT-5.5 一个百分点，领先 Opus 4.7 十一个百分点。在 PostTrainBench 中，每个智能体获得一块 H100 GPU，根据其通过后训练改进小型模型的效果进行评估，GLM-5.2 的表现优于 Opus 4.7 和 GPT-5.5，仅次于 Opus 4.8 排名第二。在 SWE-Marathon（一个超长周期软件工程基准，涵盖构建编译器、优化内核以及开发生产级服务等任务）上，GLM-5.2 仍有成长空间，落后 Opus 4.8 十三个百分点，但仍位居 Opus 系列之后的第二名。在这三个基准测试中，GLM-5.2 是排名最高的开源模型，表明其 1M 上下文窗口已转化为实际的长周期交付能力。

在标准编码基准测试上，GLM-5.2 是最强的开源模型，相较 GLM-5.1 提升显著：在 Terminal-Bench 2.1 上从 63.5 提升至 81.0，在 SWE-bench Pro 上从 58.4 提升至 62.1。它还大幅缩小了与闭源前沿模型的差距——在 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，其能力大致介于 Claude Opus 4.7 和 Claude Opus 4.8 之间，且 token 消耗相当。此外，最大努力级别允许用户在面临挑战性任务需要更高性能时分配额外计算资源，进一步扩展了模型的编码能力。这一设计让用户在使用 GLM-5.2 进行编码任务时拥有更大的灵活性，能够根据不同场景选择最合适的推理模式。

1M上下文的架构

DSA的IndexShare（索引共享）

为了支持1M上下文长度，在GLM-5.2中，我们应用IndexShare来降低DSA中索引器的计算成本。具体来说，在GLM-5.2中，每4个Transformer层共享一个轻量级索引器。该索引器位于这4层的第一层，并且topk索引用于这4层。这减少了3/4层中索引器点积和topk操作的计算量。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 缓存是由目标模型计算的 $kv_{1:4}$ 与 MTP 层计算的 $kv_5$ 混合而成。而采用 IndexShare 后，$h_5$ 的 KV 缓存仅包含 $kv_{1:4}$，全部来自目标模型的隐藏状态。在训练方面，我们复用了第一个 MTP 步骤的 KV 缓存和 topk 索引。注意，与 GLM-5.1 相同，不同 MTP 步骤的参数也是共享的。此外，受 https://arxiv.org/abs/2606.12370 启发，我们引入了用于推测性解码的拒绝采样，并使用端到端 TV 损失进行训练。

下表展示了在编码场景下，按接受长度对各项技术进行的消融实验。实验中我们使用了 GLM-5.1 的骨干网络和训练数据。训练和推理的 MTP 步骤数均设为 7。与基线相比，最终 MTP 层的接受长度提升了 20%。

高效服务百万级上下文长度

随着 GLM-5.2 将最大上下文长度从 200K 扩展到 1M 个模型 token，编码工作负载预计将显著向更长提示词倾斜。这使得主要推理瓶颈从计算转向 KV 缓存容量、长上下文内核开销以及 CPU 端开销。尽管新的 GLM-5.2 架构减少了每个模型 token 的计算 FLOPs，但并未按比例减少每个模型 token 的 KV 缓存大小。因此，在有限的 GPU 资源下支持更长的上下文、更高的并发度以及更高的模型 token 吞吐量，成为推理引擎优化的核心挑战。

为应对这一挑战，我们从三个方向优化推理引擎。首先，基于 LayerSplit，我们引入了更细粒度的内存管理与并行化策略，以增加 KV-cache 容量，为超长上下文请求提供更多可用的缓存空间。其次，我们优化了那些开销随上下文长度增长的内核，并使其与缓存传输流水线更好地协调，从而最小化缓存传输对预填充和生成两个阶段性能的影响。第三，我们优化了 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 推演过程中积累的配置经验、调度策略和优化路径，可以在生产服务阶段复用并进一步优化，使得训练侧与服务侧能够相互加强。这为从后训练到生产部署创建了一条更直接的路径。结合灵活的训练 - 推理资源组织与 KV-cache FP8，slime 为 GLM-5.2 的大规模智能体强化学习训练提供了关键基础设施支撑，进一步提升了系统效率、推演吞吐量以及大规模推理并发能力。

面向长周期任务且具备抗劫持能力的强化学习

面向长周期任务的强化学习。对于 GLM-5.2，长周期任务会产生显著更长的执行轨迹，而一旦超长轨迹通过压缩被拆分为多个子轨迹，同一提示词下的不同推演会生成数量不同、长度差异极大的可训练轨迹。因此，我们从组级优化转向基于评论家的 PPO 公式，该公式从单个推演中学习，依靠评论家来估计 token 级别的优势，而非组间比较。这种单推演公式天然适配压缩，因为它不限制一个提示词产生多少条轨迹，也不限制它们之间的相对长度：我们将所有压缩后的子轨迹作为可训练轨迹纳入训练，并应用 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 判断器检查这些被标记行为的意图以保持高精确率。我们采用一种在线策略，在每一步监控工具调用。如果检测到作弊，系统会阻止该调用并返回虚拟信息作为结果。重要的是，这种在线防护允许模型在被捕获作弊行为后仍能继续生成轨迹。通过处理特定的无效行为而非拒绝整个轨迹，这种方法有助于防止因生成轨迹被突然终止而导致的训练不稳定和模型崩溃。

完整基准测试表

GLM-5.2 快速入门

使用 GLM Coding Plan 调用 GLM-5.2

在你偏好的编程智能体（如 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。你还可以根据任务选择不同的思考努力程度：High 或 Max。作为我们能力最强的模型，GLM-5.2 在高峰时段消耗 3 倍配额，在非高峰时段消耗 2 倍配额。作为截至 9 月底的限时优惠，非高峰时段使用按 1 倍计费（高峰时段为每日北京时间 14:00–18:00）。

更喜欢图形界面？我们提供 ZCode——一款由 GLM-5.2 驱动的桌面智能体，支持 `/goal` 长周期任务、SSH 远程开发以及移动端控制。特别优惠：在 ZCode 中通过 Coding Plan 使用 GLM-5.2，可享受 1.5 倍有效配额，有效期至 6 月 30 日。

立即开始构建：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 等推理框架。

脚注

• 人类最后一次考试（HLE）及其他推理任务：我们使用采样参数 temperature=1.0、top_p=0.95 进行评估。评估时最大生成长度设为 163,840 个 token。默认情况下，我们报告的是纯文本子集；标有 * 的结果来自完整数据集。对于 AIME、HMMT 和 IMOAnswerBench，我们使用以下系统提示评估每一道题：你的回答应采用以下格式：\nExplanation: {你最终答案的解释}\nExact Answer: {你简洁的最终答案}\nConfidence: {你对答案的置信度评分（0% 到 100%）}。我们使用 GPT-5.5（中）作为评委模型。对于带工具的 HLE，我们使用最大上下文长度 300,000 个 token，不设上下文管理策略。
• 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 工具链运行 DeepSWE（temperature=1.0、top_p=1.0、超时时间=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，绕过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。统治分数报告截至2026/06/16。
• PostTrainBench：评估由PostTrainBench执行，使用1M上下文长度、最大努力级别和128K最大输出token。
• SWE-Marathon：评估由Abundant AI执行，使用1M上下文长度、最大努力级别和128K最大输出token。

本文提到的模型 1