GLM-5.1:它到底是什么水平,值不值得用

我最近用 GLM-5.1 做了一段时间的日常开发,同时翻了一遍能找到的公开评测数据和技术报告。这篇文章把我的实际感受和客观数据放在一起谈,尽量说清楚 GLM-5.1 到底强在哪、弱在哪、和 Claude Opus 4.6 差多少,以及它对智谱这家公司意味着什么。

先说结论:GLM-5.1 在编码场景下已经非常接近 Opus 4.6 的水平,差距大约 5%,日常开发中几乎感知不到。但这个判断有前提条件,后面展开说。


先搞清楚 GLM-5 和 GLM-5.1 的关系

GLM-5.1 不是从零开始的新模型。它基于 GLM-5 的同一套基座,在后训练数据和强化学习策略上做了针对性升级,主要瞄准写代码和 Agent 工作流两个方向。你可以把它理解为同一代架构的”编码增强补丁版”。

GLM-5 本身的规格已经公开得比较充分:

  • 总参数约 744B,激活参数约 40B,采用 MoE(混合专家)架构,256 个专家路由,稀疏度大约 5.9%。
  • 上下文窗口 200K tokens,最大输出 128K tokens。
  • 预训练数据约 28.5T tokens。
  • 在华为昇腾 910 万卡集群上完成全量训练。

GLM-5.1 的精确参数官方没有单独披露。根据已有信息的合理推测,它沿用 744B MoE + 200K 上下文的设计,变化集中在训练数据配比和对齐策略上。

这里有一个细节值得注意:GLM-5 在昇腾 910 上完成训练,是国内首个在国产算力上训练到 700B 级别的开源大模型。GLM-5.1 能在同一个算力体系上快速迭代出来,说明这套工程链路已经跑通了,后续更新频率有望保持。


综合能力:不只是代码

GLM-5 的通用能力已经有比较完整的评测数据:

  • Artificial Analysis Intelligence Index v4.0 上拿到 50 分,是第一个达到这个分数的开源权重模型。上一代 GLM-4.7 是 42 分,提了 8 分。
  • LMArena 的真实用户对战平台上,GLM-5 在文本和代码两个类别都是开源模型第一。这个平台的评测方式是真实用户盲评,不是跑固定题库,所以更能反映实际对话体验。

200K 的上下文长度意味着你可以把几篇长文档或者一个中型代码库直接丢进去。GLM-5 用了 DeepSeek 的稀疏注意力机制来压低长文本的计算成本,实际使用中响应速度确实没有因为上下文变长而明显退化。

GLM-5.1 目前没有单独公布通用评测成绩。但考虑到它和 GLM-5 共享基座,通用理解、推理、长文本这些维度上不太可能退步。如果你主要关心通用问答而非写代码,直接参考 GLM-5 的成绩即可。


编码能力:这才是重头戏

GLM-5 的基线成绩

先看 GLM-5 在几个主要编码基准上的表现:

  • SWE-bench Verified:77.8%。这个成绩是什么概念?Claude Opus 4.5 是 80.9%。差距不到 4 个百分点。
  • Terminal-Bench 2.0:56.2。这个评测测试的是模型在真实终端环境下的表现——会不会用 bash、能不能跑测试、能不能根据报错信息调试,而不是只写单个函数。
  • CC-Bench-V2(前端开发):98%,比 Claude 还高 5 个百分点。

这几个评测的共同特点是测的是”工程能力”而非”算法题能力”。SWE-bench 要求模型在一个真实的多文件代码仓库中完成 issue 修复;Terminal-Bench 要求模型在命令行环境中完成完整的工作流。这比 HumanEval 那种”补全一个函数”的测试难得多,也更接近日常开发。

GLM-5.1 的提升幅度

GLM-5.1 最硬的数据来自一组用 Claude Code 作为统一测试框架的对比评测:

模型编码评分相对 Opus 4.6
GLM-535.473.9%
GLM-5.145.394.6%
Claude Opus 4.647.9100%

从 GLM-5 到 GLM-5.1 提升了约 28%。和 Opus 4.6 的分差只有 2.6 分。

