LFM2.5-24B-A2B-DSpark 已在 Hugging Face 上線——只是 Liquid AI 還沒正式發布

Liquid AI 最大模型的模型卡仍寫著其推測解碼草稿模型是 即將推出。這個草稿模型不會推出。LFM2.5-24B-A2B-DSpark自 2026-10-19 起就有公開儲存庫、655 MB 的 BF16 檢查點、完整的基準測試表、隔天晚上發布的 GGUF 附檔，以及寫進其模型卡的 SGLang 啟動旗標。它沒有的是一則公告。LFM2.5-24B-A2B，也就是這個草稿模型旨在加速的 24B 混合專家模型，於 2026-10-13 有了一篇部落格文章、一個標明日期的發布、一份價目表，以及一個 playground 連結。它的草稿模型得到了一個儲存庫和一張模型卡，而 Liquid AI 自己關於推測解碼的文件頁面仍只列出 1.2B、2.6B、8B 與 VL-3B 目標模型為支援。這類發布背後有記錄的 AI 失效與代理事件，都收集在 OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重度、信心等級與爭議標記。

那個落差正是這裡的重點，而值得精確說明它意味著什麼、又不意味著什麼。一個權重公開、基準測試可從放在模型旁的 CSV 重現，且推論路徑已合併進上游的儲存庫，是真正的發布，不是外洩。但廠商從未以文字確認其中任何一點，沒有第三方測量過，而模型卡上的數字是同一團隊在他們選定的同一套硬體上測出的數字。本文把兩者分開：儲存庫確立了什麼，以及什麼仍然只是聲稱。

儲存庫裡實際上有什麼？

檢查點小到連檔案清單本身都很有資訊量。model.safetensors，大小為 655,421,522 位元組——BF16 格式的 327.7M 個參數——外加一份設定檔、一份授權條款，以及一個基準測試目錄。沒有其他東西。裡面沒有分詞器、沒有嵌入矩陣，也沒有 LM head，因為此架構在載入時會從目標模型重用這三者。這就是設計：草稿模型永遠只需要知道如何猜測目標詞彙表中的下一個 token 區塊，而不需要知道如何表徵世界。

這份設定確認了八月 DSpark 文章所描述的結構。五個全注意力層，隱藏大小為 2,048、中間大小為 6,144，採用 SiLU/SwiGLU；分組查詢注意力有 32 個頭與 8 個 KV 頭，頭維度為 64；一個 rank-256 的 Markov 頭和一個獨立的置信度頭；區塊大小為 9；詞彙量為 128,000；最大位置嵌入為 131,072，與目標的上下文視窗完全相符。唯一特定於 這個草稿模型的欄位是 target_layer_ids: [2, 10, 18, 26, 34]，對照 num_target_layers: 40——亦即 24B 模型中，草稿模型讀取其隱藏狀態作為上下文的五個層。這些索引正是為什麼為一個 LFM2.5 模型訓練的草稿模型不能直接指向另一個模型。

授權條款是 lfm1.0，與同系列其餘部分相同的自訂授權條款；對於打算重新散布綑綁的 target-plus-drafter 成品，而非僅在內部使用的人來說，這點值得留意。

基準表，解讀為廠商表

這張卡公布了八個資料集在並行度 1、32 與 256 下的吞吐量，執行於單張 NVIDIA B300，採用 FP8 目標、BF16 KV 快取與溫度 0。下方每一項數字皆為 Liquid AI 自行提供，尚未在該公司外部重現；原始資料列位於儲存庫的 benchmarks/b300-fp8.csv，如果你想自行核對算術的話。

• 八個資料集的算術平均數 — 並行度為 1 時為 2.38×，並行度為 32 時為 2.69×，並行度為 256 時為 1.71×。

• 最佳單一儲存格 — 在併發數 32 時，MBPP 為 3.28×，MATH-500 緊隨其後，為 3.04×。

• 最差的單一儲存格 — LiveCodeBench 在並行數 256 時為 1.34×，AIME 在 256 時為 1.36×。

• 每步接受的代幣數量——平均為 5.16，相對於由區塊大小加上目標獎勵代幣所設定的上限 10。

• 接受度最高——MBPP 每步 6.70 個 token；最低——LiveCodeBench 為 4.02。

關於那張表，有兩件事比標題本身更有意思。第一件是平均加速比在併發數 32 時比在併發數 1 時更高——2.69× 對上 2.38×——這與常見的推測性解碼說法相反，在那种說法裡批次處理會吃掉收益。第二件是它在 256 時崩掉。在 256 個並行請求下，單就目標模型在那張 GPU 上處理 MATH-500 時，就已經每秒產生約 15,000 個 token，而草稿模型的貢獻降到 1.79×。只讀到「2.4×」的服務團隊會把叢集規模估錯；對批次端點真正重要的數字是 1.71×，而且即使是這個數字，也是 B300 上的數字，其併發特徵是大多數部署不會相符的。

