讓動態投機解碼不再局限于DSpark：LightSpec首個開源動態MTP系統實現

本文由上海交通大學、北京航空航天大學與LightLLM團隊聯合完成。作者陳俊一是上海交通大學二年級碩士研究生，研究方向聚焦于大模型推理加速算法與推理框架優化，長期關注推測解碼、動態 MTP 以及高性能推理系統等問題。其余三位位作者白世豪，汪再軍和龔睿昊均來自 LightLLM團隊，該團隊長期致力于大語言模型推理引擎、分布式并行、推測解碼與系統級性能優化，并持續推動前沿推理算法在真實服務場景中的工程化落地。

隨著 DeepSeek 發布 DSpark，動態 MTP（多 Token 預測）成為了對抗高并發、提升 GPU 利用率的絕對焦點。然而，DSpark 高度綁定特定模型且需要額外訓練。

今天，LightSpec團隊正式開源了業內首個通用動態 MTP 推理框架方案 —— 它采用創新的兩階段 Training-free 設計，完全無需訓練，不僅能直接兼容 DSpark 策略，還完美支持 Eagle3 等不同草稿模型。LightSpec首次實現了從算法到運行時的完整系統級優化，真正讓動態 MTP 從 “特定模型的專屬技巧” 演進為 “通用推理的基建能力”！

事實上，早在今年年初，LightSpec團隊便已率先聚焦動態 MTP 方向，圍繞算法設計、系統調度與推理系統實現持續推進相關工作，目前已完成首個開源通用動態 MTP 系統的實現。

相比 DSpark，LightSpec的優勢可以概括為兩個關鍵詞：更通用，也更完整。

更通用，意味著動態 MTP 不再局限于某一種草稿模型。LightSpec采用創新的兩階段 Training-free 動態調度設計，無需額外訓練置信度預測模型，而是通過運行時在線統計實時完成動態決策。因此，它不僅能夠直接兼容 DSpark 的動態驗證策略，還進一步支持 Eagle3 等自回歸草稿模型、MTP Layer 等不同類型的動態 MTP 實現，并能夠自然擴展到未來樹形草稿、多分支推測解碼等更加復雜的推理架構。

更完整，意味著開源的不只是一個動態調度算法，而是一套真正可落地的動態 MTP 系統。動態 MTP 真正落地遠不止增加一個調度器，還涉及運行時統計、預算優化、模型輸入構建、流水線協同等多個模塊之間的協同設計與系統優化。

LightSpec首次將這些關鍵模塊完整實現并開源，使動態 MTP 真正具備了可復用、可擴展、可落地的系統能力，也讓現有推理框架能夠以更低成本支持動態 MTP。

本文將圍繞這一通用動態 MTP 系統，介紹其動態調度算法設計、運行時統計機制、完整系統實現、流水線優化以及實驗結果，并展示LightSpec如何將動態 MTP 從一種面向特定模型的優化技巧，進一步演進為推理系統的一項基礎能力。

從 “動態調整驗證長度” 到 “動態 MTP 系統”

現有動態投機解碼工作主要圍繞驗證預算展開，即根據當前推理狀態動態決定哪些草稿 Token 值得送入主模型驗證，從而避免低收益 Token 占用 GPU Batch 容量。

LightSpec則進一步將動態 MTP 擴展到整個解碼流程。整個運行時規劃器被拆分為兩個連續優化階段。

• 第一階段（驗證預算優化）：系統結合上一輪草稿步數、運行時代價模型以及歷史統計信息，在可選驗證預算中搜索最優動態 Batch 大小，動態決定當前輪真正送入主模型驗證的 Token 數量。
• 第二階段（草稿預算優化）：在確定當前驗證預算后，運行時規劃器繼續搜索下一輪最優草稿步數，將草稿模型的計算成本顯式納入優化目標，動態決定下一輪需要生成多少草稿 Token。

這種雙層運行時規劃器不僅減少了驗證浪費，也進一步降低了草稿浪費。相比僅動態調整驗證長度，LightSpec將草稿預算與驗證預算統一納入運行時規劃器，使動態調度覆蓋整個 MTP 解碼周期。

