LFM2.5-2.6B-DSpark：讓 Liquid 的裝置端代理執行速度快 2.3 倍的 328M 草稿模型

目前除了Liquid AI內部人員外，還沒有任何人曾在自己的硬體上運行LFM2.5-2.6B-DSpark並公開發表數據。這是討論這款模型時最誠實的起點，因為它整體而言就是一項效能宣稱：它不是更好的2.6B模型，而是一個328M參數的草稿模型，位於2.6B代理模型LFM2.5-2.6B之前，負責提出token供其驗證，因此代理運行速度約快一倍，同時輸出保持不變。

LFM2.5-2.6B-DSpark 於 2026 年 8 月 20 日發布，並附有 Hugging Face 上的技術文章及 Liquid 自家部落格的配套文章，是 Liquid 當天發布的一小組推測解碼草稿器檢查點中的旗艦型號。下方速度欄中的所有數據皆為廠商測量，尚未經獨立確認；儲存庫中的一切內容、格式以及框架支援，都可供直接查核。

用一句話說明 DSpark 是什麼

推測解碼的技巧是讓一個廉價的草稿模型跑在真正的模型前面：草稿模型猜測接下來的幾個 token，目標模型在單一次前向傳播中檢查整批 token，並保留它認同的 token。當猜測正確時，你以一個 token 的代價推進多個 token，因此吞吐量提升，同時完全不需動到目標模型的權重。DSpark——這項技術最初由 DeepSeek 研究人員於 2026 年 7 月提出，並已部署在 DeepSeek-V4 中——是針對小型裝置端模型調校的此技巧版本。Liquid 稱之為「信心排程推測解碼」（confidence-scheduled speculative decoding），它包含三個組成部分：一個平行骨幹，在一次前向傳播中為所有草稿 token 產生隱藏狀態；一個輕量級序列頭，建模相鄰 token 之間的依賴關係，使接受率不會在區塊後期崩潰；以及一個驗證器，在檢查低信心後綴的成本高於節省時，將其修剪掉。

最後那部分正是讓 DSpark 有別於一般起草器的關鍵：它不會總是將整個區塊推進驗證。當草稿本身的信心判斷某個後綴不太可能被接受時，它會提前截斷區塊，節省浪費的算力。草稿區塊有九個 token，因此目標每次最多驗證十個。

起草者，按數字

LFM2.5-2.6B-DSpark 檢查點是一個 0.3B 參數、僅含注意力機制的草稿模型：五個完整注意力層（隱藏大小 2,048，分組查詢注意力，32 個注意力頭和 8 個鍵值頭）、128K token 詞彙表、秩為 256 的馬可夫頭，以及一個信心頭。Liquid 在 AMD 硬體上，以指令、對話、程式碼和函式呼叫資料的混合資料訓練了 15 個 epoch，並根據最高接受率而非最低損失來選擇 epoch。

接受率是決定草稿模型價值的數字。在五個基準測試中，以批次大小 1、溫度 0 的設定下，LFM2.5-2.6B-DSpark 在 H100 上平均每個解碼步驟接受 4.83 個 token，在 M4 Max 上則為 4.42 個——大約接受了一半的區塊，兩倍加速正是由此而來。

標記的加速效果

以下所有數據均來自 Liquid AI 自身的測量——在單張 H100 80GB 上以 BF16 運行 SGLang，以及在 M4 Max MacBook Pro 上以 FP16 GGUF 格式、使用 Metal 後端的 llama.cpp，批次大小為 1，溫度為 0——截至撰寫本文時，這些數據尚未經獨立方重現：

• H100 平均 — 2.67×，從 323 到 864 tokens/s。按基準：MATH500 3.06×，HumanEval 2.56×，MBPP 2.64×，GSM8K 2.22×，MT-Bench 2.87×。

• M4 Max 平均 — 2.27 倍，從 61 到 139 tokens/s。按基準測試：MATH500 2.25 倍，HumanEval 2.63 倍，MBPP 2.11 倍，GSM8K 2.36 倍，MT-Bench 1.99 倍。

• 工具呼叫 — 在多重工具函式呼叫的情境中，平均延遲降低了 57%。

• 家族背景——家族中最大的草稿模型 LFM2.5-8B-A1B-DSpark 在 H100 上達到最高 3.18×，1.2B 草稿模型在 M4 Max 上達到最高 2.87×；上述 2.6B 的數字則居於中間水準。

