3.6 RL 训练基础设施：slime 框架

我们继续用 slime 作为 GLM-5 的统一后训练基础设施，支撑端到端的大规模强化学习（RL）。GLM-5 并没有引入新的系统组件，而是充分利用 slime 的既有能力来做到三件事：(1) 通过自由形式的 rollout 定制和服务化执行模型拓宽任务覆盖；(2) 通过混合精度训练/rollout，配合 MTP 与 Prefill-Decode（PD）分离大幅提升吞吐——尤其是多轮 RL 负载；(3) 通过心跳驱动的 rollout 容错和 router 级的服务生命周期管理提升鲁棒性。

3.6.1 横向扩展：通过高度可定制的 rollout 实现灵活训练

GLM-5 的后训练横跨多样的目标谱系。为在不给每个任务开分支的情况下支持这种多样性，GLM-5 利用了 slime 高度可定制的 rollout 接口以及它的服务化 rollout 执行。

高度可定制的 rollout。 slime 提供了灵活的接口来实现任务特定的 rollout 逻辑——包括多轮交互循环、工具调用、环境反馈处理和 verifier 引导的分支——而无需修改底层基础设施。GLM-5 利用这一能力，在统一的训练栈内支持广泛的领域与训练范式，包括但不限于 reasoning RL、general RL、agentic RL 与 on-policy 蒸馏。

通过 HTTP API 的服务化 rollout。 slime 通过标准 HTTP API 暴露它的 rollout server 和推理 router，用户可以像使用常规推理引擎那样与 slime 的服务层交互。这把 rollout 逻辑与训练进程边界解耦：外部 agent 框架和环境可以直接调用 server/router 端点，而优化后端对短程单轮训练与长程多轮轨迹都保持不变。

3.6.2 纵向扩展：RL rollout 的尾延迟优化

对 RL rollout 而言，优化目标不是聚合吞吐而是端到端延迟，它由每一步中最慢的（长尾）样本主导。实践中，单条拖后腿的轨迹就能卡住同步点（例如 batch 完成、buffer 就绪、trainer 更新），直接决定 wall-clock 进度。因此 GLM-5 充分利用 slime 面向延迟的服务与调度机制，来同时压低中位延迟，以及更重要的尾延迟。

通过多节点推理加 MLA 的 DP-attention 实现无排队服务。 为避免排队延迟，rollout 请求即使在突发流量下也必须被及时服务，这需要充足的 KV-cache 容量。GLM-5 采用多节点推理部署（例如 8 节点上的 EP64 与 DP64）来提供足够的分布式 KV-cache。引入 DP-attention 主要是为了避免在不同 rank 之间复制 KV。

用 FP8 rollout 与 MTP 降低尾延迟。 GLM-5 用 FP8 做 rollout 推理，以降低单 token 延迟、缩短长轨迹的完成时间。此外 GLM-5 利用 slime 对 Multi-Token Prediction（MTP）的支持，这在 RL rollout 典型的小 batch 解码场景下尤其有效。由于尾延迟往往由小 batch size 的拖后腿样本驱动（例如罕见的长上下文、复杂多轮推理、工具密集的轨迹），MTP 在长尾上带来不成比例的巨大收益，改善了最慢样本的完成时间，从而减少步级停顿。

用 PD 分离防止多轮 RL 中的 prefill-decode 干扰。 在多轮设定下，长前缀 prefill 很频繁（对话历史、工具轨迹、代码上下文）。在 DP-attention 下，把 prefill 和 decode 混在同一份服务资源上会造成严重干扰：一次重量级 prefill 可能抢占或打断服务端正在进行的 decode，让其他样本无法持续推进，尾延迟急剧恶化。因此 GLM-5 利用 slime 的 Prefill–Decode（PD）分离。把 prefill 与 decode 跑在专用资源上，decode 就能保持稳定不被打断，让长程样本持续推进，显著改善多轮 agentic RL 的尾部行为。

3.6.3 Rollout 鲁棒性：心跳驱动的容错

在大规模下，瞬时故障（例如单个 server 崩溃、网络问题或性能退化）不可避免。GLM-5 利用 slime 的心跳驱动容错来保证这类事件下的训练连续性：rollout server 周期性发出心跳由编排层监控，不健康的 server 会被主动终止并从推理 router 中注销。于是重试会自动被路由到健康 server 而绕开故障或退化的 server，避免单机事故打断 rollout，保持端到端 RL 训练不中断。

4 Agentic Engineering

我们描述从 vibe coding（人类 prompt）到 agentic engineering 的转变。在 vibe coding 中，是人 prompt 一个 AI 模型来写代码；在 agentic engineering 中，是 AI agent 自己写代码——它们规划、实现并迭代。为支撑这些长程任务，GLM-5 使用完全异步、解耦的 RL 框架，通过减少 agent rollout 期间的空闲时间来显著提升 GPU 利用率。为扩展 agent 环境，我们开发了环境构建流水线。对编码任务，我们基于真实世界软件工程 issue 和终端任务搭建了超过 10,000 个可验证训练场景。对 search agent，我们开发了一条自动、可扩展的复杂多步推理数据合成流水线来构建 agentic 训练数据。

4.1 面向 agentic 任务的异步 RL

为对 agent 任务做 RL，我们设计了一套完全异步、解耦的 RL 基础设施，它能高效处理长程 agent rollout，并支持跨多样 agent 框架的灵活多任务 RL 训练。

我们采用 group-wise 策略优化算法做 RL 训练。对每个问题 $x$，我们从上一版策略 $\pi_{\text{old}}$ 采样 $K$ 条 agent 轨迹 $\{y_1,\dots,y_K\}$，并按以下目标优化模型 $\pi_{\theta}$：

其中 $\bar{r}(x)\;=\;\frac{1}{K}\sum_{i=1}^{K}r\bigl(x,y_i\bigr)$ 是采样回复的平均奖励。注意只有模型生成的 token 参与优化，环境反馈在损失计算中被忽略。

4.1.1 面向 agentic 训练的异步 RL 设计

由于 rollout 过程的长尾特性，朴素的同步 RL 训练会因 agentic 任务生成的严重不均衡而在 rollout 阶段引入大量 bubble，造成大量 GPU 空闲。为提升训练吞吐，我们对 Agentic RL 采用完全异步的训练范式来提升 GPU 利用率与训练效率。具体来说，我们把训练引擎与推理引擎解耦到不同的 GPU 设备上。推理引擎持续生成轨迹，一旦生成轨迹数达到预定义阈值，这批数据就被送到训练引擎更新模型。为减少策略滞后、让训练近似 on-policy，rollout 引擎使用的模型权重会周期性地与训练引擎同步：训练引擎每 $K$ 次梯度更新就更新参数并把新权重推回推理引擎。异步虽能显著提升整体训练效率，但也意味着不同轨迹可能由不同版本的模型生成，引入严重的 off-policy 问题。由于 rollout 策略在变，每次权重更新面对的其实是一个不同的优化问题，因此我们在推理引擎每次权重更新后也重置优化器。

服务化的多任务训练设计。

多任务 RL 中轨迹生成是异质的——不同任务通常依赖不同的工具集和任务特定的 rollout 逻辑。为应对这一点，我们为多任务 RL 训练引入了服务化的 Multi-Task Rollout Orchestrator。这个组件通过一个带多个已注册任务服务的中心 orchestrator，确保 slime RL 训练框架与多样下游任务之间无缝兼容。具体来说，每个任务把自己的 rollout 与奖励逻辑实现为一个独立微服务，注册到中心 orchestrator 接受管理与调度。在 rollout 阶段，中心 orchestrator 控制每个任务的 rollout 比例与生成速度，以实现跨任务的均衡数据采集。关键在于，我们把所有 agentic 任务的轨迹标准化为统一的 message-list 表示。这既支持复杂 agentic 框架（例如软件工程任务）的联合训练，也支持对异质负载做集中式后处理与日志记录。这一设计干净地把任务特定逻辑与核心训练循环隔离开，使多任务 RL 训练能无缝集成。作为 GLM-5 训练基础设施的骨干，这个 orchestrator 支持超过 1k 并发 rollout，并支持任务采样比例的自动动态调整以及任务进度的细粒度监控。

