DiffusionGemma 发布:Google 用扩散模型把文本生成加速了 4 倍

昨天(6 月 10 日),Google 在博文中正式发布了 DiffusionGemma,一个基于文本扩散(Text Diffusion)技术的实验性开源模型。Apache 2.0 许可,26B MoE(实际激活仅 3.8B),专用 GPU 上速度可达传统模型的 4 倍。

这可能是今年最值得关注的 “换个思路” 的模型之一。

传统 LLM 像打字机,DiffusionGemma 像印刷机

用过本地模型的人都知道那种体验——7B 的模型在小 GPU 上算得挺快,但每一次推理都是一次 “从左到右、逐个令牌” 的串行操作。你可以想象一个打字员,打完一个字才知道下一个字该打什么。

DiffusionGemma 彻底颠覆了这个范式。它不是自回归的:

  1. 先准备一个 256 token 的 “空白画布”(随机占位符)
  2. 在多次迭代中逐步锁定正确 token,用已锁定的内容做上下文线索去推断其余部分
  3. 最终收敛为连贯文本

这跟 Stable Diffusion 生成图片的过程本质是一回事——从噪点一步步清晰。

自回归 vs 文本扩散生成方式对比
自回归(打字机)vs 文本扩散(印刷机)——两种生成方式的本质区别(手绘 SVG)

性能数据:确实快

Google 官方给出了具体数字:

  • NVIDIA H100:1000+ tokens/s
  • RTX 5090:700+ tokens/s
  • 相比同规模自回归模型,可达到约 4 倍加速

因为激活参数只有 3.8B,量化后能控制在 18GB VRAM 以内,RTX 4090/5090 级别就能跑。

DiffusionGemma vs 自回归模型推理速度对比
DiffusionGemma 与自回归模型在相同 GPU 上的 tokens/s 对比(数据来源:Google Keyword Blog)

Simon Willison 实测用 NVIDIA NIM API 跑了一遍,生成 2409 tokens 只用了 4.4 秒,相当于 ~550 tokens/s。他生成的是一段带格式的 SVG 渲染输出——这种需要跨 token 理解结构的任务正是 DiffusionGemma 的强项。

为什么它适合本地部署?

有意思的是,扩散模型的加速优势在本地运行时反而最明显。原因在于自回归模型要靠批处理(batch)来填满 GPU 算力——服务器端同时处理上千个请求,效率很高。但本地只有你一个人用,GPU 大部分时间都在等下一个 token。DiffusionGemma 一次性塞给 GPU 256 token 的并行计算任务,把硬件压满。

不过注意一个关键限制:Apple Silicon 上加速不明显。因为 M 系列芯片是统一内存架构,推理时受内存带宽限制,不是计算瓶颈——扩散模型依赖的是高计算密集度,在 Mac 上加速效果不如专用 GPU。

它能做什么?实用场景

DiffusionGemma 的实验性质意味着它不适合替代 Gemma 4 做生产级文本生成。但它在几个特定场景上有天然优势:

  • 内联编辑 / 代码填充:因为双向注意力,每个 token 能看到上下文的两侧,适合填充代码中间段
  • 非自回归结构生成:Unsloth 团队用微调后的 DiffusionGemma 玩起了数独——自回归模型天生搞不定这个,因为后面的数字依赖前面的,但你没法同时考虑前后
  • 实时交互式应用:低延迟输出适合需要 “边想边写” 的场景

微调后的 DiffusionGemma 玩数独
Unsloth 微调 DiffusionGemma 解决数独问题——自回归模型搞不定的任务,扩散模型天然擅长(来源:Google Blog)

生态支持:该有的都有

  • 推理框架:已支持 vLLM(Red Hat 合作集成)、HuggingFace Transformers、MLX(Apple)
  • 微调工具:Unsloth、NVIDIA NeMo、Google 自家的 Hackable Diffusion(JAX)
  • 量化:支持 NVFP4(4-bit 浮点),精度损失极小
  • 云端:Google Model Garden、NVIDIA NIM 均可直接试用
  • 未来:llama.cpp 官方支持即将到来

需要留意的

  • 输出质量不如 Gemma 4——这是取舍,快必然有牺牲
  • 实验状态——Google 明确标注了 experimental,不适合做生产关键依赖
  • 本地硬件门槛:虽说量化后 18GB,但 RTX 4060 级别可能跑不了
  • 云服务场景优势递减:高并发批处理时,传统自回归模型也能饱和算力,扩散模型的加速会打折扣

总结

DiffusionGemma 不是又一个更大更强的模型——它是一个用不同思路解决问题的模型。文本扩散这条路 Google 从 Gemini Diffusion 就开始摸索了,现在把它开源成 Gemma 家族的一员,意味着这个方向正在从实验走向可用。

如果你有 RTX 5090/4090,或者想在 NVIDIA NIM 上体验一下,现在就可以去 HuggingFace 下载权重跑起来。llama.cpp 支持也快到了——到时候本地部署会更方便。


来源: Google Keyword Blog, Simon Willison’s Weblog, HuggingFace 模型页

发表评论

