核心觀點
Liquid AI 為 30 億參數的視覺語言模型（VLM）LFM2.5-VL-3B 發布實驗性 DSpark draft model。它不是替換原模型，而是讓較小的草稿器先預測一小段 token，再由目標模型逐一驗證；通過的 token 可一次採納，因此能減少昂貴的逐 token 解碼步數。由於最後仍由目標模型驗證，貪婪解碼的輸出與只跑目標模型相同。^[raw/articles/hugging-face-liquid-ai-lfm2-5-vl-dspark-2026-09-24.md]
這是把推測解碼從文字模型帶進多模態部署的實作：影像 patch 與文字 token 在進入被抽取的中間層前已投影到共同表示空間，所以 drafter 可直接以固定層的 hidden states 提議下一段 token，推理演算法本身不必因輸入模態而重寫。
技術亮點：小幅記憶成本換取解碼速度
DSpark 採四層、attention-only 的 drafter，訓練資料是偏向預期工作負載的 vision-language SFT 混合資料；最終模型約 2.795 億參數，相對 3B 目標模型增加 8.9%。官方建議 block size 為 8 或 9：區塊太大會降低被接受的比例，太小則難以攤平驗證成本，需依硬體及真實工作負載量測。^[raw/articles/hugging-face-liquid-ai-lfm2-5-vl-dspark-2026-09-24.md]
在六項 MMSpec 視覺任務上，MLX／M5 Max 的解碼加速為 2.30–3.13 倍、端到端延遲改善 1.56–2.62 倍；llama.cpp／M3 Ultra 為 1.57–2.14 倍與 1.30–1.77 倍。H100 的官方最高值則為 2.66 倍解碼加速、2.27 倍端到端改善。這些是指定模型、任務與 block size 的結果，並非所有 VLM 服務都會得到同等比例。
為何端到端改善較小
VLM 的等待時間還包括影像編碼與 prefill：模型須先把影像轉成大量視覺 token，再與文字 prompt 一起處理。DSpark 只加速 decode，不會縮短這兩段；尤其在邊緣裝置上，未被加速部分占比愈高，整體上限就愈受 Amdahl 定律限制。換言之，不能只看 tokens/s，而要量測「送進圖片到拿到完整回答」的任務延遲。
這也補充 GLM-5.2：為長期代理任務而生 的多步預測／推測解碼：兩者都以較便宜的預測換取目標模型驗證後的吞吐，但 DSpark 額外處理了影像與文字共存的 VLM 前綴成本。對需要本地多模態能力的產品，Reachy Mini 本地化對話：語音 AI 管線的離線部署實錄 所列的 llama.cpp、MLX 與 vLLM 後端，正是可評估此類加速是否能落地的起點。
部署判讀
- 相容性先於宣稱速度：首日支援涵蓋 llama.cpp、MLX-VLM、SGLang，但都需具備相應 DSpark 支援的版本；部署前要確認模型格式、runtime commit 與 draft 模型設定一致。
- 驗證品質與效能分開看：精確推測解碼可保持目標模型的貪婪輸出，但不代表模型本身的視覺理解品質提升；應另以自家圖片、OCR、圖表與多輪任務測試正確性。
- 把接受率納入觀測：drafted／accepted token 數可用來判斷草稿器是否真的貼合工作負載。若接受率低，額外模型記憶體與驗證成本可能吃掉收益。
- 優先選 decode 占比高的場景：短圖像前綴、較長生成回答，通常比高解析影像與超長提示更有機會轉成明顯端到端收益。
相關頁面
- GLM-5.2：為長期代理任務而生：多步預測與長程代理中的推測解碼脈絡。
- Reachy Mini 本地化對話：語音 AI 管線的離線部署實錄：比較 llama.cpp、MLX、vLLM 等本地推論後端。
- GRPO 微調 350M 模型：100 步改善結構化輸出：同為 LFM2.5 生態中的小模型訓練與可靠性量測案例。
反向連結
以下頁面引用了本頁：