自八月以來有所改變的判決

當 Liquid AI 於 2026-08-20 為 1.2B、2.6B 與 8B-A1B 目標模型發布 DSpark 草稿模型時，其部落格文章提出了一項強烈主張：由於目標模型會驗證每個提出的 token，並以自身選擇取代被拒絕的結果，「因此，所發出的序列在構造上與基線貪婪解碼完全相同。」8B 草稿模型的模型卡也重申了這一精神，承諾「完全相同的輸出」。

24B 草擬器的說明卡並沒有那樣說。它說目標模型會驗證每一個提議的 token，接著寫道：「批次驗證與一般解碼之間的浮點數差異可能產生不同的文字，包括在貪婪取樣下也是如此。」它還補充說，這些測量評估的是效能，而非任務準確度。

這是一種更審慎的說法，而且這才是正確的。批次驗證不會以與循序解碼相同的順序執行相同的浮點運算，因此位元一致性是一項在精確算術中成立、但在真實硬體上未必總是成立的假設。較新的模型卡這麼說、而較舊的模型卡沒這麼說，這件事本身可能是文件修正，也可能是在訓練這個 drafter 期間的發現——儲存庫沒有告訴你是哪一種，Liquid 也未發布解釋。實務上的意義範圍很窄但確實存在：如果你的回歸測試套件會逐位元組比對模型輸出，加入這個 drafter 可能會讓它觸發失敗，而這是算術本身的性質，不是 draft 的錯誤。

為什麼起草者比自己的模型晚六天出現

值得把時間線梳理出來，因為它比任何關於策略的揣測都更能解釋這片沉默。

• 2026-08-20 — Liquid 發表 DSpark 系列：為 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 與 LFM2.5-8B-A1B 提供的草稿模型。目前尚無 24B 目標模型存在。

• 2026-08-31 — SGLang 合併 PR #31041，新增 LFM2 與 LFM2-MoE DSpark 推測解碼支援。24B 所需的 MoE 路徑在此落地，比它將服務的模型早了一個半月。

• 2026-10-13 — LFM2.5-24B-A2B 隨部落格文章與定價一同推出。同日，SGLang 合併 PR #43939，讓伺服器可直接重用 Hugging Face LFM2-MoE 設定。

• 2026-10-19 — LFM2.5-24B-A2B-DSpark 儲存庫出現，附有權重與基準測試。

• 2026-10-20 — GGUF 附屬檔案登場：單一 664 MB 的 F16 檔案，供 llama.cpp 使用。

• 2026-10-21 — 目標模型卡新增一列草稿模型，仍顯示即將推出。

看那個順序，最可能的解釋就是最無聊的那個。基礎設施比產物更早發布；產物在訓練完成時發布；公告則是一項還沒進行的行銷工作。儲存庫中沒有任何跡象顯示這是刻意低調的發布——模型卡是完整的，基準測試連協定都記錄了下來，SGLang 與 llama.cpp 的呼叫方式也完整寫出。這裡的安靜是指尚未宣布，而不是隱藏。

尚未可知的事物

這篇文章誠實的界線，是一份簡短的清單；而其中每一項都是真實的缺漏，而非虛應形式。

沒有獨立測量。 沒有 Artificial Analysis 的收錄條目，沒有第三方驗收執行，也沒有對該吞吐量表格的複現。截至 2026-10-21，該儲存庫顯示為七次下載、一個讚。本文中的每一項加速數據皆出自廠商，是在廠商選定的 GPU 上、以廠商選定的目標精度所測得。

沒有公告，所以也沒有定調。我們不知道 Liquid 是打算把這款 24B 當作正式生產環境的建議，還是當作研究產物。這張卡片的語氣——完整的發布標記、家族表、聯絡連結——暗示是前者，但這只是推測。

沒有價格，因為不可能有價格。 草稿模型不是提供服務的模型。它沒有每百萬 token 的費率，也永遠不會以可呼叫端點的形式出現在模型目錄中。它的成本是緊鄰目標模型所佔用的 655 MB VRAM 或統一記憶體，再加上驗證一個區塊而非一個 token 的額外運算。

沒有 Apple silicon 的數據。 這是最大的落差，下一節會說明為什麼它比其他幾項更重要。

遺漏的 Mac 編號才是耐人尋味的省略。

