GLM-5.2: Built for Long-Horizon Tasks

GLM-5.2：专为长周期任务而设计

返回文章列表

[0

团队

]

文章

发布于 2026 年 6 月 17 日

[-1

点赞

62

[

• +56

Z.AI

zaiorg

关注

zai-org

我们推出了 GLM-5.2，这是我们的最新旗舰模型，专为长周期任务而设计。与前代产品 GLM-5.1 相比，GLM-5.2 在长周期任务能力方面实现了显著的飞跃，并且首次在坚实的 1M 令牌上下文中实现了这一能力。GLM-5.2 的新功能包括：

• 坚实的 1M 上下文：一个能够稳定支持长周期工作的坚实 1M 令牌上下文

• 灵活努力的高级编码：通过多种思考努力级别实现更强的编码能力，从而在性能和延迟之间取得平衡

• 改进的架构：我们提出了 IndexShare，它在每四个稀疏注意力层中重复使用相同的索引器，从而在 1M 上下文长度下将每个令牌的 FLOPs 减少了 2.9 倍。我们还改进了 GLM-5.2 的 MTP 层，用于推测性解码，将接受长度提高了最多 20%

• 纯开源：MIT 开源许可证——无区域限制，技术访问无边界

支持长周期任务首先要使长上下文工程可用：模型必须在长而复杂的编码代理轨迹中保持质量，而不仅仅是接受更多的令牌。1M 上下文很容易声称，但在真正的工程压力下保持可靠却要困难得多。为此，我们大幅扩展了针对编码代理场景的 1M 上下文训练，涵盖大规模实现、自动化研究、性能优化和复杂调试。结果是一个不仅范围广泛，而且执行稳固的长上下文系统：一个用于持续工程工作的实用基础。

这一能力在 GLM-5.2 在三个长周期编码基准测试中的表现中得到了体现。FrontierSWE 测量代理是否能够在数小时到数十小时的规模上完成开放式的大型技术项目，涵盖系统优化、大规模代码构建和应用机器学习研究。在这一基准测试中，GLM-5.2 仅落后于 Opus 4.8 1%，而领先于 GPT-5.5 1%，并领先于 Opus 4.7 11%。在 PostTrainBench 上，每个代理都会获得一个 H100 GPU，并根据其通过后训练提升小型模型的能力进行评估，GLM-5.2 表现优于 Opus 4.7 和 GPT-5.5，排名第二，仅次于 Opus 4.8。在 SWE-Marathon 上，这是一个涵盖构建编译器、优化内核和开发生产级服务等任务的超长周期软件工程基准测试，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 还引入了努力级别控制功能，使用户能够明确地在模型能力与任务执行速度和计算成本之间取得平衡。如图所示，在相似的 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 从中期训练开始使用 IndexShare 进行训练，序列长度为 128K，在长上下文基准测试中，其计算成本低于 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%。

| 方法 | 接受长度 | |------|--------| | 基线 | 4.56 | | + IndexShare + KV Share | 5.10 | | + 拒绝采样 | 5.29 | | + 端到端 TV 损失 | 5.47 | | (+20%) | |

高效服务 1M 上下文长度

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

为了解决这一挑战，我们在三个方向上优化了推理引擎。首先，基于 LayerSplit，我们引入了更细粒度的内存管理和并行化策略，以提高 KV 缓存容量，并为超长上下文请求提供更多的可用缓存空间。其次，我们优化了那些成本随上下文长度增长的内核，并更好地协调它们与缓存传输流水线，最大限度地减少缓存传输对预填充和解码性能的影响。第三，我们优化了 CPU 侧的缓存管理、请求调度和运行时执行路径，以减少 GPU 执行流水线中的空闲时间，提高端到端的吞吐量。如图所示，随着上下文长度的增加，GLM-5.2 实现了越来越大的吞吐量优势，展示了在长上下文推理场景中更强的可扩展性。

slime 用于智能体强化学习

GLM-5.2 的智能体强化学习（Agentic RL）后训练涉及更大规模、更多领域和更复杂执行模式的任务。异构数据和任务需要在统一的训练过程中进行组织，而长时程交互、工具使用、子任务分解以及多轮环境反馈都对 rollout 和训练编排提出了更高的要求。为了支持这一过程，slime 作为从训练到大规模推理 rollout 的集成基础设施层，提供了支持。它支持多种训练和任务组织模式，包括白盒 rollout、黑盒 rollout、紧凑轨迹和子代理工作流，使同一系统能够扩展到更大、更复杂的 RL 和 OPD 训练工作负载。在 GLM-5.2 的后训练过程中，我们使用 slime 框架进行并行 OPD 训练，高效地将超过十个专家模型合并到最终模型中。整个 OPD 训练过程大约耗时两天，展示了高训练效率。

智能体强化学习对系统资源和推理基础设施也提出了更高的要求。slime 提供了一个高度开放和灵活的接口，与推理系统连接：训练端可以以不同形式连接到推理服务，并灵活适应不同的并行策略、路由策略、PD 解耦设置和部署模式。同时，在 RL rollout 过程中积累的配置体验、调度策略和优化路径可以在生产服务阶段被复用并进一步优化，使训练端和服务端相互增强。这为从后训练到生产部署创建了更直接的路径。结合灵活的训练-推理资源组织和 KV 缓存 FP8，slime 为 GLM-5.2 的大规模智能体强化学习训练提供了关键的基础设施支持，进一步提高了系统效率、rollout 吞吐量和大规模推理并发性。

针对长时任务的强化学习与反破解机制

针对长时任务的强化学习。对于 GLM-5.2，长时任务会产生显著更长的执行轨迹，一旦一个超长轨迹被压缩成多个子轨迹，相同提示下的不同执行结果会产生数量和长度差异很大的可训练轨迹。因此，我们从基于组的优化转向基于评论家的 PPO 形式，该形式从单个执行结果中学习，依赖评论家来估计令牌级别的优势，而不是进行组间比较。这种单次执行结果的形式自然地适应了压缩，因为它对提示生成的轨迹数量或它们的相对长度没有限制：我们通过将所有压缩后的子轨迹作为可训练轨迹包含在训练中，并应用令牌级别的损失来解决它们的长度不平衡问题。

编码代理中的反破解机制。由于奖励通常是可验证的通过/失败信号，编码强化学习特别容易受到奖励破解的影响。我们发现 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-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

96.5

94.8

HMMT Feb. 2026

92.5

82.6

97.1

95.2

96.7

87.3

IMOAnswerBench

91.0

83.8

90

89.8

83.5

81

GPQA-Diamond

91.2

86.2

93

90.1

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

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

Tool-Decathlon

40.7

52.8

59.9

55.6

48.8

入门使用 GLM-5.2

使用 GLM-5.2 与 GLM 编程计划

在您喜欢的编程代理中尝试 GLM-5.2 —— ZCode、Claude Code、OpenCode 等。https://docs.z.ai/devpack/overview

对于 GLM 编程计划的订阅者：我们已经向所有编程计划用户推出了 GLM-5.2。您现在可以通过将模型名称更新为 "GLM-5.2"（或在 Claude Code 中使用 GLM-5.2[1m] 以启用 1M 上下文长度）来启用 GLM-5.2。您还可以根据任务选择不同的思考努力程度，高或最大。作为我们功能最强大的模型，GLM-5.2 在高峰时段消耗配额为 3×，在非高峰时段消耗配额为 2×。作为一项限时促销活动，截止到 9 月底，非高峰时段的使用费用为 1×。（高峰时段为 UTC+8（北京时间）每日 14:00–18:00。）

更喜欢 GUI？我们提供 ZCode —— 一个由 GLM-5.2 提供支持的桌面代理，具有 /goal 用于长期任务、SSH 远程开发和移动控制。特别优惠：在 ZCode 中通过编程计划使用 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 在内的推理框架。

脚注

• 人类的最后一次考试（HLE）及其他推理任务：我们使用温度=1.0、top_p=0.95 的采样参数进行评估。我们使用最大生成长度为 163,840 个标记进行评估。默认情况下，我们报告文本子集；标记为 * 的结果来自完整集合。对于 AIME、HMMT 和 IMOAnswerBench，我们使用以下系统提示对每个问题进行评估：您的回答应采用以下格式：\n解释：{您对最终答案的解释}\n确切答案：{您简洁的最终答案}\n信心：{您对答案的信心得分，介于 0% 和 100% 之间}。我们使用 GPT-5.5（中等）作为判断模型。对于 HLE-with-tools，我们使用最大上下文长度为 300,000 个标记，没有上下文管理策略。

• SWE-Bench Pro：我们使用 OpenHands 和定制的指令提示运行 SWE-Bench Pro 套件。设置：温度=1，top_p=1，max_new_tokens=32k，上下文窗口为 400K。

• NL2Repo：我们在温度=1.0、top_p=1.0、max_new_tokens=48k、上下文为 400k 的情况下评估 NL2Repo。为了防止黑客攻击，我们使用基于规则和基于 LLM 的判断来防止恶意行为（例如未经授权的 pip 或 curl 操作）。

• DeepSWE：我们使用官方 pier 评估框架和 mini-swe-agent 工具（温度=1.0、top_p=1.0、超时=2 小时、上下文=400K）运行 DeepSWE。每个任务在隔离的容器中解决，该容器具有 2 个 CPU、8 GB 内存，且没有互联网访问权限。

• ProgramBench：我们使用 Claude-Code 2.1.156 在温度=1.0、top_p=1.0、max_tokens=64000、max_turns=2000、sample_timeout=6 小时、reasoning_effort=max、上下文窗口为 400K 的情况下评估 ProgramBench（200 个实例）。每个实例在（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 最大输出令牌。截至 2026/06/16，报告了支配得分。

• PostTrainBench：评估由 PostTrainBench 进行，使用 1M 上下文长度、最大努力级别和 128K 最大输出令牌。

• SWE-Marathon：评估由 Abundant AI 进行，使用 1M 上下文长度、最大努力级别和 128K 最大输出令牌。

本文中提到的模型 1

社区

lysandre

1 天前

[2

令人印象深刻的模型和发布，迫不及待想尝试一个 Opus 级别的开放模型，在开放的代码代理中。

查看翻译

🚀

5

+

回复

Volotat

•

编辑于 1 天前

迫不及待想看到开放模型打破封闭，重现 GTP-2 时代之前真正透明的前沿人工智能研究和开发的黄金时期。

🔥

3

👍

编辑

预览

通过拖拽、粘贴或点击此处上传图片、音频和视频。

点击此处上传图片

评论

· 注册或登录以评论

• +50