
LFM2.5-8B-A1B-DSpark vs Qwen3-8B:加速模型的草稿模型,對上人人都在跑的 8B
- DeepSeek新DeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.15 / $0.29 每百萬 tokens
- z-ai新Z.ai: GLM 5.32026-08-1860智能75程式
- obsidian新Qwen3.8 27B2026-08-1552智能68程式
- qwen新Qwen: Qwen3.8 27B (free)2026-08-13qwen/qwen3.8-27b-free
- deepseek新DeepSeek: DeepSeek V4 Pro 08132026-08-1253智能69程式
- grok新SpaceXAI: Grok 4.62026-08-1261智能77程式
- metaMeta: Muse Spark 1.22026-08-0557智能72程式
- qwenQwen: Qwen3.8 Max2026-08-0358智能72程式
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152智能69程式
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 每百萬 tokens
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463智能78程式
- googleGoogle: Gemini 3.6 Flash2026-07-2152智能69程式
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137智能49程式
- metaMeta: Muse Spark 1.12026-07-1653智能71程式
- kimiMoonshotAI: Kimi K32026-07-1560智能76程式
- openaiOpenAI: GPT-5.6 Luna2026-07-0952智能71程式
- openaiOpenAI: GPT-5.6 Terra2026-07-0957智能77程式
- openaiOpenAI: GPT-5.6 Sol2026-07-0961智能77程式
Liquid AI 於 2026 年 8 月 20 日發布了 LFM2.5-8B-A1B-DSpark 草稿檢查點——一個 3.277 億參數的投機解碼輔助工具,能讓 LFM2.5-8B-A1B edge MoE 在單張 H100 上的生成速度提升最多 3.18 倍。在這次比較能誠實進行之前,有個事實必須先攤在桌面上:DSpark 檢查點不是一個能直接呼叫的模型,它只是用來加速另一個模型。因此,這次發布真正對應到的部署問題,正是大多數團隊一整年來一直在權衡的那個——LFM2.5-8B-A1B 與 Qwen3-8B,兩個 8B 級開放權重模型,但它們正處於截然不同的生命階段。
在這裡,框架比平時更為關鍵,因為這兩者並非同類事物。Qwen3-8B 是一個完整、可部署的模型,你今天就可以自行託管或購買 token 來使用。LFM2.5-8B-A1B 同樣也是一個完整、可部署的模型——DSpark 草稿只是它的附加元件,而不是它的某個版本。草稿所承諾的一切,皆為廠商自行量測,且僅有一天的歷史;至於儲存庫與格式的種種,則只是擺在那裡供人查證。這篇文章將這兩個類別分開處理。
首先,「DSpark」這個詞在這個句子中不是名詞。
推測解碼會讓一個廉價的草稿模型跑在真正模型之前:草稿模型先猜測接下來數個 token,目標模型再以單次前向傳播驗證整個區塊,並採納雙方一致的部分。當猜測夠準時,你只需一次權重載入的代价就能推進多個 token,因此在不更動目標模型權重的情況下提升吞吐量——而且因為目標模型會逐一檢查每個提議的 token,貪婪解碼下的輸出與單獨執行 LFM2.5-8B-A1B 完全相同。Liquid 稱此為「構造上無損」(lossless by construction),而這正是草稿模型可以安心加掛的全部理由。
Liquid 的 LFM2.5-8B-A1B-DSpark 是刻意設計得小巧的草稿模型:五個純注意力層、每一步產生九個提議 token 的區塊,以及建構在目標模型 128,000 token 詞彙表上的馬可夫頭。它以聊天、程式碼與函式呼叫資料的混合內容訓練了 15 個 epoch,檢查點依接受率而非損失來挑選。它是該供應商當天推出的三份草稿之一,另外兩份是 LFM2.5-1.2B-Instruct 與 LFM2.5-2.6B,各自提供 Safetensors 與 GGUF 格式,且首日便支援 SGLang 與 llama.cpp。同樣重要的是,對任何正在閱讀它與 8B 級模型比較的人而言:它沒有由任何推論供應商提供服務,也沒有按 token 計價的價格。它只存在於你自己的推測解碼堆疊之中。

