扩散语言模型为何能实现每秒2000+ tokens？并行去噪与Flow Matching原理拆解

最近在关注 LLM 推理优化方向时看到 Celeris-1 这个模型的一个基准数据输出吞吐达到了 2,082 output tokens/s。这个数字放在传统自回归大模型里是相当高的很多数十亿甚至上百亿参数的自回归模型在单卡环境下输出速度通常只有几十到几百 tokens/s。Celeris-1 的特别之处在于它采用了 diffusion扩散架构而不是我们熟悉的 next token prediction 范式。这引出了一个问题扩散模型不是主要在图像生成领域吗怎么跟语言模型结合还能跑这么快这篇文章会围绕 diffusion LLM 展开先讲清楚它和传统自回归 LLM 的核心差异再拆解 2,082 output tokens/s 这个 benchmark 指标到底在测什么、受什么因素影响接着解释扩散语言模型背后的 Flow Matching 与并行去噪原理最后给出你自己动手测量 token 吞吐的脚本和常见坑点。无论你是刚接触大模型的新手还是已经在做模型推理优化的工程师这篇文章都可以帮你把扩散 LLM 为什么快这件事看明白。1. diffusion LLM 是什么为什么值得关注1.1 从 Celeris-1 的 benchmark 说起Celeris-1 是一个采用 diffusion 架构的语言模型公开基准测试中的输出速度达到了每秒 2,082 个 token。单纯看这个数字可能没有概念以中文为例一个 token 大约是半个到一个字2,082 tokens/s 意味着每秒能生成约 2000 个字几乎是一口气输出一篇文章的量级。传统自回归 LLM 在相同硬件条件下受限于逐 token 串行解码的计算方式很难达到这个量级。这里要说明一点我不掌握 Celeris-1 的完整官方评测环境比如具体 GPU 型号、batch size、输入输出长度、量化精度等所以下面所有分析都基于公开 benchmark 信息来讨论这个指标意味着什么而不是替官方给出完整评测报告。实际复现或横向对比时一定要以官方发布的模型卡和评测文档为准。1.2 diffusion 模型如何迁移到语言模型提到 diffusion很多人第一反应是 Stable Diffusion、Midjourney 这类图像生成工具。图像扩散模型的基本思想是前向过程不断往图片上添加高斯噪声直到图片变成纯噪声反向过程训练一个神经网络学会一步步去噪就能从随机噪声还原出目标图片。语言模型要借用这套思路难点在于文本是离散的 token 序列不是连续像素。扩散到文本上通常不是加高斯噪声而是对 token 做随机掩码、替换或者把 token 映射到连续向量空间后再加噪声。训练目标也从预测下一个 token变成恢复被破坏的 token 序列。Celeris-1 这类模型正是沿着这个方向做的。它不再机械地一个词一个词往后生成而是先生成一个随机噪声序列然后通过多轮去噪让整个序列逐步逼近目标文本。这种全序列同时生成的方式天然具备并行潜力也是它在输出吞吐上领先的核心原因。1.3 为什么输出速度这么重要大模型落地到真实业务时输出速度直接决定成本和体验。在线对话场景用户不希望等太久才看到回答离线批处理场景比如批量总结、批量改写、内容审核输出吞吐决定了单位时间内能处理多少条任务也就决定了 GPU 成本。另外近两年 LLM Agent 应用兴起Agent 在推理过程中会反复调用模型思考、调用工具、读取结果、继续生成。一次 Agent 任务消耗的 tokens 可能是普通问答的几十倍。如果模型吞吐上不去Agent 的完整运行时间会肉眼可见地变长。这也是为什么什么任务消耗的 tokens 大会成为高频关注点而高吞吐模型恰好能在这些场景下释放价值。2. diffusion LLM 与传统自回归 LLM 的核心区别2.1 解码方式串行生成 vs 并行去噪自回归 LLM 的生成过程可以概括为输入 prompt计算第一个 token 的概率分布。采样得到 token1把 token1 拼到输入末尾再预测 token2。重复上述过程直到出现结束符或达到最大长度。每一步都必须等待上一步的输出所以是严格的串行。虽然 KV Cache、投机采样、批量推理等技术可以缓解速度问题但算法本质仍然是一步一步走。diffusion LLM 完全不同。它一开始就有一个和目标序列等长的噪声序列或者掩码序列去噪网络在每一轮同时更新序列中所有位置。整个过程更像先画轮廓再逐步补细节而不是从左往右写字。由于每一轮所有位置可以并行计算GPU 的利用率显著提升最终单位时间内产出的 token 数量自然更多。2.2 训练目标next token prediction vs denoising自回归语言模型的训练目标非常统一给定前文最大化下一个 token 的概率。这个目标让模型天然适合对话、续写、代码生成这类任务因为它学到的就是人类语言从左到右的生成规律。diffusion LLM 的训练目标则是去噪。训练时把一段正常文本按照某种噪声调度破坏掉一部分信息然后让模型学着还原。常见的噪声形式包括把某些 token 替换成 [MASK]把某些 token 随机替换成其他 token在连续表示空间上添加扰动。模型最终学会的是知道哪些位置是噪声、哪些位置是可靠的、应该把噪声位置修正成什么。这种目标和自回归相比更像是全局理解而非局部预测。2.3 性能差异的根源两者性能差异的根源在于计算模式自回归 LLM 每一步都要重新读取一次模型权重即使有 KV Cache生成阶段也主要受显存带宽限制。模型越大权重越多单位时间能生成的 token 越少。diffusion LLM 在常数轮去噪中并行更新所有 token。总计算量不一定更低但计算过程更容易被 GPU 的并行能力覆盖尤其在短输出场景下吞吐优势非常明显。当然diffusion LLM 也有自己的代价比如去噪步数设置不当可能影响文本质量采样过程可能需要调试温度、步数等超参数。理解这些差异才能在实际选型时判断快是否值得质量损失是否可以接受。3. 读懂 benchmarkoutput tokens/s 到底在测什么3.1 token 与 output tokens 的概念token 是语言模型处理文本的基本单元。它不一定等于一个词或一个字可能是子词、字符或者词根。比如英文单词 playing 可能被拆成 play 和 ing 两个 token。中文一般一个汉字可能对应一到两个 token具体取决于分词器和词表。output tokens/s 指的是模型在生成阶段每秒输出的 token 数量。它比总 tokens/s更能反映生成速度因为输入部分prompt的处理是一次性的而输出部分是逐轮或逐批推进的。3.2 吞吐与延迟要分开看聊生成速度时有两个容易混淆的指标延迟Latency从发出请求到第一个 token 出现的时间或者到完整回复结束的时间。吞吐Throughput单位时间内处理的 token 数量通常用 tokens/s 表示。2,082 output tokens/s 是吞吐指标。它回答的问题是如果持续请求系统每秒能稳定输出多少 token它不能直接回答用户感受到的第一个 token 要等多久。要全面评估一个模型的实际体验延迟和吞吐必须一起看。3.3 影响 tokens/s 的变量同一个模型在不同配置下输出吞吐可能差出好几倍。以下变量都会影响最终数值GPU 型号与显存带宽内存带宽越高权重读取越快对自回归模型影响尤为明显。精度FP16、BF16、FP32、INT8、INT4 的推理速度和显存占用不同。FP16 和 BF16 是当前大模型推理最常见的精度。batch size批量越大GPU 利用率越高但单请求延迟也会上升。输入长度与输出长度输入过长时prefill 阶段耗时增加输出过长时生成阶段耗时占比更大。采样参数比如是否使用 beam search、top-p、temperature以及并行去噪的步数。是否使用量化、投机采样、并行解码等优化手段。所以在看任何模型宣称的 tokens/s 时第一反应应该是它在什么硬件、什么精度、什么 batch size 下测出来的同样的数字配置不同含金量完全不同。4. 拆解 Celeris-1 的 2,082 output tokens/s4.1 一个 benchmark 数字不能说明全部Celeris-1 能跑到 2,082 output tokens/s说明它在公开测试环境下确实展示了很强的输出吞吐能力。但一个数字由三部分决定模型架构、运行环境、评测方法。如果只记住了数字忽略了后两者很容易在横向对比时得出错误结论。另外benchmark 通常会在理想条件下进行比如输入输出长度固定、batch 尺寸经过调优、GPU 处于稳定状态。这在工程上是合法且必要的但生产环境往往更复杂请求长短不一、并发波动、显存碎片化实际吞吐大概率会低于 benchmark。理解benchmark 是上限参考不是线上承诺是做技术选型的基本素养。4.2 这个吞吐可以支撑什么场景假设我们把 2,082 tokens/s 放到真实场景里看如果一次回答平均 300 个 token那么单进程每秒可以完成约 7 个回答。如果部署成多副本服务再配套并发队列完全足够支撑中等规模的实时对话应用。对于批量离线任务比如每天几十万篇文档的摘要生成高吞吐意味着可以显著缩减处理窗口、降低 GPU 资源占用。当然实际部署还要考虑显存、请求排队、网络开销等因素不能简单按线性外推。但至少可以说这个量级的吞吐对于高并发、短文本、大批量场景非常有吸引力。4.3 横向对比时注意什么如果你想拿 Celeris-1 和其他模型做对比建议固定以下条件相同 GPU 型号和数量相同精度FP16/BF16/量化方式相同输入长度和输出长度相同 batch size 或相同的并发压力相同采样参数。只改一个变量比如 batch size就能让两款模型的排名反过来。因此比较 benchmark 时不要只看宣传数字最好自己用统一脚本在统一环境下复测。5. 核心原理拆解Flow Matching 与并行去噪5.1 Flow Matching 和传统 Diffusion 的区别Flow Matching 是近两年很热门的生成模型训练框架。它和传统 diffusion 的目标类似都是学习一个从噪声分布到数据分布的映射但实现方式有差异。传统 diffusion 通常定义一条固定的加噪路径用离散的时间步逐步加噪、逐步去噪训练时预测噪声或预测原图/原文。Flow Matching 则更灵活它直接定义一个概率路径让样本从噪声分布平滑地流向目标数据分布训练目标是让网络学会这个流动过程中的速度场velocity field。两者的关系可以这样理解diffusion 是一种具体的生成范式Flow Matching 是训练和采样这个范式的一种更通用、更高效的方法。搜索材料里经常出现flowmatching 和 diffusion 区别的问题核心答案就是Flow Matching 不强制使用固定的噪声调度训练更稳定采样步数可以更少。对语言模型这种离散、结构化数据来说这种灵活性特别重要因为它可以用更少的去噪步骤达到可接受的质量从而进一步提升输出速度。5.2 离散文本如何进行扩散和去噪文本不能直接加高斯噪声所以离散 diffusion LLM 常用的做法是把原始 token 序列随机掩码掉一部分或者替换成随机 token训练一个 Transformer 网络输入被破坏的序列预测原始 token推理时从一个几乎全被掩码或全噪声的序列出发每轮让网络预测所有位置的 token 分布从分布中采样并更新部分位置逐步减少不确定位置最终得到完整文本。这个过程和图像扩散的从模糊到清晰非常相似只不过图像操作的是像素值语言模型操作的是 token 概率分布。因为每一步都是对整个序列的所有位置做预测计算可以充分并行这正是扩散 LLM 高吞吐的来源。5.3 去噪步数与文本质量的权衡并行去噪并不是没有代价。去噪步数太少可能文本不够连贯去噪步数太多计算量上升吞吐下降。实际使用中2,082 output tokens/s 大概率是在一个经过调优的步数配置下测出来的步数减少 20%速度可能提升 20%但文本质量可能明显下降。所以在工程上使用扩散 LLM 时需要像调温度参数一样去调去噪步数这个超参数。建议的做法是在一个固定测试集上分别用不同步数生成文本对比人工评审或自动指标比如流畅度、事实一致性、任务完成率找到质量可接受 速度最快的平衡点。6. 实操自己动手测量并对比 token 吞吐6.1 准备评估环境这一节我们用一个通用思路来测量输出吞吐。你不需要拥有 Celeris-1 的权重也可以用同样的方法评估任何能通过 API 或本地推理服务调用的模型。环境建议如下Python 3.10 或更高版本openai Python 库用于调用 OpenAI 兼容接口本地推理服务或远程 API 服务一张可用于测试的 GPU如果是本地推理。安装依赖pip install openai tiktoken查看 GPU 状态nvidia-smi如果你的推理服务跑在本地建议先确认 GPU 利用率、显存占用和驱动版本正常。6.2 用模拟脚本理解自回归与并行去噪的性能差距为了直观理解串行生成 vs 并行去噪的差异可以先运行下面这个模拟脚本。它不调用任何真实模型只是用随机词表模拟两种生成方式的执行过程重点看并行模式和串行模式在耗时上的差异。# 文件路径simulate_generation.py import random import time VOCAB_SIZE 1000 TOTAL_TOKENS 64 vocab [ftoken_{i} for i in range(VOCAB_SIZE)] def autoregessive_generate(): 模拟自回归每轮只能生成一个 token result [] start time.perf_counter() for _ in range(TOTAL_TOKENS): # 模拟计算一个 token 的时间 time.sleep(0.001) result.append(random.choice(vocab)) elapsed time.perf_counter() - start return result, elapsed def parallel_diffusion_generate(denoise_steps8): 模拟扩散式并行生成 每一轮同时更新所有位置的 token start time.perf_counter() # 初始化为全噪声序列 seq [None] * TOTAL_TOKENS for _ in range(denoise_steps): # 每轮并行预测所有位置模拟耗时约等于一轮计算 time.sleep(0.001) seq [random.choice(vocab) for _ in range(TOTAL_TOKENS)] elapsed time.perf_counter() - start return seq, elapsed _, ar_time autoregessive_generate() _, df_time parallel_diffusion_generate() ar_speed TOTAL_TOKENS / ar_time df_speed TOTAL_TOKENS / df_time print(f自回归模拟吞吐: {ar_speed:.2f} tokens/s) print(f扩散并行模拟吞吐: {df_speed:.2f} tokens/s) print(f并行去噪轮数: 8 轮)运行结果大致是自回归模拟吞吐: 1000.00 tokens/s 扩散并行模拟吞吐: 8000.00 tokens/s可以看到同样是生成 64 个 token自回归模拟需要 64 次循环扩散模拟只需要 8 次循环后者的吞吐量级明显更高。真实模型不会这么理想但它解释了一个核心逻辑扩散 LLM 的吞吐优势来自减少串行轮数增加每轮并行度。6.3 用真实 API 测量 output tokens/s下面这个脚本可以接入任意 OpenAI 兼容的服务比如本地部署的 vLLM、Ollama、LM Studio或者远程 API 服务。它会发送固定长度的请求统计完整回复的 token 数并计算输出吞吐。# 文件路径measure_throughput.py import time from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, # 按实际服务地址修改 api_keyEMPTY, # 本地服务通常不校验 key ) MODEL your-model-name # 修改为实际模型名称 def count_tokens(text: str) - int: # 如果没有 tiktoken可以粗略按字符数 / 2 估算 try: import tiktoken enc tiktoken.get_encoding(cl100k_base) return len(enc.encode(text)) except Exception: return max(1, len(text) // 2) prompt 请写一段关于大模型推理优化的详细说明。 start time.perf_counter() response client.chat.completions.create( modelMODEL, messages[ {role: user, content: prompt}, ], max_tokens512, temperature0.7, ) elapsed time.perf_counter() - start output_text response.choices[0].message.content output_tokens count_tokens(output_text) print(f输出文本长度(字符): {len(output_text)}) print(f估算输出 token 数: {output_tokens}) print(f总耗时: {elapsed:.3f} s) print(f估算输出吞吐: {output_tokens / elapsed:.2f} output tokens/s)这个脚本会忽略首次请求的排队和 prefill 时间但在连续压测时能大致反映系统吞吐。要得到更稳定的结果建议连续跑多次取第二次及之后的平均值第一次请求通常会有模型加载、预热等额外开销。6.4 压测时的注意事项先做 warmup正式测量前先发几条请求让显存、缓存、负载均衡进入稳定状态。固定输出长度输出长度不同吞吐差异很大。最好限制 max_tokens 并统计实际输出。控制 batch 与并发单进程串行测试得到的是单请求吞吐无法体现服务端批处理优势。如果要测服务上限需要用并发工具模拟多请求。记录环境信息GPU 型号、精度、batch size、并发数、输入 token 数都记录下来否则数据无法复用。7. 常见问题与排查思路在评估 diffusion LLM 或测量吞吐时比较容易遇到以下问题问题现象常见原因解决思路吞吐数字远低于预期没有做 warmup模型还在预热正式测试前多跑几条请求输出很快但文本质量差去噪步数设置太少增加去噪步数并在固定测试集上对比质量请求排队严重并发过高服务端 batch 处理能力不足降低并发或增加 GPU 数量显存不足模型权重、KV Cache、batch 过大降低 batch size、开启量化、使用更长上下文管理FP16/BF16/FP32 结果差异大精度选择影响速度和显存占用明确测试精度不要混用不同框架测出结果差异大推理引擎的算子优化水平不同统一推理框架后再对比首 token 延迟很高prefill 阶段处理长输入耗时优化输入长度、使用 prefix caching 等机制在实际排查中建议按顺序检查先确认 GPU 状态再确认请求是否真正打到目标模型然后检查日志里的平均耗时和分位数最后看是否被并发排队或限流影响。不要一上来就怀疑模型本身。8. 最佳实践与工程建议8.1 评测要规范化无论你是选型还是发技术分析建议建立一套固定的评测模板包含硬件环境GPU 型号、驱动、显存模型配置精度、量化方式、上下文长度请求配置输入长度、输出长度、温度、最大 token 数压测配置并发数、batch size、测试时长统计口径输出吞吐、首 token 延迟、单请求总延迟、成功率。有了这套模板不同时间、不同模型的评测结果才可对比排障时也能快速定位变量。8.2 部署 diffusion LLM 时的优先级如果你打算把 diffusion LLM 应用到生产建议重点关注三件事去噪步数调优。这是 diffusion 模型独有的超参数直接影响质量与速度的平衡。精度与显存规划。BF16/FP16 是常见选择如果显存紧张可以考虑量化但需要重新验证效果。批处理能力。diffusion LLM 的并行特性在 batch 场景下更占优势部署时优先设计好并发队列和 batch 聚合逻辑。8.3 安全与合规边界在评测或部署任何大模型时都要遵守最小权限原则只在获得授权的测试环境中进行压测不使用真实用户数据做未脱敏的评测涉及生产环境变更时先在测试集群验证涉及 API 调用的确认密钥、访问控制、限流策略配置正确。大模型输出速度再快也不能以牺牲数据安全和合规为代价。8.4 关注高 token 消耗场景如果你正在做 LLM Agent、RAG 知识库问答、长文档分析等应用一定要提前预估 token 消耗。Agent 场景中一次任务可能包含多轮模型调用工具返回内容也会被再次输入消耗的 tokens 远超普通问答。选择高吞吐模型或者对 prompt 长度做压缩、对历史会话做裁剪都是控制成本和延迟的有效手段。9. 总结与学习路线这篇文章从 Celeris-1 的 2,082 output tokens/s 出发梳理了 diffusion LLM 的核心概念。关键要点可以归纳为diffusion LLM 用并行去噪替代逐 token 自回归生成因此具备更高的输出吞吐2,082 output tokens/s 是一个需要结合硬件、精度、并发和步数来解读的 benchmark 数据Flow Matching 等训练框架进一步优化了扩散模型在文本生成上的效率评估任何模型时规范化的评测流程比单一数字更重要。下一步如果你想继续深入可以从这几个方向入手读 Flow Matching 和 diffusion LLM 相关的论文理解数学原理和采样算法用开源的 diffusion LLM 权重在本地跑通推理配合吞吐脚本实测对比自回归模型和扩散模型在相同硬件、相同任务上的质量与速度关注量化、投机采样、并行解码等推理优化技术它们可以叠加在模型之上进一步提升性能。对了动手实践是最重要的。你可以先把文章里的测量脚本跑一遍把自己手头模型的输出吞吐测出来记录硬件环境和参数。有了第一组真实数据再去看任何新的 benchmark 数字你都能更快判断它到底意味着什么。