LFM2.5-8B-A1B-DSpark 對比 LFM2.5-2.6B-Base：速度版對比原材料

按每個檢查點本身能做的事情來排列 LFM2.5 系列，LFM2.5-8B-A1B-DSpark 和 LFM2.5-2.6B-Base 會落在線的兩端——而這兩端都無法回答任何問題。前者是一個 327.7M 參數的草稿模型，存在的唯一目的是讓 Liquid AI 的邊緣混合專家模型更快地生成 token。後者是一個 2.69B 參數的原始預訓練檢查點，存在的唯一目的是被微調成其他模型。兩者都在 2026 年 8 月根據 Liquid 的 LFM 開放授權 v1.0 發布，在 Hugging Face 上都只需一次下載即可取得，而且都非常容易誤抓——因為它們的名稱聽起來像是同一件事物的兩個版本。

名字就是陷阱。「DSpark」讀起來像是家族中閃亮的新旗艦，而「Base」讀起來像是你可以實際執行的樸素預設版本。兩者都不是事實。DSpark 檢查點無法自行回答任何問題——它只為 LFM2.5-8B-A1B 提出 token 供其驗證。Base 也無法回答任何問題，但原因正好相反——它是一個未經調校的基礎模型，能預測文字，但從未經過後續訓練成為聊天或代理模型。這不是競爭關係；而是一條管線。一個檢查點位於服務堆疊的最末端，另一個位於訓練流程的最開頭。

兩個同名、但職責不同的檢查點

LFM2.5-8B-A1B-DSpark（2026 年 8 月 20 日發布）是一個推測解碼草稿模型：五層僅注意力的網路、每步提出九個候選 token 的區塊，以及在目標模型 128,000 個 token 詞彙表上的馬可夫頭。使用時，你把它與 LFM2.5-8B-A1B 並行載入——後者是 5 月 28 日便已推出的總參數 8.3B、活躍參數約 1.5B 之混合專家（MoE）模型——草稿模型負責猜測接下來幾個 token，目標模型則在一次前向傳播中驗證整個區塊，並保留所有它接受的 token。由於目標模型會逐一檢查每個 token，貪婪解碼下的輸出與單獨執行 LFM2.5-8B-A1B 完全相同：套用 Liquid 的說法，就是「結構上無損（lossless by construction）」。草稿模型是加速用的部件，不是大腦。它與 LFM2.5-1.2B-Instruct 和 LFM2.5-2.6B 的同系列草稿模型一同發布，各有 Safetensors 與 GGUF 格式，並在 SGLang 和 llama.cpp 獲得首日支援。

LFM2.5-2.6B-Base（2026年8月4日發布）位於流程的另一端：一個擁有26.9億參數的基礎模型，採用混合30層架構——22個雙門控短卷積區塊加上8個分組查詢注意力區塊——在約34兆個token上進行預訓練，並以中期訓練階段將上下文擴展至128K。它沒有聊天模板、沒有指令微調、也沒有公開的基準測試數據，而Liquid自家的模型卡僅建議將其用於大規模微調。它的全部意義，就是作為原材料，經由四階段後訓練流程——兩輪SFT、教師特化、在策略蒸餾、代理式強化學習——轉化為工具呼叫代理LFM2.5-2.6B。同屬一個系列、同一授權、同一下載頁面。但任務截然不同。

並列比較：七個維度，兩份工作

因為這兩個檢查點執行不同的任務，公正的比較能清楚區分雙方的角色：

• 這是什麼 — LFM2.5-8B-A1B-DSpark 是一個 0.3B 的推測解碼草稿模型；LFM2.5-2.6B-Base 是一個 2.69B 的原始預訓練基礎模型。

• 運行搭配 — DSpark 草稿模型與 LFM2.5-8B-A1B MoE（總計 8.3B 參數，每個 token 約 1.5B 活躍參數）配對使用；Base 則獨立運行，但僅作為未經調校的文字預測。

• 獨立使用 — DSpark 本身不會產生任何內容；它只會加速目標。Base 會產生文字，但沒有實用的產品行為 — 沒有指令遵循、沒有工具呼叫、沒有聊天模板。