24B 模型是以裝置端模型的名義販售。Liquid 的發布文章一開頭就主打在 Apple M5 Max 上每秒 184 個 token，並稱它是為裝置端上快速、私密的代理而打造。相較之下，drafter 的規格卡只列出 B300 的數字。針對八月的 8B drafter，Liquid 同時公布了 H100 與 M4 Max 的結果，並坦率說明兩者之間的落差：在 H100 上平均 2.54 倍的加速，到了 MacBook 上只剩 1.18 倍。它給出的理由是機械性的——驗證 k 個 token 所啟用的專家數比單次解碼步驟更多，因此 MoE 目標模型每個被驗證的 token 都要付出更多權重流量，而 llama.cpp 的 Metal 後端又讓情況雪上加霜。

LFM2.5-24B-A2B 同樣是混合專家模型：每個區塊有 64 個專家，採用前 4 名路由。相同的機制同樣適用，而 24B 是更大的模型，專家集合也更大，需要分頁調度。這並不證明裝置端加速幅度很小——草稿模型是專門為這個目標訓練的，接受率也比 8B 起初好得多——但這確實意味著筆電使用者真正需要的那個數字，正是這張卡上沒有包含的數字。任何認為 B300 的比例可以套用到 Mac 上的假設，都應視為未經證實。

執行它，以及那個會讓你栽跟頭的旗標

在 GPU 上，已公開的配置是採用 SGLang，搭配 FP8 target 並掛上 drafter，block size 為 9、十個 draft token。所安裝的 SGLang 必須夠新，才能包含來自 PR #31041 的 LFM2-MoE DSpark 路徑，以及來自 PR #43939 的配置重用；在較舊的版本上，伺服器將完全無法辨識 drafter 架構。請注意，這些基準測試數字是以 FP8 target 為前提——BF16 target 的表現會不同，而且不一定更好，因為 drafter 是針對特定分布的 target logits 訓練出來的。

在 CPU 與 Apple silicon 上，這條路徑是 llama.cpp 搭配 F16 GGUF sidecar。sidecar 會從自身的中繼資料讀取區塊大小，並將 --spec-draft-n-max 限制到該大小，所以把草稿長度設成 12 並不會真的得到 12。每次回應的計時資訊會揭露 draft_n 與 draft_n_accepted，這是你應該在自己工作負載上留意的欄位：如果你流量上的接受率遠低於這張卡的 5.16 平均值，那麼這個 drafter 就是在讓你多花一次前向傳遞、卻換不到多少回報，而誠實的做法就是把它卸除。

如果你這週要挑選模型，這代表什麼

對大多數團隊來說，實際影響很小，因為草擬模型改變的是速度，而非能力。LFM2.5-24B-A2B 才是負責回應提示的模型；草擬模型只會改變你每秒能獲得多少這類回答。如果上週 24B 不在你的候選名單上，那麼速度更快的版本也不會讓它入選。

如果草稿模型曾在你的候選清單上，它會讓自架的理由更充分，但對 API 情境毫無幫助。這個區別值得直說：對任何呼叫託管端點的人來說，推測解碼檢查點都是看不見的，因為是否掛載它由服務堆疊決定。你能在同等基礎上比較的，是模型本身與你原本會路由到的替代方案——而如果你正拿它與像 Qwen3.6-35B-A3B 這樣的模型評估，也就是 Liquid 在八項代理任務中的五項拿來對比的模型，OrcaRouter 讓這個比較目標只需一組金鑰即可存取，並以 供應商定價的 0% 加價提供，同時支援跨供應商自動容錯移轉。我們目前不提供 LFM2.5 系列，因此 24B 本身必須來自廠商自己的 API 或你自己的 GPU；我們提供的是比較的另一邊，而且不需要第二份合約。

什麼會改變這幅景象？

有三件事，依它們能多大程度改變敘事走向排序。Liquid 的一篇部落格文章會定調——這究竟是建議的正式生產搭配，還是研究性質的發布。一份公開的 Mac 實測數據會證實那個對 24B 所鎖定受眾真正重要的說法。而在真實流量上進行獨立驗收測試——而不是在 temperature 0 下跑八個基準資料集——才能告訴你，5.16 tokens per step 在碰上這個模型實際主打的那種凌亂、冗長、工具呼叫提示詞時，是否仍站得住腳。

在那之前，儲存庫是公開的，權重可以下載，CSV 就在那裡，而廠商自家的模型卡，是你最不該去找它相關消息的地方。對一次發布來說，這是很不尋常的狀態——但它確實存在，而且不會因為沒有人寫部落格文章，這個產物就變得不那麼真實。