DSpark 是由 Novita 發表的推測解碼方法。我們針對 Kimi-K2.6 與 Kimi-K2.7-Code 訓練並發布了面向生產環境的 DSpark 推測器，將其整合至 vLLM，並評估其平行區塊草稿方法在推測視窗增長時的擴展表現。
這些檢查點旨在在不改變目標模型的情況下加速 Kimi 服務。一個輕量級的草稿模型會提出一個候選 token 區塊，然後完整的 Kimi 模型在這些候選 token 被接受前進行驗證。
在我們 batch-size-1 的 vLLM nightly 評測中，使用 num_speculative_tokens=7 的 DSpark 在 Kimi-K2.6 上實現了平均 2.55 倍的吞吐量加速，在 Kimi-K2.7-Code 上則為 2.36 倍。當推測視窗從 n=3 增加到 n=7 時，DSpark 將額外的草稿 token 轉換為吞吐量的表現，比現有的 Eagle3-MLA 基線更為一致。
已發布的檢查點如下：
- novita/kimi-k2.6-dspark 適用於 Kimi-K2.6
- novita/kimi-k2.7-code-dspark 適用於 Kimi-K2.7-Code
Kimi-K2.6 與 Kimi-K2.7-Code 的 DSpark 基準測試結果
在 batch size 為 1 的情況下，將 num_speculative_tokens 從 3 增加到 7，使得 DSpark 對 Kimi-K2.6 的平均加速比從 2.17 倍提升至 2.55 倍，對 Kimi-K2.7-Code 則從 2.12 倍提升至 2.36 倍。所列出的 Eagle3-MLA 基線平均而言幾乎持平。
| 目標模型 | 草稿模型 | n=3 平均加速比 | n=7 平均加速比 | 與 n=3 相比的變化 |
|---|---|---|---|---|
| Kimi-K2.6 | DSpark | 2.17x | 2.55x | +17.8% |
| Kimi-K2.6 | Eagle3-MLA | 2.01x | 2.01x | +0.2% |
| Kimi-K2.7-Code | DSpark | 2.12x | 2.36x | +11.7% |
| Kimi-K2.7-Code | Eagle3-MLA | 2.04x | 2.05x | +0.3% |
這些數值是跨 GSM8K、MATH500、AIME、HumanEval、LiveCodeBench 與 SPEED-Bench Coding 的基準層級加速比之簡單未加權平均，並非按提示數量加權。較大的草稿視窗並不會自動改善吞吐量：額外的提議必須被足夠頻繁地接受，以抵消草稿與驗證的開銷。
LiveCodeBench 讓這個差異更加具體。對於 Kimi-K2.6，DSpark 從 n=3 時的 1.86 倍提升至 n=7 時的 1.87 倍，而 Eagle3-MLA 則從 1.67 倍下降至 1.48 倍。對於 Kimi-K2.7-Code，DSpark 從 1.75 倍增加至 1.78 倍，而 Eagle3-MLA 則從 1.69 倍下降至 1.52 倍。在 SPEED-Bench Coding 上，DSpark 在 Kimi-K2.6 上從 2.19 倍提升至 2.41 倍，在 Kimi-K2.7-Code 上則從 2.15 倍提升至 2.31 倍。
評測設定： batch size 1、線上 vLLM nightly 推測解碼、貪婪解碼、TP=8、max_model_len=20000、啟用 CUDA graphs、fuse_allreduce_rms=false。較高的 tokens/sec 與加速比為佳。Batch size 1 可隔離單一請求的解碼行為；在連續批次處理或更高並發的生產工作負載下，結果可能有所不同。完整結果可在 Kimi-K2.6 DSpark 與 Kimi-K2.7-Code DSpark 的 Hugging Face 頁面上取得。
為什麼 DSpark 能改善 Kimi 的推測解碼
我們的檢查點將 DSpark 應用於 Kimi-K2.6 與 Kimi-K2.7-Code，作為 vLLM 服務的草稿模型。
相較於 DFlash 平行草稿骨幹，DSpark 增加了兩個輕量級模組：一個用於低秩區塊內 token 依賴性的馬可夫邏輯偏置模組，以及一個用於接受預測的逐位置信心模組。DSpark 平行地提出完整的草稿區塊，然後利用這些模組來改善區塊層級的草稿品質，並估算驗證器可能接受哪些位置。
我們使用 vLLM 的 Speculators 框架的分支來訓練草稿模型。在訓練期間，草稿模型會擷取從 vLLM 中運行的即時 Kimi 驗證器串流出的隱藏狀態，使推測器與其在服務時將遇到的驗證器行為保持一致。
我們發布的表格使用相同的驗證器與服務設定，以可用的開源 Eagle3-MLA 檢查點作為草稿模型基線。核心結果在於這些方法如何在更大的推測視窗下擴展：從 n=3 到 n=7，DSpark 對 Kimi-K2.6 的平均加速比提升了 17.8%，對 Kimi-K2.7-Code 提升了 11.7%，而所列出的 Eagle3-MLA 基線平均而言幾乎持平，且在兩個 LiveCodeBench 評測中均出現減速。這表明隨著視窗增長，DSpark 能更有效地保持有用的草稿品質。此比較僅限於此處測試的檢查點、batch-size-1 工作負載與服務設定。
如何在 vLLM 中使用 DSpark 服務 Kimi-K2.7-Code
DSpark 支援目前需要 vLLM nightly 版本。對於 Kimi-K2.7-Code，請使用以下推測解碼設定：
uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly
vllm serve moonshotai/Kimi-K2.7-Code \
--tensor-parallel-size 8 \
--max-model-len 20000 \
--trust-remote-code \
--compilation-config='{"pass_config": {"fuse_allreduce_rms": false}}' \
--speculative-config '{
"model": "novita/kimi-k2.7-code-dspark",
"num_speculative_tokens": 7,
"method": "dspark"
}'
對於 Kimi-K2.6，請使用相同的設定，並將 speculative_config.model 指向 novita/kimi-k2.6-dspark。
已知的 nightly 版本注意事項： 草稿端的 FA3 AOT 排程可能需要在建構草稿注意力元資料時傳遞 fast_build=True，且 CUDA graph 捕獲可能遇到 FlashInfer all-reduce 工作區大小錯誤。已測試的設定會停用 fuse_allreduce_rms；請參閱連結的 Hugging Face 頁面以取得當前的解決方法。
DSpark 改變了解碼路徑，不會改變目標 Kimi 模型。我們建議從 num_speculative_tokens=7 開始，然後針對代表性的生產流量驗證吞吐量、接受長度、token 間延遲與端到端延遲。最佳設定將取決於工作負載形狀、批次處理與服務硬體。