4.1.2 优化异步训练的稳定性

Token-in-Token-out 对比 Text-in-Text-out。

在 RL rollout 设定中，token-in-token-out（TITO）意味着训练流水线消费的是推理引擎产生的精确分词与解码 token 流，并直接用它来构建学习用的轨迹。相反，text-in-text-out 把 rollout 引擎当成一个返回最终文本的黑盒，trainer 随后通过对该文本重新分词（并常常重新推导边界与截断）来重建轨迹，再计算损失。这个看似很小的选择很关键：重新分词会在 token 边界、空白/归一化处理、截断或特殊 token 位置上引入微妙的 mismatch，进而破坏动作与奖励/优势之间的步级对齐——尤其当 rollout 被流式传输、截断，或在很多 actor 之间交错进行时。我们发现 token-in-token-out 对异步 RL 训练至关重要，因为它保留了「采样出来的」与「被优化的」之间精确的动作级对应关系，同时让 actor 能立刻发出轨迹片段（token ID 加元数据），无需有损的文本往返，也无需等待 learner 侧事后重新分词。实践中我们实现了一个 TITO Gateway，拦截 rollout 任务的所有生成请求，记录每条轨迹的 token ID 与元数据。这一设计把繁琐的 token ID 处理从下游 agent rollout 逻辑中隔离出来，同时避免 RL 训练中的重新分词 mismatch。

用于 token clipping 的直接双侧重要性采样。

与 §3 中的同步 RL 训练设定不同，在异步设定下 rollout 引擎可能在单条轨迹生成期间经历多次更新，这使得追踪精确的行为概率 $\pi_{\theta_{\text{old}}}$ 在计算上不可承受。否则我们就得维护一大堆模型 checkpoint 的历史 $\{\pi_{\theta_{\text{old}}^{(1)}}, \dots, \pi_{\theta_{\text{old}}^{(N)}}\}$，这在实际实现中不可行。

为解决这一点，我们首先采用一个简化的 token 级重要性采样机制，把 rollout 期间生成的对数概率直接复用为行为代理。把重要性采样比值算作 $r_t(\theta) = \frac{\pi_{\theta}}{\pi_{\text{rollout}}}$ 并丢弃传统的 $\pi_{\theta_{\text{old}}}$，我们免去了单独做旧策略推理的计算开销。其次，我们采用双侧校准的 token 级 masking 策略。不同于标准 PPO 使用的非对称 clipping，我们把信任域限制在 $[1-\epsilon_\ell, 1+\epsilon_h]$，其中 $\epsilon_\ell$ 与 $\epsilon_h$ 是 clipping 超参。落在该区间外的 token 被完全从梯度计算中 mask 掉，以防止极端策略偏离造成的不稳定。这与 IcePop 机制⁴⁹ 有相似之处，但我们的策略更简单——进一步移除了 $\pi_{\theta_{\text{old}}}$ 并取得了更稳定的训练。

形式上，带 token 级 clipping 的优化目标可以写作：

在这一形式中，重要性采样比值 $r_t(\theta)$ 计算为：

稳定性进一步由校准函数 $f(x; \epsilon_\ell, \epsilon_h)$ 保证：

实验中我们发现，复用 rollout 对数概率是以接受一定程度的可控 off-policy 偏差为代价，来规避对历史策略的追踪，同时提升训练稳定性。

丢弃 off-policy 与噪声样本。

在异步 RL 中，过长的轨迹可能变得高度 off-policy，从而破坏训练稳定性。为过滤这些严重 off-policy 的样本，我们在生成时记录 rollout 引擎使用的策略权重版本。具体来说，对每条回复我们记录涉及的模型版本序列 $(w_0, \ldots, w_k)$，其中 $w_0 < \cdots < w_k$。令 $w'$ 表示当前策略版本，若某样本最旧的 rollout 版本太陈旧，即 $w' - w_0 > \tau$（$\tau$ 是预定义阈值），我们就丢弃它。这剔除了落后当前策略太多的轨迹。

此外，coding agent 的沙箱本身可能不稳定，可能因与模型无关的原因失败（例如环境崩溃）。这类失败会引入噪声训练信号，因为它们反映的是环境不稳定而不是模型能力。为缓解这一点，我们为每个样本记录失败原因，并排除因环境崩溃而失败的样本。对 GRPO 这类基于组采样的方法，移除失败样本可能留下不完整的组。这种情况下，若有效样本数超过组大小的一半，我们就通过重复有效样本来补齐这个组；否则丢弃整个组。这一流程降低了虚假奖励噪声，提升了训练稳定性。

用于加速的 DP-aware routing。

我们提出一种 DP-aware routing 机制，在大规模 MoE 推理中保持数据并行（DP）下的 KV cache 局部性。在多轮 agentic 负载中，来自同一 rollout 的连续请求共享完全相同的前缀。为最大化 KV 复用，我们强制 rollout 级亲和性：属于同一 agent 实例的所有请求都被路由到同一个 DP rank。具体来说，我们引入一个有状态的路由层，用一致性哈希把每个 rollout ID 映射到固定的 DP rank。这个映射在多轮之间保持稳定，消除了跨 rank 的 cache miss。为防止长期失衡，我们把哈希与哈希空间上的轻量动态负载再平衡结合。这一设计避免了冗余的 prefill 计算，同时不需要跨 DP rank 同步 KV。随着 rollout 变长，prefill 成本与增量 token 数成正比而不是与总上下文长度成正比。结果是端到端延迟改善、长上下文 agentic 推理的有效吞吐提升。

4.2 面向 agent 的环境扩展

为支持跨多样 agentic 任务的强化学习，我们构建了可验证、可执行的环境，为代码中心与内容生成两类工作流都提供有据可依的反馈。对 agentic coding 任务，我们开发了两条环境构建流水线来构造可验证的可执行环境：一条基于真实世界软件工程 issue 的环境搭建流水线，以及一条面向 terminal-agent 环境的合成流水线。在编码之外，我们进一步引入了幻灯片生成环境，agent 在其中操作结构化 HTML，并配有可执行渲染与基于布局的验证。

4.2.1 软件工程（SWE）环境

在构造可执行环境之前，我们先收集大量真实世界的 Issue-Pull Request（PR）对，并施加严格的规则型与 LLM 型过滤，以确保获得真实、高质量的 issue 陈述。我们把这些实例分成不同任务类型——bug 修复、功能实现、重构等——并附上必要的任务要求，以确保模型的实现与 test patch 一致。我们采用基于 RepoLaunch⁵⁰ 框架的环境搭建流水线，把从真实 SWE issue 构造可执行环境的过程规模化。这条流水线自动分析仓库的安装与依赖配置来构建可执行环境并生成测试命令，然后借助 LLM 从测试输出生成语言感知的日志解析函数，从而抽取 Fail-to-Pass（F2P）与 Pass-to-Pass（P2P）测试用例。用这条流水线，我们在数千个仓库、覆盖 9 种编程语言（Python、Java、Go、C、CPP、JavaScript、TypeScript、PHP、Ruby）上构造了超过 1 万个可验证环境。

4.2.2 终端环境

