GLM-5.2新模型支持1M真正可用上下文，在SWE-Bench等编程基准中保持国产及开源模型第一，长程任务表现介于Claude Opus 4.7与4.8之间。Coding Plan用户可即刻通过配置cc-switch接入，开源权重已上线GitHub和Hugging Face。
Tags:
前段时间 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，全球第一的表现。
01
这次升级，核心三件事
第一件：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 之间，是排名最高的开源模型。
我深度使用的体感也是。
02
看几个 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 味儿很浓的页面。
自带审美的模型 🐂
03
为什么长上下文这件事这么难
1M 上下文的难点在窗口开大之后，计算量和 KV 缓存就立刻贵起来、慢起来、衰减起来。
计算量：注意力机制的计算复杂度随长度平方级膨胀，128K 都还扛得住，到了 1M 量级，原始的稠密注意力根本跑不动了。
KV 缓存：每多一个 token，缓存占用就涨一截，长任务的显存压力会非常夸张。
这就是为什么很多模型官方号称支持 1M，真用起来又慢又贵，最后大家还是默认 200K 凑合用。
可以看看 GLM-5.2 的技术报告，他们的解法是在结构上做创新。
KV8 把每个 key/value 的分组数从标准的几组扩到 8 组，注意力分流更细。
LayerSplit 在不同层用不同的稀疏策略。
IndexShare 4 让相邻 token 共享索引。
HiSparse 做层级稀疏。
整套设计目标就是长序列的吞吐大幅提升，KV 缓存占用大幅下降。
跟 DSA 这一类稀疏注意力方案对比，这套组合在成本上还有进一步压缩空间。
1M 不再是能跑但用不起。
04
怎么用上
发布当天就能用了。
好消息是 Coding Plan 的用户也能用上，坏消息是你可能抢不到：
购买 Coding Plan：https://www.bigmodel.cn/glm-coding?ic=UX7NF0VZ4SCoding 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
05
点击下方卡片，关注逛逛 GitHub
这个公众号历史发布过很多有趣的开源项目，如果你懒得翻文章一个个找，你直接关注微信公众号：逛逛 GitHub ，后台对话聊天就行了：
没有评论:
发表评论