LFM2.5-24B-A2B-DSpark 與 LFM2.5-24B-A2B：你真的該掛上 Drafter 嗎？

用一句話說明這個決定：LFM2.5-24B-A2B-DSpark是一個 327.7M 參數的檔案，你要把它放在LFM2.5-24B-A2B旁邊，讓 24B 模型更快產生同類型的輸出。它不是該模型的替代方案，也不是讓你用來取代該模型的選項。這兩個名稱所帶出的唯一真正問題是工程問題——你要把草稿模型接到你的部署上，還是不要接——而答案與其說取決於 Liquid AI 對外主打的加速幅度，不如說取決於兩個沒人宣傳的數字：草稿模型在你的流量上能有多少個 token 被接受，以及你目前已經跑多大的併發量。像這次發布這類版本背後的已記錄 AI 失敗與代理事件，都收錄於OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

Liquid AI 尚未為草稿模型發布上線文章。該儲存庫於 2026-10-19 公開，內含權重、基準測試 CSV 與 SGLang 啟動旗標，而目標模型本身的模型卡仍將草稿模型標示為「即將推出」，Liquid 的推測解碼文件頁面也只列出 1.2B、2.6B、8B 與 VL-3B 這些目標模型。因此，這是拿已交付的成品與已發布的模型相比，而且是根據儲存庫而非新聞稿撰寫——這表示下方每一項效能數字都是廠商自行回報，且沒有任何一項經過獨立重現。

起草者實際改變了什麼，以及沒有改變什麼

這個機制值得花三十秒了解，因為它決定了一切。解碼一個 token 是受記憶體限制的：GPU 大部分時間都在把權重串流進 SRAM，而不是做算術運算。推測解碼利用這一點：讓一個小模型一次猜測接下來好幾個 token，再由真正的模型以單次前向傳遞檢查整個猜測。如果猜得準，你用大約一個 token 的成本產生了九個 token。如果猜得不準，目標模型會保留自己的 token，而你只多付出一點額外成本。

改變的是：每秒 token 數，以及 GPU 使用率的型態。不變的是：模型權重、上下文視窗、工具呼叫行為，以及其在銷售地區的價格。LFM2.5-24B-A2B 維持 24.0B 總參數、每 token 啟用 2.45B 參數，40 層分布於閘控短卷積與分組查詢注意力，每個區塊有 64 個專家並採用 top-4 路由，上下文長度 131,072 個 token，詞彙量 128,000 個 token。草稿模型新增五層注意力、一個秩為 256 的馬可夫頭與一個置信度頭，並重用目標模型的嵌入與 LM head，而非自帶一套。

有一點注意事項在兩個版本之間的位置變了，值得用一句話說明。八月時，Liquid 的 DSpark 技術說明寫道，所產生的序列「在構造上與基線貪婪解碼完全相同」。24B 草稿模型的說明卡則說，批次驗證與一般解碼之間的浮點差異「可能產生不同的文字，包括在貪婪取樣之下」。這兩種說法都站得住腳——第一種在精確算術下為真——但如果你的評估框架是逐位元組比對輸出，就得預期它會察覺到差異。

帳冊的成本面

草稿模型並非免費。它在 GPU 上以 BF16 佔用 655 MB（在 CPU 上則是 664 MB 的 F16 GGUF），且與目標模型位於同一個記憶體池；它每提出一步，代價都是要對一整塊 token 做一次驗證前向傳遞，而非只處理單一 token。對 MoE 目標模型來說，最後這點比聽起來更昂貴：驗證九個 token 會啟動比解碼一個 token 更多的專家，因此每個已驗證 token 所搬移的位元組數不降反升。Liquid 正是以此說明，為何其 8B 草稿模型在 M4 Max 上儘管接受率很高，卻只帶來 1.18× 的加速。

相較之下，節省下來的量足以用 GPU 小時來衡量。使用廠商自家的 B300 數據，來源為benchmarks/b300-fp8.csv，且僅將十億個輸出 token 除以觀測到的吞吐量：

• MATH-500，併發數 1 —— 單獨執行時為 324 tok/s（每十億個 token 需 857 GPU 小時），使用草稿模型時則為 853 tok/s（326 GPU 小時）。運算時間縮短了 2.63 倍。

• MATH-500，併發數 256 — 單獨執行時為 15,423 tok/s（18.0 GPU 小時），搭配草稿模型則為 27,579 tok/s（10.1 GPU 小時）。減少 1.79 倍。

• GSM8K，併發數 256 — 單獨執行為 4,491 tok/s（61.9 GPU 小時），搭配草稿模型則為 9,660 tok/s（28.8 GPU 小時）。省下 2.15 倍。

• LiveCodeBench，並行度 256 — 單獨執行時為 18,812 tok/s（14.8 GPU 小時），搭配草稿器時則為 25,231 tok/s（11.0 GPU 小時）。僅減少 1.34 倍，是表格中最弱的一項。

那些是將吞吐量比率換算成時間，而非換算成金錢，因為金錢取決於你每 GPU 小時支付多少，而本文不會憑空編造一個費率。但不論費率為何，排序都成立：在低併發時，附加 drafter 對推理與程式碼生成流量而言，每十小時可省下兩到三小時；在高併發時，價值大約是前者的三分之一。如果你的 24B 部署是工作站上的單使用者代理，這個理由很充分。如果它是飽和的批次端點，這個理由雖然真實，但比 2.4× 這個標題所暗示的薄弱許多。

就工作量而言，起草工具在哪些方面能證明自己的價值

