每秒1107个token，Google开源的扩散模型为什么能改变本地推理格局？
每秒 1107 个 token，但问题从来不只是速度
昨天，Google 开源了 DiffusionGemma。
一个 26B 参数的模型，在 H100 上跑到 1107 tokens/s。对比之下，传统自回归的 Gemma 4，哪怕开启了多 token 预测加速，也只有 303 tokens/s。
不是快了一点点，是快了将近四倍。这个数字说明的是：架构层面的差异，在吞吐量上的量级分化，远比参数调优或量化来得剧烈。
Transformer 的瓶颈从来不是算力
换个角度看，2023 年以来，大模型推理优化基本上围着两件事转：KV Cache 压缩、推测解码。但这些优化本质上都是修修补补，没有动底层生成逻辑。
自回归模型的生成就像打字机：一个 token 出来了，才能算下一个。本地推理时，GPU 在大部分时间里只有一个请求在跑，算力利用率低到让人心疼——显存带宽是瓶颈，矩阵乘法单元在空转。
云端场景下，服务商可以通过批量请求把 GPU 喂满，把多用户请求打包成大矩阵乘法来压榨算力。但本地场景呢？你一个人用，显卡的空转率天然就高。
DiffusionGemma 打的是这个痛点。它一次性生成 256 个 token 的整块文本，然后用迭代去噪的方式逐步修正。这不是在打字，是在印整版。
迭代生成不是新鲜事，真正新鲜的是工程落地
扩散模型在文本生成上的尝试，其实不算新。
2022 年就有 Diffusion-LM，后来有 SSD-LM、GENIE。但这些工作要么生成的文本质量差，要么速度还不如自回归。学术界做了一堆论文，工业界没人真拿去用。
区别在于，Google 把这件事落到了真正的应用层面。26B 参数只占 18GB 显存，RTX 5090 上还能跑到 700+ tokens/s。更重要的是，Apache 2.0 协议开源——这意味着开发者可以直接在消费级显卡上跑，不需要云端批量请求来掩饰架构的短板。
这个逻辑成立：扩散模型的迭代过程天然能修正前文错误。自回归模型写错了就得重新来，扩散模型在每一轮迭代中，可以拿已确定的 token 当线索，修正剩下的。这种生成质量上的内在优势，不是靠工程优化能弥补的。
但速度不是唯一变量
我的判断是：DiffusionGemma 解决了一个真实的问题，但它同样制造了一个新的不确定性。
现阶段，扩散语言模型的质量上限还没有被充分验证。自回归模型在长文本连贯性、逻辑推理上的能力经过了大量实践检验；扩散模型的一次性生成 + 迭代修正机制，在处理需要严格因果链的任务（比如数学推理、复杂代码生成）时，是否还能保持稳定，需要更多基准测试的覆盖。
Google 公布的基准数据显示，DiffusionGemma 在几个标准下游任务上与同参数量的自回归模型持平或略优。但持平和略优不够——开发者不会仅仅因为速度从 303 变成 1107 就迁移框架，如果质量有 5% 的损失，速度的优势就被抵消了。
值得持续跟踪的是：这个架构的 scaling law 会怎么走。自回归模型在参数量增加时，推理延迟的增长是线性的；扩散模型的迭代次数会怎么增长？如果 100B+ 参数时需要 20 轮迭代而不是 8 轮，那速度优势还能不能维持？
本地推理的想象力被打开了
2024 年以来，本地大模型的热度在持续攀升。Ollama、Llama.cpp 的项目 star 数在涨，甚至出现了本地运行 70B 模型的社区方案。但用户画像是清晰的：大家用本地模型做代码补全、文本摘要、内容创作，几乎没有人在本地做超长文本的实时生成，因为自回归模型在单用户场景下的速度本就勉强。
DiffusionGemma 的 1107 tokens/s 意味着什么？一秒钟生成 800 个英文单词。这个速度下，本地运行模型可以做的事情，不止是写文案和回邮件。实时翻译、同步字幕生成、交互式小说创作——那些过去只能靠云端 API 完成的实时场景，开始有了本地化的可能。
现在下结论为时尚早。框架转换的迁移成本、生态工具的适配进度、社区对扩散语言模型的信任度积累，都需要时间。但有一条线索是清晰的：自回归模式统治文本生成领域的格局，第一次遇到了实质性的挑战。
问题变了——不是本地大模型能不能跑得飞快，而是跑得飞快之后，原来的质量天花板会不会随之坍塌。或者，它只是被推高了一层。