机器之心发布
近期，DeepSeek 推出投机解码框架 DSpark，让大模型推理效率再次成为行业焦点。
几乎同一时间，另一大模型基座代表阶跃星辰提出了 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 展示了推理服务在生产系统中仍有 60%-85%（Flash 模型）和 57%-78%（Pro 模型）的速度提升空间。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 都合理，连成一条路径后却可能互相冲突，即「局部合理、整体不一致」，导致接受率迅速被稀释，浪费了计算预算。
在真实服务场景中，一旦草稿生成足够便宜，系统省下来的计算预算该如何分配，决定了不同的演进路径：
- 在高并发、吞吐量导向场景下（DSpark 的解法）： 目标是在不增加每个请求验证成本的前提下，提高整体吞吐量。DSpark 保持并行草稿主干的低成本，同时加入轻量级的串行头和置信度估计，用来更好地判断哪些候选结果值得送去验证，从而控制每个请求的计算预算。因此，相比 MTP 这类纯自回归草稿方法，DSpark 能够持续提升吞吐量。
引自 DSpark 论文：在高并发场景下，DSpark 的吞吐量与每用户生成速度（TPS）关系曲线。结果表明，在论文所测量的流量模式和推理引擎配置下，相比 MTP-1 基线，DSpark 改善了实际观测到的吞吐量 — 延迟前沿。
- 在低并发、延迟导向（低 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 基础设施。
一作为 Lanxiang Hu，目前就读于加州大学圣地亚哥分校（UCSD），师从 Prof. Hao Zhang 和 Prof. Tajana Šimunić Rosing，在阶跃实习期间完成此项工作。其他作者分别来自南京大学、UIUC 以及浙江大学。
实际上，这也不是阶跃和 UCSD 第一次在大模型效率方面合作，此前他们还共同发表了 PD 分离（Prefill-Decode Disaggregation）这条技术路线的代表性开山论文之一 DistServe。该研究将大模型的推理过程拆分为「预填充」和「解码」两个阶段，并让它们分别在独立的计算资源池中进行伸缩与调度。如今这种解耦推理架构已被 NVIDIA TensorRT-LLM、SGLang、vLLM 等主流大模型推理框架采用。
热门跟贴