無需額外訓練，基于運行時統計的動態調度

DSpark 的硬件感知調度器依賴預先 Profile 得到的 SPS (B) 曲線，并結合模型預測得到的 Token 置信度完成動態 Token 準入，因此需要額外訓練專用的置信度預測模塊。

LightSpec則采用了一條更加通用的系統路線。整個動態 MTP 運行時規劃器不依賴額外訓練的置信度預測模型，而是直接利用推理系統運行過程中自然產生的統計信息完成動態調度。

其中，主模型和草稿模型在不同批次大小下的推理耗時，會在 CUDA Graph 構建過程中自動統計并維護為運行時代價表；不同請求規模、不同動態 Batch 大小下的接受率，以及不同 MTP 長度對應的接受率變化，則通過運行時持續更新的指數移動平均（EMA）統計進行維護。

對于統計樣本尚不充分的配置，運行時規劃器會利用不同 MTP 長度上的歷史統計進行插值估計；隨著系統持續運行，EMA 統計不斷收斂，調度策略也能夠逐漸適應真實工作負載，而無需依賴額外訓練的置信度預測模型。相比需要專用預測模塊的方案，這種基于運行時統計的運行時規劃器更容易遷移到不同草稿模型和不同推理框架中，也降低了動態 MTP 的落地門檻。

調度與 Draft 架構解耦，支持更多草稿模型

動態 MTP 的另一個挑戰，在于不同草稿模型的推理模式并不相同。DSpark、DFlash 等并行解碼草稿模型（Parallel Drafter） 能夠一次前向傳播生成完整草稿塊，因此動態調度主要圍繞驗證長度展開。而 Eagle3 等自回歸草稿模型（Auto-regressive Drafter），則需要逐步生成草稿 Token，草稿本身就是整個推理過程中不可忽略的計算開銷。

LightSpec將驗證預算與草稿預算解耦之后，不再依賴具體草稿模型的生成方式。對于并行解碼草稿模型，運行時規劃器可以動態調整驗證預算；對于自回歸草稿模型，則能夠進一步動態調整草稿步數，減少不必要的草稿計算。

這種設計使動態 MTP 首次從某一種草稿模型上的專用優化，擴展成為整個開源 MTP 生態都可以復用的通用運行時能力。與此同時，兩階段運行時規劃器也天然具備更好的擴展能力。未來無論是樹形草稿、多分支草稿，還是更加復雜的投機解碼架構，都能夠繼續沿用同一套運行時規劃器，而無需重新設計調度機制。

首個開源動態 MTP 系統功能實現

除了動態調度器本身，LightSpec還首次將動態 MTP 的完整系統實現進行了開源。

整個系統并非單一的調度模塊，而是圍繞動態預算決策構建了一套完整的推理系統。運行時代價表持續維護不同批次大小下的計算開銷，為動態調度提供代價估計；EMA 接受率統計實時跟蹤不同工作負載下的接受行為，為預算決策提供在線反饋；動態調度器則綜合這些運行時統計，在每一輪推理過程中聯合決定驗證預算與草稿預算，并同步完成動態模型輸入的構建與更新。

LightSpec構建的不僅是一套動態 MTP 調度算法，而是一套覆蓋運行時統計、預算優化、輸入構建、流水線執行與系統協同的完整動態 MTP 系統實現，打破了動態 MTP 調度與 GPU 推理之間的運行時數據依賴，為不同 Draft 架構和更復雜的投機采樣算法提供了統一的系統基礎。

LightSpec采用歷史統計驅動的運行時規劃器。由于規劃器所依賴的接受率和接受長度估計均來自前幾輪持續維護的 EMA 統計，而非當前 Batch 的實時推理結果，因此 CPU 無需等待當前批次的草稿推理完成，即可提前完成下一輪動態 Batch 大小、草稿步數以及模型輸入的規劃。

