一堵看不见的墙
LLM 推理加速领域有一个公开的秘密：推测解码（speculative decoding, SD）这条路，似乎碰到了天花板。
这个"天花板"不是 GPU 算力不够，也不是显存带宽不足，而是推理算法自身的一种结构性瓶颈。UCSD Hao AI Lab 在 2026 年 6 月发表的 JetSpec 论文中，给这个瓶颈起了一个精准的名字——scaling ceiling（扩展上限）。
它的含义非常具体：在推测解码框架中，增大草稿预算（draft budget）——也就是让草稿头每轮多猜几个 token——只有在这两个条件同时满足时才有效：草稿接受率（acceptance rate）足够高，且草稿生成成本足够低。一旦这两个条件中任何一个开始劣化，增大预算不但不会加速，反而可能成为拖累。
这个洞察解释了为什么过去几年，尽管 Medusa、EAGLE、DFlash 等方法相继出现，推测解码的 wall-clock 加速始终存在一个"怎么也突破不了"的区间——对数学推理类任务大约 8 倍多，对开放式对话大约 3-4 倍。
JetSpec 的答案写在一组数字里：MATH-500 上 9.64 倍端到端加速（对比 DDTree 的 8.78 倍），GSM8K 上 7.82 倍，HumanEval 上 7.12 倍，开放对话 MT-Bench 上 4.58 倍。这些数字背后是一个全新的草稿范式——因果并行树起草（causal parallel tree drafting）。
推测解码为什么卡住了
要理解 JetSpec 的贡献，需要先回到推测解码的基本逻辑。
现代自回归 LLM 的推理瓶颈在于"串行"：每生成一个 token，都需要跑一次完整的前向传播，而这个过程天然无法并行化。推测解码的解决方案是引入一个"草稿模型"（draft model）——用较小的代价一次性猜多个后续 token，然后让目标模型在一次前向传播中并行验证这些猜测。验证通过的 token 直接采纳，第一个被拒绝的位置由目标模型自己补上。
这个方法之所以"无损"（lossless），是因为验证阶段保证了输出分布严格等于目标模型的自回归分布。
但草稿模型的设计存在一个根本性的困境，Hao AI Lab 称之为 causality–efficiency dilemma（因果性-效率二难）：
自回归草稿头（如 Medusa、EAGLE 系列）：保持了目标模型的因果条件依赖——每个草稿 token 都基于前缀和同一路径上已生成的 token——因此草稿质量高、接受率好。但代价是草稿过程本身也是串行的：树的每一层深度都需要一次单独的前向传播，草稿成本随树深线性增长。
块扩散草稿头（如 DFlash）：可以在一次前向传播中并行生成整个 token 块，草稿成本极低。但问题在于块内每个位置是独立评分的，不同分支之间缺乏因果条件依赖——就像让九个互不沟通的人分别续写同一段话的后九句，每个人只能看到原始前缀，不知道其他人写了什么。结果是一个个单独看似乎合理、但放在一起就互相矛盾的 token 树。
DDTree 尝试在 DFlash 的基础上引入最佳优先树扩展，一定程度上改善了树结构，但并未从根本上解决"扩散草稿头缺乏因果条件依赖"的问题。论文数据显示，DDTree 确实优于原始 DFlash，但在 MATH-500 上仍然只有 8.78 倍加速，且在面对更大预算时同样遭遇 scaling ceiling。
论文用一个简洁的公式描述了推测解码加速的核心：
加速比 = 平均接受长度 ÷ 草稿成本系数
其中草稿成本系数 = 1 +（草稿头计算量 ÷ 目标模型计算量）。这个公式揭示了 scaling ceiling 的本质：增大预算通常能提升接受长度，但如果草稿头的每次前向传播变得太贵（自回归头的问题），或者接受长度增长赶不上预算增长（扩散头的问题），加速比就会停滞甚至倒退。
JetSpec 的解法：一次前向传播，一棵因果树
JetSpec 的核心直觉可以概括为一句话：能不能既保持一次并行前向传播的效率，又恢复因果条件依赖？
答案是因果并行树起草（causal parallel tree drafting）。JetSpec 训练了一个轻量级因果并行草稿头，挂载在冻结的目标 LLM 之上。这个草稿头有三个关键设计：
第一，复用目标模型的富隐藏状态。 草稿头不是从零开始计算，而是读取目标模型中间多层的隐藏特征（fused hidden states）。这使得草稿头的计算量远小于目标模型的一次前向传播——论文数据显示，草稿头仅增加约 10% 的额外计算——从根本上保证了草稿过程的"便宜"。
第二，块级因果注意力掩码。 草稿头在并行生成多个树节点时，不是让它们独立计算，而是施加一个树因果注意力掩码（tree-causal attention mask）：每个草稿位置只能看到前缀 token 和同一块内位于它之前的位置。这意味着一个分支路径上的后续 token 是在"知道"前面 token 被选中的条件下生成的——这正是自回归草稿头最大的优势所在。
第三，块级监督与 forward-KL 蒸馏。 训练时，JetSpec 将草稿序列划分为多个块，每个块的第一个 token 作为锚点（anchor），剩余位置替换为掩码 token 嵌入。草稿头并行预测所有被掩码的未来 token，每个位置只关注前缀和同一块内的早期位置。论文的消融实验表明，forward-KL 风格的蒸馏略优于 SFT，因为它保留了多个可能延续上的概率质量，而 mode-seeking 的 reverse-KL 不太适合预算受限的树起草场景。
最终效果是：JetSpec 在一次草稿头前向传播中，生成一整棵内部因果一致的候选树——树的每一层有多个分支，每个分支内部保持因果条件依赖，不同分支共享前缀——然后目标模型一次验证整个树，采纳最长的匹配前缀。
论文展示了一个典型轮次：在 MATH-500 上以 256 预算运行 greedy 解码时，JetSpec 平均每个轮次接受 τ = 10.76 个 token——这意味着每跑一次目标模型前向传播（加上一次便宜的草稿头传播），就能推进超过 10 个 token。
数字背后：不只是 9.64×
JetSpec 在 Qwen3-8B 上使用 NVIDIA H100 GPU、256 草稿预算、greedy 解码的完整评测数据如下：
| 基准测试 | JetSpec | DDTree | 提升幅度 |
|---|---|---|---|
| MATH-500 | 9.64× | 8.78× | +9.8% |
| AIME25 | 8.78× | — | — |
| GSM8K | 7.82× | 7.04× | +11.1% |
| HumanEval | 7.12× | 6.31× | +12.8% |
| LCB | 7.67× | — | — |
| MBPP | 6.73× | — | — |
| MT-Bench（开放对话） | 4.58× | — | — |
几个值得注意的观察：
一是 JetSpec 在推理密集型任务上优势最大。MATH-500 的 9.64 倍加速位居所有基准之首，AIME25（8.78 倍）、GSM8K（7.82 倍）紧随其后。这与 JetSpec 的设计直觉一致：数学推理的 token 分布更可预测，草稿接受率更高，因果条件依赖带来的质量提升也更显著。
二是在开放对话上相对"温和"的 4.58 倍加速，恰好说明了 scaling ceiling 的顽固。对话的 token 分布天然更分散，草稿接受率的上限更低，任何方法都会面临天花板——但 JetSpec 仍然将天花板推高了一截。
三是 JetSpec 在 MoE 架构上也保持优势。论文在 Qwen3-30B-A3B（MoE）目标模型上使用相同训练配方评估，JetSpec 持续优于 DDTree，说明因果并行树起草不局限于某一种模型架构。
从实验室到生产环境：vLLM 集成与 B200 上的千 TPS
一篇好的系统论文的价值，很大程度上取决于其方案能否走出实验室。JetSpec 团队显然深谙此道。
Hao AI Lab 已将 JetSpec 集成到 vLLM——业界最广泛使用的 LLM 推理引擎之一——并在真实 serving 负载下进行了验证。在单张 NVIDIA B200 GPU 上运行 Qwen3-8B 加上 JetSpec 草稿头，团队在 MATH-500 上实现了**平均约 1000 tokens per second（TPS）**的吞吐量。作为对比，标准自回归解码的 Qwen3-8B 在类似条件下的吞吐量通常在 100–150 TPS 范围。
更关键的是，JetSpec 在不同请求速率（request rate）下的表现经过了系统评估：在中小负载场景下始终优于 baseline，且在更高端 GPU（如 B200）上增益尤其显著。论文指出，JetSpec 对 GPU 计算能力的利用效率更高——草稿头的轻量设计使得它可以在目标模型忙于验证时并行计算下一棵候选树，形成计算流水线。
GitHub 仓库已公开发布了 JetSpec 草稿模型权重，覆盖 Qwen3-8B、Qwen3-30B-A3B、Qwen3.6-35B-A3B、gpt-oss-20b、Gemma 4 26B A4B IT 和 Step 3.7 Flash。开箱即用的 benchmark 脚本支持一键对比 DFlash baseline 和 JetSpec 的多种树解码算法。
为什么这件事重要
推测解码是 LLM 推理加速的核心技术路线之一。与量化、剪枝、蒸馏等"有损"手段不同，推测解码承诺无损加速——输出分布严格等价于原始模型。这个承诺对于数学推理、代码生成、金融分析等对准确性有严苛要求的场景至关重要。
但也正是这个承诺，使得推测解码的加速上限天然受制于草稿质量与草稿成本之间的 trade-off。过去几年，业界在这个 trade-off 上取得了持续但渐进的进展：Medusa 的多头预测、EAGLE 的特征复用、DFlash 的块并行——每一步都在推动天花板，但每一步也都证明天花板确实存在。
JetSpec 的独特之处在于，它没有在这个 trade-off 的两端做取舍，而是通过重构草稿过程的计算图——从串行或独立并行变为因果并行——从根本上改变了 trade-off 曲线的形状。原本随着预算增大必然到来的边际收益递减，被显著推迟了。
这打开了一个新的研究方向：如果 scaling ceiling 可以被结构性突破，那么在更大的 GPU 上、配合更长的草稿预算，推测解码还能走多远？JetSpec 论文中 B200 上 1000+ TPS 的数字暗示了这种可能性——随着更强大的硬件到来，JetSpec 这类因果并行方法的优势可能会进一步放大。
对于工程团队来说，一个更直接的信号是：JetSpec 已经集成 vLLM。这意味着如果你的推理管线基于 vLLM 构建，尝试 JetSpec 的成本很低——换一个草稿头权重、调整几个配置参数即可。9.64 倍的 MATH-500 加速不是纸面数字，而是可以在你的 GPU 集群上复现的实验结果。
推测解码的故事远未结束。JetSpec 证明了 scaling ceiling 不是物理定律，而是工程选择——选择对了计算图的结构，天花板就可以被重新定义。
论文：JetSpec: Breaking the Scaling Ceiling of Speculative Decoding with Parallel Tree Drafting (arXiv:2606.18394)
