AI 终于不再一个字一个字往外吐了

过去我们看大模型写字，已经习惯了那个画面：光标闪一下，吐出一个词；再闪一下，又吐出下一个词。

这不是界面特效。今天绝大多数语言模型，本来就是这么工作的。它们像打字机，从左到右，一个 token 一个 token 往外猜。前一个 token 没定下来，后一个 token 就不能开始。

Google 这次发布 DiffusionGemma，表面上看是又一个开放模型：26B MoE、Apache 2.0、最高 4 倍文本生成速度、量化后能落在 18GB 显存级别。

它真正有意思的地方在于，把一个本地 AI 的老问题摊开了：

本地推理慢，常常卡在生成方式：GPU 明明有算力，却被逐 token 的小步子喂得太慢。

传统自回归模型每生成一个 token，都要跑一轮推理。放在云服务里，这事还能被调度系统救回来。因为云端有大量用户请求，服务商可以把很多人的 token 拼成 batch，一起丢给 GPU。一个人一句话很瘦，几千个人一起就胖了，机器终于有活干。

本地推理不是这样。

你在自己的机器上跑一个模型，通常只有一个用户、一个请求、一段输出。GPU 有算力，但它在等下一个 token，反复搬权重、查缓存、做一小口计算。它像一台印刷机，却被迫每次只印一个字。

它改的不是答案，是节奏

DiffusionGemma 不再严格从左到右逐字预测，而是先铺出一个 256-token 的“画布”，上面是一片待完成的位置，然后多轮并行去噪、修正、锁定。

你可以把它理解成：不是先写第一个字，再写第二个字；而是先摊开一整段毛坯，再一遍遍把模糊的位置擦清楚。

这件事最关键的地方，不在“更像人类思考”，在于它更像 GPU 喜欢的工作。

GPU 擅长大块并行计算，不擅长被一个 token 一个 token 地喂小勺。Google 开发者指南里说得很直接：传统 GPU 推理的主要瓶颈是 memory bandwidth，DiffusionGemma 试图把瓶颈推向 compute，用 256-token canvas 给 tensor cores 更大的并行工作量。

别急着喊替代

这也是为什么我不愿意把它理解成“扩散模型开始取代 LLM”。

Google 自己没有这么说。官方发布页明确把标准 Gemma 4 放在高质量生产输出的首选位置，DiffusionGemma 则是给速度敏感、本地交互式工作流探索用的。它为速度和并行 layout generation 做了取舍，整体输出质量低于标准 Gemma 4。

速度当然惊人。Simon Willison 用 NVIDIA NIM API 做过一次公开实测，4.4 秒返回 2409 tokens，保守估计至少 500 tokens/s。

但速度不是判断一项模型技术的唯一标准。更好的问题是：你的场景到底缺什么？

如果你做的是本地 IDE 里的行内补全、局部改写、代码 infilling、快速草稿、结构化片段生成，DiffusionGemma 这条路线就值得认真看。因为用户需要的是“下一秒给我一个可改的版本”，不一定要求第一次输出就完美。

如果你做的是客服最终答复、严肃长文、法律医学解释、企业知识库的权威答案，那就要冷静一点。质量折损、稳定性、可控性，可能比几倍 token/s 更重要。

真正的边界在并发

还有一个反直觉点：云端高并发未必是它最舒服的地方。

高 QPS 服务里，自回归模型本来就可以靠 batching 把 GPU 喂饱。很多请求一起排队，一起算，逐 token 的问题被工程调度摊平了。到了这个场景，DiffusionGemma 的并行解码收益会递减，甚至可能带来更高 serving cost。

也就是说，同一项技术，在本地单用户场景里可能是解药，在云端大规模服务里可能只是另一种账单结构。

判断一个产品是否适合 DiffusionGemma，先看三件事：

第一，看并发。低并发、本地、交互式，值得关注；高并发云服务，先算 batching 后的真实吞吐。

第二，看质量。输出能被用户快速修补，它就有空间；输出必须一次正确，它就不是首选。

第三，看硬件。瓶颈是显存带宽和逐 token 延迟，它可能帮得上；部署已经把计算吃满，换路线未必更便宜。

DiffusionGemma 不像一个终点，更像一块路标。它提醒我们，大模型竞争不只是在比谁更聪明，也在比谁更会安排硬件干活。

过去的大模型像打字机，一个字一个字敲出来。接下来，本地 AI 的关键问题会变成：怎样让一张 GPU 像印刷机一样，一次吃下一整段工作。

DiffusionGemma 的价值，是把文本生成问题重新放回硬件利用率里看。