谷歌都下场了：扩散语言模型的四倍速与六倍错

6 月 10 日，谷歌发布 DiffusionGemma：Apache 2.0 开源，26B MoE（总参 25.2B，激活 3.8B），官方一句话说清了它的身世——与 Gemma 4 26B A4B 相同架构，开发者只需实现一个去噪步。推理速度：H100 FP8 上 1000+ token/s，RTX 5090 上 700+，官方口径最高 4 倍。

这是 Gemini Diffusion 那条研究线第一次开源落地。谷歌亲自下场做这件事，等于替所有观望者把赛道验证做完了：扩散语言模型不是野路子，是正赛。 所以这篇谈我想自己训一个扩散语言模型的计划——但在谈计划之前，先把谷歌交的这份作业原样摊开，因为它同时回答了「为什么值得做」和「难在哪」。

一、先看懂它是个什么东西#

DiffusionGemma 不是把 AR 模型「改成」扩散那么玄乎，它的推理形态是三层：

1. 编码器照旧自回归：把 prompt 吃进去，建 KV cache
2. 解码器换成双向注意力：在一张 256 token 的「画布」（canvas）上并行去噪
3. 画布级自回归：一块画布完全去噪定稿后，进 KV cache，再生成下一块

也就是说：块内并行，块间串行。 一次前向大约定稿 15–20 个 token，靠这个把每秒输出推到 1000+。量化后 18GB 显存能装下，官方还顺手提醒了一句实话：这种提速靠的是吃满加速器的算力密度，Apple Silicon 那种统一内存架构（算力/带宽比低）未必有同幅加速——四倍速是有适用边界的。

模型本身多模态：文本、图像、视频输入，视觉编码器约 550M 参数——它和 AR 版 Gemma 4 一样具备视觉能力，这点后面跑分表里会直接体现。

二、同骨架 A/B：跑分原样呈现#

谷歌难得地给了一次控制变量实验：同样的架构骨架、同样的数据配方，只换生成范式。 以下是模型卡里的原表（IT 版、推荐 EB 采样器），一字未改：

Benchmark	DiffusionGemma 26B A4B	Gemma 4 26B A4B	差距
MMLU Pro	77.6%	82.6%	−5.0
MMMLU	81.5%	86.3%	−4.8
GPQA Diamond	73.2%	82.3%	−9.1
AIME 2026 no tools	69.1%	88.3%	−19.2
BigBench Extra Hard	47.6%	64.8%	−17.2
Tau2（agent 工具，3 项平均）	56.2%	68.2%	−12.0
LiveCodeBench v6	69.1%	77.1%	−8.0
Codeforces ELO	1429	1718	−289
HLE no tools	11.0%	8.7%	+2.3
HLE with search	11.9%	17.2%	−5.3
MMMU Pro（视觉）	54.3%	73.8%	−19.5
OmniDocBench 1.5（编辑距离，越低越好）	0.319	0.149	差 2.1 倍
MATH-Vision（视觉）	70.5%	82.4%	−11.9
MedXPertQA MM（视觉）	49.0%	58.1%	−9.1
MRCR v2 8-needle 128k（长上下文）	32.0%	44.1%	−12.1

谷歌自己承认：所有 benchmark 上 DiffusionGemma 都低于 AR 版。社区随后在单卡 H100 FP8 上拿它和 AR 孪生对测 agent 任务，结论更狠——快 4 倍，错 6 倍。

但真正值钱的信息不是「降了」，是降在哪。把差距按任务类型重新排一遍：

• 通用知识层几乎不痛：MMLU Pro −5.0、MMMLU −4.8。理解、记忆、知识提取这类任务，扩散架构的代价可以接受。
• 顺序敏感任务重创：AIME 长链条数学推理 −19.2、BigBench Extra Hard −17.2、Tau2 agent 工具 −12.0、MRCR 长上下文多锚点检索 −12.1、文档解析编辑距离差 2.1 倍——全部是「前一步定稿才能走下一步」的任务。
• 唯一的反超：HLE no tools +2.3。一个不依赖执行顺序的任务上，扩散第一次赢了 AR。

这张表的分布不是随机的。架构的代价不是均匀摊在所有能力上，是精确砸在「顺序」上。 记住这个结论，下一节它就是工具调用问题的答案。

三、工具调用这道坎#

先说清两种范式下「调工具」的根本差异：

自回归模型可以流式触发。 <tool_call> 的开标记、函数名、参数、闭标记——这些 token 按顺序出来，闭标记一落地，工具就能发起调用，模型的生成继续往下跑。生成和执行是流水线，互相不挡路。

扩散模型必须整段定稿。 一块画布在去噪过程中，所有位置同时变化：这一刻函数名是对的，下一刻可能被重写；参数段的「猜测值」先浮现了，闭标记还悬着。想安全触发一次工具调用，你必须保证两头标记和中间内容全部收敛定稿——而并行去噪恰恰不保证任何局部先收敛。

