一张H100,每秒跑出1500个token——这是DiffusionGemma论文自己给的数字,比自回归模型正常解码快出不少。谷歌这次没有从零训练模型,而是把Gemma 4改造成了离散扩散语言模型,用不到原模型十分之一的训练量,换来这次提速。
数字好看,但这是论文自设评测套件、单张H100、特定batch条件下测出来的。真正决定这套方案能不能落地的,不是峰值吞吐,而是首token延迟、显存占用和高并发下的稳定性——这些论文摘要里都没细说。
从"一个字一个字吐"到"一整块一起改"
自回归模型生成文字,必须等上一个token算完,才能算下一个。这是延迟的根源。DiffusionGemma换了个思路:把256个token的一整块文字一起丢进去,让模型反复迭代、并行去噪,直到整块内容收敛成通顺的句子。
论文给出的数字:平均每次前向传播能生成约20个token,单张H100上跑出约1500 tokens/s。论文说这比目前最好的自回归投机采样方案还快,但没指明具体是哪个版本,这个对比目前只出自论文自己的评测,没有第三方复现数据。
模型不是从零训练的,直接把Gemma 4的混合专家骨架改造成扩散模型,激活参数3.8B,总参数25.2B。训练分两步:
| 阶段 | 做什么 | 目的 |
|---|---|---|
| 第一阶段 | 监督微调,教模型学双向去噪 | 让模型学会"整块修改",而不是"逐字预测" |
| 第二阶段 | 强化学习 + 采样器蒸馏 | 同时优化生成质量和推理效率 |
整个过程新增的训练token,不到原始自回归模型训练预算的10%。
论文还提到,思考模式、多模态输入和长上下文支持都保留了,模型依然能做传统自回归生成,只是性能有轻微下降。两种解码方式理论上可以混用。
训练便宜,但这笔账还没算完
论文说DiffusionGemma划出了"新的Pareto前沿"。这个说法只在论文自己那条速度-能力权衡曲线里成立,不等于全面碾压自回归模型的生成质量。
决定部署成本的几项关键信息,论文摘要里基本是空的:
| 项目 | 论文披露情况 |
|---|---|
| 单卡峰值吞吐 | 约1500 tokens/s(论文自设评测套件,单张H100) |
| 首token延迟 | 未披露 |
| 高并发/多任务吞吐 | 未披露 |
| 显存占用 | 未披露 |
| 量化精度 | 未披露 |
| 对比的具体投机采样方案 | 未指明版本 |
| 权重开放程度 | 开放权重,训练代码与数据细节未必全公开 |
这些空白,恰好是推理服务商做容量规划时最先要填的表格。而且这仍是一个实验性模型,离生产可用还有距离,"开放权重"不等于"完全开源"。
该盯的不是这个数字,而是社区复现的下一版
做推理和部署的工程师,现在能做的是拿开放权重在自己的硬件、自己的batch和并发条件下重新测一遍,尤其是首token延迟和显存占用。这两项决定了同样的吞吐数字,换到你的机房是不是还成立。不建议直接拿单卡1500这个数字做容量规划,论文的评测条件和生产流量的差距,大概率比想象中大。
关注生成架构演进的人,该盯的不是这一次的速度记录,而是接下来有没有别的团队,用同样的两阶段训练思路——双向去噪SFT加RL蒸馏——在别的基础模型上复现类似效果。只有DiffusionGemma一家能做到,这更像一次工程优化;方法能被复制,才算得上解码范式的转向。
已经在用自回归模型做低延迟服务的团队,现在更现实的动作是观望,不是迁移。长文本一致性和精确控制是扩散模型的老问题,256个token一起改,逻辑连贯会不会打折,论文自己的评测说了不算。
技术路线本身站得住:自回归解码慢是这几年被诟病最多的问题,投机采样、并行采样、蒸馏小模型陪跑,本质都是给串行结构打补丁。DiffusionGemma把生成单位从"一个token"换成"一整块文本",用不到10%的训练量做出来,这个方向没错。
但速度好看不代表账已经算平。真正的成绩单,是社区拿到权重、换上自己的硬件和真实流量之后跑出来的那一版,不是论文里这个1500。生产线的成本曲线,从来不是靠一张显卡算出来的。
