从自回归到扩散式LLM：Celeris-1如何实现2082 tokens/s

如果你的工作流已经习惯了 ChatGPT 逐字输出时的打字动画那你可能已经默认了一件事大模型生成文本本质上是一个字一个字往外蹦。但 Celeris-1 这个新模型恰好把这种默认认知撬开了一道口子——它以 2,082 output tokens/s 的推理成绩进入视野。这个数字意味着什么它不只是更快一点的问题而是生成方式本身发生了改变它不再走自回归逐 token 生成的老路而是把扩散模型diffusion model的思想搬进了大语言模型。扩散模型在图像生成领域已经家喻户晓Stable Diffusion、Midjourney 背后的核心技术都是它。但把扩散模型用在语言模型上过去一直面临离散 token 空间的巨大挑战。Celeris-1 的价值在于它把这条路线真正推进到了可以做性能评测的阶段。读完这篇文章你会理解扩散式 LLM 的核心原理、它为什么能跑出远超传统架构的速度以及在实际工程中应该怎么看待这类模型——哪些场景值得用哪些场景暂时别碰。1. Celeris-1 是什么把扩散模型搬进 LLM 的新尝试先解释这个标题里的三个关键词。Celeris 是模型名从词根看有快速的含义这也和它的 benchmark 定位一致。diffusion LLM 指的不是给 LLM 加了个图像生成模块而是指模型本身的文本生成机制采用扩散模型架构。2,082 output tokens/s 则是一个推理速度指标表示每秒可以输出 2082 个 token。如果对这个数字没有概念可以对比一下主流大模型的推理速度。在消费级显卡上运行 7B 到 13B 的开源模型常见速度在每秒 20 到 80 个 token 之间即便在 A100/H100 上用 vLLM、TensorRT-LLM 做了工程优化单条请求的 decode 速度也很少超过每秒几百 token。2,082 tokens/s 几乎是传统自回归模型一个数量级以上的提升。为什么传统模型很难达到这个速度根本原因在于自回归autoregressive的串行生成方式。GPT 系列模型生成文本时每生成一个 token都要把之前生成的所有 token 重新输入模型计算一次。虽然 KV Cache 等技术缓存了历史计算结果但一个 token 一个 token 地产生这个串行链条无法被打破。输出 100 个 token就至少需要 100 次前向推理。Celeris-1 这类扩散式 LLM 的思路是与其一个词一个词地挤牙膏不如先并行生成一整段候选 token再通过多轮去噪逐步修正。这种先整体生成、再迭代优化的方式天然具备并行计算的优势也让高吞吐推理成为可能。因此2082 tokens/s 这个数字背后本质是架构层面的变化而不是单纯靠工程优化堆出来的结果。当然这里要强调一句目前关于 Celeris-1 的公开技术细节仍然有限本文的分析更多是基于扩散式 LLM这个技术方向做推演。对于它具体用了多少参数、基于什么训练框架、评测环境如何还需要等更多官方信息。但即便只看 benchmark 数字扩散模型 大语言模型这条路已经值得每个关注 LLM 推理效率的开发者认真研究。2. 扩散模型基础从图像生成到语言生成的跨越要理解 diffusion LLM先要理解扩散模型本身。扩散模型的核心思想可以用一句话概括先学会把数据变成噪声再学会从噪声还原数据。2.1 前向过程与反向过程扩散模型包含两个方向的过程。前向过程forward process是逐步往数据里添加高斯噪声经过足够多步之后原始数据完全变成随机噪声。反向过程reverse process则是训练一个神经网络学会逐步去掉噪声从纯噪声中还原出原始数据。在图像生成中Stable Diffusion 把这个过程从像素空间搬到了潜空间latent space通过 VAE 将图像编码成低维潜变量再在潜空间里做扩散和去噪最后用解码器还原成图像。这样做的好处是计算量大幅降低生成质量也更高。这也是为什么 Stable Diffusion 能在消费级显卡上跑起来的原因。2.2 从连续空间到离散 token 空间的挑战图像是连续数据像素值可以表示为浮点数加噪、去噪都很自然。但语言是离散数据——一个 token 是词表中的一个整数索引不存在半个 token这种中间状态。因此把扩散模型从图像搬到语言第一个要解决的问题就是如何在离散空间里定义加噪和去噪。主流做法大致分两类。一类是把 token 映射到连续向量空间embedding在连续空间里做扩散最后再通过某种方式映射回离散 token另一类是直接在离散空间定义前向过程例如随机替换 token 为掩码或噪声 token再训练模型逐步还原。Celeris-1 具体采用哪种方式目前公开信息还不明确但无论如何它都必须解决离散 token 的扩散建模问题。2.3 和 Flow Matching 的关系近两年频繁出现在论文里的 Flow Matching流匹配可以理解为扩散模型的广义版本。扩散模型通常依赖一个预设的噪声调度过程而 Flow Matching 更灵活它直接学习从噪声分布到数据分布的任意概率路径。两者在生成模型中的应用边界越来越模糊很多新模型已经在混合使用这些思路。理解扩散模型的基本原理再看 Flow Matching 就比较容易上手。从图像到语言的迁移本质上是把连续空间的去噪换成离散空间的去噪但核心范式——先整体生成再迭代修正——没有变。正是这种范式让模型有机会摆脱自回归的串行锁。3. 自回归 LLM 为什么慢逐 Token 生成的效率困境在分析扩散式 LLM 的优势之前有必要把传统自回归模型的瓶颈讲透。很多人以为 LLM 慢是因为模型太大、显存不够这只是表面原因。更深层的原因在于生成流程本身就是串行的。3.1 串行生成的数学约束自回归模型的条件概率可以写成P(y1, y2, ..., yn) P(y1) × P(y2 | y1) × P(y3 | y1, y2) × ... × P(yn | y1, ..., yn-1)也就是说生成第 n 个 token 之前必须知道前 n-1 个 token 是什么。这在逻辑上就决定了它无法像矩阵乘法那样做大规模并行。即便你用一万张 GPU 同时推理第 100 个 token 也得等第 99 个 token 算完。3.2 工程优化手段及其天花板针对这个串行瓶颈工程界想了很多办法。KV Cache 缓存了历史 token 的 Key 和 Value避免了重复计算这是当前所有主流推理框架的标配。投机解码Speculative Decoding用一个小模型先草拟多个 token再用大模型一次验证如果草拟对了就一次生成多个 token相当于猜对了就加速。批处理Batching则把多个请求拼在一起提高 GPU 利用率。但这些手段都没有改变模型本身每步只生成一个 token的约束。投机解码的加速比取决于小模型和大模型的接受率通常只能带来 1.5 到 3 倍的提升批处理提升的是吞吐量单条请求的延迟没有实质改善。对于需要低延迟的交互式应用自回归架构的天花板非常明显。3.3 为什么 2000 tokens/s 很难靠优化堆出来从 20 tokens/s 到 2000 tokens/s是 100 倍的差距。这个量级的变化单靠工程优化几乎不可能实现。它需要改变的是生成路径本身不再是一个 token 一个 token 地算而是一次性生成一段候选再通过少数几轮迭代修正到可接受的质量。这就是扩散式 LLM 的核心逻辑。下表可以一目了然地对比两种架构的差异对比维度自回归 LLM扩散式 LLM生成方式逐个 token 串行生成整段 token 并行生成计算瓶颈串行依赖不可打破并行度高适合 GPU 批量计算每轮迭代生成 1 个 token生成全部 token 并修正推理延迟随输出长度线性增长受去噪迭代轮数控制工程优化空间KV Cache、投机解码、批处理并行解码、少步采样、蒸馏主要风险速度慢但生成稳定生成质量可控性仍需验证4. 扩散式 LLM 如何实现一次生成整段输出理解了自回归的瓶颈接下来看扩散式 LLM 具体怎么做。前面提到扩散模型生成图像时是从一张纯噪声图开始逐步去噪得到最终图像。语言模型做类似的事情时可以这样理解它的流程。4.1 整体流程拆解第一步初始化一个长度为 L 的噪声 token 序列。这个长度 L 就是模型预测的输出长度可以由用户指定也可以由模型在生成过程中动态确定。第二步把这段噪声序列输入扩散模型进行第一轮去噪。此时模型会给出一个初步猜测的完整 token 序列。由于是第一次猜测序列里可能有很多不合理的地方比如语法不通、语义混乱。第三步重复去噪迭代。每一轮迭代模型都会根据当前的 token 序列重新预测一个更合理的完整序列。这个预测是全序列的而不是单点的——这是关键区别。第四步经过预设的迭代轮数比如 4 步、8 步、16 步得到最终输出。从这个流程可以看出扩散式 LLM 的单次推理是高度并行的。一次前向计算同时预测了输出序列中所有位置的 tokenGPU 的并行计算能力得到了充分利用。4.2 为什么能跑出高 tokens/s2082 output tokens/s 这个数字可以从两个层面来解释。第一个层面是一次生成多个 token。如果模型一次前向计算生成 256 个 token且硬件上完成这次计算只需要很短时间那么等价于每秒输出大量 token。第二个层面是去噪轮数少。扩散模型从纯噪声到最终结果通常需要很多步迭代但通过训练阶段的优化比如加入速度蒸馏、步数蒸馏可以让推理阶段只用少数几步就达到可用质量。两步迭代和二十步迭代速度差十倍。因此一个扩散式 LLM 如果设计得好理论上可以在保持输出质量的前提下用极少步数完成生成。而传统自回归模型无论如何优化每一步只能产生一个新 token且这一步的计算量和序列长度相关。4.3 需要留意的代价不过速度优势往往伴随代价。扩散式 LLM 目前最需要关注的问题有三个一是生成质量是否真正达到生产可用水平特别是长文本的连贯性二是可控性自回归模型可以通过 prompt 精确控制下一个 token 的分布扩散模型这种整体生成再修正的机制控制粒度会有所不同三是停止条件的处理自回归模型生成到 EOS token 就自然停止扩散模型则需要额外机制判断输出长度。这些都会影响实际工程接入时的复杂度不能只看速度一个维度。5. 用代码理解自回归生成与扩散式并行生成理论讲完用代码来具象化两种架构的差异。以下不是 Celeris-1 的真实源码而是帮助理解架构逻辑的最小伪代码。5.1 示例一自回归生成伪代码# 文件路径examples/autoregressive_generate.py # 自回归生成的逻辑串行逐 token 预测 import torch def autoregressive_generate(model, tokenizer, prompt, max_new_tokens64): # 将 prompt 编码为输入 token input_ids tokenizer.encode(prompt, return_tensorspt) for _ in range(max_new_tokens): # 前向推理输入全部历史 token预测下一个 token 的分布 logits model(input_ids).logits # 取最后一个位置的 logits作为下一个 token 的概率分布 next_token_logits logits[:, -1, :] # 采样获得下一个 token next_token_id torch.argmax(next_token_logits, dim-1) # 把新 token 拼到输入序列尾部 input_ids torch.cat([input_ids, next_token_id.unsqueeze(0)], dim-1) # 如果生成 EOS token提前终止 if next_token_id.item() tokenizer.eos_token_id: break return input_ids这段代码的核心是那个 for 循环。每一次循环只生成一个 token而且下一次循环的输入依赖上一次循环的输出。循环次数等于生成的 token 数这个串行依赖就是自回归模型的本质约束。5.2 示例二扩散式并行生成伪代码# 文件路径examples/diffusion_generate.py # 扩散式生成的逻辑并行生成整段候选 token再通过去噪迭代修正 import torch def diffusion_generate(model, prompt_embedding, output_length128, denoise_steps8): # 初始化生成一段与目标长度相同的噪声 token序列 # 实际实现中噪声可以作用在 embedding 空间或离散 token 空间 noise torch.randn(output_length, model.hidden_size) # 将 prompt 的语义信息注入初始噪声作为生成条件 current_latent model.inject_condition(noise, prompt_embedding) for step in range(denoise_steps): # 每轮推理都同时处理整个序列的所有位置 current_latent model.denoise(current_latent, step) # 将最终的连续表示映射为离散 token 序列 output_ids model.project_to_tokens(current_latent) return output_ids对比两段代码差异非常直观。自回归生成是一层层垒砖每一块砖都要等前一块就位扩散生成是先搭一个粗糙的骨架再整体精修每一步操作的都是完整序列。5.3 示例三tokens/s 基准测试的思路如果要自己评测一个模型的输出速度可以参考下面这个脚本的核心逻辑。它计算的是纯生成阶段的速度不包含 prompt 处理时间。# 文件路径examples/benchmark_tokens_per_second.py # 简单测速脚本统计纯生成阶段的 tokens 每秒输出量 import time def benchmark_tokens_per_second(generate_fn, prompt, max_new_tokens512): # 预热避免首次推理的 CUDA kernel 加载影响数据 generate_fn(prompt, max_new_tokens16) # 正式计时 start time.perf_counter() output generate_fn(prompt, max_new_tokensmax_new_tokens) elapsed time.perf_counter() - start generated_tokens len(output) - len(prompt) tokens_per_second generated_tokens / elapsed print(f生成 token 数: {generated_tokens}) print(f耗时: {elapsed:.2f}s) print(f吞吐: {tokens_per_second:.1f} tokens/s) return tokens_per_second在进行这类测速时有几点值得注意硬件型号要记录清楚不同显卡差异很大batch size 会影响吞吐量是否开启 KV Cache、是否使用量化、输入输出的 tokenizer 差异都会影响最终数字。所以看到别人发布的 benchmark 数字先问清楚测试环境再对比才有意义。6. 2082 tokens/s 的正确解读方式回到标题中的核心数字2,082 output tokens/s。这个数字看起来很亮眼但解读时需要保持理性。对于技术博客读者来说掌握 benchmark 的正确打开方式比记住一个数字更有价值。6.1 数据需要结合测试条件任何一个 tokens/s 数字都依赖具体条件GPU 型号、显存大小、batch size、精度FP16/BF16/INT8、输入序列长度、输出序列长度、是否使用投机解码、是否使用量化。同一个模型在不同条件下测出的速度可能相差数倍。2,082 tokens/s 这个成绩对应的具体测试环境目前公开信息并不完整。在没有确认测试条件之前最稳妥的判断是这个数字证明了扩散式 LLM 在推理速度上的巨大潜力但不宜简单等同于所有场景下都能跑到这个速度。6.2 峰值吞吐与实际体感的差异还有一个容易混淆的点tokens/s 是吞吐指标还是延迟指标在批处理场景下框架可以同时处理多个请求用总 token 数除以总时间得到的是系统吞吐而单条请求从发出到收到完整响应的延迟是另一个指标。一个系统可以做到很高的吞吐但单个请求的响应延迟未必很低——这取决于它是否采用了批处理、请求排队等策略。因此如果这个 2082 tokens/s 是在大 batch 下测得的它更多代表的是系统的吞吐能力而不是单请求的交互式体验。后者对于对话类应用更关键。6.3 token 粒度的理解还要注意 token 和字的区别。在英文场景下一个 token 大约对应 3 到 4 个字符在中英文混合场景下一个汉字可能对应 1 到 2 个 token。所以每秒 2082 个 token换算成每秒输出多少个汉字或单词会因 tokenizer 而异。这提醒我们做跨模型对比时要确保使用的是同一个 tokenizer 体系否则数字没有可比性。7. 扩散式 LLM 的适用场景与边界对于工程团队来说真正有价值的问题是扩散式 LLM 适合我用吗这个问题要分场景回答因为速度快不等于所有场景都适用。7.1 适合的高吞吐场景如果你在做离线批处理、大规模文档摘要、知识库问答的离线索引生成、批量邮件撰写、代码批量注释生成或者任何不要求极低首 token 延迟但要求单位时间产出尽量多的任务扩散式 LLM 的高吞吐特性就非常有价值。它能用更少的 GPU 数量支撑更大的任务量直接降低推理成本。在 RAG 场景中文档解析和向量化之前的文本清洗、抽取、摘要往往需要调用 LLM 处理大量文本。这个环节通常可以异步执行不要求交互式响应非常适合高吞吐模型。7.2 暂时不适合的场景对于实时对话、流式输出、需要精确控制生成长度的场景扩散式 LLM 还需要观察。传统自回归模型天然支持流式输出——生成一个 token 就推送一个用户可以边看边等。扩散模型的整段生成再修正机制意味着它可能不适合做逐字流式输出或者需要额外的工程手段模拟流式效果。另外在需要强随机性和多样性的任务上扩散模型的可控性与采样机制和自回归模型不同。如果你依赖 temperature、top_p 等参数精细调节输出风格扩散式 LLM 的对应控制方式需要重新学习。7.3 对基础设施的含义从基础设施角度看扩散式 LLM 的高吞吐特性意味着推理引擎的优化重点会从减少单 token 延迟转向减少去噪迭代轮数和提高 batch 并行度。这可能带来一个变化未来 LLM 推理框架的 benchmark 指标除了传统的 tokens/s还会引入有效输出率这类新指标——即生成的 token 中有多少是最终用户真正看到的。因为扩散模型在迭代过程中产生的中间 token 不计入最终输出计算有效输出率比只看原始吞吐更合理。8. 常见误区与工程建议面对一个新的技术方向最容易犯的错误是用旧框架去理解新事物。这里整理几个最常见的误区以及接入这类模型时的工程建议。8.1 常见误区常见误区真实情况建议速度快体验好高吞吐不等于低延迟交互式体验还需看首 token 延迟和流式支持根据场景选指标别只看一个数扩散 LLM 会取代自回归 LLM两种架构各有优势短期内互补共存把模型当作工具箱里的不同工具tokens/s 高就是更强生成质量、可控性、上下文长度、幻觉率都是重要维度做综合评测别只看推理速度只用 8 步去噪质量一定差通过训练阶段优化少步推理质量可能接近多步效果跑具体任务验证别凭直觉下结论扩散 LLM 像 Stable Diffusion语言扩散面向离散 token 空间技术难度完全不同用图像扩散做类比理解别做技术等同8.2 工程接入建议第一评测先行。不要因为 benchmark 好看就立刻替换现有模型。先在你自己最有代表性的任务集上做评估既测质量指标准确率、BLEU、人工评分也测性能指标吞吐、延迟、GPU 利用率同一套数据跑旧模型和新模型用数据说话。第二设计缓存和批处理策略。扩散式 LLM 的高吞吐能力依赖并行度因此单条请求调用可能浪费算力。更合理的做法是把请求攒成 batch 再统一处理。在峰值不高但并发持续的场景下配合请求队列和异步架构效果更好。第三灰度替换。如果要在生产环境引入扩散式 LLM建议先选择一个非核心、对延迟不敏感、允许异步处理的任务做灰度。同时保留旧模型的切换开关一旦出现质量问题可以快速回滚。第四监控不能省。除了常规的推理延迟、吞吐、GPU 利用率还要额外监控生成质量漂移。扩散模型的生成行为与自回归模型不同可能在特定 prompt 模式下出现意想不到的退化需要建立样本级的质量抽检机制。8.3 给不同角色的建议算法工程师可以把扩散式 LLM 当作一个新的研究方向关注它如何处理长文本一致性、如何动态终止生成、如何与 RLHF 对齐。后端/平台工程师关注的是推理框架的适配。新架构需要新的 Serving 层设计传统的 KV Cache 优化经验可能需要重新调整。架构师/技术决策者建议保持关注但不要急于把核心业务迁过去。等模型成熟度提高、社区生态完善之后再评估迁移成本。9. 总结与后续研究方向Celeris-1 的 2,082 output tokens/s 让我们看到了大语言模型推理的一条新路径从自回归的逐 token 串行生成转向扩散式的并行生成再修正。这个方向如果持续成熟对推理成本、GPU 利用率和批处理场景的收益都会非常显著。理解这个技术方向重点是抓住三点扩散模型先整体生成、再迭代去噪的核心范式离散 token 空间建模的技术挑战以及 benchmark 数字必须结合测试环境解读的判断方法。对于正在构建高吞吐 LLM 应用的团队可以在非核心场景小范围试验扩散式 LLM用一套完整的评测体系来验证它的实际价值。后续值得继续关注的方向包括扩散式 LLM 在长文本生成中的一致性表现、与 RLHF 等对齐技术的兼容性、推理框架和 Serving 工具的生态支持以及它和 Flow Matching 技术的融合趋势。技术在快速演进保持对架构层面的敏感度比追逐某一两个 benchmark 数字更重要。当你的应用场景需要大规模批量生成时不妨重新审视这个问题如果模型不再逐字生成你的系统架构应该做出什么改变