Z.ai 发布开源模型 GLM-5.2：稳定 1M 上下文主打长程编程

GLM-5.2 是 Z.ai 刚刚开源的旗舰级编程模型，核心主打需要长时间持续推进的长程复杂任务，并把工程可用的上下文长度直接拉到了 1M token。整个模型遵循 MIT 开源协议发布，没有任何地域使用限制，相关技术细节和权重已经在 Hugging Face 和官方博客公开。

长程任务与实测表现

大多数长上下文模型在面对真实代码工程时，往往只是形式上能塞进大量 token，一旦执行轨迹变长就会陷入混乱。GLM-5.2 重点针对耗时数小时甚至数十小时的复杂工程场景进行了大规模训练，涵盖底层系统优化、编译器构建、自主研究与复杂调试。

在衡量长程软件工程能力的几个核心基准测试上，GLM-5.2 成为了目前排名最高的开源模型。在针对数小时至数十小时项目的 FrontierSWE 测试中，GLM-5.2 的成绩仅比闭源顶尖模型 Claude Opus 4.8 低了 1%，同时以 1% 的优势击败了 GPT-5.5，并领先 Opus 4.7 达 11%。

在评估 Agent 能否利用单张 H100 优化小模型的 PostTrainBench 上，它同样超过了 Opus 4.7 和 GPT-5.5，仅次于 Opus 4.8。在涉及内核优化和工业级服务开发的 SWE-Marathon 上，它落后 Opus 4.8 约 13%，依然稳居开源第一。

在常规编程测试中，GLM-5.2 同样大幅刷新了前代的纪录。它的 Terminal-Bench 2.1 得分从上一代的 63.5 飙升至 81.0，逼近 Opus 4.8 的 85.0，并领先 Gemini 3.1 Pro；SWE-bench Pro 分数也从 58.4 提升到了 62.1。

为了平衡性能和延迟，GLM-5.2 还引入了思考力度调节机制。用户可以在轻量任务中使用较低档位以节省计算资源，在遇到极端复杂的代码重构或调试时开启 Max 档位，投入更多推理算力以换取更高的完成度。

怎样把 1M 上下文跑得又快又稳

把上下文拉长到 1M token，最大的障碍是计算开销和显存瓶颈。GLM-5.2 在架构上提出了名为 IndexShare 的稀疏注意力机制。简单来说，它让连续 4 层 Transformer 共享同一个轻量索引器，只在第一层计算 top-k 索引，后三层直接复用。这项改动让模型在 1M 上下文下的单 token 计算量直接降低了 2.9 倍。

在推测解码方面，团队改进了多 token 预测层，通过复用 KV 缓存与索引、引入拒绝采样和端到端全变差损失训练，消除了前代训练与推理不一致的缺陷，使投机解码的平均接受长度提升了 20%。

在部署工程层面，团队优化了底层推理引擎。通过精细化的显存管理扩展 KV 缓存容量，配合 FP8 格式和 CPU 侧的请求调度优化，减少 GPU 运行时的流水线空转。

为了支撑长程强化学习，Z.ai 采用了名为 slime 的基础设施框架，支持长轨迹压缩与基于评论家的 PPO 训练，两天内就完成了十几个专家模型的并行融合。针对编程智能体容易偷懒抄答案的现象，团队还专门设计了反作弊模块，防止模型通过在工作区搜索隐藏测试用例或调用远程代码来刷分。

为什么重要

如果你正在搭建自主代码 Agent，或者需要让模型一次性消化一整套大型代码仓库，GLM-5.2 是目前开源领域最值得部署的选择。它彻底抹平了开源模型在超长上下文编程任务中与顶尖商业模型之间的代差，甚至在部分严苛基准上压过了 GPT-5.5。

更难得的是它彻底的 MIT 协议和无地域限制策略。不过开发者也需要清醒地看到，即便通过 IndexShare 砍掉了将近三分之二的单 token 算力消耗，1M 上下文带来的 KV 缓存容量压力依然摆在那里。要想在本地或私有集群完整跑满 1M 上下文的并发服务，硬件门槛和显存调度依然是一笔不可忽视的硬成本。