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

- 来源：Hugging Face：Blog（RSS）
- 发布时间：2026-06-17 17:01
- AIHOT 分数：83
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.news/items/cmqhvpfla0354slf0g5ldyctw
- 原文链接：https://huggingface.co/blog/zai-org/glm-52-blog

## 精选理由

GLM-5.2 是第一个在长程编码基准上直逼 Opus 4.8 的开源模型，MIT 许可无地域限制，开源生态终于有了能打硬仗的长上下文工具。

## AI 摘要

GLM-5.2 发布，支持 1M token 上下文，采用 IndexShare 架构——每 4 个稀疏注意力层共用一个轻量索引器，将 1M 上下文下每 token FLOPs 降低 2.9 倍；MTP 层改进使推测解码接受长度提升 20%。长周期编码基准上，FrontierSWE 落后 Opus 4.8 仅 1%、领先 GPT-5.5 1%；PostTrainBench 仅次于 Opus 4.8；SWE-Marathon 落后 Opus 4.8 13% 但排名第二。标准编码测试 Terminal-Bench 2.1 获 81.0 分（GLM-5.1 为 63.5），接近 Opus 4.8 的 85.0。模型引入努力级别控制以平衡性能与延迟。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 开源许可证——无地域限制，技术获取无国界

要支持长时程任务，首先要让长上下文在工程上真正可用：模型必须在漫长而杂乱的编码智能体轨迹中保持质量，而不只是能接受更多 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,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 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。