GLM-5系列模型解析｜744B MoE、稀疏注意力与Agentic Engineering

理解 GLM-5 系列，不能只看“744B 参数”这一项。它真正值得关注的变化，是模型规模、稀疏注意力、强化学习训练方式和长时程 Agent 能力开始被放到同一条技术路线中考虑。

先给结论：GLM-5 的核心不是把模型简单做大，而是通过 744B-A40B MoE、DeepSeek Sparse Attention（DSA）和大规模异步强化学习，提升复杂推理、代码与 Agent 任务能力；随后 GLM-5.1 进一步强化长时间、多轮工具调用下的持续执行能力，GLM-5.2 则把这一能力延伸到更稳定的 1M Token 上下文，并继续优化稀疏注意力和推理解码效率。整个系列的方向，正在从“模型一次回答得好不好”逐步走向“模型能否持续完成复杂工程任务”。

概述：GLM-5 系列在解决什么问题？

GLM-5 官方将模型定位为面向复杂系统工程和长时程 Agentic 任务的基础模型。相比 GLM-4.5，GLM-5 的总参数量由 355B 提升至 744B，单次前向计算中的激活参数由 32B 提升至约 40B，同时预训练数据规模从 23T tokens 增至 28.5T tokens。

但参数扩展只是第一层。对于 Coding Agent、终端操作、软件工程和复杂工具调用任务，模型还需要在较长任务周期内持续读取状态、做判断、执行动作、观察结果，并根据反馈修改策略。因此，GLM-5 系列后续的演进重点越来越集中在三个问题上：

如何扩大模型容量，同时控制每次推理真正参与计算的参数规模？
如何在超长上下文中降低 Attention 的计算开销？
如何让模型在数十轮、数百轮甚至更长的工具调用过程中持续工作，而不是只擅长一次性生成？

GLM-5、GLM-5.1、GLM-5.2 的技术演进

版本	官方重点	技术关键词	更容易理解的变化
GLM-5	复杂系统工程与长时程 Agentic 任务	744B-A40B MoE、DSA、异步强化学习	扩大模型容量，同时降低长上下文和后训练的成本压力
GLM-5.1	Agentic Engineering	长时程任务、持续迭代、工具调用	不只关注第一次回答，而是强调模型能否长时间保持有效工作
GLM-5.2	更稳定的长时程能力	1M Context、IndexShare、改进 MTP、Flexible Effort	让更长任务历史、更复杂上下文和推理效率同时进入工程优化范围

需要说明的是，本文聚焦 GLM-5 官方仓库已经清晰披露的 GLM-5、GLM-5.1 与 GLM-5.2 技术路线，不展开 GLM-5.3 的本地部署配置。GLM-5.3 的 GPU、Context、KV Cache 与推理框架选型，可参考知识库中的独立部署条目。

744B-A40B 是什么意思？为什么总参数和激活参数差这么大？

GLM-5 采用 MoE（Mixture of Experts，混合专家）架构。官方将其标记为 744B-A40B：约 744B 代表模型总参数规模，A40B 表示单次前向计算中实际激活参与计算的参数规模约为 40B。

MoE 的核心思路不是每个 Token 都经过全部专家，而是通过路由机制选择其中一部分专家参与计算。这样可以在扩大模型总容量的同时，避免每次推理都按全部 744B 参数执行同等规模的计算。

这里最容易出现两个误区：

744B 不等于单次推理要计算全部 744B 参数。MoE 会稀疏激活部分专家。
40B Active 也不等于模型部署只需要按照普通 40B Dense 模型理解。总权重、专家分布、Runtime、KV Cache 和并行策略仍然需要被完整考虑。

因此，“总参数”和“激活参数”分别描述模型容量和单次计算路径，二者不能互相替代。对于服务器和推理平台规划而言，还需要继续看权重精度、GPU 数量、并行方式、上下文和并发。

为什么 GLM-5 要引入 DeepSeek Sparse Attention？

长上下文模型的一个核心问题是 Attention 计算量会随着序列长度增加而快速上升。GLM-5 引入 DeepSeek Sparse Attention（DSA），官方技术报告将其目标概括为：在保持长上下文能力的同时，降低训练和推理成本。

从工程角度理解，Sparse Attention 并不是让模型完全“不看”历史信息，而是通过稀疏化机制减少每个 Token 在 Attention 阶段需要参与的无效或低价值计算，使长序列处理更加可扩展。

这类优化对于 GLM-5 的意义尤其明显，因为它的目标任务不是单轮短问答，而是 Coding、Agent 和复杂系统工程。任务持续时间越长，模型需要携带的代码、工具输出、执行日志和历史状态就越多，Attention 效率会直接影响长任务能否持续运行。

从 DSA 到 IndexShare：GLM-5.2 为什么继续优化稀疏注意力？

