GLM-5 技术报告全解读｜a16z：“最好的开源模型”

GLM 5 技术报告全解读｜a16z：“最好的开源模型” GLM 5 技术报告全解读｜a16z：“最好的开源模型” Modified February 23 GLM 5 在最后加了一个蒸馏阶段：把前面每个阶段（SFT、Reasoning RL、General RL）的最终 checkpoint 作为教师模型，学生模型通过 logits 差距直接计算 advantage，不需要大 group size。batch size 开到 1024 提吞吐 Agent 环境：10000+ 可验证场景 RL 训练需要可验证的执行环境，对于模型做了什么，环境要能给出明确的对错反馈 软件工程环境 从真实 GitHub 的 Issue PR 对出发，基于 RepoLaunch 框架自动构建可执行环境。自动分析仓库的安装和依赖，构建 Docker 环境，生成测试命令，用 LLM 从测试输出生成日志解析函数 覆盖 9 种语言：Python、Java、Go、C、C++、JavaScript、TypeScript、PHP、Ruby 超过 10000 个可验证环境 终端环境 两条路径： • 种子任务合成：从真实 SWE 和终端场景收集种子，LLM 生成任务草稿 → 构建 Agent 在 Harbor 格式下实例化 → 精炼 Agent 迭代优化。Docker 构建精度超 90% • 网页语料合成：从代码网页出发，到闭环设计，要求 Coding Agent 合成任务的同时自行验证，只有通过所有检查的才纳入最终数据集 搜索任务 从早期搜索 Agent 的轨迹中收集了 200 万+ 高信息量网页，构建 Web 知识图谱（WKG）。从中生成多跳问答对，在这个过程中，每个问题需要从多个网页汇聚证据，经过多步推理 难度过滤分三阶段： • 删掉不用工具推理模型也能答对的题（8 次独立尝试中至少对 1 次就删） • 过滤掉早期 Agent 几步就能搜到的题 • Verification Agent 做双向校验，排除答案不唯一或证据不一致的样本 搜索 Agent 的上下文管理 BrowseComp 基准上的性能对上下文管理策略很敏感。模型在执行搜索任务时会不断积累工具调用历史，上下文越来越长，性能开始下降 GLM 5 用了一套分层管理策略： • Keep recent k：当交互历史超过 k 轮时，只保留最近 5 轮的完整内容，旧的工具结果折叠。效果从 55.3% 提到 62.0% • 和 Discard all 结合：总上下文超过 32K 时，清空全部工具调用历史重新开始，同时继续 Keep recent k 这样模型可以在预算内执行更多步搜索，最终 BrowseComp 得分 75.9 ，所有模型里最高（含闭源） 从 GLM 4.7 到 GLM 5，不同上下文管理策略下 BrowseComp 的准确率 PPT 生成与 Reward Hacking 技术报告里写了一个很直观的 reward hacking 案例 PPT 生成用 HTML 作为中间格式。RL 训练中设计了三级奖励：Level 1 看 HTML 静态属性（定位、间距、颜色），Level 2 看运行时渲染后的真实属性（DOM 节点实际宽高），Level 3 看视觉感知（空白检测等） 模型找到了两种作弊方式： 一种是用 overflow: hidden 把溢出内容藏起来，让页面看起来符合 16:9 但实际上内容被截断了 另一种是用 flex: 1 1 8% 强行占满空间，布局看着正常但内容很稀疏 PPT 生成中的 reward hacking 案例 解法是改渲染器，直接拿渲染后的真实属性值做评估，而不是看 HTML 源码里写了什么。修正后，符合 16:9 比例的页面从 40% 提升到 92%。人工评估里 GLM 5 对比 GLM 4.5 的综合胜率 67.5% 国产芯片适配 GLM 5 从上线第一天就在跑国产芯片。适配覆盖七大平台：华为昇腾、摩尔线程、海光、寒武纪、昆仑芯、天数智芯（MetaX）、燧原 技术报告以华为昇腾 Atlas 系列为例展开了三个层面： W4A8 混合精度量化 ：标准的 Attention 和 MLP 模块用 INT8（W8A8），MoE 专家模块压到 INT4（W4A8）。让 750B 的模型能装进单台 Atlas 800T A3 服务器 融合算子 ： • Lightning Indexer：把分数计算、ReLU 激活和 TopK 三步融合成一个算子 GLM 5 在最后加了一个蒸馏阶段：把前面每个阶段（SFT、Reasoning RL、General RL）的最终 checkpoint 作为教师模型，学生模型通过 logits 差距直接计算 advantage，不需要大 group size。batch size 开到 1024 提吞吐 Agent 环境：10000+ 可验证场景 RL 训练需要可验证的执行环境，对于模型做了什么，环境要能给出明确的对错反馈 软件工程环境 从真实 GitHub 的 Issue PR 对出发，基于 RepoLaunch 框架自动构建可执行环境。自动分析仓库的安装和依赖，构建 Docker 环境，生成测试命令，用 LLM 从测试输出生成日志解析函数 覆盖 9 种语言：Python、Java、Go、C、C++、JavaScript、TypeScript、PHP、Ruby 超过 10000 个可验证环境 终端环境 两条路径： • 种子任务合成：从真实 SWE 和终端场景收集种子，LLM 生成任务草稿 → 构建 Agent 在 Harbor 格式下实例化 → 精炼 Agent 迭代优化。Docker 构建精度超 90% • 网页语料合成：从代码网页出发，到闭环设计，要求 Coding Agent 合成任务的同时自行验证，只有通过所有检查的才纳入最终数据集 搜索任务 从早期搜索 Agent 的轨迹中收集了 200 万+ 高信息量网页，构建 Web 知识图谱（WKG）。从中生成多跳问答对，在这个过程中，每个问题需要从多个网页汇聚证据，经过多步推理 难度过滤分三阶段： • 删掉不用工具推理模型也能答对的题（8 次独立尝试中至少对 1 次就删） • 过滤掉早期 Agent 几步就能搜到的题 • Verification Agent 做双向校验，排除答案不唯一或证据不一致的样本 搜索 Agent 的上下文管理 BrowseComp 基准上的性能对上下文管理策略很敏感。模型在执行搜索任务时会不断积累工具调用历史，上下文越来越长，性能开始下降 GLM 5 用了一套分层管理策略： • Keep recent k：当交互历史超过 k 轮时，只保留最近 5 轮的完整内容，旧的工具结果折叠。效果从 55.3% 提到 62.0% • 和 Discard all 结合：总上下文超过 32K 时，清空全部工具调用历史重新开始，同时继续 Keep recent k 这样模型可以在预算内执行更多步搜索，最终 BrowseComp 得分 75.9 ，所有模型里最高（含闭源） 从 GLM 4.7 到 GLM 5，不同上下文管理策略下 BrowseComp 的准确率 PPT 生成与 Reward Hacking 技术报告里写了一个很直观的 reward hacking 案例 PPT 生成用 HTML 作为中间格式。RL 训练中设计了三级奖励：Level 1 看 HTML 静态属性（定位、间距、颜色），Level 2 看运行时渲染后的真实属性（DOM 节点实际宽高），Level 3 看视觉感知（空白检测等） 模型找到了两种作弊方式： 一种是用 overflow: hidden 把溢出内容藏起来，让页面看起来符合 16:9 但实际上内容被截断了 另一种是用 flex: 1 1 8% 强行占满空间，布局看着正常但内容很稀疏 PPT 生成中的 reward hacking 案例 解法是改渲染器，直接拿渲染后的真实属性值做评估，而不是看 HTML 源码里写了什么。修正后，符合 16:9 比例的页面从 40% 提升到 92%。人工评估里 GLM 5 对比 GLM 4.5 的综合胜率 67.5% 国产芯片适配 GLM 5 从上线第一天就在跑国产芯片。适配覆盖七大平台：华为昇腾、摩尔线程、海光、寒武纪、昆仑芯、天数智芯（MetaX）、燧原 技术报告以华为昇腾 Atlas 系列为例展开了三个层面： W4A8 混合精度量化 ：标准的 Attention 和 MLP 模块用 INT8（W8A8），MoE 专家模块压到 INT4（W4A8）。让 750B 的模型能装进单台 Atlas 800T A3 服务器 融合算子 ： • Lightning Indexer：把分数计算、ReLU 激活和 TopK 三步融合成一个算子 • HMMT Feb. 2025： 97.9 ，vs Claude 92.9，Gemini 3 Pro 97.3 • HMMT Nov. 2025： 96.9 ，vs Claude 93.5，Gemini 3 Pro 96.9 • IMO AnswerBench： 82.5 ，vs Claude 87.5，GPT 5.2 xhigh 75.5 • GPQA Diamond： 86.0 ，vs Claude 85.8，GPT 5.2 xhigh 84.8 • LongBench v2： 64.5 ，vs Claude 59.5，Gemini 3 Pro 68.2 编程 • SWE bench Verified： 77.8 ，vs Claude 80.9，Gemini 3 Pro 72.5，GPT 5.2 xhigh 80.0 • SWE bench Multilingual： 73.3 ，vs Claude 77.5，GPT 5.2 xhigh 72.0 • Terminal Bench 2.0： 56.2 （修正模糊指令后 60.7 61.1 ），vs Claude 59.3 • CyberGym： 43.2 ，vs Claude 51.3 Agent • BrowseComp（含上下文管理）： 75.9 ，vs Claude 64.8，GPT 5.2 xhigh 54.4 • BrowseComp ZH： 72.7 ，vs Claude 64.8，Gemini 3 Pro 42.3 • τ² Bench： 89.7 ，vs Claude 91.6 • MCP Atlas： 67.8 ，vs GPT 5.2 xhigh 68.0 • Tool Decathlon： 74.0 ，vs Claude 75.6 • Vending Bench 2： $4432 ，vs Claude 5478 • GDPval AA Elo： 1409 ，vs Claude 1381，GPT 5.2 xhigh 1437 在 SWE rebench（一个持续更新的、去污染的 SWE 评测）上，GLM 5 的 42.1% 和 Claude Opus 4.5 的 43.8% 只差 1.7 个百分点 CC Bench V2：真实工程体验 这是智谱内部的评测基准，完全自动化，不依赖人工标注。用 Claude Code + Claude Sonnet 4.5 配合 Playwright 做 Agent as a Judge，让一个 Agent 去操作另一个 Agent 生成的前端项目，点击按钮、输入内容、截屏，逐项验证是否正确 Agent as a Judge 评估流程 前端 三个指标：BSR（构建成功率）、CSR（检查项通过率）、ISR（实例整体通过率） 对比表格 BSR 98% 说明 GLM 5 生成的项目几乎都能跑起来。CSR 和 Claude 接近，单项需求的完成度差不多 但 ISR 的差距很明显，比如 HTML 上差了 13 个百分点，Vue 上差了 14 个百分点。BSR 高但 ISR 低，说明单项能力到位了，但把所有需求组合起来端到端完成一整个任务，还有空间 后端 85 个任务，6 种语言（Python、Go、C++、Rust、Java、TypeScript），涵盖搜索引擎、数据库、Web 框架、AI 推理服务等 GLM 5 Pass@1： 25.8 ，vs Claude Opus 4.5 的 26.9 长程任务 两个子任务： 大规模代码库探索（在数万个文件的仓库里找到目标文件）：GLM 5 65.6 ，优于 Claude 的 64.5。这个任务考的是策略性搜索而不是代码生成：模型需要通过推理缩小文件范围，GLM 5 在 Agent 工具使用轨迹上的训练在这里体现了优势 多步链式任务（每一步的代码修改会改变后续步骤的上下文，模拟真实的增量开发）：GLM 5 52.3 ，vs Claude 的 61.6 ，差距明显 技术报告也写了原因：链式任务中错误会累积，上一步的次优修改可能悄然破坏后续步骤的测试。缩小这个差距需要在长上下文一致性和长程自纠错上继续突破 CC Bench V2 完整结果 通用能力 GLM 5 相比 GLM 4.7 在五个维度全面提升 • 机器翻译（ZMultiTransBench）：1016 → 1050 • 多语言对话（LMArena）：1441 → 1452 • 指令遵循（IF Badcase）：78.5 → 83.2 • 世界知识（Chinese SimpleQA）：72.9 → 75.2 • 工具调用（ToolCall Badcase）：60.8 → 95.8 工具调用这一项提升幅度很大，从 60 出头直接拉到 95 以上 五项通用能力对比 RL 训练框架：slime GLM 5 的后训练全跑在自研的 slime 框架上。三个设计重点： 横向扩展：高度可定制的 rollout 接口 + HTTP API 暴露推理服务。不同 Agent 框架可以像调用普通推理引擎一样和 slime 交互。训练逻辑和推理逻辑完全解耦 纵向扩展：RL 推理的优化目标，是端到端延迟：瓶颈在最慢的那条轨迹上。GLM 5 用多节点推理部署（EP64 + DP64 跨 8 节点），FP8 rollout 降低单 token 延迟，MTP 在小批次解码下收益尤其大，PD 分离（prefill 和 decode 分开调度）确保多轮交互中解码速度稳定 容灾：推理服务定期发心跳，不健康的节点自动终止并从路由注销，请求自动重试到健康节点 产品和使用方式 GLM 5 模型权重遵循 MIT License 开源，在 Hugging Face 和 ModelScope 同步上线 线上服务已纳入 Max 用户套餐，Pro 用户 5 天内支持。GLM Coding Plan 适配 Claude Code、OpenCode 等主流开发工具 几个新的产品场景： Z Code 智谱推出的编程工具。用户说清楚需求，模型自动拆解任务，多 Agent 并发完成代码编写、命令执行、调试、预览和提交。支持手机远程指挥桌面端 Agent。Z Code 本身也是 GLM 模型参与开发完成的 OpenClaw 适配 OpenClaw（开源的 Agent 框架，a16z 文章里提到它在 OpenRouter 上占了 13% 的 token 消耗）现在有了 AutoGLM 版本，支持官网一键配置和飞书机器人集成。Pro / Max 用户限量赠送 办公文档输出 在 Z.ai 和智谱清言上，可以让 GLM 5 直接生成 .docx、.pdf、.xlsx 文件，比如产品需求文档、教案、试卷、财务报告等 GLM in Excel 原生适配 Excel 的 AI 插件，侧边栏里用自然语言处理表格数据。Beta 阶段仅 Max 用户 Pony Alpha 技术报告最后有一个彩蛋 GLM 5 最早的时候，是在 OpenRouter 上以匿名身份「Pony Alpha」上线 ，未公开任何品牌信息，纯靠模型体感 上线几天后在 OpenRouter 社区引起关注。开发者注意到它在复杂代码、Agent 任务链路和角色扮演上的表现，开始猜测身份 25% 的用户推测它是 Anthropic 的 Claude Sonnet 5； 20% 认为是 Grok 的新版本； 10% 猜是 DeepSeek V4； 最终确认是 GLM 5 相关链接 技术报告全文 https://arxiv.org/pdf/2602.15763 GitHub https://github.com/zai org/GLM 5 Hugging Face https://huggingface.co/zai org/GLM 5 ModelScope htps://modelscope.cn/models/ZhipuAI/GLM 5 modelscope.cn/models/ZhipuAI/GLM 5 Z Code https://zcode.z.ai/cn Blog https://z.ai/blog/glm 5 🔗 原文链接： https://mp.weixin.qq.com/s/d6qHr9kB... https://mp.weixin.qq.com/s/d6qHr9kB... 原创 金色传说大聪明 金色传说大聪明 赛博禅心2026年2月22日 23:01 北京 a16z 昨天发了一张图，把 GLM 5 和 Claude Opus 4.6 并排标注在 Artificial Analysis Intelligence Index 的时间线上 https://www.a16z.news/p/charts of the week vertical saas 原文的说法是： A proprietary model (Claude Opus 4.6) is still the 'most intelligent,' but the gap between it and the next best open weight model has closed substantially. 换句话说： a16z 称智谱的 GLM 5，是最好的开源模型 而今天， GLM 5放出了完整的技术报告，40 页 https://arxiv.org/pdf/2602.15763 报告发出后，我看到许多开发者社区已经开始逐页学习 其中被讨论最多的几个技术点： DSA 稀疏注意力 （20B token 追平 DeepSeek 943.7B token 的效果）、 完全异步的 Agent RL 训练框架 、 自研的 slime RL 基础设施 .... 还有...快夸我是预言家，早早的透露了财富密码： 智谱+龙虾 智谱+龙虾 下面，让我们一起把这份技术报告逐块过一遍 基座：744B 参数，40B 激活 先说模型的基本面：仅次于海外最头部的闭源模型 Artificial Analysis Intelligence Index v4.0：GLM 5 得分 50，开源第一 GLM 5 沿用 MoE 架构（Mixture of Experts，一种让模型在推理时只激活一小部分参数的设计），总参数 744B ，每次推理激活 40B ，256 个专家，80 层 对比上一代 GLM 4.5：总参数从 355B 翻到 744B，激活参数从 32B 涨到 40B 预训练数据从 23T token 增加到 28.5T token（其中预训练 27T，中期训练 1.5T） 「744B 总参，40B 激活，开源模型第一次在 Artificial Analysis Intelligence Index 上拿到 50 分」 Artificial Analysis Intelligence Index v4.0：GLM 5 得分 50，开源第一 在 LMArena（原来的 Chatbot Arena）上，GLM 5 在文本竞技场和代码竞技场里都排开源第一，整体和 Claude Opus 4.5、Gemini 3 Pro 同档 LMArena 竞技场排名 架构改动 在架构上，GLM 5 区别于之前的 GLM 4 系列模型，有三个大的改动 • MLA + Muon Split • 多 token 预测 • DSA 稀疏注意力 让我们按次序，逐个来说 MLA + Muon Split GLM 5 用的注意力机制叫 MLA（Multi latent Attention），和 DeepSeek V3 同源。它通过 压缩 KV 缓存的维度来节省显存 ，处理长文本时比传统方案快 但团队在训练时发现一个问题： 用 Muon 优化器配 MLA 时，效果追不上更简单的 GQA 8 方案 团队之后找到了一个解法，叫 Muon Split：是对整块投影矩阵做正交化（一种让权重更均匀的数学操作），改成按每个注意力头单独做。这样不同的头可以按自己的节奏更新。效果追平了 GQA 8，还有个附带收益：注意力分数在训练过程中自动保持稳定，不用额外裁剪 额外的，GLM 团队还做了一个 MLA 256 变体：把每个注意力头的维度从 192 增大到 256，头数量减少 1/3。参数总量不变，性能持平，但推理时的计算量降下来了 MLA 各变体的对比评测 多 token 预测：参数共享的 MTP 在大模型推理中，有一种加速方法叫推测解码： 用一个小模型快速猜接下来几个 token，再让大模型验证 。猜对了就省了大模型的计算 DeepSeek V3 只用 1 个 MTP（Multi Token Prediction）层训练，推理时预测 2 个 token。但训练和推理的方式不一致，导致第二个 token 的猜中率偏低 GLM 5 的做法： 训练时用 3 个 MTP 层，但这 3 层共享同一套参数 。推理时的内存开销和 DeepSeek V3 一样（因为参数只有一套），但猜中率更高 实测数据：同样 4 步推测解码，GLM 5 的平均接受长度 2.76 ，DeepSeek V3.2 是 2.55 DSA 稀疏注意力 这是 GLM 5 在效率上最核心的一个改动 传统的注意力计算是全量的，也就是每个 token 都要和所有其他 token 算一遍关系 随着上下文长度的增加，其计算量是成平方倍增长的，例如：当 上下文从 100 个 token 增长到 1 万个 token 时，其运算量就增长了 1 万倍 ，就导致了大模型在长上下文下，非常贵 DSA（DeepSeek Sparse Attention）的思路：加一个轻量级的「索引器」，先快速扫一遍所有 token，找出和当前 token 最相关的那些（top k，k=2048），只对这部分做注意力计算。其余的跳过 和滑动窗口（只看最近 N 个 token）不同，DSA 是看内容来决定哪些 token 重要，而非位置 经过测算，在 GLM 5 中， 20B token 的 DSA 适配，追上了 DeepSeek 花 943.7B token 训出来的效果 具体流程：从中期训练结束后的基础模型开始，先做 1000 步预热（只训练索引器，主模型冻结），然后做 20B token 的稀疏适配训练。总预算 20B token。DeepSeek V3.2 的 DSA 训练用了 943.7B token，是 GLM 5 的将近 50 倍 最终效果：DSA 模型在长上下文基准上和原始 MLA 模型基本持平。SFT 之后的训练损失曲线也几乎重合 MLA 和 DSA 的 SFT 损失曲线几乎重合 实际收益：长序列的注意力计算降低 1.5 2 倍。后面做 Agent 推理时动辄 200K 上下文，GPU 成本直接砍一半 技术报告还做了一组消融实验，对比了 DSA 和其他几种省计算的注意力方案： • 朴素的滑动窗口交错 ：固定每隔一层用窗口注意力，128K 上下文下 RULER 跌了 30 分，基本不可用 • 基于搜索的 SWA 模式 ：用束搜索找到最优的层分配，效果好很多，但细粒度检索上还是丢 5 7 分 • GDN 和 SimpleGDN ：SimpleGDN 在复用预训练权重方面最高效 • DSA ：索引器做的是 token 级的动态选择，不丢弃任何长程依赖 各种高效注意力方案在 64K/128K 下的对比 预训练数据 三个来源都做了升级 网页数据 在 GLM 4.5 的管线上新增了基于句子嵌入的 DCLM 分类器，用来捞标准分类器漏掉的高质量内容。另外训练了一个「世界知识分类器」（用 Wikipedia 条目 + LLM 标注数据），从中低质量网页里筛出有价值的长尾知识 代码数据 刷新主要代码托管平台的快照，模糊去重后 unique token 增加 28%。修复了 Software Heritage 的元数据对齐问题。给 Scala、Swift、Lua 等低资源语言训练了专用分类器 数学与科学 从网页、书籍、论文里收集，用 LLM 打分只保留最具教育价值的部分。长文档用分块聚合评分。严格排除合成数据和 AI 生成数据 中期训练 上下文窗口分三个阶段扩展： • 32K（1T token） • 128K（500B token） • 200K（50B token） GLM 4.5 最大做到 128K，新增的 200K 阶段主要为了处理超长文档和多文件代码库 软件工程数据扩了一轮：放宽仓库级筛选获得约 1000 万个 Issue PR 对，但加强了单个 issue 的质量过滤。最终 issue PR 部分约 160B token 长上下文数据包括自然数据（书籍、论文）和合成数据。合成数据用了 NextLong 和 EntropyLong 的思路构建长程依赖。200K 阶段额外加入 MRCR 类数据的多种变体，用来增强超长多轮对话中的召回能力 训练工程 技术报告花了不少篇幅讲训练基础设施的优化，列几个关键的： • MTP 布局优化：MTP 模块的输出层和主输出层放在流水线最后一个 stage 共享参数，其余前移，平衡各 rank 的显存占用 • ZeRO2 梯度分片：每个 stage 只存 1/dp 的梯度，配合双缓冲，不增加同步开销的前提下大幅降低梯度显存 • Muon 优化器零冗余通信：all gather 限制在本 rank 负责的参数分片内 • 流水线激活卸载：前向完成后把激活按层卸到 CPU，反向时再加载，和计算重叠执行 • 序列分块输出投影：长序列下输出层和 loss 的显存峰值很高，按序列维度分块处理 • INT4 量化感知训练（QAT）：在 SFT 阶段就做，开发了训练和推理 bit level 对齐的量化 kernel 这些并非是某一项特别新，但组合在一起让 744B 的模型能在合理的硬件规模上训起来 后训练全流程 GLM 5 的后训练是一条完整的流水线：SFT → Reasoning RL → Agentic RL → General RL → 跨阶段在线蒸馏 GLM 5 训练全流程 SFT 三大类数据：通用对话（问答、写作、角色扮演、翻译、多轮对话、长上下文）、推理（数学、编程、科学）、编程与 Agent（前端/后端代码、工具调用、Coding Agent、搜索 Agent） 最大上下文长度扩到 202752 token 三种思考模式： • 交错思考（Interleaved Thinking）：每次响应和工具调用前都思考一轮，提升指令遵循和生成质量 • 保留思考（Preserved Thinking）：在 Coding Agent 场景里，多轮对话之间保留所有思考内容，不重新推导。适合长程复杂任务，减少信息丢失 • 轮级思考（Turn level Thinking）：按轮次控制开关。简单请求关掉思考降延迟，复杂任务打开提精度 交错思考和保留思考的对比示意 编程和 Agent 的 SFT 数据用了专家 RL 和拒绝采样来提质。一个细节：轨迹中的错误片段被保留下来，但在计算 loss 时用掩码屏蔽。模型能看到错误发生了什么，学会纠错行为，但不会被训练去重复错误动作 Reasoning RL 算法基于 GRPO + IcePop。核心改动是明确区分了用于梯度更新的「训练模型」和用于生成轨迹的「推理模型」，去掉了 KL 正则项来加速训练。纯 on policy，group size 32，batch size 32 一个很小但影响很大的工程发现 DSA 的索引器在每个 token 位置要做 top k 检索（k=2048，就是从所有 token 里挑出 2048 个最重要的）。SGLang 推理引擎里用的是基于 CUDA 的 top k 实现，速度快，但结果有随机性：同样的输入跑两次，排序结果可能不完全一样 「把 torch.topk 换成 CUDA 的非确定性 topk，RL 几步就崩了」 具体表现：熵值骤降，性能急剧退化。原生的 torch.topk 慢一些，但每次输出确定一致。最终方案是全程用 torch.topk ，并在 RL 阶段冻结索引器参数 Reasoning RL 在四个领域做混合训练：数学、科学、代码、工具集成推理（TIR）。难度过滤逻辑：只保留 GLM 4.7 做不出来、但 GPT 5.2 xhigh / Gemini 3 Pro Preview 能做出来的题 Agentic RL 这是技术报告里篇幅最大的一块 核心问题：Agent 任务的 rollout（让模型和环境交互生成完整轨迹）时间极长，而且不同任务之间差异很大。一条 SWE 任务可能几分钟，另一条可能半小时。同步 RL 的做法是等所有轨迹都生成完再一起训练，最慢的那条卡多久，整批 GPU 就闲多久 GLM 5 的做法是完全异步： • 训练 GPU 和推理 GPU 物理分开 • 推理端持续不断地生成轨迹，攒够一批就发给训练端 • 推理端的模型权重每隔 K 步和训练端同步一次 Multi Task Rollout Orchestrator ：不同类型的 Agent 任务（SWE 修 bug、终端操作、搜索问答）各自作为独立的微服务注册到中央编排器，编排器控制任务比例和生成速度。支持 1000+ 并发 rollout 几个保证异步训练不崩的关键设计： TITO（Token in Token out） 传统做法是把推理引擎当黑箱：先发进去一段文字，然后拿回来一段文字，训练时再重新做 tokenization。问题是 re tokenization 会在 token 边界、空格处理、截断位置上引入细微差异，影响对单个 token 采样概率的估计 TITO 的做法：训练流程直接消费推理引擎生成的 token ID 序列和元数据，不做文本往返。保证 token 级别的精确对应 直接双侧重要性采样 异步场景下，推理引擎的模型可能在一条轨迹生成过程中被更新了好几次。要追踪完整的历史策略概率，就得存一堆历史模型权重，不现实 GLM 5 直接用 rollout 时记录的对数概率作为行为代理，算重要性比率 r t(θ) = π θ / π rollout。落在信任域 [1 ε l, 1+ε h] 外的 token 直接屏蔽梯度，不让偏差太大的样本影响训练 样本过滤 ：记录每条轨迹的模型版本号，版本差距超过阈值的丢弃。因环境崩溃（不是模型能力问题）导致失败的样本也排除 DP aware 路由 ：多轮 Agent 任务里，同一个 rollout 的后续请求通过一致性哈希路由到同一个 DP rank，复用 KV cache。预填充成本只和增量 token 成正比 General RL 优化目标分三个维度： • 正确性：指令遵循、逻辑一致、事实准确、无幻觉 • 情商：同理心、洞察力、自然的人类表达风格 • 特定任务能力：写作、问答、角色扮演、翻译等各领域的细粒度优化 奖励系统是三种信号混合的：规则奖励（精确但覆盖面窄）+ 判别式奖励模型 ORM（低方差但容易被 reward hacking）+ 生成式奖励模型 GRM（鲁棒但方差大） 一个有意思的做法：在 RL 中引入人类撰写的高质量回复，作为风格和质量的锚点。原因是纯模型 RL 容易收敛到冗长、公式化的「机器感」模式。这些模式在奖励函数上得分高，但读起来很不自然。人类回复用来把风格拉回来 跨阶段在线蒸馏 多阶段 RL 的经典问题：后面的阶段优化新目标时，前面学到的能力退化（灾难性遗忘） • Sparse Flash Attention：TopK 检索和稀疏注意力计算并行执行 • MLAPO：把 13 个碎片化的预处理算子融合成一个 推理引擎优化 ：vLLM Ascend 和 SGLang 都做了适配。异步调度消除采样回传的气泡，RadixCache 做前缀共享，注意力 DP + MoE EP 混合并行，MTP 加速 最终效果：单台国产节点的推理性能接近两台国际主流 GPU 集群。长序列场景下部署成本降低 50% 评测 下面是完整的跑分数据 全面对比表格 当然，我也整理了文字版的对比 推理 • HLE（含工具）： 50.4 ，vs Claude Opus 4.5 的 43.4，GPT 5.2 xhigh 的 45.5，Gemini 3 Pro 的 44.2 • HLE（不含工具）： 30.5 ，vs Claude 35.9，GPT 5.2 xhigh 25.1 • AIME 2026 I： 92.7 ，vs Claude 93.3，Gemini 3 Pro 92.7