Liquid AI 將 speculative decoding 加入 LFM2.5-VL-3B，以加速視覺語言推論

Liquid AI 發布了一款實驗性的 speculative-decoding 模型，旨在加速其 LFM2.5-VL-3B 視覺語言模型，鎖定多模態推論中的一個核心瓶頸：在影像與提示詞處理完成後，快速產生回應。

這個名為 LFM2.5-VL-DSpark 的模型，為 30 億參數的目標模型增加了一個 2.8 億參數的 draft model。Liquid AI 表示，在內部評估中，這個組合在 Apple M5 Max 上的解碼速度提升最高達 3.13x，在 Nvidia H100 上最高達 2.66x。端到端延遲的提升較小，在 M5 Max 上達到 2.62x，在 H100 上達到 2.27x。

這次發布對於在本地硬體上部署視覺語言模型的團隊最有意義，因為在這些場景中，回應延遲與記憶體限制往往比大型推論叢集更嚴格。它也將 Liquid AI 的 DSpark 方法從文字模型延伸到多模態工作負載，而不需要不同的 speculative-decoding 演算法。

為多模態輸入打造的 drafter

Speculative decoding 使用較小的模型一次提出多個 token。接著，較大的目標模型會驗證這些提案，接受與自身下一個 token 分布相符的 token，並在必要時生成替代結果。這種方法可以減少昂貴的目標模型步驟數，同時在精確驗證下不改變目標模型的輸出。

根據 Liquid AI 在 Hugging Face 的發布，LFM2.5-VL-DSpark drafter 會從 LFM2.5-VL-3B 的選定層取得 hidden states，並提出候選 token 區塊。影像與文字會先投影到共享表示，因此 drafter 無論輸入模態為何，都能接收相同維度的向量。

Liquid AI 表示，這個視覺 drafter 在訓練期間使用四層 attention-only 層與區塊大小九。推論時，該公司建議依硬體採用區塊大小八或九。這個 drafter 只會讓部署模型的參數量增加約 8.9%，相較於為同一任務運行另一個大型模型，記憶體增幅相對較小。

該模型使用一組視覺語言 supervised fine-tuning 資料進行訓練，並將權重偏向 Liquid AI 預期服務的工作負載。公司測試了三層、四層與五層設計，並將選定配置訓練 10 個 epoch，報告指出在加入更多 token 後接受率有所提升，之後才出現遞減效益。

報告的效益因硬體與任務而異

Liquid AI 使用 MMSpec 基準測試了六種視覺型工作負載。任務包括一般視覺問答、偏文字導向的視覺問答、影像描述、圖表問答、複雜推理，以及多輪對話。

裝置端結果分別使用 M5 Max 上的 MLX，以及 M3 Ultra 上的 llama.cpp 進行測量。Liquid AI 表示，MLX 的解碼速度依任務不同可快 2.30x 到 3.13x，而端到端延遲改善為 1.56x 到 2.62x。使用 llama.cpp 時，解碼提升介於 1.57x 到 2.14x，端到端延遲則改善 1.30x 到 1.77x。

根據該公司說法，H100 的評估顯示解碼提升最高達 2.66x，端到端改善最高達 2.27x。原始資料中關於 H100 解碼範圍下限的數字並不一致，因此較寬的結果應視為供應商報告的最大值，而不是一致的效能預期。

這些是 Liquid AI 的量測結果，並非獨立基準測試。它們也描述了特定硬體、軟體組態、任務混合，以及 DSpark 區塊大小八。實際效益會取決於提案 token 的接受率、提示詞長度、影像複雜度、量化、批次大小，以及總延遲中用於影像處理與提示詞輸入的比例。

Liquid AI 表示，speculative decoding 之所以是 exact，是因為目標模型會驗證每個提議的 token。因此在其實作中，greedy 輸出應與不使用 speculation 運行的目標模型一致。這個特性解決了加速技術的一項主要部署疑慮：在不悄悄改變模型行為的情況下提升速度。

