DiffusionGemma：扩散式文本生成第一次进了主流开源生态
Google 开源了首个主流文本扩散模型。真正的卖点不是「快」，而是它把本地解码的瓶颈从显存带宽挪到算力，用双向注意力并行生成 256 个 token。代价是质量、实验性和那个 26B MoE 的取舍。
概述
DiffusionGemma 真正的意义不在「比自回归模型快 4 倍」这个被放进标题的数字。它是第一个被认真打包、上 Apache 2.0、放进主流开源生态供人下载折腾的文本扩散模型。文本扩散这个方向研究圈聊了好几年，Inception 的 Mercury、各种实验性 checkpoint 都有人玩过，但它一直停在「论文有趣、没人敢用」的状态。Google 这次把它从研究演示推到了一个普通开发者能在自己那张消费级显卡上跑起来的工程品。
但 Google 自己也把话说得很直白：这是一个实验性模型，输出质量低于同门的标准 Gemma 4，要最高质量就别用它。所以这篇分析不是替这个模型背书，而是判断它改变了什么，又有哪些被速度营销盖住的真问题。它改的不是模型多聪明，是本地交互式推理的延迟长什么样。
发生了什么
Google 发布了 DiffusionGemma，一个 26B 的混合专家（MoE）模型，推理时只激活 38 亿参数，量化后能塞进高端消费级显卡的 18GB 显存里。它建立在 Gemma 4 家族和 Gemini Diffusion 研究之上，但核心换了一个东西：一个专门为提速设计的扩散头。
跟我们熟悉的自回归大模型逐字往外吐 token 不同，DiffusionGemma 一次性并行生成一整块 256 个 token。它的工作方式更像图像扩散模型：先铺一张全是随机占位 token 的「画布」，然后多轮迭代，每一轮锁定它认为正确的 token，再拿这些已确定的 token 当上下文线索去修正剩下的，直到整段文字收敛成型。因为这个并行结构，每个 token 在生成时都能看到块里的所有其他 token，即所谓双向注意力，而不是只能看左边已经写完的部分。
数字上：单张 NVIDIA H100 超过 1000 tokens/s，RTX 5090 上超过 700 tokens/s。权重已经上了 Hugging Face，MLX、vLLM、Transformers 都能直接跑，llama.cpp 的官方支持据 Google 说也在路上。配套还有 Unsloth、NVIDIA NeMo 的微调路径，以及和 NVIDIA 一起做的 NVFP4 内核优化。从生态完整度看，这不是一个扔出来就不管的 demo，而是一次有部署意图的发布。
为何重要
要理解这件事的分量，得先看清它解决的到底是哪个瓶颈。自回归模型在本地单用户场景下，几乎总是受显存带宽限制：每生成一个 token，都要把整套权重从显存里搬一遍，而这一搬的时间里，GPU 的算力大部分在闲着等下一次「敲键盘」。云端服务商靠把成千上万个用户的请求批在一起来填满这块算力，所以这个问题在云上不明显；但你一个人在本地跑，那张昂贵的卡其实大半时间在空转。
DiffusionGemma 把这个等式反过来：一次给处理器一整块 256 token 的活，瓶颈就从显存带宽挪到了算力。这才是「4x faster」背后的真实机制，不是某种魔法加速，是把原本浪费掉的本地算力用起来了。也正因如此，Google 强调这个加速是为本地和低并发场景设计的。在高 QPS 的云端服务里，自回归模型本来就能把算力喂饱，扩散式的并行解码反而边际递减，甚至因为多步迭代消耗更多浮点运算而推高服务成本。HN 上有人把这点讲得很清楚：你有 256 个用户时，自回归模型本就能一次算 256 个 token；扩散模型是给一个用户算 256 个 token 但要跑好几个前向步。所以它不是一个全面更快的模型，是一个把延迟结构换了形状的模型。
延迟结构的改变对交互式体验是实打实的。社区里已经有人把这种快当成第一价值。有开发者说自己日常最爱用的反而是扩散模型 Mercury，不是因为它聪明，是因为它快到能把写代码从「提示完干等」变回接近结对编程的手感。当一个模型能在你眼前几乎实时地把整段代码铺出来、把复杂的 markdown 格式完美闭合，交互的心理节奏完全不同。跑分忽略这个维度，实际工作流却对它很敏感。
双向注意力还带来一个结构性的好处：它擅长非线性的文本任务。代码补全（infilling）、行内编辑、甚至数独这种「每个 token 依赖未来 token」的任务，自回归模型天生别扭，因为它只能从左往右一锤子买卖；DiffusionGemma 能看到整块、来回修正。Google 举的例子是 Unsloth 微调它去解数独。HN 上有人点得更到位：双向地用左右文去修正一个句子，其实更接近人真正编辑、思考的方式，而不是对每个 token 都做出永不反悔的承诺。这个方向感，可能比当前这个模型本身更值得记。
对建设者的影响
如果你在做本地或边缘端的交互式应用，这是个值得现在就上手实测的东西，但要带着清醒的预期去测。
第一，它最合适的位置是速度比绝对质量更值钱的场景：生成样板代码和 POJO、写和迭代单元测试、行内补全、快速原型。这类活儿不需要前沿模型的智商，但慢一点就毁掉心流。把它当成本地的快速草稿员，别当成你最终交付的那支笔。
第二，别把官方那个 1000+ tokens/s 当成你的卡上能复现的数字。HN 上已经有人在 3090 Ti 上跑 Q4 量化，远没摸到广告速度。Google 的数字是 H100 和 5090，还配了 NVFP4 这类专门内核。你的硬件、量化方案、推理栈不一样，体感会差很多。要做选型，自己在目标硬件上量。
第三，质量差距得当成一等问题来对待，别用「实验性」三个字一笔带过。Google 明说了输出质量低于 Gemma 4，社区里最大的怀疑也集中在这里：越难的任务掉得越多。有一个被点出来的根本限制值得记：自然语言里存在很强的前后依赖，开头一个词会强烈影响后面，如果一个扩散块里的依赖链够长，而扩散步数不够，就可能解析不完，吐出语义上不连贯的文字。微调能在特定任务上把它救回来（NeMo、LoRA 都有路径），但通用质量的差距是这套方法当前的内在代价，不是调几个参数就能抹平的。
第四，有一个安全维度值得提前想：如果你的管线依赖思维链（CoT）的可读性来审计模型推理，扩散式生成会让这种逐步可读的链路在很大程度上消失。它不是一步步往下推理，是整块来回收敛。对需要可解释、可审计推理轨迹的应用，这是个真问题。
该忽略什么
忽略「4x faster」这个被推到标题里的营销词本身。它在特定条件下为真（本地、低并发、对的硬件），但作为一个笼统的「更快」承诺会误导你，在云端高并发场景它甚至可能更贵。该关心的不是快几倍，是在你的硬件、你的场景下延迟结构变成了什么样。
也别把它读成「自回归要被取代了」。Google 把标准 Gemma 4 留作高质量生产的默认选项，社区里清醒的声音也都同意：质量差距目前很硬，扩散在规模化时的速度优势又大多被批处理抵消，所以它现在只在窄场景里有吸引力。这更像一颗五年后可能成势的种子，不是今天就该 all-in 的换代。
最后，别被那些 SVG 鹈鹕、实时渲染代码的炫酷 demo 牵着走去高估它的通用能力。那些 demo 真正展示的是双向、非线性生成这个机制的有趣之处，不是这个具体 checkpoint 的生产可用性。机制的潜力值得长期跟，当前产品还在实验阶段，两件事分开看。