扩散模型不再逐个生成 Token：Clover-35B 用 350 亿参数挑战 Agent 编程

InfoQ 中文 2026-10-29T06:53:53+08:00

扩散语言模型正在从研究走向更大规模。10 月 28 日，DiffuSpace 开源 Clover-35B-A3B-Preview，用混合专家架构把总参数推到 350 亿，官方称生成速度达 680 tokens/s，并在 SWE-bench 等 Agent 基准上给出成绩。它想证明的是：并行解码不只是快，也能干活。

换一条生成路线：从“逐字写”到“并行改”

大语言模型一定要从左到右、一个词一个词地往外生成吗？

过去几年，GPT、Claude、Qwen 等主流模型都采用自回归方式：每生成一个 Token（模型处理文本的基本单位，可粗略理解为词或词的一部分），都要基于前面所有内容重新计算一遍。模型越大、输出越长，这种串行计算的开销就越明显。

扩散语言模型（dLLM）走的是另一条路。它不强制从左到右，而是先给出一堆带噪声的 Token，再通过多轮“去噪”并行修正，最终得到完整文本。理论上，这种并行更新能在特定场景下提高解码效率。

问题也随之而来：当模型规模变大、任务变复杂，扩散路线还能不能既保住速度，又追平主流自回归模型的能力？

10 月 28 日，深圳 AI 创业公司扩散智能（DiffuSpace）发布并开源 Clover-35B-A3B-Preview，试图回答这个问题。DiffuSpace 由香港大学 NLP 实验室联合主管孔令鹏教授与博士生龚珊三、叶佳成创立，团队此前做过 DiffuSeq、Dream 7B 等扩散语言模型研究，近期完成两轮融资，总额数亿元人民币。

350 亿总参数，每次只激活 30 亿

Clover-35B-A3B-Preview 采用混合专家（MoE）架构。“混合专家”可以理解为：模型内部有很多组参数，每次推理只调用其中一部分，而不是让全部参数参与计算。因此它的总参数量为 350 亿，单次推理实际激活约 30 亿参数。相比上一代 Clover，总参数规模扩大到约 5 倍。

按 DiffuSpace 公布的内部测试，新模型整体生成速度为 680 tokens/s；在部分 Agent 任务和通用能力评测中，表现达到或超过同等规模的自回归模型。

对扩散语言模型而言，这次更新真正要解决的是两个问题：一是如何在更大参数规模下维持并行解码的效率，二是如何把速度优势转化为真实任务中的执行能力。参数变大不难，难的是变大之后还快、还能用。

680 tokens/s 之后，速度不等于任务效率

DiffuSpace 此次公布的数据主要覆盖三类：生成速度、Agent 任务能力、端到端执行时间。

官方展示的一个 Demo 是无人机空域管理：模型读取 20 条空管报文，从中提取地点、半径等信息，再在三维地图上设置相应禁飞区。Clover 完成该任务用时 7.32 秒，对照使用的 Qwen3.5 用时 62.3 秒，相差约 8.5 倍。

这个案例说明扩散模型在结构化信息处理上可能有优势，但 Demo 耗时同时受模型配置、硬件环境、输出长度和工具调用流程等因素影响，不能直接等同于生产环境中的表现。

另一组测试来自 WindTunnel 的 49 个任务：Clover-35B-A3B-Preview 中位执行时间为 1.52 秒，Jev 与 Mercury 2.5 的组合为 3.21 秒，GPT-5.6 Luna 为 5.74 秒，Gemini 3.6 Flash 为 7.22 秒。按这组结果计算，Clover 的中位任务耗时约为 Jev 与 Mercury 2.5 组合的 47%。

不过，不同模型组合的推理部署方式、任务处理流程和计费规则并不相同，仅凭中位执行时间，还不足以判断其在生产环境中的综合效率。

对 Agent 应用来说，这一点尤其关键。模型生成 Token 的速度，并不等于 Agent 完成任务的速度。一个真实任务往往包含多轮规划、工具调用、等待外部服务返回、结果校验等环节。如果主要时间花在外部工具或任务执行上，模型生成再快，端到端收益也可能有限。因此，比起紧盯 tokens/s，Clover 在完整 Agent 工作流中的表现更值得关注。

Agent 编程能力到了什么水平

扩散语言模型过去的一大挑战，是在提升生成效率的同时，维持复杂推理、代码生成和指令遵循能力。DiffuSpace 公布的评测结果显示，Clover-35B-A3B-Preview 在多项 Agent 基准上得分不低：SWE-bench Verified 73.6，Terminal-Bench 2.1 为 51.7，τ³ Overall 为 65.3。

