LFM2.5-24B-A2B 對比 LFM2.5-8B-A1B-DSpark：其中一個不是你能執行的模型

把 LFM2.5-24B-A2B和LFM2.5-8B-A1B-DSpark放進同一張比較表，這張表在你填上任何一格之前就已經是騙人的。Liquid AI 的 LFM2.5-24B-A2B 於 2026 年 10 月 13 日發布，是一個語言模型：24.0B 參數、每個 token 2.45B 啟用參數、131,072 tokens 上下文，而且它會回答提示詞。LFM2.5-8B-A1B-DSpark 於 2026 年 8 月 20 日發布，是一個 3.277 億參數的草稿檢查點，本身什麼都回答不了——它的存在，是為了替另一個模型 LFM2.5-8B-A1B 猜測接下來會出現的 token，並由那個模型來檢查。把兩者混為一談，是這次發布最常見的誤讀方式，而這一點值得在第一段就講清楚，因為本頁其餘內容全都取決於此：這兩者當中，一個有每百萬 token 的價格，也有一張能讓你把 agent 指向它的 Hugging Face 卡片，另一個則活在別人的推論堆疊裡。

不過，真正讓這個配對值得單獨用一頁來談的，是這其實是 Liquid AI 為自己設下的比較。LFM2.5-24B-A2B 的模型卡列出，專為 24B 打造的 DSpark 推測解碼草稿即將推出。等它真的問世，這一頁所回答的那個問題，就會是人們對它提出的同一個問題——那個讓 8B 模型在資料中心 GPU 上最高快上 3.18× 的草稿技巧，是否真能在一個存在的全部理由就是筆電的 24B 模型上奏效？8B 的數字裡其實已經藏著答案的形狀，而那不是標題所暗示的形狀。

用三句話說明草稿檢查點究竟是什麼

推測解碼把一個便宜的模型放在昂貴模型前面：草稿模型提出一整塊候選 token，真正的模型以單次前向傳播驗證整塊，並保留它認同的部分。由於目標模型會檢查每一個被提出的 token，貪婪解碼下的輸出與單獨執行目標模型逐位元完全相同——Liquid 的說法是「依構造即無損」，這也是為什麼草稿模型可以安全地加裝到正式環境堆疊上。LFM2.5-8B-A1B-DSpark 是刻意設計得小的草稿模型：五層純注意力層、每步提出九個 token 的區塊，以及在目標模型 128,000 個 token 詞彙表上的 Markov 頭，以聊天、程式碼與函式呼叫資料訓練 15 個 epoch，並依接受率而非驗證損失來挑選檢查點。

最後那個細節並非無關緊要。Liquid 自己的技術文章指出，對於較大的草稿模型，驗證損失「在我們所關注的基準接受率停止變動之後仍持續改善」——這種句子，只有當一個團隊是要把這個東西部署到正式服務、而不是發表論文時，才會出現。

兩個堆疊，每個維度一行

• 這是什麼——LFM2.5-24B-A2B 是一款可部署的推理模型，輸入文字、輸出文字。LFM2.5-8B-A1B-DSpark 則是推測解碼加速器，僅此而已。

• 規模 — 總計 24.0B／每個 token 啟用 2.45B，64 個專家在 40 層中採用 top-4 路由，相較於五個純注意力層中的 327.7M 草稿參數。

• 上下文 — 24B 為 131,072 個 token，是前一代的兩倍；草稿模型本身沒有上下文，因為它是在目標模型的串流上運作。

• 推理 — 24B 總是會在 <think> 區塊內輸出明確的思維鏈。草稿則不會輸出任何使用者可見的內容。

• 價格 — 在 Liquid 的 Console 上，24B 每百萬個輸入 token 為 $0.10（快取為 $0.05），每百萬個輸出為 $1.00，並附贈 $2 起始額度。draft 模型沒有價格，因為目前沒有任何推論服務供應商提供服務。

• 授權 — 兩者皆採用 lfm1.0：可免費下載、微調及商業部署，直到公司年收入超過 1,000 萬美元，屆時便須取得商業授權。

• 已發布格式 — 從 14.5 GB 的 Q4_K_M 到 48 GB BF16 的 GGUF，13.6 GB 的 QAT QAD-Q4_0，FP8、ONNX，以及 24B 的 4/5/6/8 位元 MLX；草稿模型則有 Safetensors 與 GGUF，並於首日即支援 SGLang 與 llama.cpp。

決定一切的維度，是第五個所修改的最後一個：其中一個有每 token 的價格，另一個則是你安裝來讓自架模型每 token 更便宜的東西。它們從不競爭。它們會疊加。

真正重要的數字，以及那個該讓你擔心的數字

Liquid 在批次大小為 1、溫度為 0 的設定下，於五個資料集上量測了 DSpark 草稿模型——在配備 80GB 的 H100 上以 BF16 搭配 SGLang 執行，以及在 M4 Max MacBook Pro 上以 FP16 GGUF 搭配 llama.cpp 與實驗性 Metal 核心執行。每一項加速都是與同一目標模型在同一硬體上單獨執行時相比。所有這些都是廠商自行報告的數據，而且三個月過去，仍未被重現。

在 H100 上，與 LFM2.5-8B-A1B 相比：

• MATH500 — 3.18×（428 → 1,362 tokens/s，接受率 8.27）——最受矚目的數字。

• MT-Bench — 3.02×（426 → 1,288 tokens/s，接受率 8.52）。

