GLM-5 由 Zhipu AI（Z.ai）于 2026 年 2 月 11 日发布，相较 GLM-4.7 在架构上实现了巨大的跃迁：更大的 MoE 规模（≈744B vs ~355B 总参数）、更高的激活参数容量、更低的测得幻觉率，并在智能体与编程基准上取得显著提升——代价是推理复杂度以及（有时）时延的增加。
什么是 GLM-5，为什么它的发布很重要？
GLM-5 是什么类型的模型？
GLM-5 是 Zhipu AI（Z.ai）最新发布的开放权重大型语言模型，于 2026 年 2 月 11 日发布。它是一种专家混合（MoE）Transformer，将 GLM 系列扩展到 ~744B 总参数，同时每次推理激活约 40B 参数（即模型的 MoE 路由让活跃计算远小于总参数量）。该模型采用 MIT 许可证，针对智能体工作负载进行了优化——用于长时间运行的多步骤任务，如编排工具、编写并完善代码、文档工程以及复杂知识工作。
相比早期 GLM 变体的核心改进是什么？
最重要变化的简短列表：
- 参数扩展： GLM-5 ≈ 744B 总参数（40B 激活）对比 GLM-4.7 的 ~355B 总参数 / 32B 激活——模型规模大约提升 2×。
- 基准与事实性： 在独立基准上显著提升（Artificial Analysis Intelligence Index：GLM-5 = 50 vs GLM-4.7 = 42），并在 AA Omniscience 指标上大幅降低幻觉（相对 GLM-4.7 报告降低 56 个百分点）。
- 智能体能力： 工具调用、计划分解与长周期执行的可靠性提升（Z.ai 将 GLM-5 定位为“智能体工程”）。
- 部署与芯片： 适配国产推理硬件（华为 Ascend 等）进行构建与基准测试，体现 Z.ai 向多样化芯片栈的迁移。
重要性：GLM-5 缩小了开放权重模型与专有前沿模型在智能体与知识任务上的差距——让高能力、开源模型成为需要可控部署与许可灵活性的企业的现实选择。
GLM-5 的新变化（详解）
定位：可扩展的“智能体工程”
Z.ai 明确将 GLM-5 定位为“智能体工程”模型：该类用例中，模型进行规划、发起工具调用、检查结果，并在多步骤中自主迭代（例如，构建 CI 流水线、分诊并修复失败测试套件，或拼接微服务）。这标志着从纯粹的单轮代码生成转向旨在跨执行轨迹与工具输出进行运行与推理的模型。
思维模式：保留/交织的推理
GLM-5 引入了更精细的“思考”模式（文档中有时称为interleaved thinking、preserved thinking），即模型可以输出并在后续轮次与工具调用中复用内部推理轨迹。实际效果是降低长流程中的重复推导开销，并在智能体必须在工具结果之间维护计划状态时提升一致性。GLM-4.7 曾引入早期的思考变体与工具感知行为；GLM-5 优化了机制与训练配方，使这些轨迹更可靠且可复用。
长上下文工程与系统稳定性
GLM-5 的训练与微调明确在超长上下文下进行生成测试（在 SFT/评估运行中为 202,752 token）。当你需要模型在一个提示中同时查看多个仓库、测试日志与编排输出时，这是一项实用的提升。在部分推理工作负载中，评估设置将生成长度推动到 131,072 token。这是为缓解在巨量上下文条件下常见不稳定性的显著工程投入。
架构与扩展（MoE）
公开报告显示 GLM-5 采用大规模 MoE 架构，总参数达数百亿级（公开统计约为 ~744–745B）。GLM-4.7 拥有针对不同部署权衡的 MoE 与 Flash 变体（例如，面向本地或低成本推理的“Flash”变体具有更小激活参数数）。MoE 设计帮助 GLM-5 提升峰值能力，同时提供配置选择（降低激活参数以实现更低成本推理）。根据你部署的变体，推理性能（时延、显存）会有所不同。
Z.ai 如何扩展并训练 GLM-5，相较 GLM-4.7 有何不同？
核心架构差异
| 特性 | GLM-5 | GLM-4.7 |
|---|---|---|
| 发布日期 | 2026 年 2 月（旗舰） | 2025 年 12 月 |
| 模型家族 | 最新一代 | 上一代 |
| 总参数 | ~744B | ~355B |
| 激活参数（MoE） | ~40B（每次前向传递） | ~32B（每次前向传递） |
| 架构 | 专家混合加稀疏注意力 | 带思维模式的 MoE |
| 上下文窗口 | ~200K token（相同基础大小） | ~200K token |
要点： 与 GLM-4.7 相比，GLM-5 的总容量几乎翻倍，并提升激活参数，这有助于增强推理与综合能力，尤其是在长篇技术内容、延展推理管线与复杂代码工程任务中。
架构：发生了哪些变化？
GLM-4.7 的较大变体采用专家混合（MoE）设计（文档为 ~355B 总参数，且每 token 的激活参数集更小以提升效率）。GLM-5 保留 MoE 式稀疏思路，同时叠加了新的稀疏注意力机制——报告称为 DeepSeek Sparse Attention（DSA）——它会将注意力资源动态分配给其认为重要的 token。该机制据称降低了训练/推理成本，同时保持（或提升）模型的长上下文推理能力，使模型能在保持可控算力的前提下处理远超旧检查点的上下文长度。
规模：参数与数据
- GLM-4.7：主 MoE 版本记录为约 355B 总参数（每次前向激活参数集远小于总参数，以提升效率）。
- GLM-5：报告为 ~744B 参数，并在预训练预算中使用了 ~28.5 trillion token，训练重点聚焦代码与智能体序列。这一组合旨在提升代码合成与持续的智能体规划能力。
参数跃迁、token 预算扩张与架构更新，是 GLM-5 在代码与智能体排行榜上取得更好数值结果的主要输入侧原因。
训练策略与后训练（RL）
在 GLM-4.7 引入“交织/保留思考”模式以提升多步骤推理与工具使用的基础上，GLM-5 通过以下方式正式化该流程：
- 通过中期训练日程扩展上下文长度（团队报告逐步扩展至 200K token）。
- 实施序列化 RL 后训练管线（Reasoning RL → Agentic RL → General RL），并采用在策略上的跨阶段蒸馏以避免灾难性遗忘。
- 引入异步 RL 与解耦的 rollout 引擎，在 RL 期间扩展智能体轨迹而不受同步瓶颈影响。
这些方法专门旨在提升长视野智能体行为——例如在模型进行多个相互依赖的工具调用与代码编辑的长会话中，保持稳定的内部状态。
GLM-5 与 GLM-4.7 的性能与能力对比如何？
基准与智能测度
| 评估领域 | GLM-5 | GLM-4.7 |
|---|---|---|
| 编程（SWE-bench） | ~77.8%（开源模型 SOTA） | ~73.8%（SWE-bench Verified） |
| 工具与 CLI 任务 | ~56%（Terminal Bench 2.0） | ~41%（Terminal Bench 2.0） |
| 推理（HLE 与扩展） | 得分约 30.5 → ~~50（结合工具，内部基准） | 约 24.8 → 约 42.8（HLE，结合工具） |
| 智能体与多步骤任务 | 显著更强（更长链） | 强（思维模式），但不如 GLM-5 深 |
解读：
- GLM-5 在核心编程与推理基准上整体优于 GLM-4.7，差距可量化。尤其体现在多步骤自动化、问题分解与深度逻辑任务上。
- 提升是非平凡的：例如 Terminal Bench 能力从 ~41% 跃升至 56%，这是智能体自动化可靠性的重大相对增幅。
- 在推理测试（如内部 HLE 指标）中，GLM-5 展示出更强的原始与工具增强的推理输出。
- 在真实世界智能体测试中也有可测增益：在 CC-Bench-V2 前端 HTML ISR 指标上，GLM-5 记录的 38.9% 相比 GLM-4.7 的 35.4% 在一部分前端任务上更优。（这是用于体现实际前端开发能力的自动评估指标之一。）
上下文大小与长文任务
- 两者均支持超大上下文（~200K token）——意味着它们能摄取并在更长文档、代码库或对话上进行推理。
- 真实世界的轶事报告显示，GLM-5 的某些部署在部分平台上偶尔出现感知到的上下文管理问题——但这可能反映宿主平台特定限制，而非模型设计本身。
工具与函数调用
两者都支持结构化函数/工具调用；GLM-5 在更复杂脚本逻辑上的执行保真度更高，尤其是在延展分支操作中。
示例：任务输出质量如何不同
编码示例（概念性）
- GLM-4.7： 能够生成胜任的单文件脚本，语法正确、逻辑清晰可读。
- GLM-5： 擅长多文件代码生成、深度调试建议与较长反馈循环，同时尽量减少上下文截断。
推理与规划
- GLM-4.7： 多步骤推理表现良好，但在非常深的推理链上偶有卡顿。
- GLM-5： 更擅长对推理进行分块、回忆先前步骤并在长链路中导航——有助于数据综合与多领域策略。
从 GLM-4.7 迁移到 GLM-5，延迟与成本如何变化？
延迟权衡及 GLM-4.7 的优势场景
短消息与敏捷 UI： 实践者基准显示，GLM-5 在短响应上可能增加一个小的固定开销（路由与专家选择的开销），在极小负载下会呈现略高的时延。对于超低延迟的小消息类 UI，GLM-4.7 或 Flash 变体仍具吸引力。
GLM-5 与 GLM-4.7 对比：
- GLM-4.7： 输入 $0.60/1M tokens，输出 $2.20/1M tokens。
- GLM-5： 输入 $1.00/1M tokens，输出 $3.20/1M tokens。
成本与人工编辑的权衡
当 GLM-5 能显著减少下游人工时间（例如编辑合并请求、分诊自动修复或避免重复模型调用）时，较高的模型价格是可被证明合理的。一个简单的决策规则：
若 GLM-5 将人工编辑时间减少超过 X%（X 取决于人工成本与每个工作流的 token 数量），尽管其每 token 成本更高，仍可能更具成本效益。多篇博客分析建模了此类盈亏平衡条件，发现对重度、重复的智能体工作流（如规模化的自动化代码修复），GLM-5 往往更划算。
延迟与硬件
推理显存与时延取决于变体（Flash、FlashX、完整 MoE）。社区指南显示，GLM-4.7 的 FlashX 与 30B Flash 变体可部署在 24GB GPU 上；完整 MoE 变体需要大型多 GPU 集群。GLM-5 的完整配置在相同吞吐下会需要更高的资源，尽管 MoE 稀疏性有助于降低每 token 的活跃计算。预期需要工程投入来调优量化、内存映射与流式处理以用于生产。
何时应从 GLM-4.7 升级到 GLM-5？
若以下情况，建议升级：
- 你需要更好的多文件代码推理、长上下文智能体编排或更高的端到端智能体成功率。
- 你的任务价值较高，能够接受更高的每次请求基础设施复杂度与成本。
若以下情况，建议继续使用 GLM-4.7：
- 你的工作负载是高频、短提示（分类、标注），成本与时延的可预测性比边际质量提升更重要。
- 适合继续使用 GLM-4.7 的用例
- 高吞吐、短负载： 聊天机器人、自动建议、微小改写任务——GLM-4.7（尤其是 Flash 变体）通常更便宜且时延更低。
- 预算受限且规模化的任务： 对于标签、分类或规模化执行的微任务，GLM-4.7 的效率与更低的每 token 价格很有吸引力。
- 你缺乏处理 MoE 分片/复杂自动扩缩的基础设施或预算。
我如何在 API 调用中选择模型？（示例）
cURL — 切换模型 ID（CometAPI / 兼容 OpenAI 的示例）：
# GLM-4.7
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-4.7","messages":[{"role":"user","content":"请总结这个仓库..."}],"max_tokens":800}'
# GLM-5
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-5","messages":[{"role":"user","content":"请总结这个仓库..."}],"max_tokens":1200}'
Python（requests）：将 model 字段改为 GLM-4.7 或 GLM-5——其余客户端代码可保持不变。
最终评估：
GLM-5 可被视为渐进式且带重要拐点：
- 渐进式：因为它延续了 GLM 家族的 MoE 与面向推理的设计，并持续迭代改进（4.5 → 4.6 → 4.7 → 5）。
- 拐点：因为它在规模上有实质提升、引入 DSA，并采用专为长视野智能体任务量身定制的 RL 课程——这些都在一系列实用基准上带来有意义且可测的提升。
若仅按排行榜排名评估，GLM-5 在多个指标上宣称开放权重领先，并在智能体与编程任务上缩小与顶级专有系统的差距。若从开发者体验与对时延敏感的使用场景评估，实践利弊仍需在更大规模部署中随时间验证。这意味着当用例需要持续的智能体能力时，GLM-5 很有吸引力；在许多当前生产需求中，GLM-4.7 仍是成熟、更快、且更具成本优势的选择。
开发者可通过 GLM-5 与 GLM-4.7 使用 CometAPI 即刻访问。开始之前，可在 Playground 探索模型能力，并查阅 API guide 获取详细说明。在访问前，请确保你已登录 CometAPI 并获取 API key。CometAPI 提供远低于官方价格的报价以帮助你集成。
准备好了吗？→ Sign up fo GLM-5 today