廠商表格中八個資料集之間的差異不是雜訊；它對應到不同的提示類型，而這個對應是這次發布內容中最有用的部分。接受長度從 MBPP 的每步 6.70 個 token，一路降到 LiveCodeBench 的 4.02。得分高的資料集，是模型輸出受提示約束的情況——簡短的單元測試風格函式、具有可檢查路徑的算術、選擇題答案。得分低的資料集，則是模型必須發想出冗長且不受約束的解法：競賽程式設計題目與 AIME 風格數學題。

這就是你在進行自身評估時應抱持的直覺。一款以代理式工作為賣點的 24B 推理模型，會把大部分輸出 token 花在思維鏈中，這看起來更像 LiveCodeBench，而不是 MBPP。用於結構化擷取、依結構描述進行分類，或固定工具呼叫格式的模型，看起來則更像高接受率的資料列。如果你的工作負載屬於前者，預期落點會更接近範圍下限 1.34×，而非上限 3.28×。目前還沒有人發表這個草稿模型的逐工作負載接受率，而模型卡上的八個資料集是最接近指引的參考。

與此相對：24B 是純推理模型。Liquid 表示它總是在回答前先思考——聊天範本會自動插入一個 <think> 標籤。對推測解碼來說，這是最糟糕的結構，因為推理區段正是那段漫長、接受率低的區間。草稿模型仍會有幫助；它對最終答案的幫助最大，對耗時最久的部分幫助最小。

如何在一個下午內，用自己的硬體判斷出來

你不必相信上述任何內容。兩種推論路徑都會揭露接受計數器，而這是唯一能決定草稿器在你的流量上是否回本的數字。

在 SGLang 上，啟動目標模型並掛上 drafter，block size 設為 9、draft token 設為十個，然後讀取伺服器針對每個請求回報的 speculative-decoding 指標。廠商表格中的接受率依資料集不同，介於 0.33 與 0.65 之間；若某次執行的結果遠低於對應列，代表 drafter 猜錯了，你付了驗證成本卻沒換到加速。在 llama.cpp 搭配 F16 GGUF sidecar 時，每次回應的計時會帶有draft_n 與 draft_n_accepted，可直接取得。將其一除以另一個。

有兩個操作細節，若漏掉會讓你多花一小時。SGLang 伺服器需要一個建置版本，其中包含於 2026-08-31 合併的 LFM2-MoE DSpark 路徑——在更舊的版本上，草稿模型架構根本未知。而區塊大小是檢查點本身的屬性，不是可自由設定的參數：llama.cpp 會把 --spec-draft-n-max 限制為 sidecar 中繼資料中的值 9，所以要求 12 也毫無用處。

這個比較無法回答的問題

「我該不該掛上草稿模型」有一種版本與 GPU 完全無關，而這正是大多數團隊實際面對的情況。如果你是透過託管 API 呼叫 LFM2.5-24B-A2B，草稿模型的決定就不在你手上。服務堆疊要嘛掛上推測解碼器，要嘛不掛；你看到的是每秒 token 數和價格，而這兩者都是上游決定好的。Liquid 自家的 Console 將 24B 列為每百萬輸入 token $0.10、每百萬快取輸入 token $0.05，以及每百萬輸出 token $1.00——這是公開費率，已經反映他們所採用的任何解碼路徑，而且可能未經通知就變更。

這正是路由能發揮幫助、而非讓事情變複雜的分界點。託管呼叫與自架部署與其說是互相競爭的方案，不如說是同一個成本旋鈕的兩種設定：若你的用量能讓 GPU 持續滿載，自架加上 drafter 能將每 token 成本降到最低；而託管端點則能將取得答案所需的工作降到最低。OrcaRouter 正是為後者而打造——一組金鑰即可橫跨200 多個模型，且在供應商定價上零加成，因此供應商調價當天就會反映在我們這邊，並具備供應商效能劣化時的自動容錯移轉，以及用來分流流量、而非硬編碼單一後端的路由 DSL。我們目前並未提供 LFM2.5 系列，因此就這個特定模型而言，託管選項指的是 Liquid 自家的 API 或你自己的 GPU；值得進行的比較，是拿我們實際提供的模型來對照，例如Qwen3.6-35B-A3B——Liquid 在代理任務上用來對標的模型——或Gemma 4 26B-A4B。

所以：要附上它還是不附？

如果你以中等併發量自行提供 LFM2.5-24B-A2B 服務，尤其是針對結構化或擷取型輸出，而且目標模型旁還有 655 MB 的餘裕，就把它掛上。廠商數據顯示，在那裡你的解碼時間大約可減半或降至三分之一，而缺點是有界的：不良的草稿模型只會多花一次驗證流程，不會造成錯誤答案。

如果你的端點已經在數百的量級上飽和、如果你的輸出是冗長的非結構化推理，或者如果你需要在投入前先取得 Apple Silicon 的數據，就保持關閉——這張卡沒有這些數據，而同系列中最接近的對應型號在 MacBook 上達到 1.18×。而且顯而易見地，如果你根本沒有在執行這個模型，也請保持關閉：草稿模型是針對部署的優化，而在部署存在之前，沒有什麼可優化的。

能讓其餘問題塵埃落定的，是廠商公告與一項 Mac 實測數據。截至 2026-10-21，兩者都還不存在；對於一個權重已可下載的發布版本來說，這是個奇怪的狀態——而對任何願意自行執行驗收計數器的人而言，這是一個異常低廉的機會，能成為排行榜上第一個獨立數字。