機(jī)器之心發(fā)布

近期，DeepSeek 推出投機(jī)解碼框架 DSpark，讓大模型推理效率再次成為行業(yè)焦點(diǎn)。

幾乎同一時(shí)間，另一大模型基座代表階躍星辰提出了 JetSpec ，也把問題指向了同一個(gè)方向：當(dāng)模型開始被 Agent 高頻調(diào)用，智能能不能更快、更穩(wěn)定輸出出來？

• JetSpec 項(xiàng)目地址：https://jetspec-project.github.io/jetspec-web/
• 論文地址：https://arxiv.org/abs/2606.18394
• 開源地址：https://github.com/hao-ai-lab/JetSpec

簡單來說，DSpark 更關(guān)注推理服務(wù)中的驗(yàn)證效率，JetSpec 則從 Draft 生成本身入手，用因果并行樹生成提高一次驗(yàn)證能接受的 Token 數(shù)。前者是在系統(tǒng)層面減少無效計(jì)算，后者是在算法層面提高有效 Token 生成率。

從結(jié)果來看，DSpark 展示了推理服務(wù)在生產(chǎn)系統(tǒng)中仍有 60%-85%（Flash 模型）和 57%-78%（Pro 模型）的速度提升空間。JetSpec 則從算法側(cè)給出了一組更直接的加速結(jié)果。在 Qwen3-8B 上，JetSpec 相比標(biāo)準(zhǔn)自回歸解碼，最高實(shí)現(xiàn) 9.64× 端到端解碼加速；在 MATH-500 上，一次驗(yàn)證平均可接受 10.76 個(gè) token。這種加速不局限于數(shù)學(xué)任務(wù)，在 HumanEval、LiveCodeBench、MT-Bench 等代碼和對話任務(wù)上，JetSpec 也分別實(shí)現(xiàn)了 7.12×、7.67× 和 4.58× 加速。

在 H100 GPU 上，跨數(shù)學(xué)、代碼和對話基準(zhǔn)測試中，相較于標(biāo)準(zhǔn)自回歸解碼的端到端解碼加速比。DFlash 表示原始的塊并行草稿方法，DDTree 是 DFlash 的樹狀變體，JetSpec 表示本文提出的方法。兩者均采用算法 1，使用 256 個(gè) token 的樹預(yù)算。

過去幾年，大模型競爭的主線看的是誰的模型更強(qiáng)，誰能在數(shù)學(xué)、代碼、推理、多模態(tài)上拿到更高分。但 Agent 場景下，這個(gè)邏輯變了。

一個(gè) Agent 完成任務(wù)，需要規(guī)劃、搜索、寫代碼、調(diào)用工具、檢查結(jié)果、修復(fù)錯(cuò)誤，再繼續(xù)下一輪執(zhí)行。一次任務(wù)背后，可能是數(shù)十次甚至上百次模型調(diào)用。此時(shí)，單次推理延遲和 token 生成效率會(huì)被連續(xù)放大，最終直接影響產(chǎn)品體驗(yàn)、系統(tǒng)吞吐和商業(yè)成本。

這也是 DSpark 和 JetSpec 幾乎同期引發(fā)關(guān)注的原因。它們切入點(diǎn)不同，卻都說明了大模型行業(yè)正在進(jìn)入一個(gè)新階段。模型能力仍然重要，推理效率正在成為 Agent 能否規(guī)模化落地的基礎(chǔ)變量。

投機(jī)解碼的瓶頸：

草稿預(yù)算增加，不必然帶來加速

大語言模型通常是自回歸生成的，也就是一個(gè) token 接一個(gè) token 往外吐。這個(gè)過程天然串行，越長的回答、越復(fù)雜的推理，延遲越明顯。

投機(jī)解碼（Speculative Decoding）的思路是通過讓輕量級草稿模型提前生成候選 token，再由目標(biāo)模型一次性并行驗(yàn)證這些候選結(jié)果，目標(biāo)模型接受的候選越多，下一輪需要重新生成和驗(yàn)證的次數(shù)就越少，整體解碼速度也就越快。

但草稿生成得多，并不代表系統(tǒng)一定更快。只有更多候選 token 被目標(biāo)模型接受，加速才會(huì)真正發(fā)生。

這也是 DSpark 和 JetSpec 共同指向的核心瓶頸：當(dāng)草稿生成已經(jīng)足夠便宜之后，如何保留足夠的因果一致性，讓并行生成的 token 能夠通過目標(biāo)模型驗(yàn)證，并真正轉(zhuǎn)化為實(shí)際的系統(tǒng)收益？

這兩項(xiàng)工作分別從吞吐量 — 延遲邊界的兩個(gè)互補(bǔ)側(cè)面切入。

