ORL 与 dlmrt 开源：扩散语言模型推理冲至 2788 Token/s

2026 年 10 月 17 日，ORL（On-Policy Residual Learning）与配套推理引擎 dlmrt 开源，研究团队公布的最高成绩是：在单张 NVIDIA RTX 5090 上，结合 LLaDA-2.1-mini 和 NVFP4 量化，单请求生成速度达到 2788 Token/s。

这个数字的意义不只是“又刷新了一次跑分”。ORL 试图解决扩散语言模型最现实的矛盾：dLLM 理论上可以一次预测多个位置，但为了把错误修正回来，往往需要反复迭代去噪；迭代轮数一多，并行生成带来的优势就会被抵消。ORL 的做法，是让模型在自己真实生成的中间状态上学习“下一步应该如何修正”，再用专门的推理引擎把这些并行更新尽可能压缩到硬件擅长的执行路径中。

研究团队同时公布了 8 张 B200 上运行 DiffusionGemma 26B MoE 的 7708 Token/s，以及单张 B200 上最高 5046 Token/s 的结果。在 QwenDLM-4B 测试中，ORL 带来的端到端吞吐提升最高达到 6.9 倍；在单请求 H100 对比里，匹配准确率后，ORL 比 DFlash speculative decoding 快 1.74 倍。

但必须先把口径说清楚：这些数字都是 batch size 为 1 的单请求解码结果，不是并发服务下把多个用户请求相加后的总吞吐，也不是任意提示词、任意长度下都能稳定达到的平均速度。它更像是一次针对扩散式生成路径的性能上限展示，而不是直接可复制的线上 SLA。

dLLM 是什么，为什么能并行生成

扩散语言模型（diffusion language model，dLLM）是通过多轮掩码预测和迭代去噪生成文本的语言模型，而不是严格按从左到右逐个生成 Token。

传统自回归模型（AR）每次只生成一个下一个 Token。无论回答是 20 个 Token 还是 2000 个 Token，解码阶段都存在天然的串行依赖：第 101 个 Token 要等第 100 个 Token 生成后才能开始。GPU 最擅长的是大规模并行矩阵计算，但 AR 解码每一步往往只推进一个新位置，因此容易受到显存带宽和 KV Cache 访问的限制。

NVIDIA 对 LLM 推理的拆分也说明了这个问题：Prefill 阶段可以同时处理整段输入，计算密度较高；Decode 阶段则反复处理新生成的 Token，计算规模变小，内存访问占比上升，GPU 算力容易闲置。传统服务框架会用连续批处理、分块 Prefill 等方式提高利用率，但它们并没有改变“一个 Token 接一个 Token 生成”的基本约束。

扩散语言模型走的是另一条路径。它可以先为整段输出建立一个带有大量掩码的序列，然后同时预测多个位置，再根据置信度和上下文继续修正。对于代码补全、结构化文本、短答案和需要全局规划的任务，这种机制有一个直观优势：模型不必先决定开头，再被迫沿着开头一路写到结尾，而是可以在整段候选答案上反复调整。

问题也随之出现。并行预测的每个位置并不一定可靠，早期错误会污染后续上下文；如果模型通过更多轮去噪来弥补这些错误，单轮并行带来的速度收益就会被消耗。dLLM 的关键性能指标因此不是“每轮能预测多少 Token”，而是 在保持准确率的前提下，需要多少轮迭代，以及每轮迭代的硬件效率有多高。

ORL 的核心：训练模型适应自己的错误

ORL（On-Policy Residual Learning）是一种让扩散语言模型直接学习自身生成轨迹中残差修正的训练方法。

这里的“on-policy”可以理解为：训练时不只使用理想的、由教师模型提供的干净中间状态，而是让模型先按照自身的推理方式生成中间结果，再针对这些真实但可能有缺陷的状态学习修正。它和传统 teacher forcing 的差别在于，模型面对的是部署时真正会遇到的输入分布，而不是训练阶段经过人工整理的完美路径。

“Residual Learning”则对应另一层含义。模型不需要每次从头重新生成完整答案，而是学习当前序列还缺什么、哪里不一致、哪些位置应该被替换。对于扩散解码来说，这种残差更新可以减少无效的全量重算，让后续迭代更像是在已有草稿上做定向修改。

可以把两种模式简单类比成写作：AR 模型像是从第一个字开始逐字打字，每写一个字都要等上一个字完成；普通 dLLM 像是先把整段文章的骨架填出来，再反复润色；ORL 则是在模型已经写出的草稿上，专门训练它判断“这一轮哪些地方真的需要改”。如果每一轮都只改必要位置，扩散模型就有机会把并行能力转化为实际吞吐，而不是停留在算法结构上的理论优势。

这也是 ORL 与单纯增加采样步数的区别。增加迭代轮数通常能改善质量，却会线性或近似线性地增加推理成本；ORL 的目标是让每一轮更新携带更多有效信息，在较少迭代下达到接近甚至更好的结果。研究结果显示，这种训练策略在 QwenDLM、LLaDA-2.1-mini 和 DiffusionGemma 三类模型上都能改善并行解码效率。

