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

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 的经典问题：后面的阶段优化新目标时，前面学到的能力退化（灾难性遗忘）

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 三步融合成一个算子
• 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
• 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

GitHubhttps://github.com/zai-org/GLM-5

Hugging Facehttps://huggingface.co/zai-org/GLM-5

ModelScopehtps://modelscope.cn/models/ZhipuAI/GLM-5

Z Codehttps://zcode.z.ai/cn

Bloghttps://z.ai/blog/glm-5

文章来自于微信公众号 "赛博禅心"，作者 "赛博禅心"