下面这个交互演示把三种典型事故拆开了，拖动进度条逐步看（页面由 DeepSeek 生成，完全本地运行，本站自托管）：

三个场景对应三种症状，根源是同一个：

• 预填：参数还没定稿，「猜测值」先出现在了文本流里——后续可能被修正，但你已经看见了一个假的调用
• 误触：半定稿状态里恰好凑齐了一次调用的形状，框架误触发——工具拿着错误的参数真的执行了
• 围栏打断：代码块的 ``` 围栏在去噪中被重排，前后两半对不上——格式塌了

要说明的是：DiffusionGemma 的模型卡自己写着「原生支持结构化工具调用」。支持不等于可靠——官方自家 Tau2（agent 工具基准）掉 12 分，社区实测错误率 6 倍，才是这个「支持」的实测口径。

四、为什么 agent 框架接不住#

主流 agent 框架的工具循环（八月那篇生态对照里清点过的那几家），全部是按流式 AR 的三条假设设计的：输出是逐 token 的流、边界标记是确定性信号、生成顺序就是执行顺序。

扩散模型把三条同时打破：

1. 输出以画布为单位，不是流——框架的「流式解析器」没有挂载点
2. 局部收敛无保证——边界标记出现了也可能被撤销，确定性信号不存在
3. 「已生成」不等于「已定稿」——中间状态可以回退重写，执行侧无法判断何时安全

所以这不是某个框架偷懒，是协议层缺一块：需要一套块级确认协议（画布定稿事件、局部定稿窗口、安全触发判定），让工具循环改订阅「定稿」而不是「生成」。谷歌交付了模型，没交付这套协议——这层空着，扩散的 agent 生态就起不来。

五、我的 v2 设计笔记#

正因为谷歌把「能做」证明了、把「难在哪」标价了，自己动手训一个才有意义。以下是我的 BLRH v2 设计与现状。状态先说死、按仓库实际代码说：扩散层（mask-恢复目标、去噪采样、ReMix 拒绝）未编码，v2 分支没建；但设计中的核心块 BioCircuitBlock 已经以 v1 形态在 MindSpore 里实现、并在昇腾上训练过——这不是纸上谈兵，是半个已验证的地基。涉及 v2 的数字仍是设计估算。

目标函数改造：训练目标从 next-token prediction 换成 mask-恢复——随机 mask 一部分 token，模型负责恢复。生成时从整张 [MASK] 画布开始迭代去噪。

保留的组件（都是被验证过的通用件）：注意力机制、SwiGLU FFN、RMSNorm、RoPE、反向传播。改变的只有生成范式和训练目标。

已经写进代码的部分：BioCircuitBlock 不是纸面概念。v1 已用 MindSpore 实现（src/blrh_llm/model/blrh_v1.py）：一个共享块按 T_max 次迭代调用、带自适应停止（halting threshold + 迭代正则）；稀疏隐层按果蝇蘑菇体的「扩张 + TopK 抑制」思路做（扩张 2 倍、4 组、每组取前 25%）；Hebbian 门控用相邻状态调制残差。这套骨干在 OpenI 的昇腾卡上真训过——config 落在 d_model 384、6 头、迭代上限 10，当前主线训的是自回归目标。

还停在纸面的部分：扩散的「mask-恢复目标 + 去噪采样器 + ReMix 拒绝」这一层，v2 分支未创建，代码未落地。有意思的是，OpenI 上的项目和数据集早就起了 DLLM 这个名字——名字为扩散预留，目前其上跑的还是 AR 训练。命名先行，代码殿后，这是我给自己挖的坑，也是给自己留的路线图。

ReMix 风格拒绝机制：每个 token 位置有三个状态——M（masked）、C（连续态，可继续修正）、T（定稿）。当相邻两次迭代的输出分布 JS 散度超过阈值，C 态拒绝回 M 态重来。这是扩散「可撤销」能力的直接实现，也是 AR 从结构上做不到的。

规模与硬件账：d_model=384，约 10M 参数——fp16 权重 20MB、梯度 20MB、AdamW 状态 80MB、激活值约 150MB，合计约 270MB，一块 8GB 显存的卡就够。训练资源先交代实话：v1 的 AR 主线实际是在 OpenI（启智AI开源社区，官方口号「提供普惠算力」）上白嫖华为昇腾卡训的（910/910B，24G 到 48G 档位都碰过）。普惠是真的，但普惠不含「无限时间」——后来平台额度政策收紧，无限训练的前提没了，这条线就停在那里，这也是 v2 至今停在纸面的真实原因之一。设计笔记里写的 RX 580 只是兜底选项。

顺带说说白嫖对象本身。旧昇腾卡在算力账那篇里被归进「接不到活的存量」，但白嫖视角下它其实真香：定位就是低端大碗算力，用的人也不少。痛苦的是生态——算子支持和框架适配写起来折磨人，同样的层在 MindSpore/CANN 那条路上要多踩好几道坑。全程纯 PyTorch、不写任何专用 kernel 的约束，就是这段经历换来的：模型代码必须能在昇腾、消费卡和 CPU 之间随时搬家，不把自己绑死在任何一家的算子库上。

诚实的预期：按谷歌那张掉分地图，我这个 10M 玩具在顺序敏感任务上必然掉分，而且比 26B 掉得更惨。但这个实验要验证的从来不是「扩散能不能打赢 AR」，而是在小尺度上复现那张掉分地图的形状——知识层掉多少、顺序层掉多少、拒绝机制能不能把工具调用的误触率压下来。若形状对得上，谷歌的结论就在 10M 尺度可复现；对不上，那更是有意思的发现。

六、训练计划#

• 数据：NVIDIA Nemotron 公开集打底（GSM8K、FineWeb-2、Stack Exchange 等，合成数据注意许可条款），加上我自己在 OpenI 上滚出来的中文短对话小集——v1 那条 AR 主线的数据管线直接复用
• 硬件：三段式——能白嫖就用 OpenI 启智社区的昇腾卡（口号是「普惠算力」，确实普惠，只是普惠多少由平台政策说了算，说停就停）；消费卡 RX 580 8GB 兜底跑小实验；本地 CPU 做链路验证。纯 PyTorch 约束就是这套三段式的地基
• 阶段：先跑通 mask-恢复目标的最小复现（不加任何生物启发块），再加 ReMix 拒绝机制，最后换上完整 BioCircuitBlock——每阶段都留一个能对账的 checkpoint
• 评测：不刷 perplexity。按谷歌的掉分地图设计两组对照——知识层任务（预期小幅掉分）vs 顺序敏感任务（预期大幅掉分），外加一组工具调用模拟评测量化误触率。评测设计本身抄谷歌的作业，这是这次发布最被低估的遗产

七、收束#

四倍速与六倍错的本质，是一次明码标价的交换：把串行解码的内存带宽瓶颈，换成并行去噪的算力瓶颈；代价精确落在「顺序」上。 知识问答几乎无痛，长链条推理、工具调用、长上下文检索全部重创——而这些恰恰是 agent 时代最值钱的能力。

所以当下扩散语言模型的核心矛盾可以一句话说完：工具调用是最强的需求，却是扩散最弱的项。 谁先补上块级定稿协议、让 agent 框架的循环从「流式」迁移到「画布」，谁就打开了扩散 agent 的大门——在那之前，四倍速只属于不需要工具的场景：行内编辑、代码填空、Sudoku 这类全局约束问题。

至于我那个 10M 的小玩具，它赢不了任何 benchmark。它的意义是把这条边界亲手踩一遍：设计笔记写在前面了，训完之后，掉分的形状对不对得上，我在本站交卷。

数据口径#

• DiffusionGemma 发布信息（2026-06-10、Apache 2.0、26B A4B 骨架、4x 提速、1000+ tok/s@H100 FP8、18GB 量化显存、统一内存脚注、「相同架构只需去噪步」）：Google 官方博客 ↗
• 全部跑分数字：HuggingFace 模型卡 ↗（与 ai.google.dev 模型卡同源），表中数字原样转录，未做换算；国内镜像入口见 ModelScope Gemma-4 合集 ↗
• 「快 4 倍、错 6 倍」：Reddit r/LocalLLaMA 社区实测帖（2026-06-12，单卡 H100 FP8，agent 任务对比）口径，非官方数据
• Tau2 为 agent 工具调用基准；MRCR 为多锚点长上下文检索基准；HLE（Humanity’s Last Exam）no tools 一项为扩散版唯一反超项
• 工具调用交互演示页：DeepSeek 生成，本地自包含 HTML，本站自托管于 /embed/tool-call-compare.html
• BLRH 项目（本站作者私有仓库，按实际代码口径）：src/blrh_llm/model/blrh_v1.py 已实现 BioCircuitBlock（共享块 T_max 次迭代 + 自适应停止、果蝇蘑菇体式稀疏隐层扩张 + TopK、Hebbian 门控，MindSpore），以自回归目标在 OpenI - 启智AI开源社区（openi.pcl.ac.cn/bhys ↗，官方定位「提供普惠算力」）的昇腾卡上训练（910/910B，24G–48G 档，config 如 d_model 384、t_max 10、vocab 12000）；扩散层（mask-恢复目标、去噪采样、ReMix 拒绝）未编码，v2 分支未创建；OpenI 项目/数据集名为 DLLM/DLLM1，其上当前运行为 AR 训练。额度后期收紧、训练线暂停；「昇腾生态与算子适配痛苦」为作者一手使用体感
• 「主流框架按流式 AR 假设设计」「协议层缺块级确认」为本文判断，非引述