除了平均值之外，這些數字還有兩點值得關注。{{1}}首先，它們是在溫度 0 和批次大小 1 下測量的——前者是有利於推測式解碼的配置，後者是互動式裝置端代理工作大多所處的配置。一致性保證在此同樣成立：推測式解碼會驗證每個提議的 token，因此在貪婪解碼下，產出的文字與目標模型單獨運行時所產生的完全一致。{{/1}}{{2}}其次，隨著並發度上升，差距會縮小：在單張 H100 上，Liquid 報告指出 DSpark 的優勢在批次大小約 128 時趨於收斂，因此草稿模型對互動式及重度工具導向的工作負載是延遲上的優勢，而非針對滿載伺服器原始吞吐量的銀彈。{{/2}}

什麼是已確認的，什麼又不是

已確認——就儲存庫公開且可查驗而言：草稿模型以 Safetensors（BF16）與 GGUF 形式發布；它與後訓練的 LFM2.5-2.6B 搭配，而非基礎模型；首日支援已進入 llama.cpp（含實驗性 Metal 核心）與 SGLang 的上游版本；其授權為 Liquid 的 LFM Open License v1.0；而且——對任何以其為規劃前提的人來說很重要——模型卡註明目前沒有任何推論提供商提供此模型，因此這是個需要自行執行的元件。

尚未確認的事項包括：加速效果能否在其他硬體與配置上重現（Liquid 以外尚無任何人發表過測量結果）、草稿模型在採樣模式而非貪婪解碼模式下會如何表現，以及 57% 工具呼叫延遲數據在 Liquid 所用的基準測試框架之外的真實代理框架中是否依然成立。這些都不是指控——發布才一天而已——但它們正是「有前景的數字」與「經過驗證的數字」之間的差異。

運行中

在 SGLang 中，你使用支援 DSpark 的建置版本，針對目標模型啟動伺服器，並指定草稿模型：推測演算法為 DSPARK，草稿模型路徑指向 LiquidAI/LFM2.5-2.6B-DSpark，區塊大小則從草稿的 config.json 讀取。在 llama.cpp 中，你載入目標 GGUF，並將草稿 GGUF 作為草稿模型，同時將 spec 類型設為 draft-dspark，區塊大小則從 sidecar 中繼資料讀取。這兩個整合都已經 upstream，因此不需要 fork——只要使用一個夠新的建置版本即可包含它們。

何時值得新增

LFM2.5-2.6B-DSpark 額外佔用的約 0.3GB 記憶體，只有當您實際將 2.6B agent 部署在 Liquid 設計的運行環境——手機、筆記型電腦或邊緣設備——並用於延遲受限且以貪婪模式執行的互動式或工具呼叫工作負載時，才算物有所值。正是在這種情境下，2.27 倍的裝置端加速數據與 57% 的工具呼叫延遲降低才得以發揮作用。如果您在伺服器上以高批次提供服務（加速比會趨近於 1 倍），或者您的工作負載在溫度參數大於 0 的情況下運行，那麼這些已報告的數字就不再適用，其吸引力也會降低。此外，如果您使用的是該系列的 8B-A1B 變體，請注意這個特殊情況：目前其裝置端加速僅約 1.18 倍，因為在 llama.cpp 的 Metal 後端中驗證草稿 token 會啟動更多專家——Liquid 已將此標記為已知問題。

DSpark 不會改變 2.6B 代理程式執行的位置——它本質上就是一個自架設的故事，而且它會與你已在呼叫的託管模型並肩運作。本地草稿模型與十幾個 API 端點的組合，正是路由層存在所要化簡的那種管線：一個 API 金鑰就能橫跨 200+ 模型、供應商效能衰退時自動故障轉移，以及供應商列表價格以 0% 加成直接傳遞，因此 2.6B 級代理程式的本地與託管成本比較依然清楚明瞭，而不是藏在試算表裡。

今天解讀 LFM2.5-2.6B-DSpark 的正確方式，是把它視為一項有前景、由廠商自行量測、尚未經獨立驗證的速度宣稱，而它所依附的檢查點是真實存在、可下載、可執行的。若你在裝置端部署 2.6B agent，草稿模型嘗試成本很低，移除也很簡單——在 SGLang 指令中加上兩個 speculative 旗標，維持 greedy decoding，並用你自己的負載實測之後，再來相信 2.3× 這個數字。Repo 就在那裡；獨立驗證是尚待完成的事項。