與此同時，系統會在推理開始之前按照最大可能的草稿長度預留 Token 槽位，在 GPU 推理結束后，僅根據估計得到的接受長度完成切割，只保留真正需要驗證的 Token，而無需重新組織輸入。

這種設計徹底消除了規劃器與 GPU 執行之間的運行時數據依賴，實現了 CPU 調度與 GPU 執行的完全重疊，將調度、輸入構建以及統計維護幾乎全部隱藏在 GPU 推理過程中。對于高并發在線推理而言，這類流水線優化往往比單個 Kernel 優化更加重要，因為真正決定端到端吞吐的，通常是調度、同步、數據組織、后處理以及 GPU 執行能否實現完全重疊。

實驗結果：LightSpec 持續優于固定 MTP 步數

在 Qwen3-14B（TP=1）、H200、256 并發環境下，LightSpec 分別在 ShareGPT、HumanEval 和 GSM8K 三類工作負載上，對動態投機采樣與固定 MTP 步數進行了對比。

結果表明，LightSpec 的整體性能始終不劣于固定配置，并且隨著推測步數增加，其優勢進一步擴大。當固定 MTP 步數從 3 提升至 11 時，靜態方案會生成越來越多低收益候選 Token，導致接受率持續下降；動態方案則能夠根據在線接受率和模型執行成本動態收縮無效預算，使接受率保持在相對穩定的水平。在 MTP=11 時，ShareGPT、HumanEval 和 GSM8K 的接受率分別提高約 43、29 和 19 個百分點。

更高的有效接受率直接減少了主模型的驗證工作量。在 MTP=11 時，LightSpec 在 ShareGPT、HumanEval 和 GSM8K 上所需的驗證行數分別降低約 3.2×、1.8× 和 1.5×；其中 ShareGPT 的實際驗證量僅約為靜態方案的三分之一。相應地，LightSpec 的請求吞吐分別提升 64%、39% 和 8.9%。即使在較淺的 MTP=3 配置下，其吞吐也能保持不劣，并在 ShareGPT 上獲得 14% 的提升。

這些結果說明，固定 MTP 步數難以同時適應不同任務的接受率特征：較小的步數可能限制潛在加速收益，較大的步數又容易引入過量 Draft 和 Verification 開銷。LightSpec 的運行時規劃器通過聯合調整 Draft Budget 與 Verification Budget，能夠在不同任務和系統狀態下持續尋找更合理的計算預算，而無需為每類工作負載反復人工選擇固定 MTP 步數。

從一種優化技巧，到一項基礎系統能力

動態 MTP 的意義，正在從一種模型優化策略，逐漸演進為推理系統的一項基礎能力。

隨著樹形草稿（Tree Draft）、混合草稿（Hybrid Draft）、多策略投機解碼等更加復雜的推理架構逐漸落地，系統需要動態優化的將不僅是驗證長度，而是整個投機預算（Speculative Budget），包括草稿深度、草稿寬度、樹擴展（Tree Expansion）、分支剪枝（Branch Pruning）等多個維度。未來的動態 MTP，也將不再是單一調度策略，而是一套覆蓋整個推測解碼流程的系統能力。

LightSpec的設計正是圍繞這一方向展開。通過驗證預算與草稿預算分離建模的雙層動態調度器，以及圍繞運行時統計、預算優化、模型輸入構建和流水線協同設計的完整系統實現，動態調度不再局限于 "驗證多少 Token" 的算法設計，而是擴展到整個推測解碼系統的實現，并與具體草稿模型生成方式解耦，從而能夠自然支持并行草稿模型、自回歸草稿模型以及未來更加復雜的推理架構。

目前，LightLLM 動態 MTP 系統已正式開源，相關代碼已經集成至 LightLLM 開發分支：https://github.com/ModelTC/LightLLM/tree/mtp_optimization。

從動態驗證到動態 MTP 系統，從單一草稿模型到通用動態調度框架，從模型優化技巧到推理系統基礎能力，LightSpec希望推動動態 MTP 從針對特定模型的局部優化，發展為整個開源 MTP 生態共享的系統基礎設施。