按团队提供的对比数据，Clover 在这几项上超过 Mercury 2.5，以及同参数规模的 Qwen3.6-35B-A3B。这三项测试分别对应真实软件问题修复、终端环境中的任务执行、带工具交互的复杂任务处理，比传统知识问答或代码补全更接近 Agent 需要完成的多步骤工作。

通用能力方面，Clover 还接受了知识、数学、代码、逻辑推理、指令遵循和长上下文理解等测试。从团队公布的数据看，Clover 在部分指标上超过同尺寸自回归模型，但并非全面占优——在部分数学和代码评测中，其他模型仍然保持领先。

重构 GDN：长上下文与并行解码如何兼得

相比参数规模和测试分数，Clover 这次更值得关注的变化在底层网络架构。它没有从零训练，而是基于 Qwen3.6-35B-A3B 构建：保留原有的混合 GDN/Attention MoE 骨干，在此基础上加入块级扩散生成机制，并把门控 Delta 网络（GDN，一种用压缩状态记录历史信息的线性注意力结构）改造成双向版本，以适配并行去噪。

传统自回归模型依赖因果注意力，当前 Token 只能看到已经生成的历史内容。扩散语言模型则不同：它可以在一个文本块内同时处理多个 Token，再通过多轮迭代逐步收敛到最终输出。

生成方式变了，对架构的要求也随之改变。一方面，模型要保留足够的历史上下文，才能支撑长文本理解和多轮任务；另一方面，同一个生成块内的 Token 需要充分交换信息，否则并行生成容易出现语义不一致。Clover 的设计试图同时满足这两点。

具体做法是：用递归状态压缩历史上下文，减少重复处理历史信息的计算开销；在当前生成块内引入双向注意力，让不同位置的 Token 进行更细粒度的交互。此外还配合了可学习的块大小校准机制和双向局部特征提取，以适应不同生成需求。核心思路是对两类信息采用不同机制——历史信息通过压缩状态保留，当前块内部允许双向交互与并行更新。

这对扩散语言模型来说是有针对性的取舍。完全依赖标准注意力，上下文长度和模型规模一涨，计算与存储成本就会持续上升；过度压缩历史信息，又可能丢掉复杂任务所需的上下文细节。Clover 想用混合结构在两者之间找平衡。

目前它展示的是一种适用于大规模扩散语言模型的架构思路，效率优势能否在不同模型规模和任务场景下稳定复现，还需要更多验证。

从写文本到做任务，扩散模型离 Agent 还有多远

Clover-35B-A3B-Preview 的发布，说明扩散语言模型正尝试从“高速生成文本”走向更复杂的任务执行。过去，dLLM 最容易展示的优势就是速度：并行更新多个 Token，有机会减少部分文本生成任务所需的串行解码步骤。

但 Agent 场景远不止生成文本。模型要理解任务目标、规划执行步骤、调用外部工具，并根据执行结果持续调整后续行为。有些任务还要求输出严格符合特定格式，或者在多个相关判断之间保持逻辑一致。换句话说，生成速度只是 Agent 效率的一部分。

DiffuSpace 透露，接下来计划基于 Clover-35B-A3B-Preview 推出决策模型和多模态模型。决策模型面向快速、结构化的判断任务，计划支持在一次生成过程中联合处理最多 8 个关联问题。按团队设想，这种方式能让模型在多个判断之间共享上下文，减少逐项独立决策带来的逻辑冲突。不过这些仍属于后续产品规划，实际效果尚待观察。

放到行业层面看，扩散语言模型已不只是实验室里的研究方向。Google 推出过 Gemini Diffusion，Inception 持续迭代 Mercury 系列，LLaDA 等开源研究也在探索扩散式文本生成的能力边界。各家技术路线并不一致，但目标相似：突破传统自回归解码的效率限制。

与此同时，自回归模型也在通过推测解码、结构优化、推理引擎改进等方式提升生成效率。因此，扩散模型的速度优势并不意味着它必然取代自回归架构。未来两类路线更可能在不同任务和部署条件下各有所长。

对开发者而言，更实际的问题是：在相同硬件、相近模型能力和可接受的质量约束下，哪种方案能以更低成本完成任务？这也是扩散语言模型从研究成果走向生产环境必须回答的问题。

目前，Clover-35B-A3B-Preview 已正式开源，模型权重和代码分别发布在 Hugging Face、GitHub 和 ModelScope，采用 Apache-2.0 许可证，并提供 SGLang、llama.cpp 等推理后端的支持。

随着更多大规模扩散语言模型开源，行业将有机会在统一的硬件和任务条件下，进一步比较两种生成范式的实际效率。对 Clover 来说，35B 参数规模和 680 tokens/s 的速度只是起点。能否把这种速度稳定转化为复杂 Agent 任务中的成本和效率收益，才是下一阶段更重要的考验。

关键要点

查看原文