dlmrt 不只是一个启动脚本

dlmrt 是面向扩散语言模型的专用推理引擎，负责将并行去噪、残差更新、量化计算和解码调度组合成硬件友好的执行流程。

这点很重要。把一个 dLLM 放进传统自回归推理框架，并不等于已经获得扩散模型的完整性能。AR 引擎通常围绕单 Token 解码、KV Cache 和连续批处理设计，而 dLLM 更关心整段序列的掩码状态、并行位置更新、不同置信度 Token 的调度，以及多轮迭代之间的中间状态复用。

dlmmrt 的价值就在于把算法改动落到执行层。它需要处理的不是简单的“模型前向运行几次”，而是如何减少不必要的内存读写、如何让并行 Token 的计算保持较高利用率，以及如何在不同去噪阶段选择合适的更新范围。对于扩散模型而言，推理引擎本身可能和训练方法同样重要：没有针对解码路径优化的 runtime，模型在纸面上能并行生成，实际运行时仍可能被调度和显存访问拖慢。

此次开源还包括模型、训练代码、评测流程和推理引擎。完整开放意味着外部开发者可以检查训练策略、复现实验设置，并将 ORL 迁移到其他 dLLM，而不必只依赖一份经过高度封装的测速脚本。对这个仍处于早期阶段的方向来说，可复现性比单个最高数字更重要。

与 AR、投机解码相比，速度到底处在什么位置

研究团队在 QwenDLM-4B 上给出了更有参考价值的单请求对照。以下数据来自相同准确率约束下的对比，其中“宽松”比较允许结果准确率在 ORL 结果上下浮动 0.5 个百分点；“严格”比较则要求保持自回归目标模型的准确率。

| 方法 | 解码吞吐 | 对比口径 | 说明 | |---|---:|---|---| | AR | 240 Token/s | 基线 | 传统自回归解码 | | EAGLE3 strict | 353 Token/s | 严格 | 保持目标准确率 | | EAGLE3 relaxed | 405 Token/s | 宽松 | 允许轻微准确率变化 | | DFlash strict | 573 Token/s | 严格 | 扩散式投机解码对照 | | DFlash relaxed | 746 Token/s | 宽松 | 放宽准确率约束 | | QwenDLM + ORL | 1298 Token/s | 接近或更高质量 | 使用 dlmrt 推理 |

在这组测试里，ORL 的 1298 Token/s 是 AR 基线 240 Token/s 的约 5.4 倍，是 DFlash relaxed 746 Token/s 的约 1.74 倍。这说明 ORL 的优势并不只来自“同时预测多个位置”，还来自训练和推理引擎共同减少了并行预测中的浪费。

不过，表格中的数字不能简单理解为 ORL 在所有任务上都比投机解码快。投机解码依赖一个较小的草稿模型和目标模型验证，适合已有成熟 AR 模型的生态；ORL 则要求模型本身采用扩散生成路径，并需要相应的训练和 runtime 支持。两者的工程迁移成本不同，不能只按最高 Token/s 排名。

另外，严格准确率比较里，研究团队也披露了一个值得关注的细节：ORL 结果在某些设置下比自回归目标准确率低 2.4 个百分点。宽松口径下速度优势更明显，但严格验证会牺牲部分吞吐或质量。对于代码生成、数学推理、工具调用这类错误成本较高的任务，准确率差异可能比速度差异更重要。

三组硬件数据，分别说明了什么

ORL 公布的主要峰值结果如下：

| 模型与硬件 | 量化 | 单请求最高吞吐 | 结果解读 | |---|---|---:|---| | LLaDA-2.1-mini + RTX 5090 | NVFP4 | 2788 Token/s | 面向消费级单卡的代表性结果 | | DiffusionGemma 26B MoE + 8× B200 | NVFP4 | 7708 Token/s | 大模型与多卡扩展结果 | | ORL 模型 + 单张 B200 | NVFP4 | 5046 Token/s | 数据中心 GPU 峰值结果 | | QwenDLM-4B | 视测试设置而定 | 最高约 6.9 倍端到端提升 | 综合 ORL 与 dlmrt 的收益 |

RTX 5090 的 2788 Token/s 最容易引发关注，因为它把扩散模型的高吞吐展示带到了消费级显卡上。但这里的“消费级”不等于“低门槛”：NVFP4 量化、特定模型结构、特定输出长度和 batch size 都会影响最终结果。一个模型在短回答上达到 2788 Token/s，并不意味着它处理长上下文、长链路推理或复杂代码时仍能维持同样速度。

8 张 B200 上的 7708 Token/s 也不能直接除以 8，再推断单卡性能。MoE 模型的专家路由、通信、并行策略和负载均衡都会改变多卡扩展效率。多卡场景中，瓶颈可能从单卡计算转移到 NVLink、跨卡同步或专家分发，峰值吞吐和扩展效率需要分开评估。

