GLM-5.2 登顶开源模型：744B/40B MoE 的「长程思考」时代

今天 AI 圈最大的新闻，当属智谱（Z.ai）正式发布 GLM-5.2——一个在 Artificial Analysis Intelligence Index 上以 51 分 登顶开源榜首的模型，压过 MiniMax-M3（44 分）和 DeepSeek V4 Pro max（44 分）。

51 分什么概念？比 GLM-5.1 整整高了 11 分，已经摸到了 GPT-5.5 的边。

这篇文章从一名开发者的视角，拆一下 GLM-5.2 的技术亮点和实际意义。

不是更大，是更会「想」

GLM-5.2 的参数规模和上一代完全一样：744B 总参数 / 40B 活跃参数。Mixture-of-Experts 架构没动，activation ratio 保持在 ~5.4%。

744B 总参数、40B 活跃参数——这个 MoE 架构跟上一代完全一样，参数规模没变。activation ratio 保持在 ~5.4%，也就是每次推理只激活总容量的二十一分之一。

MoE 路由机制大概是这样：每个 token 进入模型后，router 网络会计算一个分数，决定把这个 token 发给哪几个 expert（通常是 top-2）。expert 收到 token 后做实际计算，output 再按 router 分数加权合并。整件事的难点不在模型有多大，在于两个问题——负载均衡和路由坍塌。

负载均衡是说，不能让某些 expert 忙死、某些 expert 闲着。如果 router 每次都把 token 发给同样的几个 expert，那些 expert 的梯度会爆炸，其余 expert 收不到足够的训练信号。解决方案通常是加一个 auxiliary loss，惩罚不均衡的路由分布——但加多了会影响模型质量，加少了又均衡不了。这是 MoE 训练里最磨人的调参环节。

路由坍塌更致命。训练中后期，某些 expert 可能突然「死掉」——无论输入什么 token，router 都不再选它们。一旦 expert death 超过 10-20%，模型的有效容量急剧下降。恢复手段包括重新初始化 dead expert、调整 expert 容量上限、或者用 dropless MoE 让所有 expert 都参与计算。

GLM-5.2 在参数完全不变的情况下把 Intelligence Index 从 40 拉到 51，意味着智谱在路由策略上做了扎实的优化。MoE 模型的 scaling law 不只是「加参数」，路由算法的改进能带来等效于几倍参数增长的提升——而且不增加推理成本。

这次跑的 benchmark 覆盖面和以往不太一样。除了传统的 MMLU、GPQA、HumanEval，加入了大量长程推理和 Agent 类评测。智谱对 GLM-5.2 的定位很明确：不是聊天模型，是能干活、能走完长流程的模型。

当前开源模型头部梯队一览

模型	架构	总参数	活跃参数	上下文	Index评分	API输出价	亮点
GLM-5.2	MoE	744B	40B	128K	51	$4.4/M	Agent能力最强
DeepSeek V4 Pro	MoE	~800B	42B	128K	44	$4.0/M	推理性价比高
MiniMax-M3	MoE	700B+	38B	1M	44	$5.0/M	超长上下文
Kimi K2.6	MoE	~700B	40B	1M	43	$4.5/M	多模态融合

在纯数学和代码生成上，各家差距很小——说明基础能力已经趋于同质化，下一阶段的竞争核心转向了「谁能把模型用得更顺」。

对比 GLM-5.1 的分数分布：

Benchmark	GLM-5.1	GLM-5.2	提升
CritPt（科学推理）	5%	21%	+16pp
HLE（难题）	28%	40%	+12pp
AA-LCR	62%	71%	+9pp
GPQA Diamond	86%	89%	+3pp
TerminalBench v2.1	62%	78%	+16pp
SciCode	43%	50%	+7pp

注意这几个分数。CritPt 从 5% 涨到 21%——绝对值虽然还是不高，但 4 倍的相对提升说明模型在「需要多步推理的科学问题」上产生了质变。TerminalBench v2.1 提升到 78%，意味着它在终端任务（命令行、脚本执行、Agent 操作）上已经相当可用。

Agent 能力是真正的亮点

