LFM2.5-24B-A2B-DSpark 對比 LFM2.5-8B-A1B-DSpark：同一個 328M 檔案，兩種截然不同的押注

下載任一檔案，得到的都是 655,421,522 位元組。LFM2.5-24B-A2B-DSpark與LFM2.5-8B-A1B-DSpark大小完全相同，精確到每個位元組，並共用五層主幹、相同的 rank-256 Markov 頭、相同的區塊大小 9，以及相同的 128,000 詞元詞彙表——但兩者都無法回答任何一個提示，因為它們都是推測解碼草稿模型，只為目標模型猜測詞元而存在。真正區分它們的並不是它們自身的規格，而是它們各自針對哪個目標模型訓練，以及有多少證據顯示這套技巧在該目標上奏效。其中一款有發布文章中公布的 GPU 與 MacBook 實測數據；另一款只有 GPU 表格，沒有任何發布公告。因此，在兩者之間做選擇根本不是在比較模型——而是在比較兩場賭注，而其中只有一場已經兌現。 像這類發布背後的已記錄 AI 故障與代理事件，都收錄在 OrcaRouter AI Incident Archive，其中每一條記錄都附有自己的來源、嚴重程度、信心評級與爭議標記。

檔案是雙胞胎；工作則不是。

並排檢視這兩份 config.json 檔案，幾乎每個欄位都吻合：隱藏層大小 2,048、中間層大小 6,144、SiLU 啟用函數、32 個注意力頭對應 8 個 KV 頭且頭維度為 64、五層全注意力層、區塊大小 9、enable_confidence_head: true，以及一個秩為 256 的 vanilla Markov 頭。參數數量完全相同，這就是為什麼 safetensors 檔案能逐位元組完全相符。

有三個欄位不同，而每一個都舉足輕重。

• 目標層截取 — 8B 草稿模型會讀取 24 層目標模型第 2、6、10、14 和 18 層的隱藏狀態；24B 草稿模型則讀取 40 層目標模型第 2、10、18、26 和 34 層的隱藏狀態。這正是讓這些檔案無法互換的欄位。

• 最大位置數 — {{1}}8B 草稿模型{{/1}}為 128,000，相較之下 24B 為 131,072，並與其各自目標模型的上下文視窗保持一致。

• RoPE theta — 5,000,000 對 10,000,000，由目標模型的位置編碼決定，而非取決於草稿模型的任何因素。

最後那一對是最清楚的證據，說明這些檢查點是針對各個目標模型分別訓練的，而不是從共同的基礎模型擴展而來。草稿模型沒有獨立的身分：它的輸入分布取決於目標模型的隱藏狀態長什麼樣子，而當目標模型的架構與訓練改變時，這些隱藏狀態也會改變。把 8B 草稿模型指向 24B 模型，光是層索引就會讓它變得毫無意義；即使層索引能對上，它被訓練來預測的 logits 也不會吻合。

每一個實際上究竟在加速什麼

這兩個目標的差異比「8B 對上 24B」這個命名所暗示的還要大，而且對任何認為較大模型在裝置端負擔較重的人來說，這個差異的方向正好相反。

• 總參數與作用中參數 — LFM2.5-8B-A1B 總計 8.3B，每個 token 有 1.5B 作用中；LFM2.5-24B-A2B 總計 24.0B，有 2.45B 作用中。

• 深度 — 24 層（18 個閘控卷積加上 6 個 GQA），對比 40 層（30 個卷積加上 10 個 GQA）。

• 上下文 — 128,000 個 token，對比 131,072。

• 訓練預算 — 38T token 對上 36T，因此較小的模型相對於較大模型並未訓練不足。

• 路由 — 8B 採用 64 專家的 MoE，搭配 top-4 路由，與 24B 相同，因此兩者都需承受會損害驗證的專家啟用懲罰。