• MBPP — 2.64×（426 → 1,122）以及 HumanEval — 2.58×（426 → 1,100）。

• GSM8K — 1.29 倍（385 → 496，接受長度 4.02）—— 這是表現較弱的情況，且請注意，這正是目標模型原本就已經更快的那一個。

• 平均 — 2.54×（418 → 1,074 tokens/s）。

在 M4 Max 上，相同的草稿模型對上相同的目標模型，會得到截然不同的成果：MATH500 1.21×（93 → 112）、GSM8K 1.44×（90 → 129）、HumanEval 1.12×（91 → 101）、MBPP 1.09×（89 → 97）、MT-Bench 1.04×（87 → 90），平均 1.18×（90 → 106）。

把這兩份清單放在一起看，結論無可迴避：草稿檢查點加速的是模型原本並非為其打造的硬體，卻幾乎撼動不了它原本所針對的硬體。這不是 Liquid 實作上的錯誤，而是瓶頸所在——推測解碼在你運算閒置、記憶體吃緊時才有回報，而一台執行量化、活躍參數 1.5B 的 MoE 的 M4 Max，早已逼近其記憶體頻寬上限。Liquid 自己公布了結果中不好的那一半，這就是為什麼 3.18× 這個數字被單獨引用的頻率，遠高於大多數讀者實際上會體驗到的 1.18×。

為什麼 24B 配對是一個真正懸而未決的問題

關於即將推出的 LFM2.5-24B-A2B 草案，除了模型卡上的「coming soon」之外，一切均未公布，因此接下來的内容是對問題輪廓的推論，而非一份報告。

草稿的價值取決於接受率，而接受率取決於目標模型有多可預測。一個總是產生明確思維鏈的推理模型——LFM2.5-24B-A2B 正是如此，而 Liquid 為它提供的建議溫度是 0.1——會輸出很長、局部可預測的文字段落。那正是 9 個符元區塊的理想土壤。因此，24B 草稿的上限可能很高，而模型卡本身的詞彙表註記也有幫助：24B 使用的正是 8B 草稿模型的馬可夫頭所建立於其上的同一個 128,000 符元詞彙表，所以草稿頭不需要從不同的符元空間重建。

制衡點在硬體。24B 模型宣稱的邊緣端結果是在 Apple M5 Max 上每秒 184 個 token，而更大的目標代表著更大的驗證流程，即使整個區塊被接受也一樣。如果 8B 的模式成立——在有多餘運算資源的地方大勝，在筆電上只有小勝——那麼 24B 草稿模型可能到頭來只是個附掛在邊緣模型上的資料中心工具，這對產品來說是很奇怪的形態。任何預期它而引用「3.18×」的人，引用的都是在不同模型、不同硬體、不同草稿模型上測得的數字。

成本，以及完全不自行託管的理由

有個必須誠實面對的複雜之處：DSpark 的整個價值主張在於每個自行託管 token 的吞吐量，因此其經濟考量便是你自己 GPU 時間的每 token 成本。相較之下，24B 模型有公開定價——每百萬輸入 token 為 0.10 美元（快取為 0.05 美元），每百萬輸出 token 為 1.00 美元——如果你根本不想在自己的筆電上執行 14.5 GB 的量化檢查點，這就是你所需支付的價格。

先說清楚我們提供與不提供什麼：我們不在 OrcaRouter 上提供 LFM2.5-24B-A2B 或 LFM2.5-8B-A1B-DSpark。我們提供的是這項決策不斷遇到的開放權重模型——qwen/qwen3.6-35b-a3b，也就是 Liquid 將其 24B 拿來對比的模型，總參數與活躍參數大約多出百分之五十，再加上google/gemma-4-26b-a4b-it，obsidian/gemma-4-26B-A4B以及google/gemma-4-31b-it，這些都屬於同樣的稀疏開放類別。如果你正在權衡 14 GB 下載與推測解碼堆疊，對比用單一金鑰呼叫已提供的模型，並以供應商標價零加成，這是你可以今天下午在我們這邊實際跑、而在他們那邊只能估算的比較。

今天要拿他們兩個怎麼辦

如果你想找一個能呼叫的模型，答案就是 LFM2.5-24B-A2B，而 DSpark 檢查點對你來說無關緊要——它只加速某一個特定的 8B 模型，而且也沒有任何第三方平台提供這兩者。如果你已經在 GPU 上自行託管 LFM2.5-8B-A1B，這個草稿模型就是免費的輸送量倍增器，完全不會改變你的輸出，而平均 2.54× 是實實在在的服務成本降低。如果你是在 Mac 上自行託管，平均值是 1.18×，而誠實的解讀是：這個草稿模型的價值大約只有發表時頭條所暗示的十分之一。

值得關注的不是 24B 草稿模型的到來日期，那沒有人公布過。而是它會落在兩種體制中的哪一種。如果 Liquid 公布在 Apple silicon 上的平均高於 2×，推測解碼就已跨過界線，邊緣層級也真正變得更便宜運行。如果它公布的是峰值數字，卻沒有筆電平均，那麼 8B 的結果一直以來就是答案：這項技術在你有多餘運算資源時才划算，而一台用電池運行 24B 專家混合模型的機器，並沒有任何多餘資源。

像這樣的比較，也正是失效模式會浮現的地方：這一類模型背後有紀錄的 AI 事故與代理失效，都彙集在OrcaRouter AI 事故檔案庫，其中每一筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。