LFM2.5-VL-3B-DSpark 對比 LFM2.5-VL-3B：你不是二選一，而是掛載一個

讓人們來到這裡的那個搜尋是一項比較，但誠實的答案是，LFM2.5-VL-3B-DSpark 和 LFM2.5-VL-3B 並不是兩個讓你從中二選一的東西。後者是一個 3.1B 的視覺語言模型，你可以下載並用它來提供服務。前者則是一個 279.5M 參數的草稿模型，它存在的唯一目的，就是坐在後者前面，讓它解碼得更快。把這個草稿模型從堆疊中抽掉，它就什麼也產不出來；你無法單獨對它做基準測試，因為「單獨」並不是它支援的配置。真正的比較，是 LFM2.5-VL-3B 單獨運行，對上同一個模型在掛上草稿模型後運行。

如果這樣解讀，這個決定就歸結為一個問題：額外的記憶體和額外的執行期複雜度，是否能換來足夠的延遲優勢，讓它對你的工作負載產生實質影響？Liquid AI 自家的數據顯示，對於解碼密集型工作來說答案是肯定的，而當預填充主導時則明確表示否定。這兩種說法都沒有在公司外部被重現過。

這兩個檢查點，並排

它們之間的差異才是關鍵所在，所以在速度爭論開始之前，值得先把這兩個儲存庫並列比較。

• 角色 — LFM2.5-VL-3B 會產生文字並回答影像相關問題；LFM2.5-VL-3B-DSpark 會提出符元供其驗證，本身無法產生任何可用的內容

• 參數 — 目標模型為 3.1B，草稿模型為 279.5M BF16，Liquid 估計這會使部署參數數量增加 8.9%

• 架構 — 目標是建構於 LFM2.5-2.6B 主幹與 SigLIP2 NaFlex 視覺編碼器之上的混合模型；草稿模型為 4 層完整注意力層，隱藏大小為 2,048，採用分組查詢注意力，外加一個馬可夫頭與一個信心頭

• 上下文視窗 — 目標為 32,768 個 token；起草器本身不攜帶任何上下文，並繼承目標的上下文

• 視覺編碼器 — 目標模型上使用 SigLIP2 NaFlex 400M；草擬器沒有視覺編碼器，且從不直接看到影像

• 詞彙量 — 128,000，且草稿模型的嵌入層與 LM 頭是與目標模型綁定而非重複配置，這就是為什麼記憶體負擔比 279.5M 參數所暗示的還小

• 授權條款 — 兩者皆採用 Liquid 的 LFM1.0 授權條款發布，該授權在 Hugging Face 上被歸類為「other」，而非 OSI 授權，因此商業部署前請詳閱條款

• 格式 — 目標模型以 safetensors、GGUF、ONNX 與 MLX 量化形式發布；草稿模型則以 safetensors 及單一約 567 MB 的 F16 GGUF 發布

那份清單中有一行值得強調，因為它正是這個配對之所以能運作的機制上的原因：草稿模型不是小型視覺模型。它沒有視覺編碼器，也從不接觸影像。當符元抵達它據以草擬的隱藏層時，影像區塊和文字符元都只是張量，因此對草擬運算而言，模態是不可見的。這正是讓 Liquid 能將一項為文字模型開發的技術移植到 VLM 上，而不必重新設計它的原因。

起草者會改動什麼，以及會保留什麼不動

目標模型不會改變。這不是行銷話術——而是推測性解碼的正確性特性。在貪婪解碼下，每個草稿 Token 都會由目標模型驗證，因此輸出會與目標模型單獨產生時完全相同。在非零溫度下採用相符的取樣設定時，輸出分布會與目標模型的分布相符。草稿模型以記憶體換取時間，除此之外不會影響其他任何東西。

這意味著你能找到的 LFM2.5-VL-3B 每一項品質數據，都原封不動地適用於成對配置。在 Liquid 自家的評估中，目標模型在 ScreenSpot-v2 上得分 80.7，在 BLINK 上 61.5，在 MuirBench 上 58.3，在 MME 上 73.1，在 MMStar 上 63.3，在 ChartQA 上 81.3，在 POPE 上 88.7 ——全數由廠商自行報告，無一經過獨立重現，而且無論是否掛上草稿模型，這些數字都同樣成立。這裡沒有需要權衡的品質與速度取捨，任何呈現出這種取捨的比較頁面，都是誤讀了這個模型。

真正改變的是每個 token 的實際耗時成本。Liquid 測得解碼加速倍數：在單張 H100 上以 BF16 透過 SGLang、區塊大小 9 時為 2.04× 到 2.66×；在 Apple M5 Max 上透過 MLX-VLM、區塊大小 8 時為 2.30× 到 3.13×；在 M3 Ultra 上透過 llama.cpp 時為 1.57× 到 2.14×。端到端方面，相同執行的結果分別落在 1.64×–2.27×、1.56×–2.62× 和 1.30×–1.77×。這些成對數字就是全部的論點所在：解碼的改善幅度大約是端到端的兩倍，而這個落差，正是草稿模型無法觸及的那部分工作負載。

