Hugging Face 今日發布了 LFM2.5 系列中三款模型的 DSpark 草稿模型檢查點,包括 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。這些模型新增了推測解碼路徑,僅需微幅增加記憶體,即可大幅提升解碼速度,同時不改變輸出品質。
這項更新帶來了顯著的推論加速:在 GPU 上吞吐量最高可提升 3.18 倍,在裝置端最高可提升 2.87 倍。對於 LFM2.5-2.6B 模型,它平均將函數呼叫延遲降低了 57%,有助於實現裝置端的代理式推論。此外,這些模型從發布首日就支援 llama.cpp 和 SGLang,其 LFM 相容的 DSpark 整合已開源。
大型語言模型(LLM)的推論解碼階段傳統上受記憶體限制。大部分延遲來自於將權重從 DRAM 串流到 SRAM,而非密集的計算。推測解碼技術透過使用一個輕量級的草稿模型來產生候選詞元,然後讓目標模型在單次前向傳播中驗證所有候選詞元,從而分攤載入權重的成本。
多年來,人們提出了多種推測方法,其中最著名的是 EAGLE-3、DFlash,以及最近的 DSpark。DSpark 結合了三個關鍵組件:一個 DFlash 風格的平行骨幹網路,它根據目標模型的上下文特徵,在單次前向傳播中為所有草稿詞元產生隱藏狀態;一個輕量級的序列頭部,模型化為相鄰詞元之間的馬可夫鏈,增加了詞元間的依賴性,提高了後續位置的接受率;以及一個信心排程驗證器,它預測每個詞元的存活機率,並在驗證成本超過其節省時修剪低信心的後綴。
我們遵循 DSpark 的訓練方法,並使用了更大、更多樣化的資料組合,涵蓋了 SFT、聊天、程式碼和函數呼叫資料。根據我們的消融實驗,草稿模型的第一個版本是簡化的僅注意力機制模型,包含 5 個層和一個 9 個區塊。對於每個草稿模型,我們在整個資料集上進行了 15 個訓練週期,並選擇了接受率最高而非損失最低的週期。
這些草稿模型相對較小,每個模型約有 3 億個參數。例如,LFM2.5-1.2B-Instruct 的草稿模型總參數為 2.957 億,而 LFM2.5-8B-A1B 和 LFM2.5-2.6B 的草稿模型總參數則為 3.277 億。
在貪婪解碼(greedy decoding)下,草稿詞元只有在與目標模型的分布匹配時才會被接受。如果被拒絕,則由目標模型自身的詞元取代。因此,透過這種設計,輸出的序列與基準貪婪解碼的結果是相同的,這表示基準測試的準確性(pass@1 或精確匹配)並未改變。
我們為 LFM2.5 推出的 DSpark 草稿模型,從發布首日就支援 llama.cpp(其實現基於官方程式碼庫,並運行實驗性的 Metal 核心)和 SGLang(其實現基於 DSpark 的官方 SGLang 實作)。我們使用 llama.cpp 和 Metal 在 M4 Max MacBook Pro 上測量裝置端吞吐量,使用 FP16 GGUF 權重,輸出詞元最多 256 個。
我們使用 SGLang 在單個 H100 80 GB GPU 上以 BF16 測量 GPU 吞吐量。兩種配置都使用 9 的 DSpark 區塊大小、1 的批次大小和 0 的溫度。我們在五個基準資料集上進行了評估。所有三個草稿模型在大型加速器(H100)和邊緣部署(M4 Max MacBook)上都顯示出顯著的吞吐量提升。
對於 LFM2.5-2.6B 模型,在 MacBook 上的加速尤其明顯,它將使用者可享受的互動性水準推向了大多數專有雲端模型(約 140 詞元/秒,取決於資料集)所提供的吞吐量之上。平均而言,LFM2.5-2.6B 在 H100 上實現了 2.67 倍的加速,在 M4 Max 上實現了 2.27 倍的加速。在各種多工具情境中,DSpark 平均將 LFM2.5-2.6B 的延遲降低了 57%。
對於 LFM2.5-1.2B-Instruct,我們觀察到資料集接受率的差異更大,因此加速效果會因底層文本分布而異,最高可達 52%。平均而言,該模型在 H100 上實現了 2.10 倍的加速,在 M4 Max 上實現了 2.54 倍的加速。
對於 LFM2.5-8B-A1B,與兩個密集模型相比,接受率有所提高,但在裝置端平均僅獲得 18% 的改進。這個差距是由於 llama.cpp 的 Metal 後端中目前的 MoE(混合專家模型)實作,以及驗證 k 個詞元會比單次解碼步驟啟動更多專家並產生更多權重流量的事實所致。平均而言,該模型在 H100 上實現了 2.54 倍的加速,但在 M4 Max 上僅為 1.18 倍。
使用 SGLang 運行 DSpark 草稿模型需要支援 LFM2 目標的 SGLang 版本(PR #31041)。您可以透過以下指令啟動帶有草稿模型的目標:
```
python -m sglang.launch_server \
--model-path LiquidAI/LFM2.5-2.6B \
--speculative-algorithm DSPARK \
--speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark \
--speculative-draft-attention-backend flashinfer \
--disable-radix-cache --mem-fraction-static 0.75 --port 30000
```
然後,您可以查詢位於 http://localhost:30000/v1 的 OpenAI 相容端點。區塊大小會從草稿模型的 config.json 中讀取;基準測試則是不帶三個 --speculative-* 旗標的相同指令。
若要使用 llama.cpp 運行這些模型,則需要相應的 llama.cpp 版本(PR#27383)。指令範例如下:
```
llama-server -m LFM2.5-2.6B-F16.gguf \
-md LFM2.5-2.6B-DSpark-F16.gguf \
--spec-type draft-dspark --spec-draft-n-max 10 --spec-draft-n-min 0 \
-fa on -ngl 99
```
區塊大小會從側邊中繼資料中讀取(n-max 會被限制在其中)。推測解碼是精確的:目標模型會驗證每個提議的詞元,因此貪婪解碼的輸出與單獨使用目標模型的輸出相同;每次回應的計時會報告 draft_n / draft_n_accepted。
DSpark 草稿模型的檢查點已在 Hugging Face 上提供,格式包括 Safetensors 和 GGUF。您可以找到 LFM2.5-2.6B-DSpark、LFM2.5-1.2B-Instruct-DSpark 和 LFM2.5-8B-A1B-DSpark 的 Safetensors 版本,以及 LFM2.5-2.6B-DSpark-GGUF、LFM2.5-1.2B-Instruct-DSpark-GGUF 和 LFM2.5-8B-A1B-DSpark-GGUF 的 GGUF 版本。我們期待看到您將創造出什麼。
如需引用,請使用以下參考資料或 BibTeX:
Liquid AI, "LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook", Liquid AI Blog, Aug 2026.
```
@article{liquidAI2026dspark,
author = {Liquid AI},
title = {LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook},
journal = {Liquid AI Blog},
year = {2026},
note = {www.liquid.ai/blog/lfm2.5-dspark},
}
```



