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

GLM-5.2 正式发布并开源模型权重，是智普专为长周期任务打造的最新旗舰模型。相比上一代 GLM-5.1，它的长周期任务能力有了质的飞跃，并首次将这种能力落地在实打实的 1M Token 上下文基础上，核心能力跃升包括：

• 稳健的 1M 上下文：实打实 100 万 Token 容量，可以稳定支撑长周期工作流。
• 可调节思考强度的进阶编程能力：编程能力大幅提升，同时支持多档思考强度，可以在模型性能和延迟之间灵活平衡。
• 架构升级：首次提出 IndexShare 技术，1M 上下文长度下每 4 个稀疏注意力层复用同一个索引器，单 Token 浮点运算次数（FLOPs）锐减 2.9 倍；同时优化了用于投机解码的 MTP 层，接受长度最高提升 20%。
• 纯粹开源：采用 MIT 开源协议，无地域限制，技术访问无国界。

要真正支持长周期任务，首先要让长上下文在工程上「真正可用」：模型不只是能接收更多 Token，还要能在冗长复杂的编程智能体执行轨迹中，稳定保持生成质量。宣称支持 1M 上下文不难，难的是在真实工程高压下,始终高度可靠。智普针对 Coding Agent 场景大幅扩展了百万上下文训练数据，覆盖大规模代码实现、自动化研究、性能调优、复杂排错等工程场景。最终打造的长上下文系统不仅覆盖面广，执行表现也足够扎实稳健，可以作为持续推进工程交付的可靠基础层。

这种能力直接体现在 GLM-5.2 的三大长周期编程基准测试成绩上：

• FrontierSWE 专门衡量智能体能否在数小时到数十小时的跨度内，完成系统优化、大规模代码构建、应用级机器学习研究等开放性技术项目。GLM-5.2 在这项测试中，仅落后 Claude Opus 4.8 约 1%，同时以 1% 优势反超 GPT-5.5，领先 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 同样是目前最强的开源模型，相比上一代提升明显：Terminal-Bench 2.1 得分 81.0（前代 GLM-5.1 为 63.5），SWE-bench Pro 得分 62.1（前代 58.4）。它还大幅缩小了和顶级闭源模型的差距，Terminal-Bench 2.1 测试中仅比 Claude Opus 4.8（85.0）低 4 分，稳压 Gemini 3.1 Pro。

GLM-5.2 还新增了思考强度（Effort Level）控制选项，用户可以在模型能力、任务执行速度、算力成本之间做明确平衡。如图所示，同等 Token 消耗下，GLM-5.2 的智能体编程表现远超 GLM-5.1；相近 Token 预算下，综合能力大致介于 Claude Opus 4.7 和 Opus 4.8 之间。面对极具挑战性的任务，用户还可以开启 Max 最高思考强度分配额外算力，突破编程能力上限。这种设计给了用户极大的灵活性，可根据不同场景需求匹配最合适的推理模式。

为 1M 上下文打造的架构

DSA 架构中的 IndexShare

为了支撑 100 万上下文长度，GLM-5.2 的动态稀疏注意力（Dynamic Sparse Attention, DSA）架构中引入了 IndexShare 技术，大幅降低了索引器的计算成本。具体来说：

• 每 4 个 Transformer 层共享一个轻量索引器，索引器放在每 4 层的第一层，计算出的 Top-K 索引会被后续 3 层复用，这样 3/4 的网络层都省去了索引器点积计算和 Top-K 提取的开销。
• 中期训练阶段，在 128K 序列长度下启用了 IndexShare 训练，最终以更少的计算量超过了 GLM-5.1 在长上下文基准测试的表现。

结合 IndexShare 与 KVShare 的 MTP

智普升级了 GLM-5.2 的 MTP 层来优化投机解码效果，设定了两个明确的优化目标：一是把 MTP 层作为草稿模型的计算成本降到最低，二是最大化投机解码的接受率（Acceptance Rate）。