NVFP4 同样是解读结果时必须保留的前提。低比特量化可以降低显存占用和内存带宽压力，让推理更适合高吞吐执行，但它可能影响模型输出质量，尤其是在长链路推理、数字计算、代码细节和低频知识上。ORL 的速度结果说明“量化与扩散解码组合起来很有效”，但不能据此证明所有模型都能无损使用 NVFP4。

这对开发者意味着什么

ORL 最现实的价值，是把 dLLM 从“可以并行生成”推进到“在特定任务上值得部署”。

第一类受益者是本地模型运行者。对于短文本生成、代码补全、批量改写、结构化字段填充等任务，用户通常更在意首屏之后的持续输出速度。若生成内容本身比较短，单请求高吞吐可以明显降低等待时间，也能让消费级 GPU 承担更大的本地工作负载。

第二类是研究 dLLM 的开发者。ORL 同时开放训练、评测和 runtime，降低了复现和二次实验门槛。开发者可以进一步测试不同掩码策略、步数调度、量化方式和模型尺寸，而不是只在一个封闭推理服务上观察最终结果。

第三类是推理基础设施团队。传统 LLM 服务主要围绕 prefill、decode、KV Cache 和连续批处理建立。dLLM 引入后，需要重新考虑批处理单位：一次迭代处理多少位置、不同请求是否能共享去噪步骤、长输入的 Prefill 是否会阻塞正在迭代的请求，以及如何在低延迟和高吞吐之间调节。NVIDIA 对 chunking 的分析已经说明，较大的计算块可以降低首 Token 延迟，但可能拖慢其他请求的持续生成；扩散模型的多轮更新会让这种调度权衡更加复杂。

但对于普通线上产品，ORL 目前还不能直接替代成熟的 AR 模型。服务系统通常同时面对不同长度的输入、不同输出上限、多个并发用户和严格的尾延迟要求。单请求峰值很漂亮，却无法回答 P50、P95 延迟是多少，也无法说明 32、128 或 1024 并发下吞吐会如何变化。真正的生产评估至少需要同时报告首 Token 延迟、完整请求延迟、并发吞吐、显存占用、准确率和错误率。

仍然需要验证的几个问题

ORL 当前最强的证据是受控基准测试，而不是已经完成大规模生产验证。

第一，模型覆盖范围仍有限。研究结果涉及 QwenDLM、LLaDA-2.1-mini 和 DiffusionGemma，但不同 dLLM 的训练目标、词表、掩码机制和输出长度分布并不相同。ORL 在这三类模型上有效，是积极信号，却不能自动外推到所有扩散语言模型。

第二，质量评估需要更细。总体准确率接近并不代表所有能力都接近。代码任务可能更容易暴露局部 Token 错误，数学任务可能更依赖中间步骤一致性，长文本则可能出现前后指代和结构漂移。未来需要看到更完整的长上下文、工具调用、多轮对话和事实性测试。

第三，扩散生成的交互体验还需要重新设计。高 Token/s 适合完整答案快速生成，但 dLLM 的输出可能以多轮更新的方式出现。若系统必须等待若干轮去噪后才展示稳定文本，峰值吞吐并不等价于更低的首屏等待时间；若过早显示中间结果，用户又可能看到随后被改写的文本。

第四，软件生态尚未成熟。AR 模型已经拥有成熟的模型格式、量化工具、服务框架和监控体系，dLLM 则需要专门的 runtime 和调度逻辑。dlmrt 的开源是重要一步，但生态能否快速接入主流硬件、编译器和服务框架，决定了 ORL 能否从研究成果变成开发者日常会使用的工具。

判断：速度突破成立，但真正的竞争才刚开始

ORL 与 dlmrt 的开源，证明扩散语言模型的性能瓶颈并不只在模型架构，也在训练分布和推理系统。通过让模型学习自身生成轨迹中的残差，再配合面向并行去噪的执行引擎，dLLM 可以在单张 RTX 5090 上达到 2788 Token/s，在 H100 的对照测试中以 1298 Token/s 超过传统 AR 和 DFlash 基线。

这是一项有说服力的工程结果，但它还不是“扩散模型全面取代自回归模型”的信号。当前更准确的结论是：在合适的模型、量化、输出长度和准确率容忍度下，dLLM 已经具备非常强的单请求吞吐潜力；在复杂推理、长上下文、并发服务和严格质量约束下，它仍需要更多公开验证。

对开发者而言，值得关注的不是盯住 2788 这个最高数字，而是 ORL 是否能在自己的任务上同时满足三个条件：质量没有明显下降、延迟确实降低、并发后吞吐仍然稳定。如果答案是肯定的，那么扩散式生成就不再只是论文里的并行解码技巧，而会成为下一代推理栈中值得单独部署的一条路线。

参考来源

1. Reddit：ORL 与 dlmrt 项目发布说明：研究团队公布 ORL、dlmrt、硬件配置、吞吐数据和开源范围。
2. OpenAI Hub：扩散语言模型相关工具与模型导航：用于补充 AI 工具与模型生态背景。