Liquid AI 為旗下語言模型系列 LFM2.5 發表了一組名為 DSpark 的草稿模型。透過推測解碼，在完全不更動模型輸出文字的前提下，GPU 上的吞吐量最高提升 3.18 倍，MacBook 上最高提升 2.87 倍。權重已在 Hugging Face 公開，llama.cpp 與 SGLang 也在發表首日就提供支援。

推測解碼加速的到底是哪一段

大型語言模型逐一吐出 token 的過程，瓶頸不在運算本身，而在於把模型權重從記憶體搬進運算單元所耗費的時間。不論是 NVIDIA H100 這類高階 GPU，還是 MacBook、手機這種手邊的裝置，情況都相同。每產生一個 token 就要重讀一次龐大的權重，運算單元大半時間其實都在等待。

推測解碼的做法，是把這段等待時間攤開來共用。先讓一個小而輕的草稿模型預測接下來的數個 token，主模型再以一次前向運算一併驗證。命中的部分整批採用，從第一個不吻合的位置起改由主模型接手。由於每讀取一次權重能確定的 token 變多了，體感速度自然就上來了。

值得注意的是，在貪婪解碼下，輸出在原理上與原本完全相同。草稿提出的 token 只有在符合目標模型分布時才會被採用，被拒絕的位置則換成目標模型原本會輸出的 token。因此基準測試的正確率不會改變。把它想成只買速度、不動品質的改良，會比較好理解。

DSpark 多加的三個部件

DSpark 本身是 2026 年提出的方法，與 EAGLE-3、DFlash 屬於同一條脈絡。其內容由三個部件組合而成。

第一個是平行骨幹，它接收目標模型傳來的脈絡特徵，一次為整個區塊的候選 token 產生隱藏狀態與基礎 logits。第二個是輕量的循序頭，把相鄰的 token 視為馬可夫鏈，讓每個位置的機率往與前一個已取樣 token 相符的方向偏移。純粹平行預測時，越後面的位置越容易失準，這個部件把依賴關係補回來，藉此拉高採用率。

第三個是依信心程度調度的驗證器。它以獨立的頭預測每個草稿 token 被採用的機率，並把驗證成本高於效益的尾端切掉。能依照硬體餘裕動態調整驗證長度，正是實作上的巧思所在。

公開的草稿模型體積相當小：5 層結構、區塊大小為 9，參數量各約 3 億。Liquid AI 也說明，訓練與所有消融實驗都是在 AMD 硬體上、使用自家的訓練框架完成的。

加速幅度取決於草稿猜得準不準

數字會隨著目標模型與工作內容而明顯擺盪。量測環境為單張 H100 80GB 搭配 SGLang，以及搭載 M4 Max 的 MacBook Pro 搭配 llama.cpp 與 Metal，皆為批次大小 1、溫度 0。評測資料集使用 MATH500、GSM8K、HumanEval、MBPP 與 MT-Bench。

主力的 2.6B 模型在 GPU 與裝置端都全面改善，在 MacBook 上的產生速度來到每秒 140 個 token 左右。這已經超越不少商用雲端模型的回應水準，也讓在手邊完成推論的理由更加充分。

1.2B 模型屬於不做思考鏈的類型，各資料集之間的採用率落差較大，加速幅度的落差可達 52%。8B-A1B 的狀況更為複雜：GPU 上平均提升 2.54 倍，裝置端卻只有 18%。一方面是 llama.cpp 的 Metal 後端目前對 MoE 的實作仍有限制，另一方面是一次驗證多個 token 會啟動更多專家，權重搬運量也隨之增加。Liquid AI 如實公布了這組數字，並將其列為後續要處理的課題。

真正有感的是讓人乾等的場景

被點名受惠最多的用途，是一邊呼叫工具一邊推進的代理式處理。這類流程中，模型每次呼叫工具前都要先思考一輪，而使用者從頭到尾都在等。

在函式呼叫評測資料集 BFCL 上的量測顯示，橫跨各種多工具情境，回應延遲平均縮短了 57%。等待時間能否砍到一半以下，往往就是裝置端代理能否日常使用的分水嶺。Liquid AI 想把 2.6B 打造成第一個實用的裝置端代理模型，放在這個脈絡下看也就說得通了。

想在自己的環境跑跑看

草稿模型已在 Hugging Face 上提供 Safetensors 格式與 GGUF 格式。GGUF 對應透過 llama.cpp 的裝置端推論，SGLang 則對應使用 GPU 的正式營運部署。相關整合都已併入官方儲存庫，不需要另外追蹤分支。不過 Metal 這一側的數據是以實驗性核心量測的，能否原封不動重現得看環境而定。

權重可自由下載、微調與再散布，1.2B、2.6B、8B-A1B 三種尺寸則讓人依照精度與檔案大小的取捨來挑選。

總結

DSpark 是一組在不更動輸出的前提下、單純拉高推論速度的草稿模型。GPU 最高 3.18 倍、MacBook 最高 2.87 倍是它交出的成績，但提升幅度取決於草稿的命中率，採用 MoE 架構的 8B 模型在裝置端的效益目前仍然有限。即使如此，函式呼叫延遲平均縮短 57%這項結果，確實讓在手邊執行的代理往實用又靠近了一步。