• 輸出品質 — DSpark 繼承了目標的完全貪婪輸出，因為每個提議的 token 都經過驗證；Base 在任何任務上都沒有已發布的基準測試，這是設計使然。

• {{1}}速度{{/1}} — {{2}}DSpark 宣稱在其目標上達到供應商量測的平均加速：H100 上 2.54 倍（MATH500 上最高 3.18 倍）、M4 Max 上 1.18 倍，{{3}}未經複現{{/3}}；{{4}}Base {{5}}完全{{/5}}沒有推論速度的宣稱{{/4}}

• 記憶體佔用 — DSpark 在目標模型旁增加約 0.3GB 的草稿權重；Base 則是完整的 2.69B，可在 2.5GB 以下運行，是該系列中最小但真正具實力的基礎模型。

• 格式與可用性 — DSpark 提供 Safetensors 與 GGUF 格式，並於首日即支援 SGLang 與 llama.cpp；Base 提供 Safetensors 以及 GGUF、ONNX 與 MLX 格式，並可於 Transformers、vLLM、SGLang、llama.cpp 與 MLX 上運行。目前兩者皆無任何推論供應商提供服務——皆為自托管檢查點。

這場對決中唯一的數字來自一個實驗室。

這裡所有的量化數據都來自單一供應商的測量，於草稿發布當天取得，且尚未被獨立重現——請將其視為有前景的結果，而非已驗證的事實。Liquid 在 batch size 1、temperature 0 的條件下，於單張 80GB H100 上以 BF16 格式搭配 SGLang 測量了 LFM2.5-8B-A1B-DSpark，並在 M4 Max MacBook Pro 上以 FP16 GGUF 格式搭配 llama.cpp 的實驗性 Metal kernels 進行測量。在 H100 上，這對組合平均達到 2.54× 加速（418 → 1,074 tokens per second），其中在 MATH500 上取得最佳單一結果 3.18×（428 → 1,362 tok/s），平均約可接受 10 個提議 token 中的 7 個。在 M4 Max 上，同一對組合平均僅 1.18×（90 → 106 tok/s）——這是 Liquid 本身也指出的裝置端邊緣案例，因為在目前的 MoE Metal 後端中，驗證一個區塊會啟動更多專家，並使更多權重流量在記憶體匯流排上傳輸。

這組對比中的 Base 端完全沒有任何數字，而這種「沒有」本身就是規格。LFM2.5-2.6B-Base 是經過預訓練而非後訓練的；它從未針對聊天、工具使用或代理行為進行評估，因為沒有人打算這樣使用它。其有意義的數據是架構層面的：2.69B 參數、128K 上下文、一個支援 16 種語言的分詞器、運行所需不到 2.5GB。你不會對基礎模型進行基準測試；你基準測試的是你微調後的成果。

在做任何決定之前，有一個同家族內的反諷值得先點明。本文所討論的草稿——也就是 8B-A1B 的那一份——恰恰是在筆電上增益最少的（1.18×），而同家族 2.6B 的兄弟草稿（它加速的正是這個 Base 後訓練出來的同源兄弟）在 M4 Max 上平均可達 2.27×，且多工具函式呼叫延遲降低了 57%。如果目標裝置是手機或筆電，而非 GPU 主機，那麼速度的故事就寫在 2.6B 這條路上。

那麼，你要下載哪一個？

你永遠不必在這兩者之間直接做選擇，因為它們並非互斥的選項——但你確實必須知道當下自己身處哪一種情況：

如果你在你擁有的 GPU 上部署 LFM2.5-8B-A1B，並想從同一批硬體中獲得更多每秒 token 數，LFM2.5-8B-A1B-DSpark 是一個可逆的附加元件：使用 8 月 20 日的 DSpark 整合來建置 SGLang 或 llama.cpp，在啟動命令中指定 draft 名稱，保持 greedy decoding，區塊大小會從 draft 的 config 自動讀取。優點是吞吐量大約 2.5 倍，且輸出完全不受影響；缺點是多了 0.3GB 的額外權重，以及需要一個新到足以包含這些 PR 的建置版本。移除兩個 speculative flags，你就回到原本單純的目標模型。