从种子数据合成。

为大规模构建可验证的 terminal-agent 环境，我们设计了一条 agentic 数据合成流水线，包含三个阶段：任务草稿生成、具体任务实现、迭代任务优化。从真实世界软件工程与基于终端的 computer-use 场景中收集的一组种子任务出发，我们借助 LLM 头脑风暴生成大量可验证的终端任务草稿。这些草稿随后由一个构造 agent 实例化为 Harbor⁵¹ 格式的具体任务，包括结构化任务描述、Docker 化执行环境和相应测试脚本。之后一个 refine agent 按人工定义的 rubric 检查并迭代精修生成的任务，确保 Docker 镜像能可靠构建、测试用例与任务规格一致、环境对潜在的漏洞利用或捷径足够稳健。整体上，这条流水线产出了数千个多样且可验证的 terminal-agent 环境，Docker 构建成功率超过 90%。

从 web 语料合成。

我们开发了一条可扩展的自动化流水线，基于 web 语料构造 LLM 验证过的终端编码任务，采用闭环设计——构造 agent 同时充当自己的第一轮评估者。第一步，我们收集大规模代码相关网页语料，并用数据质量分类器只保留高质量内容，丢弃以非技术为主或缺乏实质代码内容的页面。从过滤后的子集中，我们进一步识别适合形成终端式任务的网页。然后我们按主题类别与难度等级做分层采样，确保最终任务池在分布上均衡且多样。第二步，我们把 Harbor 任务构造规范⁵²——包括任务 schema、格式要求和示例任务——连同每个选定的源网页一起提供给一个 coding agent。这个 agent 被要求 (i) 基于网页内容合成一个完整的终端任务，并 (ii) 对自己的输出执行 Harbor 验证脚本。验证失败时，agent 迭代诊断并修改任务直到通过所有自动检查。只有成功通过这一自验证循环的任务才被纳入最终数据集。

4.2.3 搜索任务

对深度搜索的信息寻取任务，我们构建了一条数据合成流水线来产出有挑战性的多跳 QA 对。每个问题都要求基于从多个 web 来源聚合的证据做多步推理。

Web 知识图谱（WKG）构造与问题生成。 从早期版本 search agent 的轨迹出发，我们收集并去重所有遇到过的 URL，保留了跨多样领域的超过两百万个高信息量网页。LLM 执行语义解析来做实体识别、噪声过滤和结构化信息抽取。WKG 会随新页面不断更新，并通过实体对齐、属性归一化、关系合并与语义一致性修正，用下游验证信号来精修。基于 WKG，我们采样中低频实体作为种子节点，扩展它们的多跳邻域形成完整子图，同时控制扩展以减少重叠。用针对高难度、多领域推理的 prompt，我们把每个子图转成一个隐式编码多实体关系链的问题。

高难度问题过滤与验证。 我们用一条三阶段流水线在难度与正确性之间取得平衡：(1) 移除那些无工具推理模型在八次独立尝试中至少答对一次的问题。(2) 过滤掉早期版本 agent 用基础搜索、浏览和计算在几步之内就能解出的问题。(3) 用一个验证 agent 做双向校验：我们从阶段 2 的搜索轨迹中收集候选答案，然后分别独立验证候选答案与标注 ground truth 各自与问题的一致性，剔除答案不唯一、证据不一致或标签错误的样本。这产出了高质量、高难度、可靠的多跳 QA 对。

4.2.4 面向 search agent 的上下文管理推理

我们发现 BrowseComp⁷ 上的表现对 judge prompt 和 judge 模型都很敏感，开源 judge 会引入系统性偏差。为确保一致性与可复现性，我们用官方 OpenAI 评测 prompt 和闭源模型 o3-mini 作为 judge，标准化了所有基于 judge 的环节。案例研究显示这一配置与人工标注 ground truth 最吻合，因此我们在所有实验中都采用它。

先前工作¹³ 引入了上下文管理，其中 Discard-all 通过移除整个工具调用历史来重置上下文。我们进一步观察到，模型准确率在极长上下文（例如超过 10 万 token）下会大幅退化。受此启发，我们采用一个简单的 Keep-recent-k 策略：当交互历史超过阈值 $k$ 时，比最近 $k$ 轮更早的内容会被折叠，以控制上下文长度。设轨迹为 $(q,r_1,a_1,o_1,r_2,a_2,o_2,\cdots,r_n,a_n,o_n)$，其中 $q$ 表示问题，$r_i$ 表示第 $i$ 轮的推理，$a_i$ 表示动作（我们设计了 search、open、find 和 python 四个工具），$o_i$ 表示工具观测。我们只折叠比最近 $k$ 轮更早的观测：$o_i\leftarrow\text{Tool result is omitted to save tokens.}\quad i=1,\ldots,n-k$。实验中我们取 $k=5$，这带来稳定提升，把 GLM-5 从 55.3%（无 keep-recent-$k$）提升到 62.0%（有 keep-recent-$k$）。我们还发现，用不同的 keep-recent $k$ 值，或改为在上下文长度达到预定义 token 阈值时触发 keep-recent，都得到相同结果。

在此基础上，我们把 keep-recent 与 Discard-all 结合成一个混合的分层上下文管理策略。用 keep-recent 做推理时，若总上下文长度超过阈值 $T$，就丢弃整个工具调用历史、以全新上下文重启，同时继续应用 keep-recent 策略。我们通过参数搜索选定 $T=32k$。

如图 8 所示，在不同计算预算下，这一策略有效释放了上下文空间，让模型能执行更多步数并持续提升表现。相比单用 Discard-all，与 keep-recent-k 结合在所有预算下都取得一致增益，最终得分 75.9，优于所有配备上下文管理的开源模型。

4.2.5 幻灯片生成

我们采用一条自我改进的流水线，目标是通过强化学习和拒绝采样微调训练一个专门的幻灯片生成专家，从而系统性地提升幻灯片生成表现。我们先用监督微调（SFT）初始化模型以提供基础的幻灯片生成能力，然后做强化学习，奖励采用基于演示幻灯片常见美学与结构属性的多层次形式。这一阶段带来了生成质量的大幅提升。我们进一步做拒绝采样微调和 mask 微调，让强化学习期间获得的知识被注入回训练语料。这一流程以协同、迭代的方式同时提升了数据质量与模型能力。

我们提出一种多层次奖励形式，把基于 HTML 的幻灯片生成过程中的奖励信号划分为三个层次：

Level-1：静态标记属性。 这一层关注生成 HTML 中的声明式属性，包括定位、间距、颜色、排版、饱和度等风格属性。基于专业设计原则，我们设计了一组规则来规范模型生成这类声明时的行为。这些规则确保生成 HTML 的语法可解析性，同时把标记层面的设计空间约束到一个针对表现力、结构清晰度、视觉和谐与可读性优化过的子空间。此外，我们引入了幻觉图片与重复图片检测机制，来抑制幻觉性或冗余的插图。

Level-2：运行时渲染属性。 与静态检查不同，这一层评估渲染时 DOM 节点的运行时属性，例如元素宽高、bounding box 和其他几何布局指标。通过约束这些属性，我们鼓励生成的幻灯片在空间组织上更贴合人类审美偏好。我们开发了一个分布式渲染服务，能以高吞吐执行渲染作业并抽取所需的运行时属性。训练期间我们观察到若干 reward hacking 行为，例如对超长内容做硬截断，或过度操纵间距（见图 9）。为缓解这些问题，我们改进渲染器实现来消除可利用的漏洞，确保奖励信号真正激励美观协调的布局，而不是对几何指标的表面合规。

