JetSpec 是什麼？投機解碼加大 draft budget 為何反而變慢的解法

2026 年 7 月 7 日，來自 UC San Diego、浙江大學、UIUC、南京大學與階躍星辰的聯合團隊發表 JetSpec，正面回應投機解碼（speculative decoding）的一個老問題：把 draft budget（草稿預算）加大，推理速度為什麼反而停滯。他們的核心論點是，瓶頸不在算力，而在 draft tree（草稿樹）的建構邏輯，現有方法不論怎麼加大草稿預算，都突破不了這道結構性限制。JetSpec 在 MATH-500 上達到最高 9.64x 加速、開放式對話 4.58x，在數學、程式與對話三類任務上穩定超越目前最強的基準方法。

投機解碼的基本邏輯是讓輕量 drafter 先生成候選 token，主模型再批次驗證，跳過逐 token 自回歸的成本。擴大 draft budget 理論上應讓 drafter 生成更多候選、加速更多，現實中卻沒有發生，因為 drafter 本身就是瓶頸。現有方法困在兩個死角：自回歸式 drafter 建出的 draft tree 語義連貫，但擴展速度天生被串行計算拖住；並行式 drafter 雖快，卻因各節點缺乏上下文依賴，tree 內語義不一致，主模型的驗收率跟著跌，速度增益被抵銷。JetSpec 用單次前向傳遞搭配因果條件（causal conditioning），讓整棵 draft tree 在同一次計算內共享上下文，各節點同時生成又保持語義連貫，兩個死角都繞開了。

對自建推理服務、正在壓低延遲與 token 成本的工程師，JetSpec 指向一個值得直接評估的方向：投機解碼的擴展天花板，看起來被 draft tree 怎麼建卡住，而不是被算力卡住。這意味著，理論上在同樣的硬體預算下，換一套 tree 建構策略就能釋放加速空間，不必等更大的 draft 模型或更多 GPU。MATH-500 的 9.64x 與對話的 4.58x 之間有明顯落差，側面說明不同任務的 token 分佈對 draft tree 一致性的要求並不相同，生產環境部署前仍需針對自身工作負載實測。這則素材來自機器之心（Jiqizhixin）轉發的論文推介貼文，9.64x 峰值背後的實驗設置（模型規格、beam 配置、硬體環境）與跨任務泛化性，須回原論文與代碼核實才算數。