谷歌开源DiffusionGemma：H100跑出1000TPS

谷歌DeepMind昨天扔出来一个有意思的东西——DiffusionGemma，Apache 2.0 协议开源，权重已经挂上 Hugging Face。这模型最大的卖点不是参数多大、跑分多漂亮，而是它根本就不是自回归模型。一次性吐出 256 个 token，H100 单卡能跑到 1000 tokens/s，RTX 5090 也能压到 700 tokens/s 以上。

注意，这是单用户、单请求的延迟数字，不是云端 batch 出来的吞吐。对于跑本地推理的开发者来说，这个意义比看上去大得多。

自回归模型到了该被挑战的时候

先把背景捋一下。从 GPT-2 开始，主流 LLM 全是自回归（Autoregressive）路线：从左到右、一个 token 一个 token 地预测。这个范式在云端 batch serving 里非常划算——一张 H100 同时处理几十上百个请求，GPU 利用率拉满，单 token 成本压到极低。

但放到本地、单用户、单请求的场景里，自回归就变成了一种浪费。你的 4090 或者 H100 明明有几十 TFLOPS 算力，可每生成一个 token 都要把整个模型权重从显存里搬一遍，瓶颈完全卡在内存带宽上，算力大部分时候是闲着的。这就是为什么本地跑 LLM，token/s 永远上不去——不是算力不够，是架构不对路。

谷歌这次的思路其实不新——扩散模型早就在图像生成里证明过自己。Stable Diffusion 那一套，是从一张全噪声的图开始，反复去噪迭代，直到清晰图像浮现。DiffusionGemma 把这套搬到了文本上：模型先在一块「文本画布」上铺 256 个随机占位 token，然后通过若干轮迭代逐步去噪、修正，最终整段文字一次性成形。

谷歌官方那个类比挺贴切的：自回归是打字机，一次一个键；扩散是印刷机，一次一整页。

26B MoE 架构，但只激活 3.8B

规格层面看几个关键点：

• 总参数 260 亿，MoE 架构
• 每步激活 38 亿
• 建立在 Gemma 4 系列和 Gemini Diffusion 研究基础之上
• 加入了新设计的 diffusion head
• 具备双向注意力机制
• 量化后可在 18GB VRAM 的消费级 GPU 上跑

MoE 这一手很关键。260 亿总参数听起来挺唬人，但每次前向只调用其中几个专家子网，实际激活就 38 亿。这意味着模型容量和推理成本被拆开了——你不用为了用上全部知识，就承担全模型激活的代价。

双向注意力是另一个值得拎出来说的点。自回归模型只能看左边的 token，这在生成代码、Markdown、数独这种需要前后呼应的内容时是个硬伤——前面写错了，后面只能将错就错。扩散模型不一样，每个 token 在每一轮迭代里都能看到上下文里的其他 token，写错了下一轮还能改回来。这就是为什么谷歌特别强调它适合代码补全、行内编辑、数学公式、氨基酸序列这类结构化任务。

性能数字怎么看

NVIDIA 给出的实测数据：

| 硬件 | 单请求吞吐 | |------|-----------| | H100 | ~1000 tokens/s | | DGX Station | ~800 tokens/s | | DGX Spark | ~150 tokens/s | | RTX 5090 | >700 tokens/s |

相比同级别的自回归模型，单用户单 GPU 场景下提速约 4 倍。

但这里得划重点：这 4 倍提速是有前提的。谷歌自己也很诚实地把适用边界说了：

1. 高 QPS 云端服务下，优势会缩水。因为云端 batch serving 本来就把 GPU 喂得很饱，并行解码的边际收益快速衰减——你已经在用 batch 把算力榨干了，再叠一层扩散并行没多大意义。
2. 共享内存架构（如 Apple Silicon）上，加速效果一般。统一内存的 Mac 本来内存带宽就不是瓶颈，自回归跑得已经够顺，扩散的优势体现不出来。
3. 输出质量低于标准 Gemma 4。这是一个为了把速度推到极限而主动牺牲质量的实验型号。

这一点谷歌讲得很直白：要质量你用 Gemma 4 正式版，要速度和低延迟交互你来玩 DiffusionGemma。

它真正的目标场景是什么

抛开 benchmark 数字，琢磨一下这模型实际能用在哪。

第一是本地实时编辑器。你写代码、写文档时，IDE 里那个补全/重写助手，最讨厌就是延迟。Cursor、Copilot 这类工具如果接入扩散文本生成，理论上能做到「整段重写」近乎瞬时返回——而不是一字一字地往外蹦，让你看着光标焦虑。

