内容摘要：机器之心发布近期，DeepSeek 推出了投机解码框架 DSpark，再次将大模型推理效率推向行业焦点。几乎在同一时间，另一家大模型基座厂商 阶跃星辰StepFun）提出了 JetSpec，同样直指这

机器之心发布

近期，不只倍DeepSeek 推出了投机解码框架 DSpark，阶跃再次将大模型推理效率推向行业焦点。等开大模

几乎在同一时间，型解另一家大模型基座厂商 阶跃星辰（StepFun）提出了 JetSpec，码提同样直指这一核心命题：当大模型被 Agent 高频调用时，速近如何实现更快、不只倍更稳定的阶跃智能输出？

• JetSpec 项目地址：https://jetspec-project.github.io/jetspec-web/
• 论文地址：https://arxiv.org/abs/2606.18394
• 开源地址：https://github.com/hao-ai-lab/JetSpec

简而言之，DSpark侧重于提升推理服务中的等开大模验证效率，而 JetSpec则从草稿（Draft）生成本身入手，型解利用因果并行树生成机制，码提显著提高了单次验证可接受的速近 Token 数量。前者旨在系统层面减少无效计算，不只倍后者则在算法层面提升有效 Token 的阶跃生成率。

从实测结果来看，等开大模DSpark 展示了推理服务在生产系统中仍有巨大的加速空间：Flash 模型提升 60%-85%，Pro 模型提升 57%-78%。而 JetSpec 从算法侧给出了更为直接的加速数据：
* 在 Qwen3-8B上，JetSpec 相比标准自回归解码，最高实现 9.64×的端到端解码加速。
* 在 MATH-500基准上，一次验证平均可接受 10.76个 token。
* 这种加速不仅限于数学任务，在 HumanEval、LiveCodeBench、MT-Bench等代码和对话任务上，JetSpec 分别实现了 7.12×、7.67×和 4.58×的加速。

上图：在 H100 GPU 上，跨数学、代码和对话基准测试中，相较于标准自回归解码的端到端解码加速比。DFlash 表示原始的块并行草稿方法，DDTree 是 DFlash 的树状变体，JetSpec 表示本文提出的方法。两者均采用算法 1，使用 256 个 token 的树预算。

过去几年，大模型竞争的主线在于模型能力的强弱，即在数学、代码、推理、多模态等领域争夺更高分数。但在 Agent 场景下，这一逻辑发生了根本性转变。

一个 Agent 完成任务，往往涉及规划、搜索、写代码、调用工具、检查结果、修复错误，再进入下一轮执行。一次任务背后，可能伴随数十次甚至上百次模型调用。此时，单次推理延迟和 Token 生成效率会被连续放大，直接决定产品体验、系统吞吐量和商业成本。

这也是 DSpark 和 JetSpec 几乎同期引发关注的原因。尽管切入点不同，但它们共同揭示了一个行业趋势：模型能力依然重要，但推理效率已成为 Agent 能否规模化落地的基础变量。

投机解码的瓶颈：草稿预算增加，不必然带来加速

大语言模型通常采用自回归生成方式，即一个 Token 接一个 Token 地输出。这个过程天然串行，回答越长、推理越复杂，延迟越明显。

投机解码（Speculative Decoding）的核心思路是：让轻量级的草稿模型提前生成候选 Token，再由目标模型一次性并行验证这些候选结果。目标模型接受的候选越多，下一轮需要重新生成和验证的次数就越少，整体解码速度也就越快。

然而，草稿生成得多，并不代表系统一定更快。只有更多候选 Token 被目标模型接受，加速才会真正发生。

这也是 DSpark 和 JetSpec 共同指向的核心瓶颈：当草稿生成成本足够低时，如何保留足够的因果一致性，让并行生成的 Token 能够通过目标模型验证，并真正转化为系统收益？

这两项工作分别从吞吐量和延迟边界的两个互补侧面切入：

• DSpark面向高并发服务场景。在 Qwen3-8B 和 AIME25 上，DSpark 在投机预算为 7 的设置下，通过带有因果递归状态的置信度调度验证，将平均接受长度从 DFlash 的 4.07提升到 5.01。
• JetSpec面向低延迟、计算预算更充足的场景。通过将因果性直接融入并行草稿头，它能够把更大的草稿预算转化为更长的接受前缀。在相同设置下，JetSpec 将平均接受长度从投机预算为 16 时的 7.23提升到预算为 128 时的 9.82，超过了预算为 128 下 DFlash 的 7.34 和 DDTree 的 8.66，从而更好地支持低延迟生成。

为什么接受率是关键：破解两难困境

在低草稿生成成本的场景下，保持较高的逐 Token 接受率尤为重要。根据投机解码的理论公式：

图 1：在不同逐 Token 草稿成本和接受率下，投机解码的期望加速比会随着草稿长度变化而变化。结果表明，即使在极低逐 Token 草稿成本的场景下，逐 Token 接受率从 0.85 提升到 0.95 也会带来显著差异。

这就引出了当前投机解码继续扩展时遇到的核心障碍：因果一致性与并行效率的两难困境（Causality-Efficiency Dilemma）。

• 自回归草稿（如 EAGLE 系列）：能够沿着具体路径进行条件化预测，因果一致性好、候选质量高。但树越深，串行草稿生成步骤就越多，时间成本随之上升，限制了扩展性。
• 块并行草稿（如 DFlash 系列）：改变了成本结构，它使用轻量级的块并行草稿模型，在一次前向传播中预测多个未来位置（双向块扩散）。虽然草稿成本极低，但由于缺乏分支级的因果条件约束，这些未来位置更像是各自独立的边缘预测。单独看每个 Token 都合理，连成一条路径后却可能互相冲突，即「局部合理、整体不一致」，导致接受率迅速被稀释，浪费了计算预算。