DSpark 面向高并發(fā)服務(wù)場景。在 Qwen3-8B 和 AIME25 上，DSpark 在投機(jī)預(yù)算為 7 的設(shè)置下，通過帶有因果遞歸狀態(tài)的置信度調(diào)度驗(yàn)證，將平均接受長度從 DFlash 的 4.07 提升到 5.01。

JetSpec 則面向低延遲、計(jì)算預(yù)算更充足的場景。通過將因果性直接融入并行草稿頭，它能夠把更大的草稿預(yù)算轉(zhuǎn)化為更長的接受前綴。在相同設(shè)置下，JetSpec 將平均接受長度從投機(jī)預(yù)算為 16 時(shí)的 7.23 提升到預(yù)算為 128 時(shí)的 9.82，超過了預(yù)算為 128 下 DFlash 的 7.34 和 DDTree 的 8.66，從而更好地支持低延遲生成。

為什么接受率是關(guān)鍵：破解兩難困境

在低草稿生成成本的場景下，保持較高的逐 token 接受率尤其重要。根據(jù)投機(jī)解碼的理論公式：

圖 1：在不同逐 token 草稿成本和接受率下，投機(jī)解碼的期望加速比會(huì)隨著草稿長度變化而變化。結(jié)果表明，即使在極低逐 token 草稿成本的場景下，逐 token 接受率從 0.85 提升到 0.95 也會(huì)帶來顯著差異。

這就引出了當(dāng)前投機(jī)解碼繼續(xù)擴(kuò)展時(shí)遇到的核心障礙：因果一致性與并行效率的兩難困境（Causality-Efficiency Dilemma）。

• 自回歸草稿（如 EAGLE 系列）： 它們能夠沿著具體路徑進(jìn)行條件化預(yù)測，因果一致性好、候選質(zhì)量高。但樹越深，串行草稿生成步驟就越多，時(shí)間成本隨之上升，限制了擴(kuò)展性。
• 塊并行草稿（如 DFlash 系列）： 改變了成本結(jié)構(gòu)，它使用輕量級的塊并行草稿模型，在一次前向傳播中預(yù)測多個(gè)未來位置（雙向塊擴(kuò)散）。雖然草稿成本極低，但由于缺乏分支級的因果條件約束，這些未來位置更像是各自獨(dú)立的邊緣預(yù)測。單獨(dú)看每個(gè) token 都合理，連成一條路徑后卻可能互相沖突，即「局部合理、整體不一致」，導(dǎo)致接受率迅速被稀釋，浪費(fèi)了計(jì)算預(yù)算。

在真實(shí)服務(wù)場景中，一旦草稿生成足夠便宜，系統(tǒng)省下來的計(jì)算預(yù)算該如何分配，決定了不同的演進(jìn)路徑：

• 在高并發(fā)、吞吐量導(dǎo)向場景下（DSpark 的解法）： 目標(biāo)是在不增加每個(gè)請求驗(yàn)證成本的前提下，提高整體吞吐量。DSpark 保持并行草稿主干的低成本，同時(shí)加入輕量級的串行頭和置信度估計(jì)，用來更好地判斷哪些候選結(jié)果值得送去驗(yàn)證，從而控制每個(gè)請求的計(jì)算預(yù)算。因此，相比 MTP 這類純自回歸草稿方法，DSpark 能夠持續(xù)提升吞吐量。

引自 DSpark 論文：在高并發(fā)場景下，DSpark 的吞吐量與每用戶生成速度（TPS）關(guān)系曲線。結(jié)果表明，在論文所測量的流量模式和推理引擎配置下，相比 MTP-1 基線，DSpark 改善了實(shí)際觀測到的吞吐量 — 延遲前沿。

• 在低并發(fā)、延遲導(dǎo)向（低 SLO）場景下（JetSpec 的解法）： 系統(tǒng)擁有更充足的 FLOPs 預(yù)算，目標(biāo)轉(zhuǎn)向最大化單次驗(yàn)證步驟中的接受率。此時(shí)，系統(tǒng)可以承受稍微高一點(diǎn)的草稿樹計(jì)算開銷，用來提升接受率，從而將可用算力直接轉(zhuǎn)化為極低的單用戶延遲。

在低并發(fā)場景下，JetSpec 加速 Qwen3-8B 運(yùn)行 MATH-500 時(shí)的每用戶生成速度（TPS/user）。在多種代碼和數(shù)學(xué)任務(wù)上，JetSpec 將接受長度提升到約 10–11 個(gè) token，從而顯著降低生成延遲，帶來更好的交互體驗(yàn)。

因果性如何發(fā)揮作用？