Level-3：视觉感知特征。 在运行时渲染约束之外，我们对渲染后的幻灯片做感知层面的评估。例如我们检测异常空白模式作为辅助信号，来进一步改善整体构图平衡与视觉美观。

训练策略。 这些信号在 RL 中被联合优化，以提升生成 HTML 的结构有效性、增强布局组织、提升整体视觉美感。除奖励设计之外，我们还通过动态采样重塑训练分布：具体来说，一部分结构上过于平凡的样本会被概率性丢弃，让优化聚焦在更有挑战的页面上，提升在复杂构图场景下的鲁棒性。我们还采用 token 级策略梯度损失来稳定优化⁵³。此外，我们引入一种均衡策略，把同一样本的不同 rollout 结果分散到多个训练 batch 中，降低优化偏差、提升训练稳定性。

拒绝采样。

在拒绝采样阶段，RL 中用的奖励函数被迁移到一条数据过滤流水线中，用来构造高质量训练子集。在页面层面，过滤标准包括代码有效性与可编译性。在轨迹层面，我们进一步强制工具执行正确性和全局内容多样性约束，确保结构一致。我们采用 Best-of-$N$ 选择策略，从多个独立生成的候选中保留质量最高的样本。这一机制有效地把分布重新加权到更高质量的实例上，带来更好的样本效率与更稳定的训练。

基于 mask 的精修。

尽管拒绝采样移除了大多数低质量输出，仍有一些轨迹的缺陷只集中在少数几页上。丢弃这类样本会降低有效数据利用率、增加生成成本。为此我们引入基于 mask 的纠正机制，自动识别有缺陷的页面并施加 mask，同时保留同一轨迹内的高质量内容。这种选择性精修保留了有价值的监督信号，提升了有效数据效率，减少了冗余重生成的开销，从而提升整体训练效率。

经验性改进。

严格符合 16:9 宽高比的生成页面比例从 40% 提升到 92%，页面溢出情况也大幅减少。人工评测进一步显示，相比 GLM-4.5，GLM-5 在内容质量上胜率 60%、布局合理性 57.5%、视觉美观 65%，整体胜率 67.5%。这些结果为所提出的多层次奖励设计与自我改进框架的有效性提供了经验证据。

5 把 GLM-5 适配到国产芯片基础设施

把 GLM-5 适配到多样的国产芯片基础设施是个不小的挑战，因为硬件生态是异质的，这往往使高性能部署变得复杂。尽管有这些障碍，我们通过与七个主流国产芯片平台——包括华为昇腾、摩尔线程、海光、寒武纪、昆仑芯、沐曦、燧原——的密切合作，成功实现了 GLM-5 的全栈适配。本节我们以昇腾 Atlas 系列为例，展示我们的适配方法论，聚焦三大支柱：极致量化、高性能算子融合、先进推理引擎调度。

混合精度 W4A8 量化。

为把 750B 参数的 GLM-5 模型装进单台 Atlas 800T A3 机器，我们实现了一套精细的 W4A8 混合精度量化策略。借助 msModelSlim⁵⁴ 工具，我们对不同模型组件施加不同精度：标准 Attention 与 MLP 块用 W8A8（INT8），而 MoE 专家被压缩到 W4A8（INT4），在不显著损失精度的前提下大幅降低显存占用。我们还采用了 QuaRot⁵⁵ 做离群值抑制、Flex_AWQ_SSZ 做缩放校准这类先进算法，来维持低比特部署下的稳定性。

高性能融合算子。

为克服稀疏注意力在昇腾 NPU 上的计算瓶颈，我们开发了一套定制融合算子：Lightning Indexer、Sparse Flash Attention 和 MLAPO（Multi-head Latent Attention Pre-processing Optimization）。Lightning Indexer 把 score 计算、ReLU 和 TopK 操作整合进单个 kernel，让 NPU 能把计算与访存重叠。对 Sparse Flash Attention kernel，我们专门针对 GLM-5 的稀疏模式做了优化，这个 kernel 并行处理从 KV cache 中选取 TopK token 以及稀疏注意力计算。最后，MLAPO 把 13 个小的预处理算子融合成一个「超级算子」，利用 Vector 与 Cube 单元之间的并行处理来提升端到端效率。

专门的推理引擎优化。

我们适配了两个主流推理引擎 vLLM-Ascend 与 SGLang，以最大化硬件利用率：

• 异步调度：在 vLLM 内，我们实现了一套机制，把「Device-to-Host」（D2H）采样拷贝与下一个 decode 步的准备工作重叠，有效消除调度「bubble」。
• 上下文管理：RadixCache（前缀共享）与 Prefix Cache（把 KV 存储扩展到系统 RAM）这类特性支持 KV 条目的高效复用，这对长上下文性能至关重要。
• 并行策略：我们采用了 Attention 数据并行（DP）与 MoE 专家并行（EP）结合的混合方案，并配合 FlashComm——它拆分 AllReduce 操作，把通信延迟隐藏在计算之后。
• Multi-Token Prediction（MTP）：通过每个推理步生成多个 token，我们显著提升了 NPU 计算密度、缩短了总序列生成时间。

通过这些硬件层面的协同优化，GLM-5 在单台国产节点上取得了与双 GPU 国际集群相当的性能，同时在长序列场景下把部署成本降低了 50%。

6 评测

如前所述，GLM-5 标志着从 vibe coding 到 agentic engineering 新时代的转变。我们首先在 agentic、reasoning、coding（ARC）benchmark 上把 GLM-5 与前沿模型做对比。为全面评测 GLM-5 在真实世界 agentic engineering 场景下的表现，我们提出一个新的内部评测套件 CC-Bench-V2，包含前端、后端与长程任务。最后，我们在五个常见真实场景中评测 GLM-5 的通用能力。

6.1 ARC benchmark 评测

我们在表 7 中报告 ARC benchmark 的主要结果，把 GLM-5 与 GLM-4.7、DeepSeek-V3.2¹³、 Kimi-K2.5⁵⁶、Claude Opus 4.5⁵⁷、Gemini 3 Pro⁵⁸ 与 GPT-5.2 (xhigh)⁵⁹ 做对比。总体上，GLM-5 相比 GLM-4.7 有显著提升，在开源模型中取得 state-of-the-art 表现，并缩小了与 Claude Opus 4.5 这类闭源模型的差距。评测细节见 §B.2。

表 7：GLM-5 与开源/闭源模型的对比。带 * 的结果来自 HLE 全集。带 † 的结果在修正了部分歧义指令的 Terminal-Bench 2.0 verified 版本上评测。GDPval-AA Elo 分数记录于 2026 年 2 月 15 日。每个 benchmark 的最高分加粗，第二高在原文中加下划线。

6.1.1 推理与通用 benchmark 评测

推理与通用 benchmark 方面，我们评测了 Humanity’s Last Exam（HLE）³、AIME 2026、HMMT 2025、IMO-AnswerBench⁶⁰、GPQA-Diamond⁶¹ 与 LongBench v2⁶²。对 HLE 只评测纯文本子集，并用 GPT-5.2 (medium) 作为 judge 模型。大多数推理任务以 131,072 token 的最大生成长度评测，HLE-with-tools 用 202,752 最大 token。

从表 7 看，GLM-5 在推理任务上的表现与强开源 baseline Kimi-K2.5 相当。相比闭源模型，GLM-5 在 HLE（带工具）上优于 Claude Opus 4.5 与 Gemini 3 Pro。相比前代 GLM-4.7，GLM-5 在 HLE benchmark（带工具与不带工具）上都有显著提升。在 HMMT 2025 年 2 月/11 月 benchmark 上，GLM-5 表现优于 Claude Opus 4.5 与 Gemini 3 Pro。GLM-5 在长上下文任务上也有显著进展，在长上下文推理 benchmark LongBench v2 上取得高分，仅次于 Gemini 3 Pro。