GLM-5.2 在 GDPval-AA v2 上拿了 1524 分，超过了 DeepSeek V4 Pro（1328）和 MiniMax-M3（1418），和 GPT-5.5 的分数基本持平。

GDPval 是一个面向长程 Agent 任务的评测——不再是单轮问答，而是 250 轮交互 内的规划、执行与纠错。模型需要在对话过程中持续维护上下文状态，在遇到失败时调整策略，直到完成任务或耗尽轮数。

1524 分意味着：GLM-5.2 已经具备了相对可靠的多步 Agent 能力。不是玩具级别，是真的可以在生产链路里跑一些中等复杂度的 Agent 任务了。

对于自己在搭 AI Agent 的团队来说，这个分数比 MMLU 和 GPQA 更有参考价值，因为它直接对应了「模型会不会用工具」「遇到错误能不能自己纠正」「会不会跑着跑着忘了前面在干什么」。

拿实际场景举例：

# 一个简单的自动化运维 Agent 伪代码
agent = GLMAgent(model="glm-5.2", tools=[shell, kubectl, curl])

task = """
1. 检查生产环境所有节点的 kubelet 状态
2. 找到状态异常的节点，查看 kubelet 日志最后 50 行
3. 如果日志中有 OOM 相关的关键字，执行 `kubectl describe node` 并分析
4. 汇总报告
"""

result = agent.run(task, max_turns=30)

上面这个任务看似简单，但涉及了多次工具调用、日志分析、条件分支决策。过去用开源模型跑这种流程，经常在第二步就翻车——模型直接返回一个编造的 kubelet 状态，而不是真的去执行命令。GLM-5.2 在 TerminalBench 上的 78% 和长程 Agent 评测的 1524 分，说明了它在「真的执行命令而不是假装执行」这件事上有了很大进步。

如果你在用 vLLM 或 SGLang 部署，接入 GLM-5.2 的 OpenAI 兼容接口大概是这样：

curl https://api.z.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [
      {"role": "system", "content": "你是一个运维助手"},
      {"role": "user", "content": "分析这台机器的磁盘使用情况"}
    ],
    "tools": [...],
    "max_tokens": 4096
  }'

API 兼容性是关键——工具调用（function calling）格式是否和 OpenAI 对齐、流式输出的稳定性、长上下文的推理延迟——这些才是实际落地的障碍，而不是 bench 分数。

另外两个实用的接入方式：

LangChain 直连——如果你已经在用 LangChain 做 Agent 编排：

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="glm-5.2",
    base_url="https://api.z.ai/v1",
    api_key="your-key",
    temperature=0.1,
)

vLLM 本地部署——自己跑推理：

vllm serve THUDM/glm-5.2-9b \
  --tensor-parallel-size 4 \
  --max-model-len 131072 \
  --enable-auto-tool-choice

本地部署的主要成本在显存。744B 的 FP8 量化版本需要约 8×H100-80GB；如果跑 INT4 量化加 tensor parallel 8 卡，能在 4×A100-80GB 上勉强跑起来。对个人开发者来说还是太重了，但团队级别完全可接受——一张 H100 的时租现在 ~$2.5，跑一个 Agent 任务几毛钱。

API 调用则简单很多：GLM-5.2 定价 $1.4/$4.4/$0.26（输入/输出/缓存命中，每百万 token），和 GLM-5.1 价格一样。在同等价格下 Intelligence Index 从 40 跳到 51，性价比明显比上一代好。

长上下文的定位

从 GLM 系列的历史来看，智谱一直在押注长上下文。GLM-5.1 支持 128K，GLM-5.2 延续了这一路线。

128K 上下文在今年的模型竞争中已经不是最突出的——MiniMax-M3 和 Kimi K2.6 都支持到了 1M。但长上下文和长程 Agent 能力是两件不同的事。

长上下文是「能记住」：128K 的 context window 可以容纳约 10 万 tokens 的内容。一部《三体》大约 30 万字，128K 能装下约 7 万字的有效信息。

长程 Agent 是「能干完」：在一个多步任务里，模型不仅要记住之前说了什么，还要在每一步做出正确的决策——调用什么工具、解析什么输出、下一步怎么做。这比「记住」难很多。

