Google DiffusionGemma：4 倍速度背后，本地 AI 开始换赛道

一张 RTX 5090，本地生成约 700 tokens/s；单张 H100，超过 1000 tokens/s。Google DeepMind 新发布的 DiffusionGemma，最抓人的数字就是这个：最高约为类似规模自回归 Gemma 的 4 倍。

但这不是普通的 Gemma 更新。

反常点在生成方式。它没有沿着主流大模型逐 token 吐字的老路走，而是把扩散模型的思路搬进文本：先铺出一块占位 token，再多轮修正，最后定稿一段文本。最多并行处理 256 个 token。

这件事的主线很清楚：Google 在本地 AI 的效率瓶颈上，押了另一条路线。不是继续喊参数更大，而是尝试让本地 GPU 的闲置算力派上用场。

DiffusionGemma 快在哪里

DiffusionGemma 属于 Gemma 4 开放模型家族。Apache 2.0 许可，权重可从 Hugging Face 下载。

它是 26B MoE 模型，总参数 260 亿，推理时激活约 38 亿参数。目标硬件不是手机小模型，而是高端消费级 GPU，以及 H100、DGX 这类企业级硬件。

自回归模型像排队过闸机。一个 token 生成完，下一个才能走。

扩散文本更像先铺开一张答题卡，来回涂改，再统一交卷。它把部分瓶颈从内存带宽挪到计算。

这对本地 AI 很要命。

很多本地部署不是算力完全不够，而是显存带宽、调度效率和延迟拖后腿。GPU 有算力，但喂不饱。DiffusionGemma 的算盘是：既然本地硬件有空转的计算单元，就用更多计算换更低延迟。

这不是玄学优化，是路线选择。

它适合谁，不适合谁

最该看这件事的，是两类人。

一类是做本地 AI 部署的开发者。比如本地助手、企业内网工具、离线文档处理、低延迟写作和摘要类应用。你可以下载权重做验证，但不该立刻迁移主链路。更合理的动作是做 A/B：长输出、批量生成、延迟敏感任务先测；短问答、代码、数学和结构化输出先观望。

另一类是关心硬件成本的技术负责人。DiffusionGemma 提醒你，采购决策不能只盯显存和参数表。生成机制也会影响硬件利用率。如果团队正准备为本地 AI 扩机器，至少该把“扩散式文本生成是否能提高现有 GPU 利用率”放进评估表，而不是直接加卡。

普通用户暂时不用兴奋。它不是一个新的聊天 App，也不是 Gemini 的替代品。它更像一条给开发者和部署团队看的实验路线。

限制要说在前面。

文本不是图片。图片里一个像素错了，肉眼可能忽略；文本里一个 token 错了，数字、代码、权限指令都可能出事故。

Google 也把 DiffusionGemma 定为实验性模型。这个定语很关键。它说明这条路线有潜力，但还没到可以替换主流自回归架构的阶段。

云端大模型也不会因此失速。云端有 HBM 带宽、多用户负载、批处理和更成熟的推理栈。本地 AI 的痛点不同：机器常常闲着，带宽没那么奢侈，延迟又很敏感。扩散文本的吸引力，主要在这里。

有点像铁路和公路的分工。铁路单位运力强，但依赖线路和班次；公路不一定最省，却能把货送到门口。不完全一样，但今天的 AI 部署也在重复这个逻辑：最强的路线，不一定是最容易落地的路线。

4 倍速度不是结论，部署能力才是分水岭

我更在意的不是 4 倍这个数字，而是它暴露出的行业变化。

过去两年，大模型叙事太爱堆参数、上下文、榜单。听起来热闹，落到开发者手里，经常变成三件事：显存不够，延迟太高，成本太贵。

模型看着更强，产品反而更虚。

DiffusionGemma 的价值，是把问题掰得更直：本地 AI 要普及，不能只等硬件变贵、显存变大。生成机制也要改。

用并行换低延迟，用计算换带宽。这条路值得试。

但账还没结完。

接下来最该看的不是宣传页上的峰值速度，而是四个变量：

• 同等质量下，扩散文本的错误率能不能压住；
• 短输出场景里，额外计算会不会抵消速度收益；
• 在真实本地应用里，端到端延迟是不是也能接近 4 倍提升；
• 部署成本、显存占用和工程复杂度，是否低于继续优化自回归模型。

这些变量没跑通，4 倍速度就只是漂亮的局部指标。

“天下熙熙，皆为利来。”放到 AI 产业里，就是谁能把模型便宜、稳定、低延迟地塞进设备，谁才可能拿到下一轮应用红利。

DiffusionGemma 不是终局，也没有宣布自回归过时。它只是把一个更现实的问题摆到台面上：AI 竞争正在从“谁最大”移到“谁最能部署”。

这比又一个榜单排名更重要。