到了 GLM-5.2，官方继续围绕稀疏注意力做优化，并提出 IndexShare。根据官方仓库说明，IndexShare 会在每四个稀疏注意力层之间复用同一个 indexer，在 1M Context 下可将相关的单 Token FLOPs 降低约 2.9 倍。

这说明 GLM-5 系列对“长上下文”的理解已经不只是扩大模型能够接受的最大 Token 数，而是进一步考虑：

上下文拉长以后，Attention 计算是否还能承受；
模型能否在长时间任务中稳定保留有效信息；
Context、吞吐、延迟和算力成本之间如何平衡。

因此，1M Context 更适合理解为一项系统级能力，而不是单独的参数标签。真正进入生产环境时，还需要结合并发、KV Cache、Prompt 长度和任务持续时间进行评估。

为什么 GLM-5 特别强调异步强化学习？

复杂 Agent 任务和普通问答最大的差异之一，是模型需要在环境中不断执行动作并接收反馈。一次任务可能包括写代码、运行代码、读取报错、修改方案、再次执行，甚至持续数十轮以上。

GLM-5 技术报告指出，大规模强化学习面临的一个问题是训练效率。为此，GLM 团队开发了 slime 异步强化学习基础设施，通过解耦生成与训练，提高大规模 RL 后训练的吞吐与迭代效率；论文同时提到异步 Agent RL 方法，用于提升模型从复杂、长时程交互中学习的能力。

这一变化很重要，因为 Agent 能力并不只来自“更大的预训练模型”。模型还需要学习在长任务中如何规划、执行、观察、纠错和重新规划。后训练基础设施因此开始成为模型 Agent 能力的重要组成部分。

Agentic Engineering 到底是什么意思？

“Agentic Engineering”可以理解为：模型不再只负责生成一段答案或一段代码，而是作为 Agent 持续参与一个工程任务，通过工具和环境反馈逐步完成目标。

一个典型的软件工程 Agent 流程可能是：

读取任务目标和代码仓库；
定位相关文件和依赖关系；
制定修改计划；
调用终端、编辑器或测试工具；
读取测试结果和错误日志；
判断失败原因并修改策略；
反复执行，直到完成任务或达到退出条件。

这与“给模型一个 Prompt，让它一次生成答案”的工作模式存在本质区别。真正困难的地方不是某一次回答是否正确，而是模型在长时间运行中能否持续保持上下文、正确理解环境变化，并根据反馈修正下一步行动。

为什么 GLM-5.1 特别强调 Long-horizon？

GLM-5.1 官方介绍把重点进一步放在长时程 Agentic Engineering。官方观察是，部分模型在任务开始阶段能够快速取得进展，但随着任务时间拉长，容易重复已有策略或进入平台期。

GLM-5.1 强调的是模型在更长任务周期中的持续有效性：面对模糊问题时分解任务、运行实验、读取结果、识别阻塞点，并通过反复推理和策略修订继续推进。官方仓库甚至将其描述为可在数百轮迭代和数千次工具调用中持续优化。

因此，判断 Agent 模型能力时，仅看单轮 Benchmark 或首轮代码生成质量是不够的。对于真实工程应用，更需要关注：

长时间运行后的任务完成率；
是否会出现重复调用、循环或策略退化；
工具调用失败后的恢复能力；
上下文不断增长后的信息保持能力；
完成整个任务所需的 Token、时间和计算资源。

1M Context 对 Agent 有什么实际意义？

GLM-5.2 将“Solid 1M Context”作为核心能力之一。对于长时程 Agent 来说，更大的上下文窗口可以容纳更长的代码、文档、工具调用结果和任务历史，为持续任务提供更大的状态空间。

但 1M Context 并不意味着所有 Agent 应用都需要默认使用 1M Token。Context 越大，Prefill、Attention、KV Cache 和整体推理资源压力通常也会随之增加。

更合理的理解是：更大的 Context 为超长任务提供了能力上限，而实际生产环境仍需要根据任务长度、并发量和成本目标选择合适的服务窗口。

MTP 在 GLM-5.2 中解决什么问题？

GLM-5.2 还进一步改进了 MTP（Multi-Token Prediction）层，用于支持 speculative decoding。根据官方仓库介绍，改进后的 MTP 可将 speculative decoding 的 acceptance length 提升最高约 20%。

对于用户而言，这类优化的重点不在于记住某个单独指标，而是理解 GLM-5 系列正在同时处理两个方向：

模型能力：更复杂的推理、更长的任务、更稳定的工具使用；
推理效率：通过稀疏注意力、IndexShare、MTP 等机制降低长上下文和生成阶段的成本压力。

Agentic Engineering 如果只提升任务能力而不控制推理成本，很难在真实业务中大规模运行，因此“能力”和“效率”需要同步优化。

这些变化为什么会反过来影响算力基础设施？