在真实服务场景中，一旦草稿生成足够便宜，系统省下来的计算预算该如何分配，决定了不同的演进路径：

1. 高并发、吞吐量导向场景（DSpark 的解法）

目标是在不增加每个请求验证成本的前提下，提高整体吞吐量。DSpark 保持并行草稿主干的低成本，同时加入轻量级的串行头和置信度估计，用来更好地判断哪些候选结果值得送去验证，从而控制每个请求的计算预算。因此，相比 MTP 这类纯自回归草稿方法，DSpark 能够持续提升吞吐量。

引自 DSpark 论文：在高并发场景下，DSpark 的吞吐量与每用户生成速度（TPS）关系曲线。结果表明，在论文所测量的流量模式和推理引擎配置下，相比 MTP-1 基线，DSpark 改善了实际观测到的吞吐量 — 延迟前沿。

2. 低并发、延迟导向（低 SLO）场景（JetSpec 的解法）

系统拥有更充足的 FLOPs 预算，目标转向最大化单次验证步骤中的接受率。此时，系统可以承受稍微高一点的草稿树计算开销，用来提升接受率，从而将可用算力直接转化为极低的单用户延迟。

在低并发场景下，JetSpec 加速 Qwen3-8B 运行 MATH-500 时的每用户生成速度（TPS/user）。在多种代码和数学任务上，JetSpec 将接受长度提升到约 10–11个 Token，从而显著降低生成延迟，带来更好的交互体验。

因果性如何发挥作用？

当草稿变得便宜之后，下一个问题是如何分配有限的计算强度：是在高并发下进一步压榨吞吐，还是在每个请求可用 FLOPs 更充足时追求更低延迟？这正是因果性成为关键之所在。

推进吞吐极限：用于预算感知校正的 DSpark

推进延迟极限：JetSpec 将草稿预算转化为更高接受长度

在低并发场景下，现代 AI 加速器通常拥有更多空闲 FLOPs，因此关键问题变成：如何把更高的计算预算转化为每次草稿—验证步骤中更多被接受的 Token？

这正是 JetSpec 选择不同路径的地方。JetSpec 使用因果并行草稿头生成路径条件化的草稿树，其中更深层的节点会依赖同一分支上更早生成的 Token。

这一效果可以从深度维度的接受率曲线中清楚看到。在代码生成和数学推理任务上，JetSpec 都能比 DFlash 持续保持更高的接受率。

DFlash 和 JetSpec 在 AIME25 上不同草稿深度位置的逐位置接受率。

这对应于约 93%的有效逐 Token 接受率，显著高于 DFlash。在这种低成本、高接受率的场景下，即使逐 Token 接受率提升 5%，也会对投机解码产生显著影响：它会大幅提高最大理论接受长度（图 1），进而直接降低生成延迟。

一个可预见的下一步，是构建一个动态服务框架，同时推动吞吐量—延迟帕累托边界的两端：在低并发场景下提升每用户生成速度，在高并发场景下则在严格验证预算约束下提升整体吞吐量。

在这一方向上，当前阶段的 JetSpec 和 DSpark 具有天然互补性。JetSpec 强化了并行草稿主干，使其能够在低延迟场景下更好地利用更大的草稿预算；而 DSpark 则通过轻量级串行置信度检查和预算控制，更好地支持高并发服务。

结语

放在阶跃的技术路线里看，JetSpec 不是一个孤立的推理加速论文，它是 Flash 模型叙事的一部分。

从 Step 3.5 Flash 到 Step 3.7 Flash，阶跃一直强调的并不是「大而全」的模型竞赛，而是面向 Agent 场景的高效智能：更快的输出速度、更优的调用成本、更好的工具调用与多模态任务执行能力。JetSpec 则进一步从推理算法层面补上了这块拼图。当模型开始被 Agent 高频、长链路、持续调用时，真正决定体验和成本的，是它能不能以足够高的效率完成一次又一次推理。

值得一提的是，DSpark 和 JetSpec 这两篇论文均有 AI 行业技术大佬坐镇：
* DSpark作者栏中看到了 梁文锋的名字。
* JetSpec作者栏中则看到了阶跃两位大佬：CEO 及创始人姜大昕、CTO 及联合创始人朱亦博。其中朱亦博博士是 AI Infra 领域的顶级专家，长期深耕大模型训练与推理系统、分布式计算和高性能 AI 基础设施。

JetSpec 的第一作者是 Lanxiang Hu，目前就读于加州大学圣地亚哥分校（UCSD），师从 Prof. Hao Zhang 和 Prof. Tajana Šimunić Rosing，在阶跃实习期间完成此项工作。其他作者分别来自南京大学、UIUC 以及浙江大学。

实际上，这也不是阶跃和 UCSD 第一次在大模型效率方面合作。此前他们还共同发表了 PD 分离（Prefill-Decode Disaggregation）这条技术路线的代表性开山论文之一 DistServe。该研究将大模型的推理过程拆分为「预填充」和「解码」两个阶段，并让它们分别在独立的计算资源池中进行伸缩与调度。如今，这种解耦推理架构已被 NVIDIA TensorRT-LLM、SGLang、vLLM 等主流大模型推理框架广泛采用。