如果你想打造自己的專屬模型——無論是領域模型、自訂語言助理，還是基於專有資料的微調——LFM2.5-2.6B-Base 都是開放權重生態系中最便宜且可靠的起點之一：2.6B 參數、不到 2.5GB、128K 上下文、多語言 tokenizer。DSpark checkpoint 對此完全派不上用場，因為它不是 base 模型。

如果你真的想要 Liquid 的裝置端代理——工具呼叫、多步驟任務——那麼這兩個你都不需要。你要的是後訓練的 LFM2.5-2.6B，之後再決定是否要加掛它自己的 draft。Base 是給想訓練的人用的原始材料；8B-A1B draft 是給已經部署 MoE 的人用的加速零件。錯誤的作法，是因為想要更快的代理而下載 Base，或是因為想要訓練的基礎而下載 drafter。

兩者連接之處 — 以及路由器的角色

這兩個檢查點都是自托管性質的部署方案。草稿是服務層的附屬元件，只存在於你自己的 SGLang 或 llama.cpp 技術棧中；基礎版則是訓練工件。兩者都不會出現在任何托管目錄中，也都沒有按 token 計價的公開定價。這在實務上意味著，無論走哪條路徑，最終都會與你目前呼叫的托管模型並肩運行——而這種混合狀態，正是路由層存在所要收斂的底層管道。

在服務端，草稿模型的經濟效益簡單且真實：{{1}}同一塊 GPU 每秒能產出的 token 增加 2.5×，代表時間縮短 2.5×，相同工作負載所需的 GPU 也大約減少 2.5×，且品質完全不受影響{{/1}}。但這個槓桿只有在{{2}}你自行掌握推論{{/2}}時才存在。一旦你透過 API 呼叫 8B-A1B，{{3}}加速的效益就由供應商保有{{/3}}——這時，API 端的比較才是真正重要的：{{4}}供應商收取多少費用，以及降價是否在宣布當天就傳遞到你身上{{/4}}。這就是直通路由器（pass-through router）的意義：{{5}}單一 API 涵蓋 200+ 種模型，供應商列表價格以 0% 加成直接傳遞，讓供應商的降價立即在你端生效{{/5}}，以及{{6}}自動故障轉移，讓單一供應商的延遲飆升不會變成你的延遲{{/6}}。你也可以透過同一個端點，將自行託管的 LFM 技術棧放在前端，這就是{{7}}你用真實流量測試全新草稿模型，卻不必把生產路徑押在它身上{{/7}}的方式。

LFM2.5-8B-A1B-DSpark 和 LFM2.5-2.6B-Base 共享同一個家族名稱，但工作完全相反：一個是安裝在邊緣 MoE 上的加速零件，另一個是 2.6B 智慧體（agent）賴以成長、未經調校的大腦。兩者都無法獨立運作。想加速你已在 GPU 上部署的 MoE，就選草稿模型（drafter）；想將 2.6B 基礎模型微調成屬於自己的東西，就選 Base；如果你想要的是能實際運作的智慧體，那麼兩個都別碰——因為這兩個 checkpoint 唯一的共同點，就是它們各自單獨使用時，都無法做出任何你能用的東西。

常見問題

我可以單獨運行LFM2.5-8B-A1B-DSpark嗎？

不。它是一個草稿模型，沒有獨立的輸出能力——它會提出候選 token，再由 LFM2.5-8B-A1B 目標模型進行驗證，因此它只存在於基於 8 月 20 日 SGLang 或 llama.cpp 整合所建置的推論解碼（speculative decoding）服務架構中。單獨下載它，你無法對其進行任何查詢。

LFM2.5-2.6B-Base 是在裝置端作為代理（agent）運行的檢查點嗎？

並非照原樣使用。Base 是未經指令微調、也沒有對話模板的原始預訓練基礎模型。作為 Liquid 裝置端代理運行的是經後訓練的 LFM2.5-2.6B，它由 Base 經四階段後訓練流程產生——若想加快速度，可搭配 LFM2.5-2.6B-DSpark 草稿模型。