機器之心發布

近期，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 等主流大模型推理框架采用。