350 亿参数的扩散模型，在 Agent 赛道上把自回归模型跑赢了：1.52 秒 vs 3.21 秒

350 亿参数的扩散模型，在 Agent 赛道上把自回归模型跑赢了：1.52 秒 vs 3.21 秒

扩散模型给人写代码、操作网页、调用工具，当 Agent。

听起来有点违和——毕竟在大多数人脑子里，扩散模型是拿来生成图片的：Stable Diffusion、Midjourney、Sora，那些模糊色块一层层变清晰的画面。

而”写代码、调工具”这件事，一直是自回归模型的地盘。GPT、Claude、Kimi，全都是一个字一个字往外蹦的。

昨天，扩散智能发布了 Clover-35B-A3B-Preview，第一次把这条路真实跑通了。

而且不是”勉强能用”级别——它在速度上把自回归的对手正面击败了。

先看那个最关键的数字

网页 Agent 评测 WindTunnel，49 个任务，每个任务尝试 3 次：

| 模型 | 中位执行时间 | 尝试成功率 | |—|—|—| | Clover | 1.52 秒 | 98.6% | | Jev + Mercury 2.5 | 3.21 秒 | 95.9% |

时间少了一半多，成功率还高 2.7 个百分点。

对比同表里的 Gemini 3.6 Flash，官方说法是”速度快了好几倍”。

这个对比不是随便找的靶子。Jev 是 9 月份爆火的那个判别模型，主打的就是极致的推理速度——它抛弃了文本生成，直接输出判断概率，官方宣称比传统 LLM 快 40 到 200 倍。

Clover 是拿扩散模型，跟一个专门为速度而生的架构，在速度上正面比了一场，然后赢了。

架构：350 亿总参数，每个 token 只激活 30 亿

Clover 走的是 MoE 路线：总参数 350 亿，每个 token 激活约 30 亿，支持思考模式。

这个数字值得琢磨。它相比团队上一代 Dream 7B 的 70 亿参数，翻了 5 倍。

而在大模型世界里有个反常识的规律：参数量上去，速度一般会掉下来。 你要跑更大的矩阵乘、读更多的权重、占更多的显存。

但 Clover 没有变慢。官方说它在同尺寸对比中超过了自回归模型。

怎么做到的？三个设计：

第一，块内并行生成。 扩散模型的本质是”多个位置同时生成，然后迭代修正”。这跟自回归”必须等前一个 token 出来才能算下一个”完全不同。

对于 Agent 这种场景——反复生成代码、反复调用工具、反复读返回结果——串行等待的代价极其高昂。你让 Agent 连续做 6 件事，每一层都要等前一步吐完最后一个字，累积起来的延迟非常可观。

第二，历史记忆作为独立信息单元参与注意力。 这块是精心的设计：把历史上下文单独提取出来，跟当前 token 一起放进注意力计算，让模型自己学怎么权衡”前文”和”现在”。

第三，可学习的块大小校准。 并行生成有个副作用：块大了，历史信息容易被稀释。这个校准机制就是用来对抗这种稀释的。

三件事的目标是一致的：让并行生成、历史利用、计算效率彼此配合，而不是互相拖累。

实测：太阳系模拟器 4-5 秒，LaTeX 简历十来秒

官方演示和实测里有几个场景值得看：

生成一个可交互的太阳系模拟器：思考约 1 秒，4-5 秒产出成品。

一堆简历信息 → LaTeX 简历代码：十来秒。

WebMCP 六个连续任务：开票、课程报名、金额汇总、活动状态查询、客户信息查询、发票信息查询。Clover 全部完成，而且官方对比视频里，速度上是把 Gemini 3.6 Flash 甩开的。

线上购物场景：找到指定款式、黑色、L 码的 T 恤，加入购物车，填写访客信息，走完测试结账流程。

这个购物场景其实是整个演示里最有价值的部分。因为它不是单次生成——它有搜索、有筛选、有表单填写、有流程推进，中间任何一步出错，整个任务就崩了。

能连续处理长链路任务，才是 Agent 能力真正的门槛。

为什么扩散模型在 Agent 上有天然优势

这里得稍微讲一下原理，因为这是整件事的根。

自回归的困境：必须串行。

GPT 生成 “Hello world” 的过程是：算 “Hello” → 把 “Hello” 塞回去 → 算 ” ” → 再塞回去 → 算 “world”。

