LFM2-VL 邊緣部署：量化、速度與商業授權

LFM2-VL 曾以「最高可達 2× GPU 推論速度」作為亮點，但部署決策不該只剩下一個倍數。真正要問的是：這個結果用了什麼圖片、輸出多少 token、在哪一種 GPU 與執行環境測得？當模型換成 Q4、Q8 或不同的邊緣裝置，延遲、記憶體與回答品質又會怎麼變？

先說結論：LFM2-VL 官方頁面目前已標示為 deprecated；新專案應優先把 LFM2.5-VL 納入評估。原先的「最高 2×」來自特定 GPU 工作負載，不是每一台手機、瀏覽器或量化格式都能直接套用的承諾。商業使用也不能只看「開放權重」，而要核對實際模型版本、授權條款與公司適用條件。

先更新現況：LFM2-VL 已被標示為 deprecated

Liquid AI 的 LFM2-VL 發表頁與模型文件目前都明確標示這個系列已 deprecated，並建議改用 LFM2.5-VL-450M 或相對應的新版本。LFM2-VL-450M 原本定位為 450M 參數、面向記憶體與運算受限裝置的視覺語言模型；它仍可作為既有系統的比較基準，但不宜把舊版宣傳數字直接當成新專案的採購結論。

這不代表既有 LFM2-VL 專案必須立刻下線。比較務實的做法是：保留現行版本作為 baseline，先以相同資料、相同裝置與相同品質門檻測試新版本；確認輸出格式、視覺理解品質、模型大小與實際延遲後，再安排遷移。

「最高 2×」究竟測了什麼？

官方的速度說明有清楚的測試前提：一張 1024 × 1024 圖片、類似「詳細描述這張圖片」的短 prompt、產生 100 個輸出 token，並在各模型的預設設定下比較。結果是在這個工作負載與 GPU 比較條件中，LFM2-VL 最快可比最快的可比模型快到 2 倍。

因此，這個數字值得參考，但不能延伸成「所有場景都會快 2 倍」。實際服務可能面對的是手機相簿裡不規則尺寸的照片、OCR、長回答、多張圖片、同時多人使用、裝置過熱後降頻，或瀏覽器 WebGPU 的相容性差異。這些條件都會改變影像前處理、prefill、token decode 與整體延遲的比例。

解讀速度數字的四個問題

輸入圖片的數量、解析度與長寬比是否與真實任務一致？
輸出 token 上限是否相同？短回答與長回答的瓶頸不一樣。
比較的是冷啟動、熱機後，還是包含模型下載與載入的端到端時間？
是否在相同硬體、runtime、batch、並發與溫度條件下量測？

量化不是一條固定的加速公式

ONNX 的價值在於可攜性：同一類模型能由 CPU、GPU、NPU 或瀏覽器的 WebGPU runtime 執行。不過可攜不等於各平台表現相同；硬體算子支援、記憶體頻寬、runtime 版本與影像處理流程，都會影響最終結果。

Liquid 的 ONNX 文件列出 LFM2-VL／LFM2.5-VL 可使用 fp32、fp16、q4 與 q8。文件建議多數部署先從 Q4 開始；Q4 可用於 WebGPU、CPU 與 GPU，FP16 著重較高品質並支援 WebGPU／GPU；Q8 是品質與體積間的折衷，但官方文件列為伺服器 CPU／GPU 使用。FP32 則適合作為全精度 baseline。

要注意的是，Q4 並不保證「比 FP16 快一倍」，也不保證所有視覺任務品質足夠。量化可能降低模型檔案與記憶體壓力，但在某些裝置上，解碼、影像編碼器或資料搬移才是瓶頸；有些任務還會在細小文字、圖表、低光影像或特定語言辨識上出現品質差異。

邊緣部署應如何做出可重現的基準測試？

1. 先固定真實工作負載

從實際產品蒐集一小組去識別化測試案例，而不是只用單一漂亮範例。至少涵蓋常見圖片尺寸、最困難的視覺情境、典型 prompt、最大輸出長度與預期並發量；每次測試都記錄模型 revision、量化格式、runtime、硬體、驅動程式與溫度狀態。

2. 把延遲拆開量