兩者都是會先思考再回答的推理模型，這點在這裡比參數量更重要。推測解碼最大的弱點是冗長且不受約束的輸出，而思維鏈正是如此。廠商表格顯示了這一點：在兩個版本中，接受率最高的列都是像 MBPP 和 MT-Bench 這類簡答型基準，而最低的則是模型必須自行構思出冗長解題路徑的那些。

證據差距才是真正的差別

這就是兩個版本不再能相提並論的地方。8B drafter 於 2026-08-20 隨著完整家族發布一同推出，並在兩台截然不同的機器上進行測量：一台是透過 SGLang 以 BF16 執行單張 H100 80 GB，另一台是 M4 Max MacBook Pro，透過 llama.cpp 搭配實驗性 Metal kernels 執行 FP16 GGUF 權重。它在 H100 上平均達到 2.54×，在 MATH-500 上峰值達 3.18×，而在 MacBook 上僅有 1.18×——在五個資料集上平均為每秒 90 到 106 個 token。

24B drafter 只有一列硬體資料：單張 NVIDIA B300，搭配 FP8 target、BF16 KV cache、temperature 0。在八個資料集上，concurrency 1 時平均為 2.38×，concurrency 32 時平均為 2.69×，concurrency 256 時平均為 1.71×；在 concurrency 32 的 MBPP 上峰值為 3.28×。沒有 Mac 列，沒有 H100 列，也沒有任何公告文章解釋這項省略。

對於整個賣點都放在裝置端代理上的模型——Liquid 為 24B 發表的文章以 Apple M5 Max 上每秒 184 個 token 打頭陣——缺少的 MacBook 數字是這次發表中最關鍵的單一空白。8B 的結果說明了它為何可能很小：驗證一個 token 區塊比解碼一個 token 區塊會啟用更多專家，因此 MoE 目標每個被接受的 token 會搬動更多權重。而單看接受率並不是預測指標：8B drafter 實際上每步平均更多被接受的 token，超過 24B 的規格卡所報告的數字（五個資料集上 6.95，對比八個資料集上 5.16），卻在 MacBook 上仍只交出 1.18×。這才是值得記住的重點——在 8B 上，強勁的接受率並沒有挽救裝置端吞吐量。假設 24B 的表現不同，是一個背後沒有數字支撐的賭注。

對照閱讀這兩張表

主要比率並非在同基準下比較，不應彼此相減。不同的 GPU、不同的目標精確度、不同的資料集組合、不同的併發掃描。但即使存在這些不匹配，仍有兩種模式依然成立。

首先，上限相近。8B 在 H100 上的最佳儲存格是在批次大小為 1 時，於 MATH-500 達到 3.18×；24B 在 B300 上的最佳儲存格則是在並行度為 32 時，於 MBPP 達到 3.28×。此設計的草稿模型無論所服務的目標模型是哪一個，都落在相同的 1.5×–3.3× 區間，而這正是當草稿模型架構固定不變、只有權重改變時所預期的結果。

其次，更有用的是，下限正是各目標出現分歧的地方。8B 最弱的 H100 儲存格是 GSM8K，為 1.29×；24B 在並行度 256 下最弱的 B300 儲存格是 LiveCodeBench，為 1.34×，以及 AIME，為 1.36×。這兩個版本都沒有出現推測完全免費的情況，且兩者都出現了推測僅勉強值得佔用記憶體的情況。

兩張卡之間還有一處文件變更很容易被忽略，值得特別指出。8 月那份材料說，貪婪解碼下的輸出「依構造」與基線完全相同；8B 卡則承諾「輸出完全相同」。24B 卡反而警告，批次驗證與一般解碼之間的浮點差異可能產生不同文字，即使在貪婪取樣下也是如此。較晚的卡是更謹慎的那一份；如果你在 CI 中執行位元組層級的輸出差異比對，兩者都值得視為可能並非完全相同，而不是信任較早的承諾。

