LFM2.5-VL-3B-DSpark：Liquid AI 的 2.795 億參數 Drafter，在任何人宣布前六天就已出貨

這個故事有一種版本是：LFM2.5-VL-3B-DSpark 是一款新模型。但事實並非如此。它是一個 279.5M 參數的推測解碼草稿模型，存在的目的只有一個——讓 Liquid AI 自家的視覺語言模型 LFM2.5-VL-3B 解碼得更快——而且它無法自行生成可用的答案。儘管如此，它仍值得一讀的原因在於時間線：權重於 2026 年 9 月 18 日上傳到 Hugging Face，沒有任何公告，擱了六天，直到 9 月 24 日才出現一篇廠商部落格文章。Radar 在這段空檔中捕捉到了這個儲存庫。

那道落差同時也是目前可知範圍的界線。儲存庫裡的一切——參數拆解、區塊大小、框架整合、授權條款——都是你我能在磁碟上打開的檔案。每一個加速倍數都是廠商自行量測的數字，出自 Liquid 自家的基準測試工具，而公司外部沒有任何⼈發表過重現結果。本文刻意把這兩堆東西分開來看。

儲存庫實際包含的內容

打開模型卡，這東西的樣貌就毫無疑義。LFM2.5-VL-3B-DSpark 是一個草稿模型，其目標模型已固定在其中介資料中：base_model: LiquidAI/LFM2.5-VL-3B。你不能把它指向其他模型，也不能單獨提供服務。

• 總草稿參數量 — 279.5M，BF，其中 193.0 是 4 層解碼器堆疊，65.5M 是馬可夫頭，21.0M 是隱藏狀態投影，6.4 是正規化層加上一個信心頭

• 骨幹 — 4 層完整注意力層，隱藏大小 2,048，中間大小 6,144，採用 SiLU/SwiGLU，分組查詢注意力，具備 32 個注意力頭與 8 個鍵值頭，頭維度 64

• 額外的頭 —— 一個秩為 256 的馬可夫頭，以及一個置信度頭，而這正是 DSpark 草擬與普通平行草擬器之間的區別所在

• 區塊大小 — 訓練時為 9；推論時依硬體為 8 或 9，而在 Apple silicon 上則特定為 8

• 詞彙量 — 128,000，緊扣目標而非由草稿承載

• 部署堆疊中的權重 — Liquid 表示，草稿模型會使已部署的參數數量增加 8.9%

8.9% 是那個要牢牢記住的數字。這類模型的賣點從來不是「更快的推論是免費的」；而是「更快的推論會讓你付出大約十分之一個模型份量的記憶體代價」。在以 3.1B 目標模型為基礎、額外增加 279.5M 參數的情況下，這筆稅比單看 drafter 本身的大小所暗示的還要小，因為 embedding 和 LM head 都與目標模型綁定，並沒有被重複複製。

DSpark 首先是 DeepSeek 的一項技術，其次才是 Liquid 模型

這個命名容易令人混淆，因此值得精確釐清。DSpark 並非 Liquid AI 的發明，也不是一個模型系列。它是一個出自另一條獨立研究路線的推測解碼框架，在 2026 年 7 月的一篇論文中被描述為結合半自迴歸生成的信心排程推測解碼。它的三個核心構想是：一個平行主幹，能在單次前向傳遞中草擬出整個區塊；一個輕量的序列模組，還原相鄰草稿詞元之間的部分依賴關係，使接受率不會在區塊尾端崩跌；以及一個驗證器，當草稿自身的信心顯示尾端將被拒絕時，會按每個請求縮短驗證視窗。

Liquid 所做的是把這套配方套用到視覺語言模型上，並推出一個檢查點。模型卡坦率指出，這種遷移並不像聽起來那麼戲劇化：從草稿模型的角度來看，模態無關緊要，因為當 token 抵達隱藏層時，影像區塊和文字 token 都只是張量。這就是為什麼在文字模型上開發出來的技術，能移植到 VLM 而不必重新發明——也正是為什麼草稿模型無法被當成一項新能力來推銷。