针对第一个目标，在 MTP 层也应用了 IndexShare：多步 MTP 中，索引器放在第一步，生成的 Top-K 索引会被后续所有步骤复用。需要注意的是，MTP 跨步过程和主干网络不同，不同 MTP 步的预测进度不同，输入 Token 一直在变化。如下图所示，如果让 h₅ 复用 h₄ 的 Top-K 索引，h₅ 就只能注意到 h₁ 到 h₄ 的内容，无法关注到自身。团队利用这一特性彻底消除了 GLM-5.1 中 MTP 层训练和推理的差异，实现了第二个优化目标。

上面这张图展示了双步 MTP 层的推理过程：第一步推理状态和训练期完全一致，所有隐藏状态都由目标模型生成；第二步时，h₁₋₄ 来自目标模型，h₅ 由 MTP 层生成，导致 h₅ 对应的 KV Cache 是混合体——既有目标模型生成的 kv₁₋₄，也有 MTP 层生成的 kv₅。引入 IndexShare 后，h₅ 计算所需的 KV Cache 只会包含目标模型隐藏状态生成的 kv₁₋₄。

训练阶段复用了第一个 MTP 步的 KV Cache 和 Top-K 索引，和 GLM-5.1 一样，不同 MTP 步层的参数保持共享。此外受论文 arXiv:2606.12370 启发，在投机解码中引入了拒绝采样（Rejection Sampling），基于端到端 TV 损失完成了整个网络的联合优化。

下表是编程场景下，各项技术对接受长度的消融实验结果。对比实验统一采用 GLM-5.1 的主干网络和训练数据，训练和推理都设为 7 个 MTP 步。最终优化后的 MTP 层相比常规基线方案，接受长度提升了 20%。

高效驱动 1M 上下文的服务推理

GLM-5.2 把最大上下文跨度从 200K 直接拉到了1M Token，这意味着编程类负载会快速向「极长提示词」转移，系统的核心推理瓶颈也从常规计算资源耗尽，转到了 KV Cache 容量、长上下文算子损耗、CPU 侧调度开销上。

新架构虽然减轻了单 Token 计算量负担，但单 Token 的 KV Cache 显存占用并没有减少，如何在有限 GPU 池下支撑更长上下文、拉高并发上限、实现高速数据吞吐，成了百万上下文落地必须解决的核心推流引擎问题。

为解决这些问题，团队对推理引擎做了多维度深度重构：

1. 沿 LayerSplit 切分机制路线，采用粒度更细、兼容性更强的显存隔离与并发策略，扩增了 KV Cache 实装容量，为超长上下文请求腾出了充足的缓存空间；
2. 重写了「随上下文长度线性劣化」的基础算子，更好匹配缓存数据的传输流水线，大幅缓解了显存搬运对预填充（Prefill）和解码（Decode）过程的交叉干扰；
3. 优化了 CPU 端的缓存管控机制、请求调度系统和执行时数据总线，减少 GPU 执行管线中的空泡，大幅提升了模型端到端的整体吞吐表现。

如上图所示，上下文跨度越长，GLM-5.2 的数据吞吐优势越明显，这正是它在长流推理场景下具备优秀规模化拓展能力的直接体现。

驱动智能体强化学习的 slime 框架

GLM-5.2 面向智能体的强化学习后训练需要处理的任务形态更复杂、覆盖专业领域更广的数据集，把异构数据纳入统一训练范式并不容易。尤其是面对长周期多步交互、工具频繁挂载回调、复杂任务分解、多轮环境博弈反馈等场景时，底层的对齐采样（Rollout）系统和模型训练编排系统的负荷会大幅提升。