6.1.2 编码 benchmark 评测

编码 benchmark 方面，我们在 SWE-bench Verified⁴、SWE-bench Multilingual⁵、Terminal Bench 2.0⁶ 与 CyberGym⁶³ 上评测 LLM。对 SWE-bench Verified 与 Multilingual，我们用 OpenHands 框架配合为 GLM-5 定制的指令 prompt。对 Terminal-Bench 2.0，我们用两个 agent 框架（即 Terminus-2 与 Claude Code），并额外报告修正了部分歧义指令的 Terminal-Bench 2.0 verified 版本上的表现⁶⁴。CyberGym benchmark 在 Claude Code 2.1.18 中评测。

从表 7 看，GLM-5 在开源 LLM 中于编码 benchmark 上取得 SOTA 表现。相比闭源 LLM，GLM-5 在 SWE-bench Verified 上优于 Gemini 3 Pro，在 SWE-bench Multilingual 上也击败了 Gemini 3 Pro 与 GPT-5.2 (xhigh)。在 Terminal-Bench 2.0 上，GLM-5 取得与 Claude Opus 4.5 相当的结果，修正该 benchmark 的歧义指令后甚至更好。为展示编码能力的泛化性，我们用两个 agent 框架评测 Terminal Bench 2.0，GLM-5 在两个框架上表现一致。在网络安全编码 benchmark（即 CyberGym）上，GLM-5 相比 GLM-4.7 有显著提升，仅次于 Claude Opus 4.5。

6.1.3 Agentic 能力评测

agentic benchmark 方面，我们在 BrowseComp⁷、BrowseComp-ZH⁶⁵、$\tau^{2}$-Bench¹⁰、MCP-Atlas⁸、Tool-Decathlon⁶⁶、Vending-Bench 2¹¹ 与 GDPval-AA⁶⁷ 上评测 GLM-5 与前沿模型。BrowseComp 衡量语言 agent 通过浏览网页解决有挑战性问题的能力，BrowseComp-ZH 主要针对中文网页。对 BrowseComp 我们用 discard-all 策略做上下文管理，与 DeepSeek-V3.2 和 Kimi K2.5 相同。$\tau^{2}$-Bench 评测对话 agent 在双向控制环境中的能力，我们对 Retail 与 Telecom 做了小幅 prompt 调整以避免用户过早终止导致的失败（见 §B.3）。对 Airline，我们采用 Claude Opus 4.5 system card⁵⁷ 提出的领域修正以获得更准确的结果。MCP-Atlas 是一个真实世界工具使用 benchmark，评估 LLM 在给定 Model Context Protocol（MCP）server 的多步工作流中的表现。为公平比较，我们在 500 任务的公开集上重新评测了所有模型，并把每个任务的超时从 4 分钟延长到 10 分钟，以避免因部署条件导致的任务失败。MCP-Atlas 用 Gemini 3 Pro 作为 judge 模型。Tool-Decathlon 也是工具使用 benchmark，但针对真实世界的长程任务。Vending-Bench 2 在模拟环境中衡量 LLM 在长时间跨度商业场景下的 agentic 能力，相比前身 Vending-Bench 加入了更多真实世界因素。GDPval 关注 AI agent 在有经济价值任务上的表现。

从表 7 看，相比 GLM-4.7，GLM-5 在 agentic benchmark 上显著提升。在 BrowseComp 上，GLM-5 在带与不带上下文管理两种设定下都取得前沿 LLM 中的 SOTA 表现。在 BrowseComp-ZH 上，GLM-5 也击败了 Claude Opus 4.5 与 Gemini 3 Pro。对三个工具使用 agentic 任务（即 $\tau^{2}$-Bench、MCP-Atlas、Tool-Decathlon），GLM-5 取得与 Claude Opus 4.5 相当的表现，说明 GLM-5 有很强的工具使用能力。GLM-5 在 Vending-Bench 2 上的表现（即 4,432 美元）进一步展现了商业任务上的长程能力。在经济场景中，GLM-5 在 GDPval-AA 上优于 Claude Opus 4.5，仅次于 GPT-5.2 (xhigh)。

6.2 真实世界 agentic engineering 体验评测

真实体验比榜单更重要。我们把内部的 CC-Bench 升级为 CC-Bench-V2，用来评测模型能否在真实的 agentic engineering 环境下正确完成跨前端、后端与长程任务的端到端任务。CC-Bench-V2 完全去掉了人工标注，通过 Claude Code 和其他 agent harness，配合单元测试与 Agent-as-a-Judge 技术实现全自动化。

前端。 我们用一条流水线先构建 agent 生成的前端项目，检查是否有语法、依赖和兼容性错误，然后用 Agent-as-a-Judge 通过一个配备 Playwright 和 bash 工具的 GUI agent 模拟用户交互，来验证端到端正确性。

后端。 任务取自 C++、Rust、Go、Java、TypeScript 和 Python 的真实开源项目，涵盖功能实现、bug 修复、回归修复与性能优化。每一处改动都必须在真实工程约束下通过完整单元测试。

长程。 我们先评测模型在大型代码库上的信息寻取能力，这是像人类开发者那样定位正确文件、理解项目上下文的前提。然后我们通过多步链式任务评估端到端正确性——这些任务由挖掘有大量 commit 历史的已合并 Pull Request、并把其 commit 聚类成连贯任务链构造而来。agent 顺序执行这些链，考验它在阶段之间维持上下文、解决依赖的能力。评估把单元测试与 Agent-as-a-Judge 结合，验证功能正确性与语义符合度。

表 8：CC-Bench-V2 在前端、后端与长程任务上的评测结果。BSR：构建成功率；ISR：实例成功率；CSR：检查项成功率。

6.2.1 前端评测——Agent-as-a-Judge

我们开发了一个专为前端开发场景设计的全面自动化评测 benchmark。这个 benchmark 覆盖开发者日常构建的多样应用，包括落地页、管理面板、数据可视化、图形与动画、在线生产力工具、交互式游戏和表单驱动工作流，跨越 HTML、React、Vue、Svelte、Next.js 等主流技术栈。

每个测试用例由一个包含多条具体可实现规格的 Task，配上一个 Checklist 组成，其中每个检查项都直接从相应规格派生。评测流程遵循两阶段流水线：1) 静态验证：先验证生成代码能否成功构建并运行。2) Agent-as-a-Judge：对能正确执行的代码，我们用一个 GUI agent 模拟人类测试行为，交互式验证每个检查项，并按需求满足程度打分。我们定义以下指标：构建成功率（BSR）衡量成功初始化并运行的项目比例；实例成功率（ISR）衡量通过全部关联规格的项目比例；检查项成功率（CSR）衡量所有检查项上的细粒度完成率。数据分布以及构造与验证流程的更多细节见附录 §B.4.1。

Agent-as-a-Judge。

前端正确性本质上是视觉和交互性的，也就是说 bug 往往只在用户点击按钮或调整窗口大小时才显现，这让静态分析和固定测试套件都不够用。因此我们引入 Agent-as-a-Judge（图 10）：每个生成的项目被部署在一个 Docker 容器中并构建，以验证静态正确性；构建成功的实例随后交给一个自主 Judge Agent（Claude Code 配 Claude Sonnet 4.5，装有 Playwright MCP 工具），它以闭环循环运行——对每个检查项，agent 读源码、与实时 UI 交互（点击、按键、截图）、检查终端输出，然后给出通过/失败的判定。