GLM-5.2 的独特之处在于它在这两条线上同时发力。128K 上下文保证了 Agent 的长程记忆空间，250-turn 的测试框架验证了它的决策稳定性。这两个条件一起满足的模型，在开源阵营里确实不多。

在长程 Agent 任务里，128K 上下文的好处很直接：Agent 不需要频繁地 truncate 或 compress 对话历史，可以在一次 session 里完成更多步骤。但代价也很明显——更大的 KV cache 意味着推理成本更高。

GLM-5.2 在 API 上定价 $1.4/$4.4/$0.26（输入/输出/缓存命中，每百万 token）——和 GLM-5.1 一样。在同等价格下提升了 11 分 Intelligence Index，性价比确实不错。

开源模型的格局变化

GLM-5.2 以 open weights 形式发布，HuggingFace 上可以下载。

在「开源模型」这个赛道上，格局正在微妙地变化。DeepSeek V4 一直以性价比著称，MiniMax-M3 在工程部署上做得很极致（同时支持 1M 上下文），GLM-5.2 这次在综合能力和 Agent 能力上拔了头筹。

三个模型都不算严格意义上的开源（都是 open weights + 商业许可），但在这个定义下，竞争已经白热化了——每隔一两周就有新模型刷新排行榜。

API 定价也在快速收敛。GLM-5.2 定价 $1.4/$4.4/$0.26，DeepSeek V4 Pro $1.0/$4.0/$0.25，MiniMax-M3 $1.5/$5.0/$0.30。差距在 30% 以内，不再像一年前那样有「一个便宜到没朋友、一个贵到不敢用」的极端分化。竞争从价格战转向了能力战，这才对开发者有利。

几个值得关注的方向：

API 成本持续下降。开源模型的竞争直接压低了闭源模型的定价。
本地部署的门槛在降低。40B 活跃参数的 MoE 经过量化后，在 2-4 张 A100 上就能跑起来，单卡 RTX 4090 勉强也能跑 4-bit 量化版。
长上下文 + Agent 不再是闭源独有。GLM-5.2 在 Agent benchmark 上的表现证明，开源模型正在快速追平这个能力缺口。

一个开发者的视角

上个月我尝试用某开源模型搭一个自动化运维 Agent，最痛苦的不是模型「不够聪明」，而是它在多步操作中频繁丢失上下文——执行到第三步就忘了第一步的指令。不得不频繁 truncate 历史，用 prompt 工程反复强调，或者在每步工具调用之前把前面的关键信息重新注入。

很多人在实际使用开源模型时都有这个痛点：bench 很好看，但一上真实场景就翻车。模型会回答问题，但模型不会持续干活。GLM-5.2 的 GDPval 分数有参考价值，正是因为它模拟的真实场景——不考知识量，考耐力。

如果 GLM-5.2 的 128K 上下文 + Agent 能力真的像 bench 显示的那么可靠，那对于这类「带工具的多步操作」场景，可能终于不用再依赖 GPT 系列了。能跑本地、不走外网、没有数据安全顾虑——这对于很多企业场景来说是刚需。

部署参考

如果你考虑自己部署 GLM-5.2，几个需要注意的点：

vLLM 支持：GLM 系列对 vLLM 的兼容性一直不错，GLM-5.2 应该开箱即用。vllm serve THUDM/glm-5.2-9b --tensor-parallel-size 4
量化策略：MoE 模型量化比 dense 模型更复杂。建议优先用 FP8，看显存和精度是否满足需求。INT4 需要验证 expert routing 的精度损失。
前后端分离：推荐用 vLLM 做推理引擎 + 自己写的 Agent orchestration 层。用 LangChain 或自制框架都可以，关键是控制好 tool call 的格式对齐。

当然，bench 和实际体验是两回事。等 GLM-5.2 的 API 和开源权重全面铺开，我会在真实的 Agent pipeline 里跑一遍运维场景，看看终端日志里到底是「成功完成任务」还是「第三步又忘了」。希望结果是前者。

参考：Artificial Analysis Intelligence Index v4.1 / GDPval-AA v2 / z.ai GLM-5.2 发布公告

posted on 2026-09-28 22:30 0xfisher 阅读(11) 评论(0) 收藏举报

刷新页面返回顶部

导航

公告