實際部署的兩個模型
將草稿剝離,真正的比較是在它所加速的模型與現有者之間。兩者都是開放權重且約8B級,然後相似之處僅此而已:
• 架構 — LFM2.5-8B-A1B 是稀疏 MoE,總參數 83 億,但每個 token 僅約 15 億活躍參數;Qwen3-8B 是稠密型 82 億參數模型,每個 token 都會啟用全部參數。
• 發布 — LFM2.5-8B-A1B 於 2026 年 5 月 28 日發布;Qwen3-8B 於 2025 年 4 月發布,已超過一年,在一些服務平台上已遭棄用。
• 背景 — LFM2.5-8B-A1B 提供原生 128K 上下文,配有 128K-token 詞彙量;Qwen3-8B 提供原生 32K,可透過 YaRN 擴展至約 128K。
• 推理 — LFM2.5-8B-A1B 是一個會輸出明確思維鏈的推理模型;Qwen3-8B 則會依每個請求在思考與非思考模式之間切換。
• 智能 — 根據 Artificial Analysis 的數據,LFM2.5-8B-A1B 的智能指數為 8,Qwen3-8B 為 8–8.3,兩者均低於同類開放權重模型 9 的中位數;兩者都不是前沿級大腦,而且對此都很誠實。
• 速度——根據 Artificial Analysis,LFM2.5-8B-A1B 在各大供應商間約每秒輸出 340 個 token;Qwen3-8B 則約為每秒 37–40 個 token,屬於同級中最慢的之一。
• 授權 — LFM2.5-8B-A1B 採用 Liquid 的 LFM 開放授權 v1.0;Qwen3-8B 採用 Apache-2.0。

速度正是雙方不再旗鼓相當之處。
8B 級開源權重討論之所以出現轉變,最大的單一原因是每單位記憶體的速度。Qwen3-8B 是稠密模型:它產出的每個 token 都會將全部 8.2B 權重流經記憶體匯流排,這就是為什麼以它的規模來說速度偏慢,而且需要真正的 VRAM。LFM2.5-8B-A1B 讓每個 token 只經過約 1.5B 個活躍參數,這正是整個設計的核心——一個在裝置端執行、維持快速且小巧的 MoE。Liquid 自己的宣稱更進一步:在 M5 Max CPU 上、記憶體用量低於 6GB 的情況下,每秒約可處理 253 個 token(廠商宣稱數據)。就可部署模型的原始吞吐量而言,草稿模型在故事的這一部分甚至無關緊要——在加入推測解碼之前,MoE 已經比稠密的 8B 模型快上好幾倍。
在價格方面,兩者都是開放權重,因此自行託管任一方,成本就只是你的硬體成本。但在託管服務的供應上則明顯不對稱:Qwen3-8B 由阿里巴巴的 API 提供,標價為每百萬輸入 token 0.18 美元、每百萬輸出 token 2.10 美元,同時也有眾多第三方開放模型託管商支援;LFM2.5-8B-A1B 則沒有值得一提的第一方託管 token 定價,而 draft 版本更是完全沒有。這意味著目前大多數團隊實際執行 Liquid 邊緣 MoE 的方式,就是自行託管在筆電、邊緣裝置或自有 GPU 上——而正是在這種環境下,DSpark draft 成為關鍵變數。
這份草案實際上對這項決定改變了什麼
草稿模型只改變一個軸向:在你掌控的服務堆疊中,LFM2.5-8B-A1B 產生 token 的速度。它不會讓模型變得更聰明,也不會改變回答內容——貪婪輸出與單獨使用目標模型時逐位元相同。它真正有幫助的是 GPU 上單一請求吞吐量的服務:Liquid 在單張 H100 上、橫跨五個基準測試,量測到平均 2.54 倍的加速(每秒 418 → 1,074 個 token),在 MATH500 上最佳為 3.18 倍,條件是批次大小 1、溫度 0。它幾乎沒幫助的是 Apple silicon:同一個模型在 M4 Max 上平均僅 1.18 倍(90 → 106 tok/s),因為在 llama.cpp 目前的 Metal MoE 後端中,驗證一批草稿 token 會啟動更多專家,並搬移更多權重流量——這正是推測解碼(speculative decoding)原本要攤平的成本。以上皆是發布當天來自廠商的數據,並非獨立重現的結果。
這種劃分直接對應到一個決策規則。如果你在自有 GPU 上執行 LFM2.5-8B-A1B,草稿模型就是一個真正的成本槓桿——同樣的矽晶片每秒可產出約 2.5 倍的 token,而且輸出完全不變;你只需要一個具備 8 月 20 日 DSpark 整合的建置版本。如果你改為透過 API 呼叫模型,提供者會保留這項加速,草稿模型對你而言就無關緊要。如果裝置是筆電或手機,草稿對這個特定模型目前幾乎是無操作;同系列針對密集模型 LFM2.5-1.2B-Instruct 與 LFM2.5-2.6B 的草稿模型,才是具備裝置端優勢的,分別為 2.54 倍與 2.27 倍。至於 Qwen3-8B,它根本不需要草稿模型——它就是一個較慢、較密集的模型,不需要推測解碼即可部署。