每个 token 都要一次完整的前向传播。一千个 token 就是一千次。这在文本对话里还能忍（用户本来也要读），但在 Agent 场景里是真问题——Agent 要循环几十次调工具，每次都这么耗，延迟会累积到不可接受。

扩散的解法：并行 + 迭代。

扩散模型一次生成一整块，然后迭代修正。第一遍可能全是噪声，第二遍修正一部分，第三遍再修正——几轮下来收敛成结果。

关键优势有两个：

1. 多个位置同时生成，减少了串行等待 2. 生成过程中前后内容可以互相参考——因为是双向建模，多个位置在迭代中共同调整

第二点对 Agent 尤其重要。写代码的时候，后文的函数调用会影响前文的函数签名该怎么写；调工具的时候，返回结果会影响前面参数的调整。自回归只能单向看，扩散可以双向调整。

这就是为什么”块内交互”这个设计，在代码和 Agent 任务上特别有价值。

但我得泼一盆冷水：这条路还很长

第一，1.52 秒 vs 3.21 秒，是特定基准上的成绩。

WindTunnel 的 49 个网页 Agent 任务。这不是全场景。在需要长链条推理、深度规划的任务上，扩散模型还没有公开的成绩单。

第二，成功率 98.6% 听着很高，但 Agent 的容错空间极小。

98.6% 意味着大约每 70 次会错一次。如果这个 Agent 要连续做 20 步，全部成功的概率就掉到 75% 左右。Agent 领域的 98% 和聊天领域的 98%，根本不是一个量级的要求。

第三，”快”和”好”不是一个维度的事。

Jev 就是最好的前车之鉴。它当初也是以”快 40-200 倍”杀出来的，结果后来被扒出来：复杂政策判断准确率跌到 60.5%，比对文档时间数字直接掉到 26.7%，把关键信息从提示词前段挪到中段，正确率从 80.5% 暴跌到 40.9%。

极致的速度如果建立在牺牲泛化能力上，那就是个前置过滤器，不是 Agent。

Clover 现在给出的是速度数据 + 演示视频。真正的考验在后面：SWE-bench、Terminal-Bench、复杂多步规划——这些它还没跑。

我真正在意的是这个信号

抛开 Clover 本身能打几分，这条新闻最重要的意义是：

自回归的垄断地位，第一次被一个能真正干活的替代方案正面挑战了。

过去三年，所有人都默认”大模型 = 自回归 next-token 预测”。这个假设太稳固了，以至于产业界讨论架构创新，基本只在自回归内部打转——MoE、MLA、稀疏注意力、各种 position encoding 的花样。

扩散语言模型这条路一直在（何恺明参与的 ELF 在连续嵌入空间做生成，谷歌的 DiffusionGemma 在探索并行文本生成，国内几家也在研究面向代码的扩散模型），但一直停在”论文能跑、产品不能用”的阶段。

Clover 至少证明了一件事：扩散模型能在 Agent 任务上,给出有竞争力的结果，而且是在速度这个维度上赢。

这就是威胁。

还有一层：Agent 时代，架构的选择标准变了

过去大家比模型，比的是”谁回答得更好”。这个标准在对话场景里成立，因为用户等一等也无所谓。

但 Agent 场景里，标准变了：单位时间内能完成多少个可靠的动作。

这个标准下，串行生成本身就是原罪。

一个 Agent 完成一次任务，要调用十几次工具、生成几百行代码、读回来十几次结果。如果每次生成都是串行的，那你的总延迟会是这些延迟的总和。

而如果你的生成能做并行，很多等待可以重叠掉。

所以我的判断是：Agent 越普及，”生成效率”在模型选择中的权重就越高。

现在的模型排行榜还在比准确率。但用不了多久，你会看到”每任务平均耗时”和”每任务平均成本”进入主流评测。

到那时候，扩散模型的机会才真正打开。

—

*模型：Clover-35B-A3B-Preview（扩散智能）* *架构：MoE，总参数 350 亿，每 token 激活约 30 亿，支持思考模式* *基准：WindTunnel 网页 Agent 评测，49 个任务 ×3 次，中位 1.52 秒 / 成功率 98.6%* *对比：Jev + Mercury 2.5（3.21 秒 / 95.9%）、Gemini 3.6 Flash* *前代：Dream 7B（70 亿参数）* *同路线：ELF（何恺明参与）、DiffusionGemma（谷歌）、国内多家代码扩散模型* *来源：量子位 / 36氪*