6.0
关注
AI SCORE
模型发布2026-06-17 17:01
GLM-5.2：专为长期任务规划优化的模型
Hugging Face Blog#GLM#长任务
Editor brief · 编辑速览
智谱发布 GLM-5.2 模型，专注长期任务规划能力，信息有限但值得关注新模型的进展。
智谱发布 GLM-5.2 模型，专注长期任务规划能力，信息有限但值得关注新模型的进展。
扎实的百万 Token 上下文：能够稳定支持长期任务的、扎实的百万 token 上下文
灵活计算力的高级编码：更强的编码能力，配备多级计算力等级来平衡性能和延迟
改进的架构：我们提出 IndexShare，在每四层稀疏注意力层中复用同一索引器，在 100 万 token 上下文长度下将每 token 的浮点运算量（FLOPs）减少 2.9 倍。我们还改进了 GLM-5.2 的 MTP 层以支持推测解码，将接受长度增加至 20%
纯开源：采用 MIT 开源许可证——无区域限制，技术无国界
支持长期任务的首要条件是让长上下文在工程上可用：模型必须在冗长、复杂的编码智能体轨迹中保持质量，而不仅仅是接受更多 token。声称支持 100 万 token 上下文很容易，但在真实工程压力下保持其可靠性则困难得多。为此，我们大幅扩展了针对编码智能体场景的百万 token 上下文训练，涵盖大规模实现、自动化研究、性能优化和复杂调试。其结果是一个长上下文系统不仅覆盖范围广泛，而且执行扎实：为持续工程工作提供了实用基础。
这一能力在 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 都是排名最高的开源模型，表明其百万 token 上下文已转化为实际的长期交付能力。
在标准编码基准上，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 大幅提升，其能力在相似 token 消耗下大致位于 Claude Opus 4.7 和 Claude Opus 4.8 之间。此外，最大计算力级别使用户能够在更具挑战性的任务需要更高性能时分配额外计算资源，进一步扩展模型的编码能力。这种设计为用户在使用 GLM-5.2 执行编码任务时提供了更大的灵活性，允许他们根据不同场景选择最合适的推理模式。
为了支持百万 token 上下文长度，GLM-5.2 采用了 IndexShare 来降低 DSA 中索引器的计算成本。具体来说，在 GLM-5.2 中，每 4 个 transformer 层共享一个轻量级索引器。索引器放置在 4 层中的第一层，topk 索引用于这 4 层。这减少了 3/4 层中索引器点积和 topk 操作的计算量。GLM-5.2 从中期训练（128K 序列长度）起就采用 IndexShare 进行训练，在长上下文基准上的表现优于 GLM-5.1，且所需计算量更少。
我们为 GLM-5.2 的 MTP 层进行了推测解码改进，目标有两个：1) 最小化 MTP 层作为草稿模型的成本；2) 最大化推测解码的接受率。
对于第一个目标，我们也在 MTP 层上应用了 IndexShare。在多步 MTP 中，索引器放置在第一步，topk 索引用于所有后续步骤。然而，与主干网络不同的是，不同 MTP 步骤的输入 token 是不同的。如下图所示，如果我们为 $h_5$ 复用 $h_4$ 的 topk 索引，$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 loss 进行训练。
下表显示了通过编码场景中的接受长度来消融各项技术。在实验中我们使用了 GLM-5.1 的主干和训练数据。MTP 步骤数在训练和推理中均设置为 7。相比基准，最终 MTP 层的接受长度增加了 20%。
当 GLM-5.2 将最大上下文长度从 200K 扩展到 100 万 token 时，编码工作负载预计将大幅向更长的 prompt 转变。这将推理的主要瓶颈从计算转向 KV 缓存容量、长上下文内核开销和 CPU 侧开销。虽然新的 GLM-5.2 架构降低了每 token 的计算 FLOPs，但它不会按比例减少每 token 的 KV 缓存大小。因此，在有限的 GPU 资源下支持更长的上下文、更高的并发性和更高的 token 吞吐量成为推理引擎优化的中心挑战。
为了应对这一挑战，我们沿着三个方向优化了推理引擎。首先，基于 LayerSplit，我们引入了更细粒度的内存管理和并行化策略，以增加 KV 缓存容量并为超长上下文请求提供更多可用缓存空间。其次，我们优化了成本随上下文长度增长的内核，并更好地将它们与缓存传输管道协调，最小化缓存传输对预填充和解码性能的影响。第三，我们优化了 CPU 侧的缓存管理、请求调度和运行时执行路径，以减少 GPU 执行管道中的停滞并改进端到端吞吐量。如图所示，GLM-5.2 随着上下文长度增加获得越来越大的吞吐量优势，在长上下文推理场景中展现出更强的可扩展性。
GLM-5.2 的智能体强化学习后训练涉及更大规模、更多领域和更复杂执行模式的任务。异构数据和任务需要在统一的训练过程中组织，而长期交互、工具使用、子任务分解和多轮环境反馈都对回滚和训练编排提出了更高的要求。为了支持这一过程，slime 充当了从训练到大规模推理回滚的集成基础设施层。它支持多种训练和任务组织模式，包括白盒回滚、黑盒回滚、紧凑轨迹和子智能体工作流，使同一系统能够扩展到更大、更复杂的强化学习和 OPD 训练工作负载。在 GLM-5.2 的后训练过程中，我们使用 slime 框架进行了平行 OPD 训练，高效地将十多个专家模型合并到最终模型中。整个 OPD 训练过程耗时约两天，展现了高效的训练效率。
智能体式 RL 也对系统资源和推理基础设施提出了更高要求。slime 为推理系统提供了高度开放且灵活的接口：训练端能够以不同形式连接推理服务，并灵活适配不同的并行策略、路由策略、PD 解耦方案和部署模式。同时，在 RL rollout 过程中积累的配置经验、调度策略和优化路径，可以在生产服务阶段复用并进一步完善，使训练端与服务端相互促进。这样便形成了一条从后训练到生产部署的更直接路径。结合灵活的训练—推理资源组织方式和 KV-cache FP8，slime 为 GLM-5.2 的大规模智能体式 RL 训练提供了关键的基础设施支持，进一步提升了系统效率、rollout 吞吐量和大规模推理并发能力。
对于 GLM-5.2，长时程任务会产生显著更长的执行轨迹；当一条超长轨迹通过压缩被拆分成多条子轨迹后，同一提示词下的不同 rollout 会生成数量各异、长度差异很大的可训练轨迹。因此，我们从按组优化转向基于 critic 的 PPO 形式，从单次 rollout 中学习，依靠 critic 估算 token 级优势，而非进行组内相对比较。这种单 rollout 形式天然适配压缩，因为它不限制一个提示词会产生多少条轨迹，也不限制这些轨迹之间的相对长度：我们将所有经过压缩的子轨迹都作为可训练轨迹，从而把压缩机制引入训练，并使用 token 级损失处理它们的长度不均衡问题。
编程 RL 特别容易受到奖励作弊的影响，因为其奖励通常是可验证的通过/失败信号。我们发现，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)"
这些行为会虚增奖励并污染训练信号，因此需要一种明确的机制，将真正解决任务与走捷径区分开来。为此，我们在 RL 训练和评测中都引入了反作弊模块。检测过程分为两个阶段：首先使用基于规则的过滤器捕获潜在作弊行为，以最大化召回率；随后由 LLM 裁判检查这些被标记操作的意图，以保持较高的准确率。我们采用在线策略，监控每一步的工具调用。如果检测到作弊，系统就会阻止该调用，并返回虚假信息作为结果。重要的是，即使捕获到作弊操作，这种在线护栏仍允许模型继续执行 rollout。通过处理具体的无效行为，而不是拒绝整条轨迹，这种方法有助于避免因 rollout 被突然中止而可能导致的训练不稳定和模型崩溃。
在你喜爱的编程智能体中尝试 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 倍额度计费。限时优惠持续至 9 月底，期间非高峰时段的用量按 1 倍计费。（每日高峰时段为 UTC+8（北京时间）14:00–18:00。）
更喜欢 GUI？我们提供 ZCode——一款由 GLM-5.2 驱动的桌面智能体，支持通过 /goal 处理长时程任务、SSH 远程开发和移动端控制。特别优惠：在 ZCode 中通过 Coding Plan 使用 GLM-5.2，截至 6 月 30 日可获得 1.5 倍的有效额度。
立即开始构建：https://z.ai/subscribe
GLM-5.2 现已在 Z.ai 上线。
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。默认报告纯文本子集的结果；标有 * 的结果来自完整数据集。对于 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 个 token 的最大上下文长度，不采用任何上下文管理策略。
**SWE-Bench Pro：**我们使用 OpenHands 和专门定制的指令提示词运行 SWE-Bench Pro 套件。设置为：temperature=1、top_p=1、max_new_tokens=32k，上下文窗口为 400K。
**NL2Repo：**我们在 400k 上下文下评测 NL2Repo，参数为 temperature=1.0、top_p=1.0、max_new_tokens=48k。为防止作弊，我们结合基于规则的判断和基于 LLM 的判断，阻止恶意行为（例如未经授权的 pip 或 curl 操作）。
**DeepSWE：**我们使用官方 pier 评测框架和 mini-swe-agent 工具套件运行 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：**所有模型均在思考模式下，基于包含 500 项任务的公开子集进行评测，每项任务的超时时间为 10 分钟。我们使用 Gemini-3.0-Pro 作为评测的裁判模型。
**Tool-Decathlon：**我们使用官方评测服务，并将 max_token 设置为 128K。
**FrontierSWE：**评测由 Proximal 执行，使用 1M 上下文长度、最高强度级别和 128K 最大输出 token 数。报告的 Dominance 分数截至 2026/06/16。
**PostTrainBench：**评测由 PostTrainBench 执行，使用 1M 上下文长度、最高强度级别和 128K 最大输出 token 数。
**SWE-Marathon：**评测由 Abundant AI 执行，使用 1M 上下文长度、最高强度级别和 128K 最大输出 token 数。
本文提到的模型 1
非常令人惊叹的模型和发布，迫不及待想在开放式编程智能体中尝试达到 Opus 水平的开放模型。
等不及开放模型打破闭源模型的统治，让我们重新回到 GPT-2 之前那个前沿 AI 研究与开发真正透明的美好年代。
真的令人印象深刻。🥇
· 注册或登录后发表评论
本文提到的模型 1