Liquid 早已推出文字版 DSpark 草稿模型——2.6B、8B-A1B 與 1.2B-Instruct 伴隨模型已於 2026 年 8 月上線，GGUF 匯出檔則在 8 月 19 日接續發布。視覺草稿模型是同一概念延伸至多模態分支，而且是該系列中的第四或第五個成員，並非首次亮相。

加速倍數的數據，以及是誰測量的

以下每一項數字都是 Liquid 自家的，且是在 Liquid 的基準測試基礎設施上蒐集而來，沒有任何一項有獨立重現。請將它們視為供應商上限，而非預期結果。這張卡片把解碼加速與端到端加速分開呈現，而這點比標題數字更重要。

• 最佳解碼加速 — 在 COCO 上達 3.13×，以 MLX-VLM 在 Apple M5 Max 上測量（區塊大小 8、FP16、批次大小 1、溫度 0）

• 最佳 GPU 解碼加速比：在 COCO 上達 2.66 倍，於單張 H100 80GB 上使用 SGLang、BF16、區塊大小 9

• llama.cpp 最佳解碼加速 — 在 COCO、Apple M3 Ultra、區塊大小 8 上達 2.14×

• H100 解碼範圍涵蓋六項視覺任務 — 2.04× 至 2.66×，端到端為 1.64× 至 2.27×

• M5 Max 解碼範圍 — 2.30× 至 3.13×，端對端 1.56× 至 2.62×

• M3 Ultra 解碼範圍 — 1.57× 至 2.14×，端到端 1.30× 至 1.77×

• 草稿接受度 — 在全部三個技術堆疊上，每次目標驗證輪次約接受 3.2 至 4.5 個 token

那些範圍中的模式才是誠實的部分。端到端增益始終是每對中較小的一半，因為草稿模型只加速解碼，別無其他。另請注意，同一個草稿模型在相同區塊大小下，於某個堆疊上達到 3.13×，在另一個堆疊上則是 1.57×——接受率是草稿模型與工作負載的特性，但實際時間增益則是硬體與執行環境額外開銷的特性。沒有附上堆疊的「快 2.66×」說法，不是你能據以行動的宣稱。

卡片上的兩個正確性重點值得直白說明，因為它們正是讓草擬模型在生產環境中得以被接受的根本原因。在貪婪解碼下，推測解碼是精確的：目標模型會驗證每個被提議的 token，因此產生的文字就是目標模型獨自產生時會產生的內容。在非零溫度下採用匹配的取樣設定時，它會保留目標模型的輸出分佈。Liquid 的說法——你得到的是加速，而不是一個不同的模型——就其所述而言是準確的，而卡片也誠實指出，提高溫度會降低接受率，因而侵蝕吞吐量效益。

Liquid 自家貼文所承認的事

9月24日的部落格文章比模型卡更有用，原因只有一個：它點出了限制所在。視覺語言推論會付出文字推論所沒有的預填充成本——影像必須先通過視覺編碼器，接著語言主幹還得處理該編碼器產生的數百個視覺 token。在裝置上，這個預填充主導了端到端延遲。推測解碼只加速解碼階段。視覺編碼與預填充則完全未受影響。Liquid 援引阿姆達爾定律來檢視自家產品，並指出當預填充占實際耗時很大一部分時，大幅加快解碼也只能換來有限的端到端改善。

那確實是購買決策上的一項實際限制，也解釋了為什麼首個 token 時間（time-to-first-token）不在這個草稿模型改善的事項清單上。這也意味著，受益最多的工作負載，是那些從一張不大的圖片產生長輸出的工作負載——例如圖片說明、長篇 OCR 轉錄、帶著同一張圖片進行的多輪對話——而不是針對大型圖片回答簡短問題的工作負載。

