扩散式LLM生成速度突破2082 tokens/s，吞吐革命下自回归还够用吗？

最近在看生成式模型的新动态目光基本都落在推理速度和输出效率上。一个叫 Celeris-1 的 diffusion LLM 引起了我的注意不是因为它背靠多大的团队或多少融资而是项目标题里就带着一组数据output tokens/s 达到 2082。坦白说第一次看到这个数字我没有急着羡慕“快到飞起”而是先愣了几秒——一个 diffusion 架构的大语言模型凭什么能把生成速度拉到和理解模型大致同级的水平这件事值得掰开来看。我的判断是2082 output tokens/s 这个数字真正的看点不是“快”而是它背后那套生成范式正在变化。过去我们习惯了自回归模型逐字往外蹦扩散模型却是先铺一层噪声再通过多步采样逐步“显形”。如果扩散式 LLM 真的能把速度打上来那它对推理吞吐、批量生成、实时交互这些场景的影响可能比单纯换个模型权重要大得多。1. 先看懂 2082 tokens/s 背后的范式切换1.1 为什么很多人会觉得这个数字“反常”过去两年大家评估大模型最常见的速度指标是 decode tokens/s。你打开任何一个开源模型的后端日志看到的都是“每秒生成多少个 token”。这个数字通常被卡在几十到几百之间取决于显存、量化、批处理大小和上下文长度。于是突然冒出一个“2082 output tokens/s”的 diffusion LLM会觉得像机械硬盘时代突然跑出 NVMe 的顺序读取成绩。但慢着先别急着拿这个数字去和 GPT 类模型的“tokens/s”直接对比。两者计数的起点不完全一样生成路径也不一样。我们一直依赖的自回归 LLM逻辑是“预测下一个词”。给定 prompt模型先算第一个词算完之后把它拼回去再算第二个词。这个循环是串行的每一步的真正推理计算量不小而且一步没算完下一步就动不了。即使有 KV Cache、投机采样、并行解码这些优化本质上还是绕不开“序列顺序依赖”。扩散式 LLM 走的是另一条路。它的起点是一段随机噪声或者说一段随机的 token 嵌入序列然后通过若干次去噪迭代逐步把噪声“整理”成有意义的句子。关键变化是在一次去噪过程中整个序列是并行参与计算的模型不是机械地一个词一个词预测而是同时面向整个句子做优化。所以“2082 output tokens/s”更可能指向的是模型在单位时间内能完成的“输出 token 总量”而不是单条流上用户感知的、从第一个字符到最后一个字符的串行速度。这个区分非常重要否则你会拿它和一个普通自回归模型的 decode 速度直接做算术然后得出一个误导性的结论。1.2 扩散式 LLM 和自回归 LLM 的真正区别要理解这个 benchmark 的分量先要建立一张地图常见的生成式语言模型大致可以按两个维度分。输入侧看到全部提示还是只能看到左边一部分。输出侧一次生成一个 token还是并行生成多个 token。自回归模型输出侧是典型的“逐个生成”。扩散模型输出侧则更像“整体重建”。我们把输入一句话让模型去补全或续写时自回归模型会从左往右逐个决定下一个词。扩散模型则会先随机初始化一个完整的候选序列然后反复校准让序列整体逐渐贴合目标分布。这就像两种解题方式。一种是拿到一道证明题从条件出发一步一步推到最后结论另一种是先草拟一个答案框架然后反复检查、修正细节让整个证明过程越来越合理。前者思路清晰但天然有步骤依赖后者可以同时处理多个位置但需要额外控制“整体一致性”。对语言任务来说自回归为什么长期占优因为语言本身有强顺序依赖后面词的选择受前面词影响很大。扩散式语言模型过去最大的短板就在这里——如果对整体序列并行去噪长距离依赖和上下文连贯性容易出现问题。这也是为什么之前扩散模型更多出现在图像、视频领域而在语言模型里更多是研究性质的尝试。一旦扩散式 LLM 真的能在这套框架下稳定输出并且速度还够快那它解决掉的就不只是“生成一批内容有多快”而是“在批量并发场景下单位时间能产出多少优质内容”这个和成本直接挂钩的问题。1.3 这个项目最可能踩中的技术路径回到 Celeris-1 这个名字。从公开信息看它被明确标记为 diffusion LLMbenchmark 是 2,082 output tokens/s。至于具体参数数量、训练策略、采样步数、部署环境项目标题没有展开。这种情况下我们只能基于扩散语言模型的一般技术路线做一些推测而不是当作官方结论。目前扩散式语言模型通常有几类实现思路把文本离散 token 映射成连续嵌入在连续空间上做扩散去噪最后映射回离散 token。直接在离散 token 上定义扩散过程比如 D3PM。采用 flow matching 或 rectified flow 这类方法用更简单的插值路径替代传统扩散去噪过程从而减少采样步数。如果 Celeris-1 确实能跑到 2082 output tokens/s那么它很可能用了更少的采样步数、更大的并行批处理或者针对某些硬件做了极致的 kernel 优化。这些都属于工程上很常见的加速手段。但我不打算假装自己拿到过 Celeris-1 的白皮书。更稳妥的看法是这个 benchmark 至少说明 diffusion 语言模型在推理效率上已经跨过了一个门槛从“能跑”进入“可以认真讨论是否投入生产”的阶段。2. 为什么扩散式生成能拥有更高的吞吐2.1 自回归是串行推演扩散是并行重构自回归语言模型的速度瓶颈很容易理解。每一步解码都要读取前面所有 token 对应的 KV 状态计算注意力然后采样一个新 token。即使 KV Cache 把重复计算省掉了每一步之间仍然是严格的串行依赖。你可以做得更快但很难打破“必须等前一个词出来才能算下一个词”的锁。扩散模型没有这把锁。它初始化一个完整的序列比如长度 64 的候选输出然后直接对 64 个位置一起做去噪。每一轮迭代所有位置都拿到同样的约束信号同时更新。在这个意义上单条生成只需要跑若干轮迭代而不是按序列长度跑若干轮。流式输出的时候每轮迭代完成整个句子的质量都会跳跃式地提升。这就像修一张合影自回归是慢慢从左到右画出一个人再画旁边的人扩散是先把整张照片铺上一层模糊色块然后每次迭代让所有面部特征都清晰一点几轮之后整张图已经很接近成片。后者天然更适合并行处理。2.2 少步采样和 flow matching 是大提速的关键扩散模型人人都知道但“每句话要反复去噪三十步”和“每句话去噪五步”带来的延迟差异是数量级的。传统扩散模型为了保证效果可能需要几十步甚至上百步采样。如果一个大语言模型每次回答都要跑 50 轮去噪那即使每轮内部并行度很高端到端速度也未必好看。所以真正决定扩散式 LLM 有没有落地价值的是能不能把采样步数压到非常少同时质量不明显下降。这里就和热搜里的“flowmatching”对应上了。Flow Matching 的思路简单说是不再走“逐步加噪声、再逐步去噪声”的路线而是定义一个从纯噪声分布到真实数据分布的更直接路径训练模型去学这条路径上的速度场。这样在推理时只需要少量步数就能完成插值往往几步到十几步就能接近最终质量。很多新出的扩散语言模型都会倾向用这类连续路径方法而不是最早的 DDPM 式采样原因就在于速度和质量的平衡更好。Celeris-1 没有公布技术细节我不能断言它一定用了 flow matching。但从 benchmark 表现反推若它真是每秒 2082 output tokens 的扩散式 LLM那采样步数大概率不会太大或者使用了某种并行采样的策略。你要理解这个速度首先得接受“少步采样”这个前提。2.3 输出 tokens/s 测量的是什么这里要抠一下概念。Output tokens/s 到底是怎么算出来的最常见统计口径是在某个 batch 尺寸下所有输出 token 数量除以总耗时。例如一次跑 32 条请求每条输出 256 个 token总共 8192 个 token耗时 4 秒那么吞吐就是 2048 tokens/s。这个过程里单条请求的用户延迟可能不是 4 秒而是更久只是吞吐被 batch 放大。另一种口径是单条流式输出时从开始输出到结束平均每秒产出的 token 数。这种情况下2082 tokens/s 对单条流来说就是每毫秒两个 token 左右用户感知速度接近二三十毫秒一个 token体感上“文字在屏幕上是刷出来而不是蹦出来”。两种口径差异巨大。如果 benchmark 是批量测出来的那它更多说明的是服务的吞吐能力而不是单用户延迟。对于 API 服务、批处理任务、离线内容生成吞吐更重要对于聊天、代码补全这类实时交互单条延迟和首 token 延迟更重要。所以评价 Celeris-1 的 2082 output tokens/s不能只看数字大小还要看它的测量口径、硬件、batch size、量化方式、上下文长度。否则这个数字就没有横向比较的意义。3. Benchmark 数字怎么读比“每秒多少 token”更重要的是什么3.1 吞吐量不等于用户体感速度很多人一看到“每秒 2082 个 token”就会自动脑补成“回答快得离谱”。实际不是一回事。看下面这个示意表场景关键指标说明用户聊天首 token 延迟 单条生成延迟用户关注“开始回答要多快”“完整回答要多快”批量文档生成吞吐量tokens/s在乎单位时间完成多少任务代码补全首 token 延迟 生成准确率等太久会破坏编码流离线翻译吞吐量 质量吞吐维度更关键实时字幕延迟 稳定性延迟要求极高如果 Celeris-1 的 benchmark 是批量场景下的吞吐那么用户感知的单条延迟可能仍然有提升空间也可能已经很快。我们需要更多上下文。这也是我在看任何新模型 benchmark 时保持警觉的原因一个亮眼的输出速度指标经常只反映了某个特定配置下的表现而不是一个可以直接套到所有生产场景的通用数字。3.2 真正应该放在一起看的四个伴随指标面对 2082 output tokens/s我建议至少追问四件事。采样步数。步数越多质量通常越好但速度越慢。2082 是在几步下测出来的如果只用了 4 步那质量如何如果用了 32 步那又是另一个故事。Batch size。是单条测试还是大批量并发批大小提升往往会线性拉高吞吐但也会抬高显存占用和单条延迟。模型规模和量化等级。量化 fp16 和 int8 的速度差异明显。如果 benchmark 用 int8 且权重被极端压缩那模型质量的损失也要同时评估。上下文长度和输出长度。短输出测出来的 tokens/s通常比长输出更好看。因为注意力计算和 KV Cache 开销会随长度上升。如果只测短输出那么数字不能代表长文本生成的效率。还有更隐蔽的一点为了达到高吞吐模型是否牺牲了最终输出质量比如通过提前终止采样、强制截断、降低随机性等方式都能让“有效输出 token”变快但内容可能更像复读机或更冒险。所以只看速度不看质量很容易被指标带偏。3.3 不同模型之间的 benchmark 不能直接对比看到 2082人们可能会想它比 Llama 3 的 80 tokens/s 快 26 倍。这个对比没有意义除非两人基于同一模型、同一长度分布、同一硬件、同一批大小、同一采样步数。举个简单例子如果用一个自回归模型开启投机采样有可能会把 decode 速度从 60 tokens/s 提到 150 tokens/s但它输出逻辑仍是一个一个词吞吐提升来自草稿模型投机。扩散模型则完全不同它从机制上就是整体并行生成。这两种模型如果不在相同任务、相同质量约束下测评数字没什么可比性。所以 Celeris-1 的 2082 output tokens/s 更像是给“扩散式语言模型进入高速生成时代”打了一个标记而不是给所有现有模型之间搞了一个精确排名。想看它到底好不好用最终还是要落到你自己的任务上。4. 普通开发者什么时候值得关注扩散式 LLM4.1 它适合的任务类型如果扩散式 LLM 真的能做到高吞吐、低步数生成下列场景会最先受益。批量生成商品描述、SEO 文案、社媒文案、批量摘要、数据清洗后的自然语言生成。多候选生成一次生成大量候选句子再由下游分类器或规则模块筛选。扩散模型可以并行生成多个独立样本吞吐优势明显。实时对话如果单条延迟也足够低它会成为对话型应用的新选项尤其是需要高并发服务的情况。代码补全如果质量和上下文连接能解决代码补全场景也非常看重延迟。对这些场景我会更喜欢吞吐能力强的引擎因为成本结构会发生变化。比如批处理 10 万条标题如果单条延迟高一点但整体吞吐够高总等待时间还是可控的。4.2 目前仍需谨慎的边界扩散式语言模型还没有完全成为主流主要问题在质量、连贯性和生态。长文本连贯性这是扩散模型的老问题。并行去噪容易让局部漂亮但整篇的长程主题一致性未必比自回归模型稳。日志和信息流如果你需要 token 级概率、逐词困惑度、采样时的 logits扩散模型的导出方式还在成熟过程中。工具调用和结构化输出自回归模型在 JSON、function call 等格式约束上已经有一套成熟方案。扩散模型能不能严格保证输出 schema可能需要额外验证。社区生态大部分工具链、微调框架、推理后端仍然围绕自回归模型构建。你也许能找到推理脚本但 LoRA、量化、RAG 后端、日志监控都要自己适配。所以我不建议在核心生产链路里因为一个 benchmark 好看就把整个底座换掉。更合理的做法是把扩散式 LLM 放到一个新场景里做试点用真实数据验证质量、速度和成本。4.3 一个选型判断标准你可以用下面这张清单快速判断要不要在自己的项目里尝试类似 Celeris-1 的扩散式 LLM维度判断问题如果满足值得考虑任务性质是批量重复内容生成还是对话式精确回复批量生成更有利质量要求是否需要严格的逻辑推理和长链条因果因果链很长时先保守输出结构是否必须输出符合 JSON Schema 的字段需要额外做 schema 验证和重试延迟敏感度用户是否实时等待每个 token需要关注首 token 和单条延迟成本预算是否追求单位时间内最大产出吞吐型模型更划算生态成熟度团队是否能接受自己适配推理后端如果不行继续观望没有任何模型适合所有人。扩散式 LLM 的优势是在特定 workload 下实现高吞吐但这种优势必须在质量可控的前提下才成立。否则一分钟生成一千句废话和三十秒生成十句准话价值完全不同。5. 从看热闹到落地一份可执行的验证流程如果你想亲自验证一下扩散式语言模型的输出速度和真实质量不用先等 Celeris-1 放开源权重。现在生态里已经有一些可用的扩散语言模型和代码库。用它们跑通整套验证流程比盯着一个 2082 的数字更能建立直觉。下面这套流程是通用验证路径不绑定具体模型。如果你想测试的对象是某个新项目逻辑完全一样。5.1 环境准备和最小示例第一步先准备好 Python 环境和一个能跑的扩散模型推理脚本。常见的做法是基于 Hugging Face 生态做最小验证。注意Celeris-1 未提供安装命令时下面的示例结构只为了说明流程不保证每个模型都适用。实际使用时以你选择的模型仓库说明为准。# 建议创建一个干净环境 python -m venv venv source venv/bin/activate pip install torch transformers diffusers接着写一个最简单的生成脚本观察 diffusion LM 是否能完成续写任务。这里用伪代码说明结构import torch from transformers import AutoTokenizer # 这里假设你已经从模型的仓库找到了对应的 pipeline 类 from some_diffusion_lm_pipeline import DiffusionLMPipeline model_id your-local-diffusion-lm pipe DiffusionLMPipeline.from_pretrained(model_id, torch_dtypetorch.float16) pipe.to(cuda) prompt 写一段关于城市清晨的短文字 output pipe.generate( prompt, max_new_tokens128, num_inference_steps8, # 扩散模型的关键参数 temperature0.8 ) print(output)这里最重要的不是代码本身而是你要意识到num_inference_steps和max_new_tokens是扩散式语言模型和自回归模型差异最明显的两个参数。前者控制去噪轮数后者控制输出长度。它们直接决定生成速度和质量的平衡。5.2 单条验证与观测点首次跑通后不要立刻测速度。先看内容质量。建议观察三个点输出是否连贯。如果一句话内部前后矛盾说明去噪步数太少或模型对长距离关系建模不足。多个候选是否多样。扩散模型如果温度/随机性设置不合理可能产出的候选高度雷同。是否出现拼接痕迹。扩散模型有时会生成局部通顺但整体主题漂移的文本这比单个词错误更隐蔽。如果质量明显不行先加采样步数比如num_inference_steps16或32看是否改善。如果加步数后质量变好说明速度和质量之间存在一个需要你权衡的区间。5.3 批量测试和 Benchmark 方法等单条输出可以稳定复现再进入批量测试。批量测试的核心是搞清“Celeris-1 式的吞吐数字”是怎么来的。建议按这个步骤执行准备 50 条长短不一的 prompt 数据集。分别用小批大小1、4、16跑一遍记录总耗时和输出 token 数。计算 output tokens/s 输出总 token 数 / 总耗时。同时记录每条样本的生成延迟、最大显存占用。每种配置重复三次以上取中位数或平均值。这样得出的数字比项目标题里的单一 benchmark 更能反映你的生产环境。5.4 结果质量评估速度指标必须配合质量评估一起看。最简单的做法是准备 20 条测试样本分别记录语法正确性。语义一致性。是否包含幻觉信息。是否满足任务约束。是否产生重复或死循环。如果模型为了跑得快把所有输出都变成了固定的几句话那再高的 tokens/s 也没有意义。质量评估这部分不能省因为它决定了这套方案到底能不能被真实业务使用。5.5 一个排查思路如果在验证过程中发现问题可以考虑下面的排查链路。先看现象输出质量差、速度慢、显存溢出还是结果为空再查输入prompt 格式是否匹配模型训练时的格式上下文长度是否超限再看环境PyTorch 版本、CUDA 版本、GPU 型号、依赖库是否兼容再调参数采样步数、batch size、温度、top-p、输出长度是否设置合理最后看模型原始代码仓库里的 issue 或教程里是否标注了这类模型的已知限制对于扩散式 LLM我最常遇到的问题就是采样步数设置太少导致生成质量崩溃而大家第一反应往往是“模型不行”。实际上只要把步数从 4 提到 10质量可能立刻恢复正常。所以遇到质量问题时先别急着换模型把采样参数过一遍。6. 回到经验决定长期价值的是流程不是峰值每次看到一个新 benchmark 出来我都提醒自己先沉住气。2,082 output tokens/s 确实是个让人印象深刻的数字但真正决定一个模型能不能被你长期使用的从来不是这个峰值而是它在你的数据、你的长度区间、你的并发模型、你的质量校验规则下能不能稳定跑出可用结果。在工程里我们需要的不是“最高能跑多快”而是“在最差情况下能不能接受”。对一个 diffusion LLM你要验证的是它在长文本、多轮对话、工具调用、结构化输出这些真实负载下的表现而不是一个专门为了刷吞吐准备的测试环境。Celeris-1 让我更在意的不是它跑多快而是它把“扩散式语言模型”这件事推进到了一个可以严肃评价的位置。你可以不喜欢它也可以认为它不够成熟但你必须承认生成式模型的架构不再只有“自回归”一条路。下一步如果你对这类模型感兴趣我建议别停留在看 benchmark 的层面。去找一个能跑的扩散语言模型跑通单条样例试着把采样步数改小或改大亲手观察输出质量的变化。等你看懂了“步数、长度、吞吐、质量”这四者之间的拉扯再回来看 2082 这个数字你会得到一个更清晰的判断它不是神话也不该被无视而是一个新范式开始走向工程化的信号。真正值得长期关注的是扩散式 LLM 能不能在不牺牲可控性的前提下把并行生成的优势变成持续稳定可复用的服务能力。如果能那么未来很多高吞吐应用的第一选择可能就不再是那个我们已经用了好几年的自回归引擎了。