DiffusionGemma 发布:Google 用扩散模型把文本生成加速了 4 倍

昨天(6 月 10 日),Google 在博文中正式发布了 DiffusionGemma,一个基于文本扩散(Text Diffusion)技术的实验性开源模型。Apache 2.0 许可,26B MoE(实际激活仅 3.8B),专用 GPU 上速度可达传统模型的 4 倍。

这可能是今年最值得关注的 “换个思路” 的模型之一。

传统 LLM 像打字机,DiffusionGemma 像印刷机

用过本地模型的人都知道那种体验——7B 的模型在小 GPU 上算得挺快,但每一次推理都是一次 “从左到右、逐个令牌” 的串行操作。你可以想象一个打字员,打完一个字才知道下一个字该打什么。

DiffusionGemma 彻底颠覆了这个范式。它不是自回归的:

  1. 先准备一个 256 token 的 “空白画布”(随机占位符)
  2. 在多次迭代中逐步锁定正确 token,用已锁定的内容做上下文线索去推断其余部分
  3. 最终收敛为连贯文本

这跟 Stable Diffusion 生成图片的过程本质是一回事——从噪点一步步清晰。

自回归 vs 文本扩散生成方式对比
自回归(打字机)vs 文本扩散(印刷机)——两种生成方式的本质区别(手绘 SVG)

性能数据:确实快

Google 官方给出了具体数字:

  • NVIDIA H100:1000+ tokens/s
  • RTX 5090:700+ tokens/s
  • 相比同规模自回归模型,可达到约 4 倍加速

因为激活参数只有 3.8B,量化后能控制在 18GB VRAM 以内,RTX 4090/5090 级别就能跑。

DiffusionGemma vs 自回归模型推理速度对比
DiffusionGemma 与自回归模型在相同 GPU 上的 tokens/s 对比(数据来源:Google Keyword Blog)

Simon Willison 实测用 NVIDIA NIM API 跑了一遍,生成 2409 tokens 只用了 4.4 秒,相当于 ~550 tokens/s。他生成的是一段带格式的 SVG 渲染输出——这种需要跨 token 理解结构的任务正是 DiffusionGemma 的强项。

为什么它适合本地部署?

有意思的是,扩散模型的加速优势在本地运行时反而最明显。原因在于自回归模型要靠批处理(batch)来填满 GPU 算力——服务器端同时处理上千个请求,效率很高。但本地只有你一个人用,GPU 大部分时间都在等下一个 token。DiffusionGemma 一次性塞给 GPU 256 token 的并行计算任务,把硬件压满。

不过注意一个关键限制:Apple Silicon 上加速不明显。因为 M 系列芯片是统一内存架构,推理时受内存带宽限制,不是计算瓶颈——扩散模型依赖的是高计算密集度,在 Mac 上加速效果不如专用 GPU。

它能做什么?实用场景

DiffusionGemma 的实验性质意味着它不适合替代 Gemma 4 做生产级文本生成。但它在几个特定场景上有天然优势:

  • 内联编辑 / 代码填充:因为双向注意力,每个 token 能看到上下文的两侧,适合填充代码中间段
  • 非自回归结构生成:Unsloth 团队用微调后的 DiffusionGemma 玩起了数独——自回归模型天生搞不定这个,因为后面的数字依赖前面的,但你没法同时考虑前后
  • 实时交互式应用:低延迟输出适合需要 “边想边写” 的场景

微调后的 DiffusionGemma 玩数独
Unsloth 微调 DiffusionGemma 解决数独问题——自回归模型搞不定的任务,扩散模型天然擅长(来源:Google Blog)

生态支持:该有的都有

  • 推理框架:已支持 vLLM(Red Hat 合作集成)、HuggingFace Transformers、MLX(Apple)
  • 微调工具:Unsloth、NVIDIA NeMo、Google 自家的 Hackable Diffusion(JAX)
  • 量化:支持 NVFP4(4-bit 浮点),精度损失极小
  • 云端:Google Model Garden、NVIDIA NIM 均可直接试用
  • 未来:llama.cpp 官方支持即将到来

需要留意的

  • 输出质量不如 Gemma 4——这是取舍,快必然有牺牲
  • 实验状态——Google 明确标注了 experimental,不适合做生产关键依赖
  • 本地硬件门槛:虽说量化后 18GB,但 RTX 4060 级别可能跑不了
  • 云服务场景优势递减:高并发批处理时,传统自回归模型也能饱和算力,扩散模型的加速会打折扣

总结

DiffusionGemma 不是又一个更大更强的模型——它是一个用不同思路解决问题的模型。文本扩散这条路 Google 从 Gemini Diffusion 就开始摸索了,现在把它开源成 Gemma 家族的一员,意味着这个方向正在从实验走向可用。

如果你有 RTX 5090/4090,或者想在 NVIDIA NIM 上体验一下,现在就可以去 HuggingFace 下载权重跑起来。llama.cpp 支持也快到了——到时候本地部署会更方便。


来源: Google Keyword Blog, Simon Willison’s Weblog, HuggingFace 模型页

发表评论