我自己的体感和这个数据基本吻合。日常写 React 组件、调 API 接口、写 SQL 查询、排查报错日志这些任务,GLM-5.1 和 Opus 的表现差异确实很小。真正能拉开差距的场景是那种需要跨十几个文件重构、同时理解业务逻辑和底层框架设计的任务——这种情况下 Opus 的规划能力还是略好一些,但差距在缩小。

需要说明的是,这组评测没有拆分到具体子项(比如前端、后端、DevOps 各自的得分),所以无法精确判断 GLM-5.1 在哪个细分领域更突出。但结合 GLM-5 在 SWE-bench 和 Terminal-Bench 上的基线成绩,多文件重构、bug 定位与修复、跨语言协作、自动运行测试并循环调试这些场景,GLM-5.1 应该比 GLM-5 更稳定、更少走弯路。


思考模式与 Agent 设计

GLM-5/5.1 有一个我比较喜欢的设计:思考模式可以按轮开关。

轻量级的问题(比如”这个函数怎么用”)直接关掉思考模式,响应快、成本低。复杂的工程任务(比如”帮我重构这个模块”)开启思考模式,模型会在回答前先做一轮内部推理。这个设计在工程上很实用,比那种所有请求都强制深度思考的方案更灵活。

在 Agent 层面,GLM-5 的技术报告提到了 Slime 异步智能体强化学习框架。简单说,模型不是只做单轮问答,而是被训练成能在一个”思考 → 调用工具 → 观察结果 → 继续推理”的循环中持续工作。GLM-5.1 部署在 GLM Coding Plan 中就是按照这个模式运行的——你在编辑器里描述需求,背后的系统用 5.1 做任务拆解、代码生成、运行、调试、提交。

实际使用下来,GLM-5.1 在连续多轮的 Agent 工作流中表现尚可,但偶尔会在长链条推理中丢失上下文,需要人工介入纠偏。这一点 Opus 4.6 稍好一些,维持长程一致性的能力更强。


对智谱意味着什么

分开来说。

技术层面:GLM-5 在开源编码基准上已经是第一梯队,GLM-5.1 把和闭源顶级模型的差距压缩到了 5% 以内。对整个开源社区来说,这是一个有参照意义的标杆——它证明开源模型在编码这个高价值场景上已经可以和闭源模型正面对话。

算力自主层面:GLM-5 在昇腾 910 上完成训练,GLM-5.1 在同一套体系上快速迭代出来。这条链路跑通意味着智谱不再依赖海外 GPU 供给来维持更新节奏。在国内的政策环境和产业链语境下,这个能力的实际价值可能比模型本身的参数提升更大。

商业化层面:智谱的 Coding Plan 把 GLM-5.1 封装成订阅服务,定价明显低于 Claude 和 GPT 的同类产品。编码能力接近 Opus,价格是 Opus 的一小部分——这个性价比对中小团队和个人开发者很有吸引力。更多的用户意味着更多的真实开发场景数据,这些数据反过来可以用来改进模型,形成一个正向循环。

战略方向层面:GLM-5 技术报告的标题是”从 Vibe Coding 到 Agentic Engineering”,说的就是从”让 AI 写几段代码”进化到”让 AI 承担完整的工程任务”。GLM-5.1 是这个方向的第一个产品化落地。能不能真正把模型变成一个可信赖的工程伙伴,而不是一个偶尔能写对代码的聊天工具——这是智谱接下来要回答的问题。


我的判断

基于目前的公开数据和我的实际使用体验:

日常开发够用吗?够用。写代码、调 bug、重构、写测试、处理 Git 工作流,GLM-5.1 的表现已经接近 Opus 4.6。考虑到价格差异,作为日常主力编码工具是合理的。

有什么短板?超大规模的跨仓库重构、需要深度理解底层框架设计原理的任务,以及超长链条的 Agent 推理,这些场景下和 Opus 还有可感知的差距。另外,GLM-5.1 的技术细节公开得不够多,很多参数还是推测值,这对想深入研究的人来说不太友好。

值不值得关注?值得。无论你是开发者还是关注 AI 行业的人,GLM-5.1 代表了一个趋势:开源模型正在快速追赶闭源模型,而且国产算力已经能支撑这个追赶过程。这个趋势本身比单个模型的得分更有意思。