供應商所述的預填問題

Liquid 自家公告中最有用的一句話，正是那句反對無限制解讀其標題的論述。視覺語言推論要付出文字推論所沒有的預填充成本：影像得先經過視覺編碼器，接著語言主幹再處理編碼器輸出的數百個視覺符元。在邊緣裝置上，這段預填充占了端到端延遲的很大一部分。推測解碼只加速解碼階段——視覺編碼與預填充完全不變。因此在預填充占主導的情況下，3 倍解碼加速所換得的端到端效益要小得多。

那是廠商把 Amdahl 定律套用到自家產品上，而這應該左右誰會閱讀本頁。對單一掃描頁面進行冗長的轉錄、一段圖說、一場帶著同一張圖片往下進行的多輪對話——這些都偏重解碼，而草稿模型值得它的 2.795 億個參數。關於一張大型高解析度圖片的簡短問題——偏重預填，而它則不然。把同樣的目標放到高併發的伺服器上，情況又會改變：Liquid 衡量的是輸送量與互動性之間的前沿，而非單一數字，並回報 DSpark 在每個受測的併發層級都保有優勢，只是隨著併發量上升，差距會縮小。

來自同一來源的兩則較小型範疇界定備註。所有測量都對視覺編碼器與語言主幹採用 16 位元處理，且量化模型的加速不在本次發布的範疇內。如果你原本打算將 4 位元目標匯出與 drafter 配對，因為 3B VLM 的整體賣點就是能塞進幾 GB 內，那麼該組合並非實際測量的組合。

附加它實際上會讓你付出什麼代價

記憶體是可見的成本，而這張卡片把它量化了出來：部署堆疊中的參數量多了 8.9%。執行時期複雜度則是看不見的那一項。SGLang 需要 v0.5.19 或更新版本，而且啟動命令列要帶有 --speculative-algorithm DSPARK、草稿模型路徑與區塊大小；這張卡片本身的範例還會停用 radix 快取並固定一個靜態記憶體比例，這些都是你現在必須納入考量的推論服務決策。MLX-VLM 需要 v0.7.2 或更新版本，並透過 --draft-model 接收 drafter，但該處的 DSpark 解碼目前使用貪婪取樣，因此溫度必須強制設為 0 —— 如果你的應用程式仰賴取樣多樣性，這是一項實質限制。llama.cpp 則是透過 GGUF drafter 搭配 GGUF 目標來運作，而非搭配原始的 safetensors 檢查點。

還有一項成本不會出現在基準測試中，而是會在生产環境裡浮現：草稿模型與目標模型必須一起移動。兩者之間的版本偏差是一種在單一模型部署中根本不存在的故障模式，而如今要獨立滾動更新其中任何一個，都成了得同時處理兩份成品的問題。

這是自架式配對。OrcaRouter 不會路由 LFM2.5-VL-3B 或其 drafter——你必須自行下載並提供服務——因此路由問題在於小型模型交辦出去的一切。大多數將 3B 邊緣 VLM 與 drafter 配對的部署，仍會遇到小型模型不該回答的查詢，而把那些查詢送往單一端點，涵蓋 200+ 個模型，價格依各供應商的牌價計費，並在供應商效能衰退時自動容錯移轉，只需一次整合，而非每個供應商各自整合。這也意味著，一旦供應商降價，你的費率當天就會反映，而不是等到下一次合約續約。

哪一個要下載

如果你的工作負載偏重解碼，且你的硬體是 Liquid 測試過的三款之一，就掛上草稿模型——缺點有限，因為輸出可證明是目標模型的輸出，而記憶體成本不到一個模型的十分之一。如果你的延遲以預填為主，或者你執行的是量化目標模型，或者你在尚未解除該限制的執行環境中依賴非貪婪取樣，就單獨執行 LFM2.5-VL-3B。以自身標準來看，它很快：在 M5 Max 上每秒 228 個 token，在 AMD Ryzen AI Max+ 395 上每秒 116 個，在 Galaxy S26 Ultra 上每秒 20 個，全為廠商數據，且約使用 3 GB 記憶體。

目前還沒有人能告訴你的是，Liquid 的數字是否能在你的硬體上成立。截至本文撰寫時，該草稿模型在 Hugging Face 上有 37 次下載，而且其表格中沒有任何一項數字經過獨立重現。工程設計本身很紮實，正確性論證是一項證明，而非僅是宣稱；但數字有多大，是一項量測結果——而來自單一實驗室、單一組機器的量測結果，正是你在把它們納入容量規劃之前應該自行驗證的那種數字。

OrcaRouter 只要一組金鑰就能使用 200+ 個模型，各供應商的牌價以 0% 加成直接傳遞，並在供應商之間自動容錯移轉。供應商牌價以 0% 加成直接傳遞 本頁的配對無論如何都是自架——路由器負責小型模型交辦的所有事項，而這表示供應商降價當天就會反映在你的費率上。