为验证可靠性，我们从两个维度把 Agent-as-a-Judge 的判定与独立的人类专家判断做对比。逐点一致性方面，我们采样了 130 个检查项，让人类专家各自独立打分，再与 agent 的判定比较：两者在 94% 的项上一致，分歧集中在主观的视觉质量标准而不是功能规格上。排序一致性方面，我们用自动框架和人类专家分别评测了 8 个前沿模型（Claude Sonnet 4.5、Claude Opus 4.5、Gemini 3 Pro、GLM-4.7、DeepSeek-V3.2 等），得到的模型排序 Spearman 相关系数为 85.7%，说明强正相关。

如表 8 所示，GLM-5 取得 98.0% 的 BSR，在 CSR 上与 Claude Opus 4.5 有竞争力，但三个技术栈上都还有明显的 ISR 差距，说明 GLM-5 能满足大多数单项需求，但在端到端完成整个任务上仍不及 Claude Opus 4.5。

6.2.2 后端评测

后端评测衡量 coding agent 能否在真实工程约束下，对真实世界的服务端代码库做出正确、能通过测试的修改。我们整理了 85 个任务，跨六种语言（Python、Go、C++、Rust、Java、TypeScript），覆盖搜索引擎、数据库引擎、web 框架、AI 推理服务、知识管理系统，以及独立的算法与系统编程挑战等领域。任务类型包括功能实现、bug 修复、回归修复与性能优化，反映日常后端开发的多样性。

为实现全自动评测，每个任务都配有人工编写的单元测试（每任务 5–10 个），验证功能正确性与边界情况处理。任务以 terminal-bench 风格打包：每个任务在一个从项目实际构建环境初始化的 Docker 容器中运行，agent 收到一段描述所需改动的自然语言问题陈述。我们报告 Pass@1，只有当一个任务所有关联单元测试都通过才算解决。这种严格的全有或全无标准让这个 benchmark 尤其困难：GLM-5 与 Claude Opus 4.5 表现相当（表 8），两者都显著领先 GLM-4.7。

6.2.3 长程评测

长程评测针对的是把生产级 agentic engineering 与单轮 vibe coding 区分开来的能力：在庞大代码库中导航，以及执行多步开发——其中每个动作都会重塑后续动作的上下文。我们把它分解为两个互补任务。

大型仓库探索。 任何非平凡编码任务的前提，都是能在一个庞大、陌生的仓库中定位到正确的源文件。我们在包含数万个文件的真实高星 GitHub 仓库上构造了一个自动化 benchmark。每个问题都用自然的、面向用户的语言在业务语义层面提出，严格避免提及文件名、类名或函数名。此外，问题要求从面向用户的描述到实际实现之间做一到两跳的逻辑推理——例如，一个关于生成视频中唇形不同步的问题，对应到某个视频生成后端里的参数调优代码块。目标文件的选择以最大化导航难度为准：它们至少在三层目录深处，名字晦涩以抵抗基于关键词的搜索，实现了仓库中别处没有重复的独特功能，并且位于仓库主要功能面之外。我们报告三次运行平均的 Pass@1，若 agent 在探索过程中成功读取了目标文件即算解决。这个任务上 GLM-5 优于 Claude Opus 4.5（表 8），两者都远超 GLM-4.7。这一结果提示：有效的仓库探索更少依赖原始代码生成能力，更多依赖策略性搜索，也就是通过目录级推理与语义联想迭代收窄文件空间——而 GLM-5 在 agentic 工具使用轨迹上的训练在这里带来明显优势。

多步链式任务。 SWE-bench 这类主流编码 benchmark 把评测化简为单 commit、孤立的编辑，因此无法评估 agent 做增量开发的能力——即每一步都会改变代码库状态从而影响后续步骤。为此我们通过挖掘高质量仓库的已合并 Pull Request 构造了一个长程 benchmark，流水线如下：

1. PR 过滤。 只保留包含测试、含 3–15 个 commit、且历史为线性（非 merge）的已合并 PR。
2. 语义分组。 由 LLM 给相邻 commit 之间的成对语义相关度打分；用动态规划找到最优划分，切成连贯的任务组，在保持 commit 顺序的同时最大化组内连贯性。
3. Patch 分类。 每个任务的累积 diff 被切成三类：golden patch（agent 必须产出的核心代码）、test patch（验证用测试）和 auto-apply patch（自动应用的配置与 fixture）。
4. 问题陈述生成。 由 LLM 根据每个任务的 patch 与 commit message 生成自然语言问题陈述。
5. 任务分类。 任务被自动分类（功能 / bug 修复 / 重构 / 测试 / 配置），并沿三个维度评估：错误消除、关键路径准确性、测试通过。
6. 环境验证。 构造 Docker 环境，并应用 golden patch 以验证整条链上零回归。

给定一条含 $K$ 个任务的链，agent 从 base commit 开始顺序工作：完成任务 $k$ 后，它的改动被提交，任务 $k{+}1$ 的 auto-apply patch 被应用，于是代码库状态是累积演化的。评估依次检查每个 commit，在运行完整测试套件之前累积应用任务 $1$ 到 $k$ 的 test patch，从而既捕捉当前任务的失败，也捕捉对早前任务的回归。我们报告单个任务上的 Pass@1。这种链式、状态递归的设计直接评估了单 commit benchmark 无法触及的长程上下文追踪、规划与增量开发能力。如表 8 所示，GLM-5 相比 GLM-4.7 有大幅提升，但与 Claude Opus 4.5 的差距仍然显著。原因是错误会沿链复合：某个任务中一次次优的编辑，可能在后续任务里静默地弄坏测试。缩小这一差距需要长上下文一致性与长程自我纠错方面的进展，二者都是我们正在推进的研究方向。

6.2.4 演进式 SWE 任务评测

我们在 SWE-rebench⁶⁸ 上评测，因为 SWE-bench Verified 是一个静态、公开、人工验证的测试集，且已发布超过两年。相比之下，SWE-rebench 建立在一条自动化流水线上，持续挖掘新鲜的真实 GitHub issue 修复任务，实现去污染、时间稳健的评测，能更好地衡量对新软件工程问题的泛化能力，而不是在静态 benchmark 上的表现。表 9 给出 GLM-5 在 SWE-rebench 上的官方成绩，我们观察到 GLM-5 能有效泛化到新的 SWE 问题。

表 9：SWE-rebench 上的表现，2026 年 1 月。

6.3 真实世界通用能力评测

标准化学术 benchmark 提供了有用信号，但并不能完整刻画模型在实践中如何被使用。为弥补这一缺口，我们在一组从部署环境中观察到的高频用户交互模式派生出的真实世界通用能力上评测 GLM-5。这些能力包括机器翻译、多语言对话、指令遵循、世界知识与工具调用。

与以 benchmark 为中心的传统评测不同，我们的目标是衡量能直接转化为用户可感知质量提升的改进。对每项能力，我们采用内部人工评测、内部自动评测、外部人工评估与外部自动 benchmark 的组合，以兼顾诊断粒度与跨模型可比性。使用外部 benchmark 时，我们优先选择反映真实交互模式的数据集，而不是构造得很窄的测试分布。

图 11 给出 GLM-5 与 GLM-4.7 在五个真实能力领域上的对比结果。在所有评测维度上，GLM-5 在机器翻译、多语言对话、指令遵循、世界知识与工具调用上都有一致提升。

每项能力的详细评测协议与数据集描述如下。

6.3.1 机器翻译

ZMultiTransBench。

这个内部数据集包含 1,220 个样本，来自自采的高频翻译场景，覆盖七个语言对：中文到西班牙语（$300$）、俄语（$250$）、法语（$220$）、韩语（$200$）、日语（$150$）、阿拉伯语（$50$）和德语（$50$）。所有样本由受过翻译学正式训练的研究生整理、翻译并独立校验。数据集强调自然发生的使用语境而非人为构造的测试用例。评测采用与固定 baseline 回复的成对比较，判定由基于 GPT-4.1 的自动评估器给出，评估语义保真度、流畅度与整体翻译质量。

