GLM-5.2：专为长时任务打造 来源：https://huggingface.co/blog/zai-org/glm-52-blog 返回文章 (https://huggingface.co/blog) Z.AI 的头像 (https://huggingface.co/zaiorg) - 面向 1M 上下文长度的架构 (https://huggingface.co/blog/zai-org/glm-52-blog#architecture-for-1m-context) - IndexShare for DSA (https://huggingface.co/blog/zai-org/glm-52-blog#indexshare-for-dsa) - 具有 IndexShare 和 KVShare 的 MTP (https://huggingface.co/blog/zai-org/glm-52-blog#mtp-with-indexshare-and-kvshare) - 高效服务 1M 上下文长度 (https://huggingface.co/blog/zai-org/glm-52-blog#efficiently-serving-1m-context-length) - slime 用于智能体强化学习 (https://huggingface.co/blog/zai-org/glm-52-blog#slime-for-agentic-rl) - 面向长时任务且具备反作弊能力的强化学习 (https://huggingface.co/blog/zai-org/glm-52-blog#rl-for-long-horizon-task-with-anti-hacking) - 完整基准测试表 (https://huggingface.co/blog/zai-org/glm-52-blog#full-benchmark-table) - 开始使用 GLM-5.2 (https://huggingface.co/blog/zai-org/glm-52-blog#getting-started-with-glm-52) - 配合 GLM 编程方案使用 GLM-5.2 (https://huggingface.co/blog/zai-org/glm-52-blog#use-glm-52-with-glm-coding-plan) - 在 Z.ai 上与 GLM-5.2 对话 (https://huggingface.co/blog/zai-org/glm-52-blog#chat-with-glm-52-on-zai) - 本地部署 GLM-5.2 (https://huggingface.co/blog/zai-org/glm-52-blog#serve-glm-52-locally) - 脚注 (https://huggingface.co/blog/zai-org/glm-52-blog#footnote) 我们正式推出 GLM-5.2，这是我们为长时任务打造的最新旗舰模型。它在长时任务能力上相比前代 GLM-5.1 实现了显著提升，并首次将这种能力建立在坚实的 1M token 上下文之上。GLM-5.2 的新能力包括： - 坚实的 1M 上下文：一个稳定的 1M token 上下文，能够持续支撑长时工作。 - 具有灵活思考强度的先进编程能力：更强的编程能力，提供多种思考强度级别以平衡性能和延迟。 - 改进的架构：我们提出 IndexShare (https://arxiv.org/abs/2603.12201)，在每四个稀疏注意力层之间复用同一个索引器，在 1M 上下文长度下将每 token FLOPs 降低 2.9 倍。我们还改进了 GLM-5.2 的 MTP 层以用于推测解码，使接受长度提升高达 20%。 - 完全开源：采用 MIT 开源许可证——无地域限制，技术获取不受边界约束。 支撑长时任务首先要让长上下文在工程上可用：模型必须在长而杂乱的编程智能体轨迹上保持质量，而不仅仅是能接受更多 token。声称拥有 1M 上下文很容易，但在真正的工程压力下保持可靠则困难得多。为此，我们大幅扩展了针对编程智能体场景的 1M 上下文训练，涵盖了大规模实现、自动化研究、性能优化和复杂调试。最终打造出一个不仅范围广，而且执行扎实的长上下文系统：一个可用于持续工程工作的实用基础。这项能力体现在 GLM-5.2 在三个长时编程基准测试上的表现。 FrontieSWE (https://www.frontierswe.com/) 衡量智能体是否能在数小时到数十小时的规模内完成开放式技术项目，涵盖系统优化、大规模代码构建和应用机器学习研究。在该基准上，GLM-5.2 仅落后 Opus 4.8 1%，同时领先 GPT-5.5 1% 和 Opus 4.7 11%。在 PostTrainBench (https://posttrainbench.com/) 上，每个智能体获得一张 H100 GPU，通过评估其在后训练阶段提升小型模型的能力，GLM-5.2 超越了 Opus 4.7 和 GPT-5.5，排名仅次于 Opus 4.8。在 SWE-Marathon (https://swe-marathon.vercel.app/) 上，这是一个超长时程的软件工程基准，涵盖构建编译器、优化内核和开发生产级服务等任务，GLM-5.2 仍有成长空间，落后 Opus 4.8 13%，但仍仅次于 Opus 系列。在这三个基准测试中，GLM-5.2 均为排名最高的开源模型，表明其 1M 上下文已转化为实际的长时交付能力。 图1 (https://cdn-uploads.huggingface.co/production/uploads/67066ea38a79951d7b8d4195/2w_Hx2JZ2eZFJPoVgggvu.png) 在标准编程基准上，GLM-5.2 是最强的开源模型，相比 GLM-5.1 大幅提升：Terminal-Bench 2.1 上 81.0 vs. 63.5，SWE-bench Pro 上 62.1 vs. 58.4。同时它大大缩小了与闭源前沿模型的差距——在 Terminal-Bench 2.1 (81.0) 上，与 Claude Opus 4.8 (85.0) 仅差几个百分点，并领先 Gemini 3.1 Pro。 图2 (https://cdn-uploads.huggingface.co/production/uploads/67066ea38a79951d7b8d4195/grPxoFi2PIFnuUnlW1zNK.webp) GLM-5.2 还引入了努力级别控制，使用户能够明确地在模型能力与任务执行速度和计算成本之间进行权衡。如图所示，在相似的 token 预算下，GLM-5.2 提供了比 GLM-5.1 更强的智能体编程性能，其能力大致介于 Claude Opus 4.7 和 Claude Opus 4.8 之间。此外，最大努力级别允许用户在挑战性任务中需要更高性能时分配额外计算资源，进一步扩展了模型的编程能力。这种设计为用户在使用 GLM-5.2 进行编程任务时提供了更大的灵活性，使他们能够针对不同场景选择最合适的推理模式。 图3 (https://cdn-uploads.huggingface.co/production/uploads/67066ea38a79951d7b8d4195/Ldcz9AqNEaCqWPwNXfCmS.png) ## https://huggingface.co/blog/zai-org/glm-52-blog#architecture-for-1m-context 面向 1M 上下文长度的架构 图4 (https://cdn-uploads.huggingface.co/production/uploads/67066ea38a79951d7b8d4195/beSnOOqWL0KuCMJX7vHi9.webp) ### https://huggingface.co/blog/zai-org/glm-52-blog#indexshare-for-dsa IndexShare for DSA 为了支持 1M 上下文长度，在 GLM-5.2 中，我们应用 IndexShare (https://arxiv.org/abs/2603.12201) 来降低 DSA 中索引器的计算成本。具体来说，在 GLM-5.2 中，每 4 个 Transformer 层共享一个轻量级索引器。索引器放置在 4 层的第一层，topk 索引用于 4 层。这减少了 3/4 层的索引器点积和 topk 计算。GLM-5.2 在 128K 序列长度的中期训练中即开始使用 IndexShare 进行训练，在长上下文基准上以更少的计算量超越了 GLM-5.1。 ### https://huggingface.co/blog/zai-org/glm-52-blog#mtp-with-indexshare-and-kvshare 具有 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 层中训练-推理不一致的问题。 图5 (https://cdn-uploads.huggingface.co/production/uploads/67066ea38a79951d7b8d4195/7tRY5CRMpDyjeI7YxZBMo.webp) 上图中我们展示了一个两步 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%) ### https://huggingface.co/blog/zai-org/glm-52-blog#efficiently-serving-1m-context-length 高效服务 1M 上下文长度 随着 GLM-5.2 将最大上下文长度从 200K token 扩展到 1M token，编程工作负载预计将显著向更长的提示转移。这将主要的推理瓶颈从计算转向 KV 缓存容量、长上下文内核开销和 CPU 端开销。虽然新的 GLM-5.2 架构降低了每 token 的计算 FLOPs，但它并未成比例地降低每 token 的 KV 缓存大小。因此，在有限的 GPU 资源下支持更长的上下文、更高的并发和更高的 token 吞吐量，成为了推理引擎优化的核心挑战。 图6 (https://cdn-uploads.huggingface.co/production/uploads/67066ea38a79951d7b8d4195/Gh9wRyZdgUVwiDPmL8VcI.webp) 为了应对这一挑战，我们从三个方向优化了推理引擎。首先，在 LayerSplit 的基础上，我们引入了更细粒度的内存管理和并行化策略，以增加 KV 缓存容量，并为超长上下文请求提供更多可用的缓存空间。其次，我们优化了那些成本随上下文长度增长的内核，并更好地协调它们与缓存传输管线，以最小化缓存传输对预填充和解码性能的影响。第三，我们优化了 CPU 端的缓存管理、请求调度和运行时执行路径，以减少 GPU 执行管线中的气泡，并提高端到端吞吐量。如图所示，随着上下文长度的增长，GLM-5.2 的吞吐量优势越来越大，在长上下文推理场景中表现出更强的可扩展性。 ## https://huggingface.co/blog/zai-org/glm-52-blog#slime-for-agentic-rl slime 用于智能体强化学习 GLM-5.2 的智能体强化学习后训练涉及更大规模、更多领域以及更复杂执行模式的任务。异构数据和任务需要在一个统一的训练过程中进行组织，而长时交互、工具使用、子任务分解和多轮环境反馈都对展开和训练编排提出了更高要求。为支持这一过程，slime 充当了从训练到大规模推理展开的一体化基础设施层。它支持多种训练和任务组织模式，包括白盒展开、黑盒展开、紧凑轨迹以及子智能体工作流，使同一系统能够扩展到更大和更复杂的强化学习及在线策略蒸馏（OPD）训练工作负载。在 GLM-5.2 的后训练过程中，我们使用 slime 框架进行了并行的 OPD 训练，高效地将十多个专家模型合并到最终模型中。整个 OPD 训练过程大约需要两天，展现了极高的训练效率。 智能体强化学习还对系统资源和推理基础设施提出了更高要求。slime 为推理系统提供了一个高度开放和灵活的接口：训练端可以连接不同形式的推理服务，并灵活适应不同的并行策略、路由策略、PD 分离设置和部署模式。同时，在强化学习展开过程中积累的配置经验、调度策略和优化路径可以在生产服务阶段复用并进一步细化，使训练端和服务端能够相互促进。这为从后训练到生产部署创建了一条更直接的路径。结合灵活的训练-推理资源组织和 KV 缓存 FP8，slime 为 GLM-5.2 的大规模智能体强化学习训练提供了关键的基础设施支持，进一步提高了系统效率、展开吞吐量和大规模推理并发能力。 ## https://huggingface.co/blog/zai-org/glm-52-blog#rl-for-long-horizon-task-with-anti-hacking 面向长时任务且具备反作弊能力的强化学习 面向长时任务的强化学习。对于 GLM-5.2，长时任务会产生更长的执行轨迹，一旦超长轨迹通过压缩被分割成多个子轨迹，同一提示下的不同展开会产生数量不同、长度差异很大的可训练轨迹。因此，我们从基于组的优化转向基于评论家的 PPO 公式，该公式从单个展开中学习，依赖评论家来估计 token 级别的优势，而不是组间比较。这种单展开公式自然适合压缩，因为它不限制一个提示产生的轨迹数量或它们的相对长度：我们将压缩引入训练，将所有压缩后的子轨迹作为可训练轨迹，并应用 token 级别的损失来处理它们之间的长度不平衡。 编程智能体中的反作弊。编程强化学习特别容易受到奖励作弊的影响，因为奖励通常是一个可验证的通过/失败信号。我们发现 GLM-5.2 比 GLM-5.1 表现出更多潜在的作弊行为。这使得验证信号容易优化，但未能真正提高模型的基本能力。智能体可以读取受保护的评估工件，从参考资料或上游提交中复制答案内容，或者在与 GitHub 相关的任务中直接获取目标源代码。例如，智能体可能通过 curl https://raw.githubusercontent.com/ 下载解决方案，甚至进行链式泄露，如 ```

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