从算力平台角度看，长时程 Agent 与普通 Chat 服务的资源特征并不完全相同。随着任务持续时间变长，单个请求可能产生更长的输入历史、更长的输出，以及更多连续模型调用。

模型能力变化	对计算平台的直接影响	规划时需要关注
744B-A40B MoE	模型总权重规模大，同时存在专家路由与多卡并行需求	GPU 显存、并行策略、GPU 间通信与 Runtime 支持
长上下文 / 1M Context	Prompt 与 KV Cache 资源压力增加	显存余量、并发、Context 上限与 Prefill 性能
长时程 Agent	单任务运行时间更长，连续推理调用增加	吞吐、延迟、资源调度、稳定性与持续运行能力
工具调用与工程任务	模型服务需要与代码、检索、终端等外部系统协同	API 服务稳定性、任务队列、网络和应用侧架构
稀疏注意力 / MTP	依赖推理框架和 Kernel 对新架构特性的支持	框架版本、CUDA/驱动、GPU 架构与软件栈兼容性

因此，面对 GLM-5 这类模型，算力规划不能只回答“需要几张 GPU”。更完整的问题应是：模型版本是什么、需要多长 Context、同时跑多少 Agent、单任务持续多久、是否有明确的 TTFT/吞吐目标，以及当前推理框架是否已经完整支持对应模型特性。

企业和科研用户真正需要关注什么？

如果只是理解 GLM-5 系列，可以重点关注架构和 Agent 能力变化；如果准备把它用于企业或科研环境，则更建议把问题拆成四层：

模型层：选择 GLM-5、GLM-5.1、GLM-5.2 还是更新版本？需要 BF16、FP8 还是其他权重形式？
任务层：主要是 Chat、Coding、RAG，还是持续数十分钟甚至更久的 Agent 工作流？
服务层：实际 Context、并发、响应时间、任务持续时间分别是多少？
基础设施层：GPU 显存、GPU 间互联、CPU/内存、存储、网络和推理框架能否共同形成稳定运行环境？

对于长时程 Agent，最后一层尤其容易被低估。模型能够启动只是第一步，真正进入业务之后，还需要验证长任务持续运行、并发资源竞争、工具调用稳定性和整体完成时间。

常见问题 FAQ

Q1：GLM-5 是 744B 模型还是 40B 模型？

两种数字描述的是不同概念。GLM-5 总参数规模约为 744B，单次前向计算激活参数约为 40B，因此官方写作 744B-A40B。40B Active 不能直接把 GLM-5 当成普通 40B Dense 模型理解。

Q2：GLM-5 为什么使用 MoE？

MoE 可以扩大模型总容量，同时通过稀疏激活让每个 Token 只经过部分专家，从而避免所有参数在每次前向计算中全部参与计算。模型实际效率还会受到路由、并行和推理框架实现影响。

Q3：DeepSeek Sparse Attention 和 MoE 是一回事吗？

不是。MoE 主要解决前馈专家层的稀疏激活问题；Sparse Attention 主要针对 Attention 阶段的计算效率。二者作用位置不同，但都服务于“大模型容量与实际计算成本之间的平衡”。

Q4：Agentic Engineering 和 Coding Agent 有什么区别？

Coding Agent 可以看作 Agentic Engineering 的典型应用之一。Agentic Engineering 更强调模型长期参与工程任务，通过规划、工具调用、实验、反馈和策略调整完成一个多步骤目标，而不是只生成一段代码。

Q5：1M Context 是否意味着部署时必须开放 1M？

不是。1M Context 表示模型具备更高的上下文能力上限，生产部署仍需要结合显存、KV Cache、并发、Prefill 性能和真实任务长度确定实际服务窗口。

Q6：GLM-5 系列和 GLM-5.3 本地部署指南是什么关系？

本条目负责解释 GLM-5 系列的模型架构和技术演进；GLM-5.3 本地部署条目则负责回答 GPU、Context、KV Cache、推理框架和服务器选型问题。两类内容分别对应“理解模型”和“规划部署”。

赋创可提供的支持

对于 GLM-5 系列这类大规模 MoE 与长上下文模型，赋创可基于客户的模型版本、业务负载、上下文、并发和目标性能，协助梳理计算平台需求，并进一步规划 GPU 服务器、节点架构、软硬件部署支持及性能基线与验收方案。

模型与业务负载对应的算力需求梳理
GPU 服务器与多卡计算平台规划
结合现有环境的软硬件部署支持
Context、并发、吞吐与稳定性测试基线梳理

方案咨询

评估 GLM-5 系列模型的算力与部署需求

如果需要进一步评估 GLM-5 系列在企业、科研或私有化场景中的算力需求，可基于模型版本、业务负载、上下文长度、并发与目标性能，进一步梳理 GPU 服务器、计算节点和推理平台规划。

咨询算力方案浏览指南