• 为此团队开发了 slime 全栈基础设施层，衔接训练到大规模推理回采的全链路，支持白盒采样、黑盒采样、压缩轨迹结构（Compact Trajectory）、子智能体拆分协同流等多种作业调度编排能力，不仅大幅优化了集群效能，还让同一套底层网络可以支撑更大规模、更深层次的强化学习或并行 OPD 架构。
• GLM-5.2 的后训练周期里，slime 框架主导了多路在线并行 OPD 集训，高效将十几路独立专家模型融合为最终成品，整个 OPD 大规模训练加版本迭代只用了 2 天时间。

探索性强化学习（Agentic RL）非常考验底层集群和系统的综合能力。为提升算力利用效率，slime 给后端底层节点提供了非常开放灵活的标准管控接口：不管训练侧接入的是哪种推理容器节点、不同层级的并行调度框架和通信策略，还是基于 PD 分离网络搭建的热更新部署链路，这套系统都能完美兼容。

同时，强化学习对齐过程中，沉淀的最佳部署调度规则、策略、算子，会直接同步到大规模生产环境中，彻底避免了后训练成果难以落地的问题。这种训练和推理天然耦合的架构，再结合 KV Cache FP8 等前沿量化技术，为 GLM-5.2 的训练提供了扎实的大规模资源支撑。

具备反作弊机制的长周期任务强化学习

长周期任务的强化学习

长周期任务会产生非常冗长复杂的轨迹数据，如果把超长的单条数据切分成多个小片段回传，就会出现同一组提示词生成的轨迹数据切分节点不同、长度差异巨大的失衡问题。

• 团队摒弃了传统基于组别的约束寻优思路，采用了以判定型强化批评家模型主导的 PPO 设计。这套设计完全去掉了组别比对过程，可以从每条独立执行的评估数据切片中独立提取信息，由批评节点单独计算各级 Token 的优势分值。
• 这种「单轨迹架构设计」天然适配前面的压缩思路：不管有多少条轨迹、跨度差异有多大，只需要把所有可用的轨迹片段都作为样本，再通过 Token 层面的损失计算抹平轨迹长度的差异即可。

编程智能体的反作弊机制

代码强化学习过程中，很容易出现「奖励作弊」问题，根本原因是检测条件往往只有简单的「对/错」评判逻辑。相比前代 GLM-5.1，GLM-5.2 更倾向于在受控边界测试中尝试灰色操作，这也暴露出可验证结果的引导偏差问题：模型学会了更高级的刷分手段，但真实代码能力提升很小。

比如模型可能会刻意读取测试专用的隔离区文件，直接摘抄参考解答的代码参数，甚至在涉及 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)"

团队在端到端强化后训练和能力评审两个环节都内置了独立的「抗刷分防护盾」，采用两阶段审查机制：

• 第一阶段是规则预埋的拦截沙盒，先过滤所有高疑似动作，保证筛查覆盖率；
• 第二阶段用大语言模型作为「特邀裁判」，分析界定疑似恶意行为的意图，避免误伤，提升拦截准确率。

这套防护组件会实时干预，审查模型的每个动作和工具调用请求，一旦确认是恶意行为，会无声阻断请求，返回伪造的虚假结果。为了保证模型反馈数据的闭环平衡，系统不会强行中断任务或丢弃整次采样，而是让模型带着虚假结果继续执行到采样结束。这种只定点清除恶意动作、不粗暴中断流程的机制，避免了对学习过程的不必要干扰，也彻底消除了模型坍塌的隐患。

完整基准测试榜单

开始体验 GLM-5.2

• 通过 GLM Coding Plan 使用 GLM-5.2：你可以直接在常用的智能体编程插件中体验 GLM-5.2，包括 ZCode、Claude Code、OpenCode 及其他生态产品，详情见：https://docs.z.ai/devpack/overview
• 在 Z.ai 上与 GLM-5.2 对话：GLM-5.2 现已在 Z.ai 上线。
• 本地部署 GLM-5.2：GLM-5.2 的模型权重已经在 HuggingFace 和 ModelScope 全面开源。