Clover-35B：一个扩散模型的两种讲法
DiffuSpace 开源块扩散模型 Clover-35B-A3B-Preview：成绩和每秒 680 token 都是团队自报、尚无独立复现，SGLang 与 llama.cpp 后端代码仍写着“将添加到仓库”。
这两天看 Clover-35B-A3B-Preview 的资料，我一直在想一件事：同一个模型，同一堆数字，其实可以讲出两个完全不同的故事。哪一个是真的？大概两个都是真的，只是讲故事的人站的位置不同。老狗这些年读发布稿读得多了，养成一个习惯，看到一个新东西，先替它讲一遍好听的，再替它讲一遍不好听的，然后把两个版本摆在一起，看哪一个更经得起推敲。今天就这么做一次。
先讲第一种。
一个叫 DiffuSpace 的团队发布了它的第一个模型，团队自称来自港大 NLP，就是 2025 年 4 月发过 Dream 7B 的那一拨人。这次他们拿 Qwen3.6-35B-A3B 做底子，做出了一个 35B 总参数、约 3B 激活的扩散语言模型。我们平常用的大模型，写字像人写信，一个字接一个字往下写，前一个字没落笔，后一个字就得等着。扩散模型换了个写法：先划出一块空格子，然后一遍一遍去「猜」，猜得有把握的格子先填上，没把握的留到下一轮，一块填满了再往后走下一块。官方把这叫块扩散，HF 上的实现叫 LowConfidence，默认一块 32 个位置，置信度超过 0.95 的位置一起填，一个都不够格的时候，就只填最有把握的那一个。块内的字彼此可以「看见」，前面已经写好的部分仍然按因果顺序保留，于是它既保住了大模型那种从左往右的秩序，又在局部换来了并行。
为了让这件事成立，官方博客里还讲了几处结构上的改动：历史上下文用 Gated DeltaNet 的递归状态压缩起来，块内的字用双向 softmax 注意力，再把历史的读出当成一个独立的信息单元一起参与 softmax；块大小可以学习校准；右侧上下文另开一个零初始化的卷积分支。模型有 40 层、256 个路由专家、每次选 8 个，每层再挂一个共享专家，上下文 128K（131,072），支持 thinking 模式，Apache 许可，纯文本。
然后是成绩。据官方自报，SWE-bench Verified 73.6，Terminal-Bench 2.1 51.7，τ³ Overall 65.3，官方博客的通用能力部分还给了一个 GPQA Diamond 83.8；官方称六项 agent 评测都高于 LLaDA2.2 flash、Mercury 2.5、Qwen3.6 和 Qwen3.5 的 35B-A3B。速度更是它主打的东西：官方称在单张 GB300、BF16、batch 1、内部 agent 数据上跑到 680 tokens/s，在 H200 上是 515，对比 DFlash2 方案的 365。SGLang 支持块扩散加自投机解码，官方推荐用于服务和评测，llama.cpp 也支持自投机解码，另外还有一个 OpenAI 兼容的 API，流式、工具调用、Thinking 开关都有。
为什么偏偏是 agent 编程？这一点官方没有展开，但道理并不难想：agent 干活不是问一句答一句，而是读代码、调工具、看结果、再改，一个任务里要来回让模型写很多次，每一次多等一会儿，累起来就是让人坐立不安的空转。一个写得快的模型，在这种场景里省下的不是一次的时间，而是一整个循环的耐心。所以 Clover 把速度和 agent 绑在一起讲，在讲故事的人看来，是选对了战场。
讲到这里，故事很完整：一支有前作的学术团队，把一条非主流的技术路线做到了 35B，在 agent 编程这个最热的场景里，又快又不差，代码和权重都放出来了。如果你只读到这里，大概会觉得扩散语言模型的春天来了。
现在讲第二种。
还是那些数字，73.6、51.7、65.3，还有每秒 680 个 token，它们全部来自团队自己，到现在为止没有被独立复现过，那个 GPQA Diamond 83.8 也一样，是团队自己测、自己写在博客里的。连报道它的 Neural Brew 也在文章里明确标注，这些成绩和速度都有待验证。速度的测法是「内部 agent 数据」，外人拿不到同一份数据，也就没法照着再跑一遍；batch 1 的条件，说的是一个人独占一张卡时的情形，并不说明服务很多人时会怎样。
再看「代码和权重都放出来了」这一句。权重确实在，可仓库 README 自己写着，SGLang 和 llama.cpp 的后端代码和部署指南「将添加到仓库」，到 10 月 29 日仍是这句话，README 里给的只是指向 SGLang 和 llama.cpp 上游的两个 PR 链接，微调代码也还标着「即将发布」。也就是说，官方最推荐的那条又快又省的跑法，你今天未必能完整地自己搭起来。剩下的路是 HF 的 transformers，要求钉死在 transformers==5.19.0，BF16 权重约 69 GB，一张卡要装得下。一个中年人看到这种版本号钉死的要求，心里会咯噔一下，因为这通常意味着，换个版本就可能出事。
GitHub 的 issue 区更诚实。已经有人在问有没有 INT4，有人在问 llama.cpp 到底怎么用，有人在问 vLLM 或 SGLang 的镜像。这些问题本身不稀奇，每个新模型都会有，但它们合在一起，说明的是一件很朴素的事：本地部署还不顺。对大多数想在自己机器上试一试的人来说，最现实的入口可能反而是那个 API，可 API 跑在别人的机器上，你看到的速度，是对方服务的速度，不是模型在你手里的速度。
还有一层容易被忽略。它的底子是 Qwen3.6-35B-A3B，比较的对象里也有 Qwen3.6 和 Qwen3.5 的 35B-A3B。在同一个底座上改出来的模型，赢过底座，这件事有意义，但它回答的是「这套扩散改法有没有用」，不是「扩散路线是不是已经全面胜出」。这两个问题，在发布稿的语境里，很容易被讲成一个。
两种讲法都讲完了。
第一种里，有一条新路线、一支有来历的团队、一组漂亮的数字、一个明确的场景；第二种里，有一组还没人复现的数字、一段还没补齐的后端代码、一个要 69 GB 显存的单卡门槛、一串还没回答的 issue。我没有在任何一处说谎，两段用的是同一份公开资料，区别只在于，第一种讲法把「官方称」三个字悄悄省掉了，第二种讲法把它们一个一个捡了回来。
手艺人看新工具，大概都是这样。刀是好刀，磨得也亮，但真正好不好用，要等它在自己手里切过几回菜才知道。Clover 现在挂着 Preview 的名字，团队没有假装它是成品，这是一种诚实；读的人也该还它一份同样的诚实，不替它多说，也不替它少说。等后端代码补齐，等有人用自己的数据把那几个数字重跑一遍，第二种讲法里的问号，有的会被抹掉，有的会留下来。
那么，你更喜欢哪一个故事？我猜，大多数人喜欢第一个，但会想要住在第二个里，不是么？
来源：GitHub 仓库 README；Hugging Face 模型卡；DiffuSpace 官方博客；开发者页；Neural Brew 报道。SWE-bench Verified、Terminal-Bench、τ³、GPQA Diamond 83.8 与速度均为官方自报，未见独立复现，Neural Brew 也标注为待验证；截至 2026-10-29，仓库 README 仍写后端代码与部署指南“将添加”，只给出 SGLang、llama.cpp 上游 PR 链接；官方未发布 INT4 权重；“两种讲法”为作者写法。