為什麼端到端延遲仍是更難的指標

解碼速度與總延遲之間的差異，對產品團隊來說很重要。Speculative decoding 可加速 token 生成，但無法加速 vision encoder 或處理影像 token 與文字提示詞的 prefill 階段。

視覺語言模型在產生第一個 token 前，可能已經耗費相當多時間。影像先經過 vision encoder，之後語言模型再與文字輸入一起處理數百個視覺 token。在邊緣硬體上，較低的算力預算會讓這些階段佔據更大的總回應時間比例。因此，解碼速度提升三倍，並不會直接轉化為使用者可感知延遲縮短三倍。

這個限制是 Amdahl's law 的一個例子：工作負載中不變的部分會限制整體收益。對於像影像聊天、文件分析或圖表解讀這類應用，團隊需要分別量測首次 token 時間與完整回應時間。當影像已經編碼完成後，若輸出生成成為主導，較快的解碼路徑在長篇回答、重複輪次或工作流程中可能最有價值。

這些結果也暗示硬體選擇會塑造價值主張。Liquid AI 報告中最強的解碼範圍來自 Apple Silicon，而 H100 在公司的測試中帶來較低但仍具實質性的效益。這使得此發布與本地推論及 GPU 支援服務都相關，但並不能證明每個部署都會看到相同改善。

整合降低了測試門檻

LFM2.5-VL-DSpark 可透過 llama.cpp、MLX-VLM 與 SGLang 的整合使用。Liquid AI 表示，這個 draft model 已在 Hugging Face 以 Safetensors 與 GGUF 格式提供，讓開發者能走向原生與量化部署流程。

SGLang 整合需要具備 LFM2 目標的 DSpark 支援編譯版本，而 llama.cpp 與 MLX-VLM 也需要包含相關實作變更的版本。在 SGLang 中，操作者將 drafter 掛到目標模型上，並查詢相容 OpenAI 的端點。區塊大小會從模型設定中讀取，而回應時間可揭示有多少 draft token 被提議並接受。

對建置者而言，這種整合模式很重要，因為這次發布不需要替換目標視覺語言模型，也不需要重新設計應用程式介面。團隊可以用同一個目標模型比較一般部署與使用 speculative decoding 的部署，並衡量接受率、延遲、記憶體使用量與輸出等價性。不過，額外的 2.8 億參數仍會帶來記憶體與載入成本，這在較小的邊緣裝置上可能很重要。

下一步該觀察什麼

最明確的後續訊號，將是針對更多影像尺寸、量化等級、批次大小，以及接近實際生產的提示詞，對 LFM2.5-VL-DSpark 進行獨立測試。獨立結果將有助於確認，這些宣稱的效益是否能在 Liquid AI 所選的六項任務評估之外持續成立。

開發者也應該關注接受率與端到端延遲，而不只看標題中的解碼倍數。隨著實作成熟，llama.cpp、MLX-VLM 與 SGLang 的支援值得持續追蹤，特別是對在 Apple Silicon 或受限本地硬體上部署的使用者。

若未來有更多針對其他視覺語言模型的 DSpark 版本推出，可能代表這個架構能否超越 LFM2.5-VL-3B 而廣泛泛化。反之，如果效益對模型架構或工作負載高度敏感，這個方法可能仍只是一種針對性的最佳化，而非廣泛可移植的推論層。

Creati.ai 觀點

Liquid AI 的發布屬於實用性的推論更新，而不是新的能力模型。其主要貢獻在於展示 speculative decoding 如何在保留精確驗證的同時，適配到多模態目標，並保持額外模型相對精簡。

商業上的重要性將取決於使用者感受到的總延遲，而不是最高解碼數字。對於在本地執行視覺語言工作負載的團隊來說，開放權重、既有 runtime 整合與可量化的效益，可能足以值得測試。不過，買方應將目前的效能宣稱視為供應商報告，並以自己的影像、提示詞、硬體與延遲目標來驗證。