DiffusionGemma：告别逐词生成的速度革命
DiffusionGemma Technical Report
DiffusionGemma 团队推出了一款实验性开源语言模型，彻底改变了文本生成的逻辑。它不再像传统自回归模型那样逐词解码，而是利用离散扩散技术，并行迭代优化 256 个 token 的文本块，从而突破了速度瓶颈。该模型基于 Gemma 4 微调，仅需不到 10% 的训练算力预算。在单张 NVIDIA H100 GPU 上，其生成速度可达每秒 1500 个 token，远超配备最先进投机解码的自回归模型。更令人惊喜的是，它在保持高速的同时，依然支持思维模式、多模态输入和长上下文，甚至保留了自回归生成能力，为混合解码架构开辟了新路径。
DiffusionGemma 在生成速度与模型能力之间的权衡上确立了新的帕累托前沿。
HN 评论区
40- kamranjon
只是想分享这个，我发现它是理解 DiffusionGemma 工作原理的绝佳资源：https://newsletter.maartengrootendorst.com/p/a-visual-guide-...
我觉得最有趣的是，他们不需要从头训练这个模型，而是直接使用了现有的 MOE checkpoint：
“要将仅解码器模型（Gemma 4 26B A4B）转换为去噪器，我们可以利用它在生成 token 时未直接使用的部分，即所有 token 的 logits！”
让我对这次发布感到充满希望的是，同样的转换方法可能适用于其他开源模型，我们或许会看到大量现有本地模型的扩散版本。这真是令人兴奋！
- mmastrac
过去几个月里，我为 macOS 重新实现了这个项目：https://github.com/mmastrac/diffgemma
我很喜欢这个模型，它的推理能力相当不错。而且你可以根据需求灵活调整它。它专为计算能力大于内存带宽的机器设计，但在我看来，它在 Metal 上的表现也非常出色。
我在 M3 类机器上跑到了约 15 tok/s，但我敢打赌，在 M5 上还有大量性能潜力等待解锁，只是我目前没硬件能验证。
我尝试利用其他 Gemma MTP heads 来实现 MTP，但没能提升性能。关于如何利用草稿模型预填充扩散画布，这里还有一些有趣的研究空间。如果搭配合适的草稿器，DiffusionGemma 在我的机器上可以达到 20-30 tok/s，但我一直无法将两者结合，使其速度超过目前的运行水平。
- mike_hearn
如果这些模型在编程方面变得足够强大，将迫使人们重新思考语言、编译器和测试套件运行器的工作方式。“AI 改变一切”到了这个节点已经是个陈词滥调，
但我认为这确实是事实。
如果你的模型能以 1500 tok/sec 的速度进行推理和编写代码，那么在整个提示活动期间，你最终将完全受限于 CPU 时间。如果不是这样，那你在墙钟时间（wall time）上就输给了竞争对手。但我们整个开发栈都是基于这样一个理念构建的：程序员的大部分时间花在思考、交流和编码上，而不是等待 CPU（CI 集群过热是一个痛苦的例外）。
我设想的是某种混合模式，在这种模式下，代码编译和通过解释器运行可以重叠进行。这样，LLM 可以提出修改建议，并立即开始运行单元测试，同时并行地发现可能影响其他模块的类型错误。而且测试将始终分片运行，即使在本地开发环境中，也可能在远程集群上执行。
显然，这种方法在某种程度上正是 JVM 流行的原因。Java 编译非常快，因为 javac 主要只做类型检查，且类型系统很简单。然后 JVM 在运行过程中并行完成繁重的编译工作。因此，尽管 Java 以启动慢著称，但与 C++、Swift 或 Rust 相比，JVM 的周转时间（turnaround times）可以非常出色。而且很多启动时间的痛苦仅仅是由于糟糕的框架造成的，比如旧版的 Spring，它们想要 […]
- anentropic
结果很有吸引力……大家觉得有没有可能缩小与 AR 模型之间的准确率差距？或者甚至利用“双向推理与自我修正”将其转化为整体优势？
- lacoolj
我想知道将这种方法应用于 Qwen3.8-27b 的可行性如何。
目前我在本地运行它的速度大约是 7-11 t/s（16GB 4080，内存溢出充足）。如果速度能翻倍甚至翻三倍，那将是颠覆性的。