GLM-5.2 终于能用了：1M 上下文，Coding 继续国产第一。

逛逛GitHub — Wed, 17 Jun 2026 16:55:23 +0800

GLM-5.2 终于能用了：1M 上下文，Coding 继续国产第一。

原创逛逛逛逛GitHub

前段时间 GLM-5.1-HighSpeed 发布的时候。

我就说期待 1M 的版本。

没一个月， GLM-5.2 带着期待已久的 1M 上下文来了。

新模型 GLM-5.2 发布了 ，一句话总结： 1M 上下文 + Coding 国产第一， 而且审美很顶。

相比之前 200K 上下文的模型， GLM-5.2 做下面这些事儿，表现更棒了：整库代码分析、 Agentic Coding、巨型代码库重构、一键网站翻新、超长文档场景。

这些场景的共同点都是 上下文必须一次到位，压缩就是损失 。

这两天用了 38M 的 Token，挺赞同网友所说的：本周开始，你中转站的 Opus 背后可能是 GLM-5.2 冒充的。

另外，有一个全球百万用户参与盲测的前端开发评估系统 Code Arena 上， GLM-5.2 取得全球可用模型第一。

注意这里指的是全球可用模型哦， Fable 5 最牛但被封了。

还有一个专门评测模型品味 taste 的 Design Arena 上。

GLM-5.2，全球第一的表现。

这次升级，核心三件事

第一件：1M 上下文，但是真正能用的 1M。

如果你是 Claude Code 或者其它 Agent 工具的深度用户。

一定会经常用 /context 命令或者装一个 status line 看看当前上下文窗口占用多少了。

一到 70% 就感觉降智了。

很多人感觉用着用着就变傻了，就是这个原因。

上下文太短，不敢直接读大文件、不敢用搜索，俩操作上下文直接没了大半。

现在好了 GLM-5.2 支持 1M 上下文了，直接从 GLM-5.1 的 200K 拉到 1M 上下文。

而且官方说： 1M 长度下检索和推理效果的衰减，明显小于同类模型。

这是因为 GLM-5.2 在注意力结构上动刀了。

KV8 + LayerSplit + IndexShare 4 + HiSparse 一套组合拳，把 1M 长度下的效果衰减和推理成本同时压下来。

MRCR、GraphWalk 这两个长文基准 SOTA，到 1024K 那个位置衰减仍然可控。

第二件：Coding 继续国产第一、开源第一

SWE-Bench、Coding Arena 这些核心编程基准继续保持国产模型第一、开源模型第一。

对标 Claude Opus 4.8。

第三件：长任务，不忘事。

GLM-5.2 做一些长程的任务表现更好了。

在下面这些长程任务基准上，GLM-5.2 的表现在 Claude Opus 4.7 与 4.8 之间，是排名最高的开源模型。

我深度使用的体感也是。

看几个 Case

分别让 GLM 5.1 和 GLM 5.2 对同一个开源项目的仓库进行深度读取。

输出一个深度的分析报告。

最后自己仔细看了两个模型生成的报告，并让其它模型 Judge 了一下。

结论是： GLM-5.2 报告明显更有效。

不管是全面性、深度还是准确性上都要更好一些。

而且一通操作下来， GLM-5.2 的上下文窗口才用了 12%

而 200K 的 GLM-5.1 的上下文窗口直接用了接近 60%。

还没开始开发，只是对当前项目进行一个全面读取就用了一半多，后面继续迭代的效果可想而知。

而这种问题在 GLM-5.2 上不会出现了。

除了 Coding，因为长上下文的加持，在一些办公场景上：大批量文件处理、长程涉及多文件生成的任务都能很好的满足了。

阅读一个万字的 PRD 文档，一次生成 100 多个 APP 界面
学习 100 多个合同文件，输出专业的审批意见

另外，关于 GLM-5.2 的直出审美上，我也做了测试。

在 GLM-5.2 输入了一个提示词：

不要用任何 Skill，帮我生成一个2026美加墨世界杯宣传网站，要求大气、上档次。

效果如下，不再是那种紫了吧唧的 AI 味儿很浓的页面。

自带审美的模型 🐂

为什么长上下文这件事这么难

1M 上下文的难点在窗口开大之后，计算量和 KV 缓存就立刻贵起来、慢起来、衰减起来。

计算量：注意力机制的计算复杂度随长度平方级膨胀，128K 都还扛得住，到了 1M 量级，原始的稠密注意力根本跑不动了。

KV 缓存：每多一个 token，缓存占用就涨一截，长任务的显存压力会非常夸张。

这就是为什么很多模型官方号称支持 1M，真用起来又慢又贵，最后大家还是默认 200K 凑合用。

可以看看 GLM-5.2 的技术报告，他们的解法是在结构上做创新。

KV8 把每个 key/value 的分组数从标准的几组扩到 8 组，注意力分流更细。
LayerSplit 在不同层用不同的稀疏策略。
IndexShare 4 让相邻 token 共享索引。
HiSparse 做层级稀疏。

整套设计目标就是 长序列的吞吐大幅提升，KV 缓存占用大幅下降 。

跟 DSA 这一类稀疏注意力方案对比，这套组合在成本上还有进一步压缩空间。

1M 不再是能跑但用不起。

怎么用上

发布当天就能用了。

好消息是 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

点击下方卡片，关注逛逛 GitHub

这个公众号历史发布过很多有趣的开源项目，如果你懒得翻文章一个个找，你直接关注微信公众号：逛逛 GitHub ，后台对话聊天就行了：

继续滑动看下一个

逛逛GitHub

向上滑动看下一个