當(dāng)草稿變得便宜之后，下一個(gè)問題是如何分配有限的計(jì)算強(qiáng)度：是在高并發(fā)下進(jìn)一步壓榨吞吐，還是在每個(gè)請求可用 FLOPs 更充足時(shí)追求更低延遲？這正是因果性成為關(guān)鍵之所在。

推進(jìn)吞吐極限：

用于預(yù)算感知校正的 DSpark

推進(jìn)延遲極限：

JetSpec 將草稿預(yù)算轉(zhuǎn)化為更高接受長度

在低并發(fā)場景下，現(xiàn)代 AI 加速器通常擁有更多空閑 FLOPs，因此關(guān)鍵問題變成：如何把更高的計(jì)算預(yù)算轉(zhuǎn)化為每次草稿 — 驗(yàn)證步驟中更多被接受的 token？

這正是 JetSpec 選擇不同路徑的地方。JetSpec 使用因果并行草稿頭生成路徑條件化的草稿樹，其中更深層的節(jié)點(diǎn)會(huì)依賴同一分支上更早生成的 token。

這一效果可以從深度維度的接受率曲線中清楚看到。在代碼生成和數(shù)學(xué)推理任務(wù)上，JetSpec 都能比 DFlash 持續(xù)保持更高的接受率。

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

這對應(yīng)于約 93% 的有效逐 token 接受率，顯著高于 DFlash。在這種低成本、高接受率的場景下，即使逐 token 接受率提升 5%，也會(huì)對投機(jī)解碼產(chǎn)生顯著影響：它會(huì)大幅提高最大理論接受長度（圖 1），進(jìn)而直接降低生成延遲。

一個(gè)可預(yù)見的下一步，是構(gòu)建一個(gè)動(dòng)態(tài)服務(wù)框架，同時(shí)推動(dòng)吞吐量 — 延遲帕累托邊界的兩端：在低并發(fā)場景下提升每用戶生成速度，在高并發(fā)場景下則在嚴(yán)格驗(yàn)證預(yù)算約束下提升整體吞吐量。

在這一方向上，當(dāng)前階段的 JetSpec 和 DSpark 具有天然互補(bǔ)性。JetSpec 強(qiáng)化了并行草稿主干，使其能夠在低延遲場景下更好地利用更大的草稿預(yù)算；而 DSpark 則通過輕量級串行置信度檢查和預(yù)算控制，更好地支持高并發(fā)服務(wù)。

結(jié)語

放在階躍的技術(shù)路線里看，JetSpec 不是一個(gè)孤立的推理加速論文，它是 Flash 模型敘事的一部分。

從 Step 3.5 Flash 到 Step 3.7 Flash，階躍一直強(qiáng)調(diào)的并不是「大而全」的模型競賽，而是面向 Agent 場景的高效智能：更快的輸出速度、更優(yōu)的調(diào)用成本、更好的工具調(diào)用與多模態(tài)任務(wù)執(zhí)行能力。JetSpec 則進(jìn)一步從推理算法層面補(bǔ)上了這塊拼圖。當(dāng)模型開始被 Agent 高頻、長鏈路、持續(xù)調(diào)用時(shí)，真正決定體驗(yàn)和成本的，是它能不能以足夠高的效率完成一次又一次推理。

值得一提的是，DSpark 和 JetSpec 這兩篇論文均有 AI 行業(yè)技術(shù)大佬坐鎮(zhèn)。DSpark 作者欄中看到了梁文鋒的名字，而在 JetSpec 作者欄中則看到了階躍兩位大佬：CEO 及創(chuàng)始人姜大昕、CTO 及聯(lián)合創(chuàng)始人朱亦博。其中朱亦博博士是 AI Infra 領(lǐng)域的頂級專家，長期深耕大模型訓(xùn)練與推理系統(tǒng)、分布式計(jì)算和高性能 AI 基礎(chǔ)設(shè)施。

一作為 Lanxiang Hu，目前就讀于加州大學(xué)圣地亞哥分校（UCSD），師從 Prof. Hao Zhang 和 Prof. Tajana ?imuni? Rosing，在階躍實(shí)習(xí)期間完成此項(xiàng)工作。其他作者分別來自南京大學(xué)、UIUC 以及浙江大學(xué)。

實(shí)際上，這也不是階躍和 UCSD 第一次在大模型效率方面合作，此前他們還共同發(fā)表了 PD 分離（Prefill-Decode Disaggregation）這條技術(shù)路線的代表性開山論文之一 DistServe。該研究將大模型的推理過程拆分為「預(yù)填充」和「解碼」兩個(gè)階段，并讓它們分別在獨(dú)立的計(jì)算資源池中進(jìn)行伸縮與調(diào)度。如今這種解耦推理架構(gòu)已被 NVIDIA TensorRT-LLM、SGLang、vLLM 等主流大模型推理框架采用。