第二是非线性文本生成。这是个被低估的方向。传统 LLM 写 JSON、YAML、Markdown 表格的时候，本质上是在用自然语言顺序去拟合结构化输出，所以才会出现 JSON 末尾漏个括号、Markdown 表格列错位这种问题。扩散模型一次性看到整块画布，反而更适合这种有全局约束的任务。

第三是快速迭代实验。研究人员调 prompt、做消融实验，最烦的就是等推理。如果一次出 256 个 token 就是 1 秒钟的事，整个 dev loop 都能快好几倍。

至于聊天对话——其实扩散模型未必是最优选。聊天本身天然就是流式的，自回归一边算一边吐，用户体验上感知不到延迟。扩散得等整块迭代完才出，反而可能更别扭。

部署生态：vLLM、MLX、Unsloth 全家桶

谷歌这次开源的姿态做得很到位，没让你自己造轮子。已经支持的工具链：

• vLLM — 服务端推理
• MLX — Apple Silicon 上跑（虽然加速效果有限）
• Hugging Face Transformers — 标准入口
• Hackable Diffusion / Unsloth / NVIDIA NeMo — 微调
• llama.cpp — 官方支持「即将到来」

硬件层面跟 NVIDIA 一起做了深度优化，覆盖 RTX 5090、4090、Hopper、Blackwell、DGX Spark、DGX Station、RTX PRO 一整条线。

对于想本地起一个服务的开发者来说，最低门槛是 18GB VRAM——4090（24GB）、5090（32GB）都绰绰有余。考虑到这是 26B MoE 的容量，这个 VRAM 占用相当克制。

文本扩散这条路到底有没有戏

我个人的判断是：这是一个会被记住的节点，但不会颠覆什么。

文本扩散不是新概念，Inception Labs 的 Mercury 早就在卖类似的产品化方案，谷歌自家的 Gemini Diffusion 研究今年也发过技术报告。但真正开源、可下载、有完整工具链支持的 SOTA 级别模型，DiffusionGemma 是头一个。Apache 2.0 这个许可证也很关键，意味着没人拦着你拿去商用。

它解决的是一个非常具体的工程问题——本地单用户场景下 GPU 算力利用率低。这个问题在 PC 端 AI、终端侧推理、Copilot 类产品里都是真实存在的。所以你会看到 DiffusionGemma 的定位特别明确：不和云端通用模型抢饭碗，专攻本地实时交互。

但要说扩散会替代自回归，目前看还差得远。质量差距是一方面，更根本的是云端 batch serving 这个商业模型，自回归依然是最优解。OpenAI、Anthropic、谷歌自己的旗舰模型，短期内都不会切换路线。

比较可能的路径是混合架构——主干用自回归保质量，特定模块（比如代码块生成、JSON 输出、长文档重写）切到扩散模式提速。这种思路其实在多模态领域已经有先例，文本上未必不能复制。

给开发者的几条实操建议

如果你今天就想上手玩，几个建议：

• 先别拿它做生产。明确是实验模型，质量不到 Gemma 4 标准版水准。
• 优先在 NVIDIA 独显上跑。Mac 上效果会让你失望。
• 关注 vLLM 的实现进度。批量服务想发挥扩散的优势，调度逻辑跟自回归完全不一样。
• 结构化输出场景值得重点试。代码、JSON、Markdown 表格——这是它真正的舒适区。
• 微调路径已经铺好。Unsloth + LoRA 这套组合可以直接迁移，门槛不高。

顺便说一下，OpenAI Hub 这边主流闭源模型（GPT、Claude、Gemini 系列）一个 Key 都能调，国内直连不绕弯，兼容 OpenAI 格式——你拿 DiffusionGemma 跑本地实时编辑，云端走 OpenAI Hub 调旗舰模型做最终质量把关，这种「本地 + 云端」的混合工作流挺值得搭一下。

结语

DiffusionGemma 不是那种发布会上闪闪发光的模型，它没有刷新任何榜单。但它把**「文本生成必须自回归」**这个被默认了快十年的前提，扔出来重新审视了一遍。

本地 AI 这两年喊得很响，从 llama.cpp 到 Ollama，工具链一直在演进，但底层架构始终绕不开「内存带宽瓶颈」这个魔咒。DiffusionGemma 至少证明了一件事：只要换个生成范式，本地推理的天花板还能再往上推一截。

至于这条路能走多远，看接下来半年社区会拿它玩出什么花样。

参考来源

• DiffusionGemma on Hugging Face — 谷歌官方模型仓库，权重和模型卡可在 Hugging Face 下载