DiffusionGemma实测：用并行生成打破Token速度瓶颈
很多人习惯了LLM那种一个词一个词往外蹦的“打字机”模式，但DiffusionGemma这次玩了个不一样的，它把图像生成里的扩散模型思路搬到了文本生成上。简单来说，它不是在写字，而是在“洗照片”：先铺满一张随机噪声的画布，然后通过多次迭代，让文字像照片显影一样同时在画布上清晰起来。吞吐量惊人： 在RTX 5090上能跑到700+ token/s，H100甚至破千。这种速度在需要快速生成大量文本的自动化工作流中非常有竞争力。
显存占用克制： 这是一个26B的MoE模型，但推理时只激活3.8B参数。量化后18GB显存就能跑起来，这意味着很多中端专业卡也能部署。
下一篇
Sanity vs Directus：选内容湖还是数据库外壳？ →
作为一名QA工程师，我最关注的是这种架构在工程落地上的实际表现，尤其是它对硬件压力的改变。
一、 性能与部署的实际体感
传统的自回归模型最头疼的是内存带宽，GPU很多时候在等数据传输。DiffusionGemma把压力转移到了计算单元（Compute-bound），这让它在高性能显卡上的速度极其夸张。
二、 解决“死胡同”问题的逻辑
自回归模型最怕那种需要全局推演的任务（比如数独），因为它们只能从左往右走，走错了没法回头。DiffusionGemma采用的是双向注意力机制，它能同时观察整个文本块。
如果把写文章比作盖房子，传统模型是必须先打地基再盖一层；而DiffusionGemma像是在给房子上色，它能一边涂墙面一边发现地基不对，然后赶紧修正。这种自纠错能力让它在处理强约束逻辑任务时比普通模型稳得多。
三、 针对长文本的处理方式
它不是简单的全并行，而是采用了一种“块自回归扩散”策略：
1. 先在256个token的画布上并行生成。
2. 生成完成后，将这个块存入KV Cache。
3. 再开启下一个256个token的画布，并基于之前的历史记录继续生成。
这种设计在保证速度的同时，解决了扩散模型难以处理极长文本的稳定性问题，兼顾了效率和逻辑连贯性。
如果你想尝试微调这个模型来解决类似的约束类问题，可以参考这个具体的JAX工具链路径：
github.com/google-deepmind/gemma/tree/main/gemma/diffusion全部回复 （4）
R
RLHF了没有
新手
2小时前
Parallel decoding 怎么搞 constraint 确实是个坑。我之前试过用类似 Logit bias 的方案强行对齐，结果在 denoising 过程中分布被带跑了，完全没法保证 JSON 闭合。要是能在 Latent space 直接做 mask 倒是理想，但现在这种并行生成怎么保证 Token 之间的依赖关系？
0
显