MENT-SNS。

为进一步评测在语言学上有挑战性的语境下的鲁棒性，我们采用 MENT⁶⁹ 的源句，包含 $753$ 个英汉句对，覆盖四个领域：社交网络服务（SNS）、跨文化、诗歌与文学。选择这些领域是为了在复杂语言现象下压测翻译，包括俚语、谐音文字游戏、习语表达、历史典故与隐喻语言。与 ZMultiTransBench 类似，所有样本都由受过专业训练的研究生整理与校验。评测遵循相同的与 baseline 回复成对比较的协议，同样以 GPT-4.1 作为自动 judge 模型。

6.3.2 多语言对话

LMArena。

我们报告 LMArena⁷⁰ 的 Elo 评分，它们来自大规模社区提交的成对比较。这些评分反映开放式对话设定下的相对模型偏好，提供了对话表现的外部信号。

ZMultiDialBench。

除公开榜单之外，我们还在 ZMultiDialBench 这个内部多语言对话 benchmark 上做人工评测。数据集包含 141 个精选实例，跨越多样对话类别。样本来自多个国家母语标注者贡献的高质量对话数据，以及线上用户上报的困难失败案例。人工标注者按类别特定的标准化评测标准，对匿名化的模型回复给出 1–10 分的逐点打分。

6.3.3 指令遵循

IF-Badcase。

IF-Badcase 是一个内部 benchmark，由生产环境中真实用户上报的指令遵循失败案例构造而成。数据集设计用于评测对真实、多约束指令的严格遵循，强调流程准确性、逻辑一致性与刚性格式要求。评测采用详细的 checklist 协议，验证对显式约束的符合度，包括有序步骤、规则型条件与结构规格。所有样本由人类专家标注、复核并迭代过滤，最终得到 450 个测试实例。

IF-Bench⁷¹。

IF-Bench 评测 LLM 遵循复杂客观约束的能力，例如特定格式规则、长度限制与内容限制。它提供了对精确指令遵循能力的量化度量，关注可验证的符合度而不是开放式生成质量。

MultiChallenge⁷²。

MultiChallenge 通过真实的多轮对话场景考察 LLM。它针对需要准确指令遵循、上下文分配与上下文内推理的复杂交互。

6.3.4 世界知识

SimpleQA⁷³。

SimpleQA 用有单一、无争议答案的困难问题衡量短答案事实性。它通过把回复分类为正确、错误或未尝试来评估模型的校准度，优先看准确性而非生成长度。

Chinese SimpleQA⁷⁴。

这个 benchmark 把 SimpleQA 方法论适配到中文语境，在六大领域、99 个子话题上评测事实性。它使用高质量、静态的短答案问题，专为可靠的自动评分设计，以评估 LLM 的知识准确性。

6.3.5 工具调用

ToolCall-Badcase。

ToolCall-Badcase 是一个内部 benchmark，由生产环境中用户上报的工具调用场景失败案例派生而来。每个实例都关联一个可验证的 ground-truth 工具调用，从而能客观评测工具选择与参数正确性两方面。评测考察模型是否 (1) 调用了正确的工具，(2) 提供了结构正确、语义准确的参数。所有样本经过多轮复核、改写与验证以消除歧义、确保可评测性。最终数据集包含 200 个精选测试用例，反映真实的工具调用能力。

7 结论

在本报告中，我们介绍了 GLM-5，一个从根本上弥合高性能推理与极致计算效率之间鸿沟的新一代基础模型。通过从「vibe coding」范式转向真正的「agentic engineering」，GLM-5 证明开放权重模型现在已能在复杂的真实世界工作流中与顶级闭源系统一较高下。GLM-5 代表了实用 AI 效用上的一次范式转变。通过把模型开源，我们希望赋能社区超越静态 benchmark，探索高效 agentic 通用智能的前沿，迎来一个 AI agent 能自主规划、实现并迭代复杂任务的新时代。

8 彩蛋

「Pony Alpha」实验对我们来说确实是一个关键时刻。以匿名方式把 GLM-5 发布到 OpenRouter 上是个大胆的决定，但结果极其令人振奋。剥去我们的品牌名之后，我们让模型的内在能力自己说话，确保收到的反馈是纯粹且无偏的。以下是简要总结：

几天之内，Pony Alpha 就成了热门话题。OpenRouter 社区的开发者开始注意到它出色的表现，尤其在复杂编码任务、agentic 工作流和角色扮演场景中。

猜测四起，很多用户猜它是 Anthropic 这类实验室泄露的更新（Claude Sonnet 5）、一次秘密的 Grok 发布，或者 DeepSeek V4。初步统计显示 25% 的用户猜是 Claude Sonnet 5，20% 猜 DeepSeek，10% 猜 Grok，其余猜 GLM-5。

最终确认它就是我们的 GLM-5，这对我们来说是个意义深远的时刻，有效地打消了对中国 LLM 能否在前沿水平竞争的质疑。

Pony Alpha（GLM-5）的成功不只关乎原始 benchmark 分数，它标志着我们的关注点向工程级可靠性的转移。

这次匿名发布让我们得以超越地缘政治偏见。社区接受这个模型，是因为它管用。

在庆祝这一成功的同时，我们必须保持务实。开放权重模型与绝对的闭源前沿之间的差距正在缩小，但这场竞赛远未结束。我们的重心仍然坚定地放在推进可扩展、高效、智能系统的边界上。

附录 A 超参

GLM-5 模型架构相关的超参见表 10。

训练方面，我们沿用 GLM-4.5 的设置，包括 Muon 优化器、cosine decay 和 batch size warmup。学习率经历一个从 0 到 2e-4 的 warmup 阶段，然后衰减到 4e-5 直到预训练阶段结束。在 mid-training 阶段，学习率从 4e-5 线性下降到 1e-5。其他超参与 GLM-4.5 相同。对 DSA warmup 阶段，学习率从 5e-3 降到 2e-4。对 DSA 稀疏适配阶段，我们用 1e-5 的恒定学习率。

表 10：GLM-4.5 与 GLM-5 的模型架构。统计参数量时，所有模型都计入 MTP 层的参数，但不计入词嵌入和输出层。

附录 B 评测细节

B.1 基座模型评测

我们在表 11 中用英文、中文、代码和数学 benchmark 评测 GLM-5 的基座模型。

表 11：GLM-5-Base、GLM-4.5-Base 与其他代表性开源基座模型的对比。

B.2 ARC benchmark 评测细节

Humanity’s Last Exam（HLE）与其他推理任务：最大生成长度 $131{,}072$ token（$temperature=1.0,top\_p=0.95,max\_new\_tokens=131072$）。默认报告纯文本子集，标 * 的结果来自全集。judge 模型用 GPT-5.2 (medium)。对 HLE-with-tools，最大上下文长度用 $202{,}752$ token。

SWE-bench 与 SWE-bench Multilingual：我们用 OpenHands 配定制指令 prompt 跑 SWE-bench 套件。设置：$temperature=0.7,top\_p=0.95,max\_new\_tokens=16384$，200K 上下文窗口。

BrowseComp：不做上下文管理时，我们保留最近 5 轮的细节。做上下文管理时，我们用与 DeepSeek-V3.2 和 Kimi K2.5 相同的 discard-all 策略。

Terminal-Bench 2.0（Terminus 2）：用 Terminus 框架评测，$timeout=2h,temperature=0.7,top\_p=1.0,max\_new\_tokens=8192$，128K 上下文窗口。资源上限为 16 CPU、32 GB RAM。

