GLM-5.2 正式发布:1M 上下文国产第一,编程能力与审美双双领跑
GLM-5.1-HighSpeed 面世时,我就曾表示十分期待 1M 长上下文版本。没想到仅仅数周之后,大家翘首以盼的 GLM-5.2 就带着 1M 上下文窗口如约而至。

全新发布的 GLM-5.2 可以这样概括:**1M 上下文窗口 + 国产模型中编程能力第一,**并且设计审美极具水准。
相较于此前 200K 上下文的旧版模型,GLM-5.2 在下列场景中的表现有了质的飞跃:整库级代码分析、Agentic Coding、超大规模代码仓库重构、一键网页翻新以及超长文档处理。
这些任务的共同点是上下文必须完整覆盖,任何压缩都会带来信息损失。
近几天我消耗了 3800 万 Token,也颇为认同社区用户的一则调侃:从这周开始,你很可能会发现中转站里那个看起来像 Opus 的服务,背后其实跑的是 GLM-5.2。

此外,在拥有全球百万用户参与盲测的前端开发评估系统 Code Arena 上,GLM-5.2 取得了全世界所有可用模型中的第一名。
这里要强调“全球可用模型”这一限定,因为表现最惊艳的 Fable 5 尚处于被封禁状态,无法公开使用。

在专门衡量模型设计审美的 Design Arena 榜单上,GLM-5.2 同样摘得全球第一。

三重核心升级
第一重:真正可用的 1M 上下文窗口
如果你是一名 Claude Code 或其他 Agent 工具的深度用户,一定经常通过 /context 命令或者状态栏来监控当前上下文窗口占用了多少。

一旦占用率超过 70%,模型就很容易给人一种“变笨”的感觉。这正是上下文窗口不够长带来的副作用——不敢直接读大文件,也不敢频繁使用搜索功能,几次操作之后可用的窗口空间就所剩无几了。
现在 GLM-5.2 把上下文支持从之前 GLM-5.1 的 200K 直接拓展到了 1M 级别。

官方数据显示:在 1M 长度下,检索和推理效果的衰减显著优于同类模型。这要归功于 GLM-5.2 在注意力结构上所做的优化——KV8、LayerSplit、IndexShare 4 与 HiSparse 这一套组合拳,同时压低了长序列的效果衰减与推理成本。在 MRCR、GraphWalk 两项长文本基准测试中,模型持续到 1024K 长度时依然能够维持稳中有控的衰减。
第二重:编程能力稳居国产与开源模型双料第一

在 SWE-Bench、Coding Arena 等核心编程评估基准上,GLM-5.2 继续保持国产模型第一、开源模型第一的位置,性能直接对标 Claude Opus 4.8。
第三重:长链任务不“忘事”
GLM-5.2 在长程任务上的表现也明显增强。在多项长序列基准测试中,它的成绩处于 Claude Opus 4.7 与 4.8 之间,是所有开源模型中排名最高的。我本人长时间深度使用的体感也证实了这一点。

实战案例对比
我们分别让 GLM-5.1 与 GLM-5.2 对同一个开源项目的仓库进行深度读取,各自生成一份详细的分析报告。之后我精读了两份报告,并请其他模型进行评判。结论是:GLM-5.2 的输出明显更有效,无论是全面性、深度还是准确度,都优于前代版本。

更令人欣喜的是,完成同样的仓库分析后,GLM-5.2 的上下文窗口仅使用了 12%。

而拥有 200K 窗口的 GLM-5.1 在执行同样任务时,窗口占用已接近 60%。这意味着还没正式开始开发,仅是全面读懂项目就消耗掉超过一半的上下文容量,后续多轮迭代的效果必然会大打折扣。

得益于长上下文的加持,GLM-5.2 即便面对大批量文件处理、需要多文件协同生成的长链办公任务,也表现得游刃有余。例如:一次性阅读上万字的 PRD 文档并生成上百个 APP 界面,或学习上百份合同文件后输出专业的审批意见。
继续观看:GLM-5.2 终于能用了:1M 上下文,Coding 继续国产第一。
同时,我对 GLM-5.2 的直出设计审美也进行了测试。仅使用一句提示词,不调用任何 Skill:“帮我生成一个 2026 美加墨世界杯宣传网站,要求大气、上档次。” 模型直接生成的页面告别了那种充满“AI 味”的紫红色调,设计理念自带审美。
继续观看:GLM-5.2 终于能用了:1M 上下文,Coding 继续国产第一。
长上下文实现的工程难题
要将上下文窗口拓展到 1M 级别,会面临计算量和 KV 缓存两大瓶颈:令牌数量上升后,原始注意力机制的计算复杂度呈平方级增长,从 128K 到 1M,稠密注意力几乎无法运行;同时每增加一个 token,KV 缓存都会持续膨胀,显存压力急剧攀升。这正是很多模型虽然标称支持 1M 上下文,但实际使用中又慢又贵,最终大家只能退回到 200K 的原因。

根据 GLM-5.2 的技术报告,团队在注意力结构上做出了创新设计:KV8 将每个 key/value 的分组数从常规的几组扩展到 8 组,实现更细粒度的注意力分流;LayerSplit 在不同层采用差异化的稀疏策略;IndexShare 4 让相邻 token 共享索引;HiSparse 则实现层级稀疏。整套体系的目标就是大幅提升长序列吞吐、显著降低 KV 缓存开销。与 DSA 等稀疏注意力方案相比,这套组合在成本端仍有进一步的压缩空间。最终的结果是,1M 上下文不再是“能跑但用不起”的纸面规格。
如何快速用上 GLM-5.2
模型在发布当天就已经全面可用。好消息是 Coding Plan 用户也可直接体验,但坏消息是你可能需要拼手速才能抢到资源:
购买 Coding Plan:https://www.bigmodel.cn/glm-coding?ic=UX7NF0VZ4S

Coding Plan 用户可以通过 cc-switch 复制之前 GLM 的配置,然后把模型字段改为 GLM-5.2,将上下文窗口设置为 [1m],重启 Claude Code 即可生效。同样适用于 OpenCode 以及其他支持自定义模型配置的工具,具体配置方式可参考以下文档:
配置说明:https://docs.bigmodel.cn/cn/coding-plan/latest-model
开源仓库及模型链接
GitHub:https://github.com/zai-org/GLM-5Hugging Face:https://huggingface.co/zai-org/GLM-5.2ModelScope:https://modelscope.cn/models/ZhipuAI/GLM-5.2
官方 API 接入
BigModel 开放平台:https://docs.bigmodel.cn/cn/guide/models/text/glm-5.2Z.ai:https://docs.z.ai/guides/llm/glm-5.2
在线体验入口
Z.ai:https://chat.z.ai智谱清言 App / 网页版:https://chatglm.cn