請同時記錄冷啟動載入時間、熱機後的首 token 時間、影像 prefill、每 token 解碼速度、端到端 P50／P95 延遲，以及峰值 RAM／VRAM。若是電池裝置，也要看耗電、溫度與長時間執行後是否降頻；只報平均 tokens/s 往往會掩蓋真正的互動體驗問題。

3. 把品質做成通過門檻

為每種核心任務設定可人工覆核的成功標準，例如：OCR 關鍵欄位是否正確、是否漏掉安全相關物件、回答是否有明確幻覺、固定問答是否能保留必要細節。將 FP16 或 FP32 作為 baseline，再對 Q4、Q8 和目標新模型比對；若速度更快但關鍵任務失敗率超標，就不應直接上線。

4. 以產品門檻做選擇，而不是追單一最高分

可以先定義「P95 延遲、峰值記憶體、可接受錯誤率、模型下載大小、持續運作溫度」五項門檻。只有同時通過門檻的組合，才進入小規模試行。這樣的結果才能回答「它是否適合我的裝置」，而不是只重複廠商的 benchmark。

商業使用：開放權重不等於不需審核

原始 LFM2-VL 發表說明採用以 Apache 2.0 為基礎的開放授權：學術與研究可自由使用；商業使用則以較小公司（營收低於 1,000 萬美元）為條件，超過門檻需聯絡 Liquid AI 取得商業授權。這是該舊版發表頁對當時模型所寫的條件，不應自動套用到 LFM2.5-VL、任何模型 revision 或未來條款。

在採用前，請把以下事項列為交付前檢查：

確認要部署的精確模型名稱、revision、權重來源與當前授權全文。
請法務或採購確認營收門檻的計算範圍、集團關係企業與分發情境是否適用。
核對是否會重新分發權重、微調衍生物、量化檔或把模型放入客戶端產品。
一併盤點 ONNX runtime、瀏覽器套件、資料集、字型與其他第三方元件的授權。
保留採用日期、條款副本與批准紀錄；授權有疑義時，向供應商或專業法律意見確認。

這不是法律意見；重點在於把「模型可下載」與「你的公司可以如何商業散布、服務客戶」分開驗證。

新專案與既有專案的建議決策

若是新專案：先將 LFM2.5-VL 納入第一輪評估，因為官方文件已建議以它取代 LFM2-VL 的相同緊湊部署定位。不要假設它與舊版在 prompt 格式、品質、模型大小或 runtime 行為完全相同；仍要跑自己的基準測試。

若已在使用 LFM2-VL：不要只因 deprecated 就匆忙換版。先建立一組可重現 baseline，將現行版本與候選新版本在真實裝置上並列測試。只有在品質、P95 延遲、記憶體、熱管理與授權都通過後，再採用漸進式釋出與可回退機制。

若主打隱私或離線能力：本機推論能減少資料送往自家伺服器的需求，但不會自動證明整條產品流程安全。影像暫存、崩潰紀錄、分析 SDK、模型下載來源與更新機制仍需另行檢視。

常見問題

Q：把模型換成 Q4，就可以期待 2× 加速嗎？

不可以直接這樣推論。2× 是特定 GPU 工作負載下的「最高可達」比較結果；Q4 的實際收益取決於硬體、runtime、影像大小、輸出長度與是否受到記憶體或算子支援限制。

Q：Q4 一定是最佳選項嗎？

官方文件建議多數部署先用 Q4，因為它在支援範圍與資源需求間具實用性；但「最佳」仍取決於你的品質門檻。遇到 OCR、圖表或細節辨識等任務，務必以自己的測試集確認品質。

Q：LFM2-VL deprecated 代表舊系統不能再用嗎？

不代表立即不能用，但代表新功能、文件與支援重心會轉向後續版本。既有系統應排入升級評估與風險管理，而不是把舊版當成長期不變的基礎。

結論

LFM2-VL 的速度主張並非沒有價值，而是必須放回它的測試條件中解讀。對邊緣 AI 團隊而言，較可靠的路徑是：以目前產品工作負載重跑基準、把 Q4／Q8／FP16 的品質與延遲一起比較、優先評估官方建議的新 LFM2.5-VL，並在交付前完成精確版本的授權查核。這樣才能把「最高 2×」從行銷數字，轉換成可驗證的部署決策。