Terminal-Bench 2.0（Claude Code）：在 Claude Code 2.1.14（think 模式）中评测，$temperature=1.0,top\_p=0.95,max\_new\_tokens=65536$。我们移除了 wall-clock 时间限制，但保留每任务的 CPU 与内存约束。我们修复了 Claude Code 引入的环境问题，并额外报告在解决了歧义指令的 Terminal-Bench 2.0 verified 数据集上的结果⁶⁴。分数为 5 次运行的平均值。

CyberGym：在 Claude Code 2.1.18（think 模式，无 web 工具）中评测，$temperature=1.0,top\_p=1.0,max\_new\_tokens=32000$，每任务 250 分钟超时。结果是 1,507 个任务上的单次运行 Pass@1。

MCP-Atlas：所有模型都在 500 任务的公开子集上以 think 模式评测，每任务 10 分钟超时。judge 模型用 Gemini 3 Pro。

$\tau^{2}$-Bench：我们在 Retail 和 Telecom 中加了小幅 prompt 调整，以避免用户过早终止导致的失败。对 Airline，我们采用 Claude Opus 4.5 system card 提出的领域修正。

B.3 面向 $\tau^{2}$-Bench 的优化用户模拟器

我们在 Telecom 和 Retail 中加了小幅 prompt 调整，以避免用户过早终止导致的失败。优化后的 prompt 见下方图 12 与图 13。这些优化 prompt 按如下方式集成进 system prompt：

1
2
3
4
5
6
7
8
9

SYSTEM_PROMPT = """"
{global_user_sim_guidelines}

<scenario>
{instructions}
</scenario>

{optimized_user_prompt}
"""".strip()

图 12：$\tau^{2}$-Bench Telecom 的优化用户 prompt。

1
2
3
4
5
6
7
8
9

# Note:
- Do not generate the '###TRANSFER###' before agent clearly tells "YOU ARE BEING TRANSFERRED TO A HUMAN AGENT. PLEASE HOLD ON.".
    Example:
    Case1:
        - agent: "Would you like me to transfer you to a human agent who can assist you with these options and help get your service restored?"
        - user: "Yes, please transfer me to a human agent.".
    Case2:
        - user: "YOU ARE BEING TRANSFERRED TO A HUMAN AGENT. PLEASE HOLD ON."
        - user: "###TRANSFER###"

图 13：$\tau^{2}$-Bench Retail 的优化用户 prompt。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# Rules:
- Just generate one line at a time to simulate the user's message.
- Do not give away all the instruction at once. Only provide the information that is necessary for the current step.
- Do not hallucinate information that is not provided in the instruction. Follow these guidelines:
    1. If the agent asks for information NOT in the instruction:
        - Say you don't remember or don't have it
        - Offer alternative information that IS mentioned in the instruction
    2. Examples:
        - If asked for order ID (not in instruction): "Sorry, I don't remember the order ID, can you search for it? My name/email/phone number/zipcode is ..."
        - If asked for email (not in instruction): "I don't have my email handy, but I can give you my name and zip code which are..."
- Do not repeat the exact instruction in the conversation. Instead, use your own words to convey the same information.
- Try to make the conversation as natural as possible, and stick to the personalities in the instruction.
# Constraint Handling:
- Provide requests strictly based on what is explicitly stated in the instruction.
- Do not assume, extend, substitute, or generalize in any form.
- Do not modify or relax constraints on:
- Time / Date
- Budget
- Specific terms (e.g., "same" must not be replaced with "similar")
- Core Rule: Any attribute NOT mentioned in the instruction can be either changed or kept the same
- Examples:
    - If instruction says "exchange red item to blue": Only color must change, other attributes (size, material, etc.) are flexible
    - If instruction says "exchange red item to blue, keep the same size": Both color must change AND size must stay the same
- Exception: Only follow additional constraints when explicitly stated in the instruction
# Domain-Specific Rules:
## For Retail scenarios:
- Focus on product attributes and exchange/return processes as specified in instructions.
- During confirmations: Always respond based strictly on the original instruction, never deviate to match agent's provided options. Restate your requirement from the instruction rather than selecting from agent's choices.
    - Example: If the agent provides specific options (A/B/C) but the instruction states a general requirement (e.g., "same as pending order"), always restate or confirm based on what the instruction says, not by directly selecting from the agent's provided options.
# When NOT to finish the conversation:
- Do not end until you have clearly and completely expressed all your requirements and constraints.
- Do not end until the agent has completed all tasks mentioned in the instruction and verified no operations were missed.
- Do not end if the agent's execution results do not match your expectations or are incorrect/incomplete.
# When you CAN finish the conversation:
- Only when all above conditions are satisfied AND all tasks are completed correctly.
- OR when you have clearly expressed complete requirements but the system explicitly states it cannot complete them due to technical limitations - in this case, accept transfer to human.
# How to finish the conversation:
- If the agent has completed all tasks, generate the '###STOP###' token to end the conversation.
# Note:
- You should carefully check if the agent has completed all tasks mentioned in the instruction before generating '###STOP###'.

B.4 真实世界 agentic engineering 体验评测

B.4.1 前端评测

数据。

我们的数据集涵盖七个不同的前端场景，用于评测模型在多样功能领域上的工程能力：业务管理系统、Web 游戏、SVG/Canvas 渲染、创意工具与编辑器、展示页面、表单与表格，以及数据可视化。

表 12：前端应用场景的分布。

按编码语言的数据分布

这个 benchmark 完整覆盖三种主流范式：Vanilla Web Stack（HTML/CSS/JS）、React 组件式框架，以及 Vue 3 + Vite 渐进式方案。

表 13：技术栈与评测单元的统计。

数据样例

每个测试用例由三部分组成：Task、Checklist 和一个专用环境。以下是一个代表性的测试用例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

    Task: Develop an online drawing tool that includes a brush, an eraser, a white canvas, and a save button.
        The brush color and thickness should be selectable via buttons on the left. Users can draw on the canvas by clicking and dragging the mouse.
        The eraser size should be selectable via buttons on the left. Users can erase content by clicking and dragging the mouse over the canvas.
        Once the drawing is complete, clicking the "Save" button should allow the user to save the image locally.
        Please implement this using the React framework in the current directory.

    Checklist:
        The user can select the brush color and thickness using the left-hand buttons, and drawing is functional via mouse click-and-drag on the canvas.
        The user can select the eraser size using the left-hand buttons, and erasing is functional via mouse click-and-drag on the canvas.
        Upon clicking the "Save" button, the generated image is successfully saved to the local machine.

数据构造与验证

我们用一条严格的四阶段流水线来保证数据质量：

• 阶段 1：任务合成。 任务由资深前端专家设计，确保它们反映真实世界的工程挑战，同时在多样场景与技术之间保持均衡分布。
• 阶段 2：Checklist 生成与精修。 我们先用 Claude Sonnet 4.5 基于任务规格 $T$ 合成候选 checklist，然后由专家细致审核并整合。经过多轮精修，我们确保每个检查项语义无歧义、客观，并且对用户需求有穷尽覆盖。
• 阶段 3：基于执行的纠正。 我们在 Agent-as-a-Judge 框架与人类专家之间做交叉验证，任何判断分歧都会触发对底层数据的重新评估与修正，以消除潜在噪声。
• 阶段 4：动态 benchmark 迭代。 为保持高辨别力，我们迭代更新测试套件，移除已不再能挑战 state-of-the-art coding agent 的平凡任务。这一专家主导的整理过程最终形成了 220 个高质量前端编码任务及其对应 checklist。