参考文献

  1. Datalearner – GLM-5.1 模型页面. https://www.datalearner.com/ai-models/pretrained-models/glm-5-1
  2. API Yi – GLM-5.1 Coding Plan 与 Claude Opus 对比指南. https://help.apiyi.com/en/glm-5-1-coding-plan-claude-opus-alternative-api-guide-en.html
  3. 智谱 BigModel 文档 – GLM-5 模型说明. https://docs.bigmodel.cn/cn/guide/models/text/glm-5
  4. GLM-5 技术报告(arXiv). https://arxiv.org/html/2602.15763v1
  5. 腾讯云开发者社区 – GLM-5 评测分析. https://cloud.tencent.com/developer/article/2634050
  6. Z.ai 开发者文档 – GLM-5.1 使用指南. https://docs.z.ai/devpack/using5.1
  7. MEXC – GLM-5.1 发布新闻. https://www.mexc.com/news/986837
  8. UniFuncs – GLM-5 架构分析. https://s.unifuncs.com/?sid=5073f06b-1248-4ed0-a539-aa6b0af0c731
  9. 昇腾社区 – GLM-5 在昇腾 910 上的训练实践. https://ascendai.csdn.net/699444a054b52172bc5c25ff.html
  10. 腾讯云开发者社区 – GLM-5 技术解读. https://cloud.tencent.com/developer/article/2632350
  11. Verdent AI – GLM-5 编码基准分析. https://www.verdent.ai/es/guides/glm-5-coding-benchmark-reality-check
  12. Facebook – GLM-5.1 编码能力差距分析. https://www.facebook.com/0xSojalSec/posts/new-glm-51-releases-the-coding-gap-between-open-and-closed-source-is-practically/1478621867125545/
  13. 博客园 – GLM-5 相关讨论. https://www.cnblogs.com/muziji/p/19652862
  14. Verdent AI(德语)- GLM-5 编码基准. https://www.verdent.ai/de/guides/glm-5-coding-benchmark-reality-check
  15. Reddit r/LocalLLaMA – GLM-5 技术报告讨论. https://www.reddit.com/r/LocalLLaMA/comments/1r7r7zr/glm5_technical_report/

3 Comments

  1. One thing that really resonated with me was the article’s emphasis on GLM-5.1’s performance in *real terminal environments* (Terminal-Bench 2.0), where it scored 56.2—on par with high-end models. This detail matters because so many benchmarks still focus on isolated function generation, which doesn’t reflect actual dev workflows. I’ve used GLM-5.1 in my own daily coding, especially while building tools at AI Ad Creatives, and can confirm that its ability to run commands, interpret errors, and iterate through test cycles feels far more “hands-on” than older models. It’s not just writing code—it’s *working* with it like a real developer. That’s a big leap from the “copy-paste from docs” era. What’s even more promising is how this capability supports long-term agent workflows, which is critical if you’re automating tasks across multiple services or deploying AI-powered creatives at scale.

  2. LensUp PDF Tools

    这篇把实测感受和公开数据分开摆,比单纯罗列跑分有用。5% 那个差距我信,不过我更信后面那段前提条件——写代码感知不到,不等于换个 Agent 工作流也感知不到。

    上周给家里人整理签证材料,手机拍的一堆证件和票据要压到门户规定的体积以内,顺手用 lensup.ai 转成能直接打印的 PDF。压缩是按你选的那个目标来的,偶尔会稍微超出一点,换档再压一次就行。文件没有上传,处理就在浏览器里跑完。

  3. CrazyJev Team

    我用 CrazyJev 跑日常小任务有阵子了,上周拿它掐了个 75 秒的 IKEA 组装计时,又顺手在 Room Rush 里比了两把反应速度,图个乐。看完你写的 GLM-5.1 那段,编码接近 Opus 4.6、差距约 5% 这个判断我挺认同,日常确实不太摸得出边界,不过前提条件那块你说得也对,真到复杂 Agent 流程还是得盯着点。文章把公开规格和实测感受分开摆,读着踏实。

Leave a Reply

Your email address will not be published. Required fields are marked *