Accelerating vision-language models with LFM2.5-VL-DSpark

, "articleBody": "大型視覺語言模型（Vision-Language Model，簡稱 VLM）能夠同時理解圖像與文字，但這類模型在實際部署時常面臨推理速度不夠快的問題。Liquid AI 團隊於 2026 年 9 月發布了 LFM2.5-VL-3B 的 DSpark 草稿模型（draft model），這是一個實驗性的加速元件，目標是在不改變輸出品質的前提下，降低視覺語言模型的推論延遲。本文根據 Liquid AI 在 Hugging Face 發布的技術文章，整理這項技術的背景、運作原理、實測數據與限制。\n\n背景：視覺語言模型的推論瓶頸\n\n視覺語言模型的推論過程比純文字模型更為繁重。當模型收到一張圖片時，影像會先經過視覺編碼器（vision encoder）轉換成視覺特徵，接著語言主幹網路還需要處理數百個視覺 token 與文字提示。這個前置階段稱為 prefill，屬於計算密集（compute-bound）工作，其成本會隨提示長度以接近二次方的速度成長。在邊緣裝置（如手機、筆電）上，由於運算能力遠低於資料中心 GPU，prefill 佔據的端到端延遲比例更高。Liquid AI 提出的 DSpark 方法，正是針對推論中最耗時的逐 token 生成階段（decode）進行加速，而不是嘗試縮短 prefill 或視覺編碼的時間。\n\n核心內容：DSpark 草稿模型如何運作\n\nDSpark 採用的是推測解碼（speculative decoding）策略。概念上，推測解碼會先由一個較小、較快的草稿模型，一次預測出一批候選 token（稱為一個 block），再交由原始的大型目標模型（target model）進行驗證。如果候選 token 被接受，就能一次跳過多個生成步驟，大幅減少序列生成時的迭代次數。DSpark 的視覺草稿模型與 Liquid AI 先前發表的文字版 LFM2.5-DSpark 使用相同架構：它在目標模型的固定層數位置擷取隱藏狀態（hidden states），並以這些狀態為條件，產生長度為 k 的候選 token 區塊。在輸入進入這些層之前，影像區塊與文字 token 都會被投影到同一個共享表示空間，因此草稿模型無論處理哪種模態，都能使用相同維度的隱藏狀態向量，推論演算法也與純文字版本一致。\n\n根據 Liquid AI 的實驗，他們在 3、4、5 層的候選架構中進行消融測試，最終選擇了 4 層、僅使用注意力機制的簡化草稿模型，區塊大小（block size）設定為 9。訓練資料混合了視覺語言指令微調（SFT）資料，並加權偏向預期的工作負載。他們在最終資料集上訓練了 10 個 epoch，並在每個 epoch 後測量 token 接受率，發現接受率會隨訓練資料增加而提升，直到出現邊際效益遞減。最終草稿模型約有 2.8 億個參數，僅比原本 30 億參數的目標模型增加 8.9% 的記憶體開銷。其中解碼器堆疊佔 1.93 億參數、隱藏狀態投影層佔 2100 萬、馬可夫頭（Markov head）佔 6550 萬，正規化與信心頭則約 6400 個參數。\n\n實測表現：CPU 與 GPU 上的加速效果\n\nLiquid AI 在六種不同的視覺任務上進行了評測，涵蓋一般視覺問答（VQA）、文字型視覺問答、影像描述、圖表問答、複雜推理與多輪對話，並遵循 MMSpec 基準。在裝置端推論方面，使用 MLX 框架在 M5 Max 晶片上，解碼速度依任務不同可提升 2.30 倍到 3.13 倍，端到端延遲改善 1.56 倍到 2.62 倍；使用 llama.cpp 在 M3 Ultra 上，解碼速度提升 1.57 倍到 2.14 倍，端到端改善 1.30 倍到 1.77 倍。在 GPU 方面，使用 H100 時解碼速度提升 2.04 倍到 2.66 倍，端到端改善 1.64 倍到 2.27 倍。這些數據顯示，解碼階段的加速幅度相當顯著，但端到端的增益會受到 prefill 與視覺編碼時間的稀釋。\n\n影響與限制：為什麼端到端加速不如解碼加速明顯\n\n這項技術最直接的意義在於，它讓視覺語言模型在邊緣裝置上的部署變得更可行。Liquid AI 強調，DSpark 推測解碼是精確的（exact）：目標模型會逐一驗證草稿模型提出的每個 token，因此在貪婪解碼（greedy decoding）模式下，輸出結果與單純使用目標模型完全一致，不因加速而損失品質。然而，推測解碼只加速 decode 階段，無法加速視覺編碼或 prefill。當這些未加速的階段已經佔據大部分牆鐘時間（wall time）時，即使解碼速度大幅提升，端到端的整體增益仍然有限。這是阿姆達爾定律（Amdahl's law）的典型體現：整體加速上限取決於未被加速的部分所佔比例。在 Apple 矽晶片（如 M5）上，由於 GPU 的神經加速器縮小了 prefill 與 decode 之間的差距，因此端到端加速比更接近解碼加速比；但在 H100 這類資料中心 GPU 上，prefill 佔比更高，端到端增益就較為保守。\n\n使用方式與生態支援\n\nDSpark 草稿模型發布當天即支援三種主流推論框架：SGLang、llama.cpp 與 MLX-VLM。在 SGLang 中，使用者需要啟用 DSpark 支援的建置版本，並在啟動伺服器時加上 --speculative-algorithm DSPARK 等參數，指定草稿模型路徑與區塊大小。llama.cpp 則需使用對應的建置版本，透過 -md 指定草稿模型、--spec-type draft-dspark 啟用推測模式。MLX-VLM 的使用方式最為簡潔，只需在啟動伺服器時同時指定目標模型與草稿模型路徑即可。區塊大小會從草稿模型的 config.json 或 sidecar 中繼資料自動讀取。模型以 Safetensors 與 GGUF 兩種格式開源釋出，允許自由下載、微調與部署。對於有意在資源受限環境部署視覺語言模型的開發者來說，這項技術提供了一個低風險的加速選項：增加的記憶體開銷不到 9%，卻能換取可觀的解碼速度提升，同時維持輸出品質不變。\n\n本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。" }