744B参数只激活5%，这个纯国产训练的AI在编程上追平了Opus 4.6
GLM-5.1的意义不只是又一个跑分好看的模型。国产算力闭环已经跑通。从芯片（昇腾910B）到框架（MindSpore）到模型（GLM-5.1），一条完全不依赖英伟达的完整技术链路被验证了。这不是PPT上的规划，而是一个744B参数的旗舰模型实实在在跑出来的结果。对国内AI产业的自主可控来说，这是一个实质性的里程碑。AI正在从"回答问题"转向"交付项目"。8小时长程任务能力听起来像是Benchma
744B参数只激活5%，这个纯国产训练的AI在编程上追平了Opus 4.6
大家好，我是摘星，今天我们来拆解一下GLM-5.1——智谱AI刚发布的744B参数旗舰开源模型，全程零英伟达GPU、纯华为昇腾910B训练，SWE-bench Pro编程基准测试拿到58.4%位列开源第一，还能连续自主工作8小时交付工程级代码。这不是又一个大模型刷榜的故事，而是一条从芯片到框架到模型完全自主可控的技术链路首次被跑通的里程碑。这篇文章会从架构原理、训练工程、性能对比、实战调用四个维度，把GLM-5.1里里外外拆干净。
一、先说结论：GLM-5.1到底强在哪？
4月8号，智谱正式发布GLM-5.1。不是小版本的迭代，而是一次模型范式的跳跃。先看几个关键数字：
| 指标 | GLM-5.1 |
|---|---|
| 总参数量 | 744B（7440亿） |
| 每次推理激活参数量 | 40B-44B |
| 架构 | MoE（256个专家/每次激活8个） |
| 上下文窗口 | 200K tokens |
| 开源协议 | MIT |
| 训练硬件 | 10万块华为昇腾910B |
| 训练框架 | MindSpore |
| SWE-bench Pro | 58.4%（开源第一） |
| 长程任务能力 | 8小时+持续自主工作 |
这几个数字里，最让我震撼的不是744B的总参数量，而是最后一行——8小时持续自主工作。这意味着你给它一个复杂的工程任务，比如"从零搭一个带GUI的Linux桌面"，它真的能连续干8个小时，自己规划架构、写代码、编译测试、修bug、做性能优化，最后给你交付一个能跑的东西。
这种能力跟传统的"问答式AI"完全是两个物种。以前的大模型更像是一个超级聪明的顾问——你问它答，质量很高但主动性为零。GLM-5.1代表的趋势是AI从"被问才答"转向"给个目标就开干"，本质上是从Chatbot进化到了Doer。
二、认识GLM-5.1：从清华实验室到全球开源第一
2.1 智谱AI是谁？
智谱AI成立于2019年，核心团队来自清华大学计算机系KEG实验室，在知识图谱、图学习和大规模预训练模型领域深耕多年。这家公司有几个特点：学术底子厚、开源态度坚决、对AGI有长线思考。
GLM（General Language Model）系列是智谱的核心产品线，从最早的GLM-130B到GLM-4，再到今天的GLM-5.1，每一代都在尝试不同的技术路线。GLM-5.1是这一系列中参数量最大、能力最强的一次飞跃。
2.2 GLM-5.1解决了什么问题？
过去两年，大模型的竞争主要围绕两个维度：一是"聪明程度"（基准测试分数），二是"性价比"（推理成本）。但智谱团队发现了一个被忽视的第三维度——持久性。
一个能完美回答LeetCode难题的模型，和一个能连续8小时修Bug的模型，能力差距不是"量变"而是"质变"。前者是工具，后者是同事。GLM-5.1的核心定位就是做那个"能干活的AI同事"。
官方文档给出的定位非常明确：“构建Autonomous Agent与长程Coding Agent的理想基座”。这八个字浓缩了GLM-5.1的全部设计哲学——不是追求单次回答的完美，而是追求长程任务的可靠交付。
三、MoE架构拆解：为什么744B参数只激活44B？
3.1 MoE是什么？用医院来类比
MoE（Mixture of Experts，混合专家模型）这个概念其实不新鲜，但GLM-5.1把它做到了一个新高度。
想象一家超大型医院，有256个科室（专家），每个科室都有自己擅长的领域。一个病人来了，医院的分诊系统（Router/Gating Network）会根据病情，选择最对口的8个科室来会诊，而不是让256个科室全部出动。
这就是MoE的核心思想：模型很大，但每次推理只激活一小部分。
在GLM-5.1中：
- 256个专家网络，每个都是独立的神经网络
- Router（路由器） 根据输入token的特征，动态决定激活哪8个专家
- 每次推理只用到 40B-44B 的参数（约总参数的5.4%-5.9%）
- 没被选中的216个专家完全不参与计算
这种设计的直接好处是：你有744B参数的知识容量，但只需要44B参数级别的计算开销和显存。训练时可以塞进大量知识，推理时又不会因为参数量太大而慢到不可用。
上图展示了MoE的核心工作流程：输入经过Router后，只有被选中的8个专家参与计算，其余专家（灰色部分）完全闲置。这种"按需激活"的机制，使得744B的巨型模型在实际推理时，计算量跟一个44B的Dense模型差不多。
3.2 GLM-5.1的MoE特别在哪？
MoE架构已经被广泛采用——Mistral的Mixtral、DeepSeek系列、Qwen系列都在用。但GLM-5.1在工程层面做了一个关键的优化：Layer级MoE绝对均衡。
传统MoE有个老大难问题叫"负载不均衡"（Load Imbalance）——Router会倾向于把token都分给少数几个"明星专家"，导致有些专家累死、有些闲死。这不仅浪费了大量参数，还会在训练时造成严重的显存瓶颈——热门专家所在的GPU成了系统的瓶颈节点。
智谱的解法是在每一层（Layer）都强制实现专家间的负载均衡。具体来说，他们在训练的损失函数中加入了均衡惩罚项，同时配合动态的专家容量调整机制，确保每个专家被激活的频率大致相同。这听起来简单，但在256个专家、10万块芯片的训练规模上实现"绝对均衡"，背后的工程复杂度相当高。
实际效果：推理整体吞吐提升了30%。在模型部署层面，30%的吞吐提升意味着同样硬件条件下能多服务30%的用户，或者把响应延迟降低30%——这在商业场景中的价值是巨大的。
3.3 稀疏激活的经济账
来算一笔账。一个744B的Dense模型（假设每两个Token就要做一次矩阵乘法），以FP16精度运行，需要的显存大约是1.5TB。这已经不是单机能搞定的范畴了，需要多机多卡的张量并行。
而GLM-5.1的MoE架构，虽然总参数是744B，但每次只激活44B。以FP16精度运行，激活部分的显存需求约88GB——这在单张高端GPU（如A100 80G或H100）上通过张量并行就能搞定。即使加上Router的开销和专家缓存的显存，整体部署成本也远低于同等参数量的Dense模型。
四、10万块昇腾910B：纯国产算力训练的工程挑战
4.1 为什么"不用英伟达"这件事很重要？
先说背景。全球AI训练芯片市场，英伟达长期占据80%以上份额。H100、H200几乎是所有旗舰大模型训练的标配。国产芯片能不能撑起744B参数级别的大模型训练？这个问题在2025年之前，答案基本是"不确定"。
GLM-5.1用事实给了回答：可以，而且效果很好。
10万块昇腾910B，基于华为的MindSpore框架，从预训练到监督微调到强化学习对齐，全流程没有一块英伟达GPU参与。
昇腾910B的核心规格：
- 达芬奇（DaVinci）架构，内置3D Cube矩阵运算单元
- FP16算力约320 TFLOPS
- 针对大模型训练场景做过专门的通信优化（HCCL集合通信库）
- 支持FP32/FP16/BF16/INT8等多种精度
但硬件参数只是基础，真正的挑战在于软件栈的适配。大模型训练不只是"把矩阵乘法跑起来"那么简单，它涉及大量复杂的系统工程：
- 分布式训练的并行策略：数据并行（DP）、张量并行（TP）、流水线并行（PP）、专家并行（EP）的组合配置
- 混合精度训练的数值稳定性：BF16精度下的梯度溢出和下溢处理
- 万卡级别的通信同步：10万块芯片间的参数同步效率
- MoE特有的All-to-All通信：每个token需要被发送到它被分配的专家所在的芯片上，这是MoE训练最大的通信瓶颈
- 长序列（200K上下文）的显存管理：超长上下文带来的KV Cache显存压力
MindSpore在这些方面做了大量针对性优化。智谱的团队还实现了MoE场景下的通信计算重叠（Computation-Communication Overlap）——一边做矩阵运算，一边进行跨卡的专家参数同步，把通信延迟隐藏在计算过程中。这个技巧听起来简单，但在万卡规模下实现稳定重叠，需要对硬件的通信带宽和计算吞吐做极其精细的建模和调度。
4.2 训练架构全景
上图展示了GLM-5.1训练的两个维度。左侧是集群级别的4D并行策略——数据并行负责扩大batch size，专家并行负责把256个专家分布到不同芯片上，张量并行负责在芯片组内拆分单个专家的参数，流水线并行负责按层切分模型。右侧是单芯片上MoE前向传播的核心流程。其中All-to-All通信（红色节点）是整个训练中最大的瓶颈——每个token都需要被发送到它被分配的专家所在的芯片上，计算完再收回来。10万块芯片的规模下，这个通信的优化直接决定了整体训练效率。
4.3 国产化推理生态适配
智谱不仅做了训练，还推动了一整套国产化推理适配：
| 芯片厂商 | 适配状态 |
|---|---|
| 华为昇腾 | Day 0上线华为云 |
| 摩尔线程 | 已完成适配 |
| 壁仞科技 | 已完成适配 |
这意味着你用国产芯片做推理部署时，GLM-5.1可以直接跑起来，不需要自己折腾算子适配和性能调优。对于有国产化替代需求的企业来说，这是实打实的便利。
五、SWE-bench Pro 58.4%：这个分数含金量有多高？
5.1 SWE-bench Pro到底在测什么？
SWE-bench Pro是目前公认最接近真实软件开发场景的AI编程基准测试。它不像HumanEval那样给你一个函数签名让你补全几行代码——它给你一个真实的GitHub Issue，你需要在完整的代码仓库里定位问题、理解项目上下文、修改代码、通过测试。
这个测试难在哪？
- 需要理解整个项目结构，不是看几行代码就能解题
- 需要准确定位Bug或功能点，经常涉及多个文件的联动修改
- 需要通过已有的测试套件，不能"看起来对但跑不通"
- 问题空间巨大，不是简单的模式匹配能搞定的
5.2 横向对比
先说一个关键背景：SWE-bench有多个版本，难度差距极大。SWE-bench Verified上顶级模型已经能跑到80%以上，但SWE-bench Pro的难度远高于Verified——它使用的是更接近真实开发场景的测试集，模型需要处理更复杂的跨文件修改和长期依赖问题，目前所有模型的得分都低得多。
| 模型 | SWE-bench Pro | 参数量 | 开源状态 | 训练硬件 |
|---|---|---|---|---|
| GLM-5.1 | 58.4% | 744B MoE | MIT协议 | 昇腾910B |
| GPT-5.4 | ~57.7%* | 未公开 | 闭源 | NVIDIA |
| Claude Opus 4.6 | 未公开** | 未公开 | 闭源 | 未公开 |
| DeepSeek V3 | ~52%* | 685B MoE | MIT协议 | NVIDIA |
| Gemma 4 31B | ~45%* | 31B Dense | Apache 2.0 | NVIDIA |
*注：GPT-5.4、DeepSeek V3、Gemma 4的分数为行业估算值或来自公开排行榜，非各厂商官方公布
**Claude Opus 4.6的SWE-bench Pro分数暂未公开，其在SWE-bench Verified上已超过80%
GLM-5.1以58.4%位列开源第一，在所有模型中也处于最前列。这个成绩在开源模型中断层式领先——比同为开源的DeepSeek V3高了约6个百分点，比Gemma 4 31B高了13个百分点以上。即使与闭源模型对比，58.4%也是一个非常高的分数——要知道在SWE-bench Pro这个"地狱难度"的基准上，之前最高分也仅在46%-58%的范围内。
智谱官方明确表示GLM-5.1在"综合能力与Coding能力上整体表现对齐Claude Opus 4.6"。一个开源模型，在编程领域站到了闭源巨头的同一梯队，这在一年前是不可想象的。
5.3 长程任务：8小时自主编程的真实Demo
跑分是跑分，真正让GLM-5.1跟其他模型拉开差距的，是**长程任务（Long Horizon Task）**能力。
智谱展示了几个相当震撼的Demo：
Demo 1：从零构建Linux桌面环境
GLM-5.1自主完成了一个完整的Linux桌面GUI的构建，涉及窗口管理系统、事件循环、渲染管线等多个子系统。整个过程耗时数小时，中间经历了自主架构设计、编码实现、编译调试、Bug修复、性能迭代的完整闭环。没有一个人类工程师在旁边指导。
Demo 2：CUDA Kernel优化
在一个14小时的任务中，GLM-5.1自主优化了一组CUDA Kernel。它先分析现有实现的性能瓶颈，然后尝试多种优化策略——共享内存优化、warp-level并行、向量化访存等，最终实现了显著的加速比。14个小时，持续优化，自主迭代。
Demo 3：655轮向量数据库优化
这是最能体现"长程"概念的一个Demo——GLM-5.1对一个向量数据库项目进行了655轮迭代优化。每一轮都包括：分析现状→制定优化方案→编码实现→运行测试→验证效果。655轮，没有人类介入，AI自己判断什么时候该继续、什么时候该回滚、什么时候该换策略。
上图展示了一个典型的长程任务流程。注意这个循环是完全自主的——没有人在旁边说"这一步你改这里"。Agent自己判断、自己决策、自己纠错。655轮迭代意味着它经历了几百次"尝试→失败→调整"的循环，这种持久度和自我纠错能力，才是GLM-5.1最硬核的地方。
六、实战上手：5分钟调通GLM-5.1
说了这么多原理和架构，来看怎么实际使用。GLM-5.1的API调用风格与OpenAI高度兼容，迁移成本很低。
6.1 环境准备
# 安装智谱新版SDK（推荐）
pip install zai-sdk
# 或指定版本
pip install zai-sdk==0.2.2
# 也可以使用旧版SDK
pip install zhipuai==2.1.5.20250726
# 验证安装
python -c "import zai; print(zai.__version__)"
智谱提供了两套Python SDK：新版zai-sdk和旧版zhipuai。新版SDK的API设计更现代化，与OpenAI SDK的使用习惯更接近，推荐优先使用。安装完成后，到智谱开放平台注册账号获取API Key即可开始调用。
6.2 基础API调用
from zai import ZhipuAiClient
# 初始化客户端，填入你的API Key
client = ZhipuAiClient(api_key="your-api-key")
response = client.chat.completions.create(
model="glm-5.1",
messages=[
{
"role": "user",
"content": (
"请帮我写一个Python的并发爬虫框架，"
"需要支持速率限制、自动重试和结果持久化"
)
},
],
thinking={
"type": "enabled", # 启用深度思考模式
},
max_tokens=65536, # 最大输出tokens
temperature=1.0 # 控制输出的随机性
)
# 获取完整回复（包含推理过程和最终回答）
print(response.choices[0].message)
这段代码有几个关键参数需要理解：
thinking={"type": "enabled"}：这是GLM-5.1的深度思考模式，类似OpenAI o1/o3系列的Chain-of-Thought机制。开启后，模型会在给出最终回答前进行内部推理，特别适合复杂编程任务、数学证明、逻辑分析等场景。推理过程会通过返回结果中的reasoning_content字段单独返回。max_tokens=65536：GLM-5.1最大支持65536个token的输出。对于需要生成大量代码或进行长篇分析的场景，这个上限非常友好。temperature=1.0：在思考模式开启时，官方推荐使用1.0的默认温度值。思考模式下的温度参数行为与普通模式有所不同——它主要影响推理过程的探索广度，而不是最终回答的随机性。
6.3 流式调用：实时获取推理过程
from zai import ZhipuAiClient
client = ZhipuAiClient(api_key="your-api-key")
response = client.chat.completions.create(
model="glm-5.1",
messages=[
{
"role": "user",
"content": (
"用Rust实现一个高性能的TCP代理，"
"支持连接池管理、负载均衡和TLS终止"
)
},
],
thinking={"type": "enabled"},
stream=True, # 启用流式输出
max_tokens=65536,
temperature=1.0
)
# 分别获取推理过程和最终回答
for chunk in response:
# 思维链输出（模型内部的推理过程）
if chunk.choices[0].delta.reasoning_content:
print(chunk.choices[0].delta.reasoning_content,
end='', flush=True)
# 正式回答输出
if chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content,
end='', flush=True)
流式调用的一个亮点是可以分别获取推理过程（reasoning_content）和正式回答（content）。这意味着你可以在前端同时展示"AI正在思考"的过程和最终结果，用户体验更好。对于Agent应用来说，reasoning_content还能帮助你调试和优化Agent的决策逻辑——看看它为什么会做出某个选择。
6.4 用GLM-5.1搭建一个简单的编程Agent
光调用API还不够，来看一个实际的Agent应用。下面这段代码实现了一个能自主编码、执行、纠错的编程Agent：
from zai import ZhipuAiClient
import subprocess
import os
import re
class CodingAgent:
"""基于GLM-5.1的自主编程Agent"""
def __init__(self, api_key, workspace="/tmp/agent_workspace"):
self.client = ZhipuAiClient(api_key=api_key)
self.workspace = workspace
self.history = []
os.makedirs(workspace, exist_ok=True)
def _extract_code(self, text):
"""从模型回复中提取Python代码块"""
pattern = r"```python\n(.*?)```"
matches = re.findall(pattern, text, re.DOTALL)
return matches[0] if matches else None
def _run_code(self, filepath):
"""执行Python代码并返回结果"""
try:
result = subprocess.run(
["python", filepath],
capture_output=True,
text=True,
timeout=30,
cwd=self.workspace
)
output = ""
if result.stdout:
output += f"STDOUT:\n{result.stdout}\n"
if result.stderr:
output += f"STDERR:\n{result.stderr}\n"
if result.returncode != 0:
output += f"Exit Code: {result.returncode}\n"
return output
except subprocess.TimeoutExpired:
return "Error: 执行超时（30秒限制）"
def execute_task(self, task_description, max_iterations=5):
"""执行编程任务：自主编码→运行→纠错→迭代"""
# 构建初始任务提示
self.history.append({
"role": "user",
"content": (
f"请在工作目录下完成以下编程任务：\n"
f"{task_description}\n\n"
"要求：\n"
"1. 直接输出完整的、可执行的Python代码\n"
"2. 包含适当的错误处理和边界检查\n"
"3. 代码风格清晰，添加关键注释\n"
"4. 将代码放在 ```python ```代码块中"
)
})
for iteration in range(max_iterations):
print(f"\n{'='*50}")
print(f"第 {iteration + 1} 轮迭代")
print(f"{'='*50}")
# 调用GLM-5.1生成代码
response = self.client.chat.completions.create(
model="glm-5.1",
messages=self.history,
thinking={"type": "enabled"},
max_tokens=65536,
temperature=1.0
)
assistant_reply = response.choices[0].message.content
self.history.append({
"role": "assistant",
"content": assistant_reply
})
# 提取代码块并执行
code = self._extract_code(assistant_reply)
if not code:
print("模型未返回有效的代码块，请求重新生成")
self.history.append({
"role": "user",
"content": "请确保将完整代码放在 ```python ```代码块中。"
})
continue
# 保存并执行代码
filepath = os.path.join(self.workspace, "task.py")
with open(filepath, "w", encoding="utf-8") as f:
f.write(code)
print(f"代码已写入 {filepath}")
output = self._run_code(filepath)
print(f"执行结果:\n{output[:800]}")
# 判断是否成功
if "Error" in output and "Exit Code: 0" not in output:
# 执行出错，反馈给模型让它自主修复
self.history.append({
"role": "user",
"content": (
f"代码执行出错，错误信息如下：\n"
f"```\n{output}\n```\n\n"
"请分析错误原因，修复问题后给出完整的代码。"
"不要只给出修改片段，给出完整可运行的代码。"
)
})
print("→ 检测到错误，进入下一轮自动修复")
else:
print(f"\n✓ 任务完成！共经历 {iteration + 1} 轮迭代")
return code
print(f"\n达到最大迭代次数 {max_iterations}，任务未完全成功")
return None
# 使用示例
if __name__ == "__main__":
agent = CodingAgent(api_key="your-api-key")
result = agent.execute_task(
"写一个高效的文本文件去重工具，"
"支持按行去重和按内容MD5哈希去重两种模式，"
"能够处理GB级别的大文件（流式读取，不全量加载到内存），"
"最后输出去重前后的统计信息"
)
if result:
print("\n最终代码:")
print(result[:500])
这个Agent的核心逻辑非常直接：
- 把任务描述发给GLM-5.1，让它生成代码
- 从模型回复中提取代码块，写入文件并执行
- 如果执行出错，把错误信息反馈给模型，让它自主分析原因并修复
- 循环直到代码通过所有测试或达到最大迭代次数
这只是一个最基础的框架。在真实的长程任务场景中，GLM-5.1能自主运行几百轮这样的循环。而且不只是简单的"出错→修复"模式，它会在过程中主动分析性能瓶颈、重构代码架构、发现潜在的边界情况并补充处理逻辑——就像一个真正的初级工程师在干活。
6.5 直接用HTTP调用（不需要SDK）
如果你不想安装SDK，或者用的是SDK不支持的语言，直接用HTTP请求也能调通：
curl -X POST "https://open.bigmodel.cn/api/paas/v4/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer your-api-key" \
-d '{
"model": "glm-5.1",
"messages": [
{
"role": "user",
"content": "用Go实现一个支持TLS的HTTP反向代理服务器"
}
],
"thinking": {"type": "enabled"},
"max_tokens": 65536,
"temperature": 1.0
}'
API端点 https://open.bigmodel.cn/api/paas/v4/chat/completions 的请求格式与OpenAI高度兼容。如果你现有的代码已经基于OpenAI SDK开发，迁移到GLM-5.1基本只需要改两个配置：base_url指向智谱的端点，api_key换成智谱的Key。
6.6 本地部署
对于需要私有化部署或离线使用的场景，GLM-5.1以MIT协议开源，可以从以下平台下载模型权重：
# 从 HuggingFace 下载
pip install huggingface_hub
huggingface-cli download zai-org/GLM-5.1
# 从 ModelScope（魔搭）下载 — 国内推荐
pip install modelscope
modelscope download --model ZhipuAI/GLM-5.1
- GitHub仓库：github.com/zai-org/GLM-5
- HuggingFace：huggingface.co/zai-org/GLM-5.1
- ModelScope（国内推荐）：modelscope.cn/models/ZhipuAI/GLM-5.1
注意744B参数的MoE模型即使只激活44B，部署它仍然需要相当可观的显存。推荐使用vLLM等高性能推理框架进行部署，以获得更好的吞吐和延迟表现。
七、开源生态对比：2026年春季模型大混斗
2026年4月堪称"开源模型月"——GLM-5.1（4月8日）、Gemma 4（4月2日）密集发布，加上年初的DeepSeek系列，竞争已经白热化。
| 维度 | GLM-5.1 | Gemma 4 | DeepSeek V3 |
|---|---|---|---|
| 发布日期 | 2026-04-08 | 2026-04-02 | 2025年底 |
| 总参数量 | 744B MoE | 31B Dense + 26B MoE | 685B MoE |
| 激活参数 | 40-44B | 31B / 3.8B | 37B |
| 上下文长度 | 200K | 256K | 128K |
| 开源协议 | MIT | Apache 2.0 | MIT |
| 多模态 | 文本为主 | 文本+图像+音频+视频 | 文本为主 |
| 训练硬件 | 昇腾910B（纯国产） | NVIDIA | NVIDIA |
| 核心优势 | 长程任务、编程 | 边缘部署、多模态 | 推理能力 |
| 最适合场景 | Agent、编程助手 | 端侧部署、轻量应用 | 通用推理、知识问答 |
三个模型的定位差异非常明显：
GLM-5.1——为长程Agent任务而生。如果你的应用场景是"给AI一个复杂目标，让它自己完成"，GLM-5.1目前是开源领域的最佳选择。8小时长程能力、58.4%的SWE-bench Pro成绩，都是为这个场景量身打造的。
Gemma 4——Google的"小而精"策略。31B的Dense模型在AIME 2026数学竞赛上拿到89.2%，26B的MoE变体只激活3.8B参数就能达到31B Dense的水平——在边缘设备上部署，Gemma 4几乎没有对手。而且它原生支持多模态（文本+图像+音频+视频），应用面更广。
DeepSeek V3——推理和通用能力扎实。如果你需要一个不挑场景的全能型基础模型，DeepSeek V3系列依然是非常可靠的选择。它的强化学习对齐做得扎实，在推理链和知识问答方面表现出色。
怎么选？简单来说：要AI帮你干活选GLM-5.1，要部署到手机/边缘设备选Gemma 4，要通用推理选DeepSeek V3。
八、写在最后：从"能不能用"到"好不好用"
GLM-5.1的意义不只是又一个跑分好看的模型。它代表了几个趋势的交汇：
国产算力闭环已经跑通。 从芯片（昇腾910B）到框架（MindSpore）到模型（GLM-5.1），一条完全不依赖英伟达的完整技术链路被验证了。这不是PPT上的规划，而是一个744B参数的旗舰模型实实在在跑出来的结果。对国内AI产业的自主可控来说，这是一个实质性的里程碑。
AI正在从"回答问题"转向"交付项目"。 8小时长程任务能力听起来像是Benchmark上的一个数字，但它背后的含义是——AI第一次能够像初级工程师一样，接一个需求然后独立交付。这不意味着程序员要被取代，但意味着"一个资深工程师带着10个AI Agent干活"的工作模式正在成为可能。产品经理和工程师的角色分工可能需要重新定义。
开源模型的竞争力上了一个台阶。 MIT协议、744B参数、SWE-bench Pro 58.4%——放在一年前，这个组合在开源社区是不可想象的。开源不再是"闭源的廉价替代品"，而是"闭源的强力竞争者"。对开发者来说，这意味着你可以用完全免费、无商业限制的模型，获得接近顶级闭源模型的能力。
最后留几个问题供大家思考：
- 当AI能连续工作8小时自主交付项目，现有的Agent编排框架（LangGraph、CrewAI、AutoGen等）是否需要从底层重新设计？当前的框架大多是围绕"短任务+多轮对话"的模式构建的。
- MoE架构的"稀疏激活"范式会成为未来大模型的标配吗？Google、智谱、DeepSeek都在走这条路，但它对推理框架的要求更高，会不会成为新的技术壁垒？
- 纯国产算力训练的模型性能已经追平闭源顶流，这会不会加速国内企业从英伟达向国产芯片的迁移？性价比拐点可能出现在哪里？
参考链接
作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。
更多推荐
8
0- 0
已为社区贡献36条内容
所有评论(0)