哪一個對你而言有相關性，取決於你的目標，而非你的預算。

沒有任何情境會是團隊基於優點而在這兩者之間選擇其一、捨棄另一者。你會運行 24B，是因為你需要 24B 模型的能力，而且機器能容納它——GGUF 的 Q4_K_M 量化下為 14.5 GB，或是 FP8 服務配置下用單張 B300。你會運行 8B，是因為總參數 8.3B、啟用 1.5B 才適合邊緣裝置或筆電，而草稿模型能挽回一些你因為縮小模型而犧牲的解碼速度。草稿模型是那個首要決策的附屬品，而這個決策幾乎總是在推測進入討論之前，就基於記憶體與品質做出來了。

唯一真正需要抉擇的情境是評估階段。如果你是在測試 DSpark 到底值不值得導入你的技術堆疊，8B 組合是成本較低的實驗：它能在單張 H100 上運行，有 Mac 上的數據可供你對照自己的筆電，而且廠商已經記錄了它在裝置端的失效模式。24B 組合則是更有趣的生產環境實驗，也是文件記錄較少的那一個。

對兩者而言，決定結果的數字是接受計數器，而不是廠商的表格。SGLang 會針對每個請求提供推測解碼的接受率；llama.cpp 則會在每次回應的計時中報告 draft_n 與 draft_n_accepted。用你自己的提示跑個十分鐘再相除。若接受率落在顯示卡平均值附近，草稿模型就划得來；若落在低端，你就是在買驗證回合，應該把它拆掉——而這個結論在兩個檢查點上都成立，因為機制相同。

這兩個檢查點都不是你可以呼叫的模型。

這正是容易讓人誤解的地方：有人在模型目錄中看到這些名稱，就以為它們是選單上的選項。它們不是端點。兩個 drafter 都沒有每百萬個 token 的價格，都不會出現在 API 列表中，也不會被提供模型的平台路由到——因為正確的配對方式是伺服器端設定，而不是請求參數。

Liquid AI 本身以每百萬輸入 token 0.10 美元、快取 0.05 美元、每百萬輸出 1.00 美元的價格販售 24B 目標模型，而它在該價格背後執行的任何推測解碼，對呼叫者而言都不可見。這就是現在市場的常態樣貌：有趣的工程發生在服務堆疊內部，而開發者拿到的只是一個費率和每秒 token 數。路由平台的價值所在，就是在那一層之上的比較——把候選模型放到它必須擊敗的模型旁邊。OrcaRouter 透過單一端點提供 200 多個模型，對供應商定價收取 0% 加成，因此當供應商的費率變動時，你看到的費率當天就會跟著變，而容錯移轉可避免候選模型在你評估期間成為單點故障。LFM2.5 系列目前不在其中，因此自行託管、附帶其草稿模型的 8B 或 24B 仍屬於本地部署；值得拿來與它對測的模型——Qwen3.6-35B-A3B（代理式任務方面）、Gemma 4 26B-A4B（效率方面）——正是我們所路由的模型。

DSpark 發布一年來所確立的是什麼

這個系列現在涵蓋四個文字目標與一個視覺目標，規模從 1.2B 到 24B，全部共用同一套草稿模型配方：約 300M 參數、五個注意力層、block 9，並以目標模型自身的隱藏狀態訓練。這種一致性才是真正的發現。Liquid 已把推測解碼從逐模型的研究專案，轉變成一道製造工序——同一個草稿模型，重新定向後，能在每個新模型推出後幾天內交付。這道工序是否值得在你的硬體上採用，取決於你的流量；而答案因工作負載而異的程度，遠大於因你下載這兩個檔案中的哪一個而異。

24B 版本為這幅景象增添的，並不是更好的比率。而是首次有草稿模型在沒有隨附書面說明的情況下推出——也是首次廠商自家的規格卡以直白的話告訴你，輸出終究可能不是位元完全一致。