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 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 生成数据
中期训练 上下文窗口分三个阶段扩展：
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 的做法是完全异步：
• 推理端持续不断地生成轨迹，攒够一批就发给训练端
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 次就删） • 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
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
Z Code https://zcode.z.ai/cn
Blog https://z.ai/blog/glm-5
粤ICP备14082021号
免费POC，
零成本试错