這篇文章又新增了兩項範圍限制。所有數字在視覺編碼器與語言主幹上都採用 16 位元處理，而量化模型的加速則不在本次發布的範圍內。考量到 3B 邊緣 VLM 的整個賣點就是在幾 GB 的資源內運行，「加速幅度是以 FP16 測量」對任何打算將其搭配 4 位元匯出格式使用的人來說，都是個值得注意的但書。Liquid 也指出，該草稿模型完全是在 AMD 硬體上訓練的。

運行中

首日支援確實在，而且涵蓋三種執行環境，這比大多數 drafter 能得到的都多。NVIDIA 上的 SGLang 需要 v0.5.19 或更新版本，並透過 --speculative-algorithm DSPARK 搭配草稿路徑與區塊大小 9 來使用 drafter。Apple 晶片上的 MLX-VLM 需要 v0.7.2 或更新版本，當它以 --draft-model 傳入時會偵測到 drafter；有一個棘手的細節——MLX-VLM 中的 DSpark 解碼目前使用貪婪取樣，所以 temperature 必須設為 0。至於 llama.cpp，則有另一個獨立的 GGUF 儲存庫，只有一個約 567 MB 的 F16 匯出檔，而且說明卡明確指出，你要把量化後的 drafter 與量化後的目標模型配對，而不是與原始的 safetensors checkpoint 配對。

路由層在這裡之所以能佔有一席之地，並不在於這個模型——OrcaRouter 不會路由 LFM2.5-VL-3B-DSpark 或 LFM2.5-VL-3B，而且這是一組由你自己下載、自行部署的自我託管 drafter 配對。它的價值在於環繞其周遭的其餘技術堆疊。涵蓋 200 多個模型的單一端點——依各家供應商的定價計費、不額外加價，並在供應商服務劣化時自動容錯移轉——比起另立一份供應商合約，是更小的整合工程。drafter 改善了該架構的其中一條腿；而路由器正是讓另一條腿不至於變成另一個專案的關鍵。

還有什麼是尚未知道的？

在撰寫本文時，該儲存庫有 37 次下載和 6 個讚。在任何公開基準測試聚合器上，都沒有這個草擬模型的條目，沒有第三方重現任何加速範圍，也沒有對 Liquid 未測試硬體上的接受率進行獨立測量。出於明顯的原因，卡片上也沒有品質基準測試——該草擬模型在設計上就是輸出保留的，因此品質數據屬於 LFM2.5-VL-3B，而卡片指向該模型的基準測試，而不是自行發明一套。

中繼資料中的一個細節，稍稍透露了這東西有多新：這個模型帶有一個 SGLang 函式庫標籤，以及一個專門用來呼叫它的 SGLang 演算法旗標。框架支援必須在公告發布之前先行到位，這與該儲存庫和那篇部落格文章之間相隔六天的情況相符。

所以：這是一件真誠、實用、範圍明確而狹窄的工程成果，在出貨一週後才對外發布，而它整個價值主張，不過是建立在你未必擁有的硬體上、由廠商自行量測出來的一個數字。若你是在 H100 或 M 系列 Mac 上部署 LFM2.5-VL-3B，而且你的工作負載以解碼為主，那麼記憶體成本是 8.9%，而缺點幾乎為零，因為輸出可證明就是目標模型本身的輸出。若你的延遲主要由預填充主導，或者你原本指望那個 4-bit 匯出檔，Liquid 自家的文章就告訴你，這幫不上忙。等重現結果出來時，那才是真正值得等待的東西。

OrcaRouter 以供應商定價、0% 加成，將 200 多個模型放在單一金鑰之後，並把備援路徑表達為 一個路由層，而非應用程式碼。無論是哪一種方式，草擬模型都是自行託管的——路由器正是讓你的小型模型交棒出去的那一段不至於變成另一個專案的關鍵。