Qwen3-8B 問世一年後的選擇
Qwen3-8B 是無聊但正確的預設選擇:成熟、Apache-2.0 授權、支援 119 種語言、具備思考與非思考模式、隨處皆可部署,而且在對話、程式碼與結構化文字方面仍然是相當優秀的通才模型。它的問題在於年齡與速度——這是一個 16 個月大的密集 8B 模型,在同級中速度偏慢,且已在某些平台上被標記為棄用;如果你今天要展開一個全新專案,這是一個值得認真看待的維護訊號。
LFM2.5-8B-A1B 是較新且更聚焦的賭注:一款專為在消費級硬體上快速進行工具呼叫與指令遵循而打造的邊緣優先 MoE,並以 DSpark draft 作為 GPU 自架情境下的選用服務加速。它並非更聰明的模型——在 Artificial Analysis 上,兩者皆低於開放權重模型的中位數——但它的速度大幅提升,且每個 token 的記憶體用量僅需一小部分,這正是對裝置端代理程式而言重要的取捨。它的缺點正是 Qwen3-8B 的鏡像:發布較晚、沒有第一方託管定價,而推測式解碼的數據,目前還沒有供應商以外的人能重現。
底層的路由層無論如何都保持不變。目前,LFM2.5-8B-A1B 和 Qwen3-8B 都不在 OrcaRouter 的託管目錄中,因此誠實的說法是:路由器為這個組合提供的是——單一 API 涵蓋 200 多個託管模型,供應商列表價格以 0% 加價直接轉嫁,所以供應商宣布降價的當天就會在平台上生效;自動故障轉移,讓你能針對真實流量試用未經驗證的新模型,而不是把生產路徑押在它上面;以及一個路由 DSL,可以前置你自己提供的模型,這就是自託管的 LFM2.5-8B-A1B 堆疊如何與託管端點在單一金鑰背後共存。
如果你是在為筆電或邊緣裝置打造產品,而且在意工具呼叫速度,LFM2.5-8B-A1B 是值得測試的方向,而草稿模型屆時在 GPU 服務路徑上可免費獲得 2.5 倍加速。如果你想要一個可以不再費心的通用模型,Qwen3-8B 依然可用——只是要知道它是 2025 年初的模型,生態系已開始將它汰換。草稿與目標模型都不會改變的一件事,是證據的真實狀態:DSpark 版本所有關於速度的宣稱,都只是單一廠商在某一天的測量結果,而獨立基準測試才是決定你實際上該信任多少的未定項目。
