Edge AI：當 GPT-4V 等級的模型能在你的手機上跑

TL;DR（給忙碌的你）

當大家還在討論「要用哪家雲端 AI 服務」時，一個更根本的趨勢正在發生：GPT-4V 等級的模型，已經可以在手機上運行了。

三個關鍵洞察：

1. Edge AI 不是雲端的備胎，而是結構性優勢 在體驗（零延遲）、合規（資料不離開裝置）、成本（OPEX 變 CAPEX）三個維度，Edge AI 都有無法取代的價值。

2. 「Moore’s Law for MLLM」正在加速 高性能模型的參數量快速下降，手機算力快速上升。2025-2026 是兩條線交會的關鍵時刻。

3. 實現需要系統化思維 單純「換小模型」不夠，從模型架構到硬體適配，需要多層次優化技術的協同。MiniCPM-V 的案例展示了這套方法論。

這篇文章分為兩部分：

• Part A（企業主）：為什麼要投資 Edge AI？有哪些場景已經可以落地？
• Part B（工程主管）：技術架構、效能數據、需要注意的陷阱

我原本也以為 AI 就該上雲端

因為 OpenAI、Anthropic、Google 這些大模型廠商的快速進步，我們談到導入 AI 時，第一個想法自然就是「接 API、用雲端服務」。我原本也是這麼認為——畢竟，GPT-4、Claude 這些模型動輒數千億參數，怎麼可能在手機或個人電腦上跑？

直到最近我想深入了解 Edge AI 的可行性，ChatGPT 推薦了我幾篇論文。我細看其中一篇 Nature Communications 發表的 MiniCPM-V 論文後，才發現：Edge AI 的進步幅度比我想像的快太多了。

論文展示了一個驚人的趨勢——他們稱之為「Moore’s Law for MLLM」（多模態大語言模型的摩爾定律）：

• 2023 年 11 月：GPT-4V 發布，參數量未知但推測超過 1 兆
• 2024 年 4 月：Gemini Pro 達到類似性能，規模仍然巨大
• 2024 年 5 月：MiniCPM-Llama3-V 2.5 僅用 8B 參數，在 OpenCompass 綜合評測上超越 GPT-4V-1106

這代表什麼？代表「高性能 AI 必須在雲端跑」這個假設正在被打破。更重要的是，手機和個人電腦的算力還在持續成長。兩條線在 2025-2026 年交會，意味著：GPT-4V 等級的 AI 已經能在你口袋裡的手機上運行。

但這裡有個關鍵認知：單純「把模型縮小」並不足以實現真正可用的 Edge AI。真正的差異來自背後一整套系統化的優化技術。

Part A｜給企業主：為什麼現在就該佈局 Edge AI？

1) Edge AI 的三個無可取代價值

先說清楚，Edge AI 不是「因為雲端太貴所以退而求其次」。它在三個維度上有結構性優勢：

體驗：零延遲、不受網路波動

想像你的零售店有個 AI 輔助結帳系統。如果依賴雲端，每次辨識商品都要等網路往返，在尖峰時段或網路不穩時體驗會崩潰。但如果 AI 在本地跑，回應是即時的，就算斷網也能正常運作。

合規與信任：資料不離開裝置

在醫療、金融、工業等領域，「資料隱私」不是選項，而是生死線。GDPR、HIPAA 這些法規都明確要求敏感資料的處理要有嚴格控管。

端側處理的最大優勢：資料從拍攝、辨識到刪除，全程不離開裝置。這不只是合規需求，更是建立用戶信任的基礎。

成本：把 OPEX(營業費用) 變 CAPEX(資本支出)

雲端推論費用是長期壓力。一個日活 10 萬的 App，如果每個用戶每天調用 5 次 GPT-4V 等級的視覺理解，光 API 費用每月就是六位數美元。

端側部署是一次性投入（設備 + 模型），之後邊際成本幾乎為零。對穩定使用頻率高的應用來說，ROI 在 6-12 個月內就能回本。

2) 你該用什麼 KPI 衡量成效？

別只看「模型有沒有跑起來」，要看這四個數字：

P50/P95 首 Token 延遲（First-Token Latency） 這決定用戶會不會覺得「AI 在思考」還是「AI 當機了」。業界標準：P95 延遲要在 3 秒內，否則用戶會流失。

持續解碼吞吐（tokens/sec） 這決定長回應的體驗。人類閱讀速度約 3-5 tokens/s，如果 AI 輸出低於這個速度，用戶會不耐煩。

每次推論能耗（mAh/Wh） 這決定設備續航。如果一次推論耗掉 5% 電量，用戶根本不會持續使用。

準確度保持率 量化和優化會損失精度。關鍵是確保端側模型和雲端模型在關鍵任務上的品質差距控制在 5% 以內。

3) 哪些場景最適合 Edge AI？

不是所有任務都適合搬到端側。以下四類場景有明確的商業價值：

金融 身分證件 OCR、合約審閱、客戶盡職調查（KYC）。這些任務涉及敏感個資，需要「資料不出裝置」和「即時處理」。

製造 設備點檢、瑕疵檢測、SOP 導引。工廠內網往往封閉，無法連雲端。

醫療／隱私敏感 病歷 OCR、診間助理。法規要求資料不能外傳。

個人裝置體驗 多語助理、圖文混合搜尋、桌面 OCR。用戶不想每次用 AI 都要上傳隱私資料。

一句話總結：Edge AI 不是雲端備胎，而是在體驗、合規、成本三軸同時佔上風的新產品邏輯。

結語：Edge AI 的競爭優勢來自系統思維

回顧整篇文章，可以看到一個清晰的主軸：Edge AI 的真正門檻不在「模型大小」，而在「系統化優化能力」。

MiniCPM-V 的案例展示了，8B 參數的模型，經過模型架構、部署優化、硬體適配這三層的系統化優化後，能在手機上達到 GPT-4V 等級的性能——視覺編碼 1.3s（NPU 加速），解碼吞吐 8.2 tokens/s，超越人類閱讀速度。

更值得關注的是，「Moore’s Law for MLLM」趨勢正在加速：高性能模型的參數量快速下降，邊緣裝置的算力快速上升。這兩條線的交會，意味著我們正站在一個轉折點上。

從企業策略角度來看，現在佈局 Edge AI 不是賭未來，而是抓住現在。那些在體驗、合規、成本三軸都有優勢的場景，已經具備落地條件。

從技術實現角度來看，這篇文章提供了完整的優化框架。從模型選型到硬體適配，每一層都有明確的優化方向和實證數據。

核心洞察是：Edge AI 不是簡單的模型遷移，而是一場系統化的工程挑戰。成功的團隊往往不是因為擁有更小的模型，而是因為掌握了多層次優化技術的協同方法。

想立即體驗 Edge AI？試試 QVAC Workbench

如果你想親身體驗 Edge AI 在手機/筆記型電腦上的運行效果，QVAC Workbench 是個不錯的起點。

這是 Tether 推出的本地 AI 平台，核心理念正好呼應本文的主題：AI 可以在你的裝置上運行，資料不需要離開你的手機。目前支援 Android、iOS、Windows、macOS 等平台，可以在手機（8GB+ RAM）上流暢運行 1B-3B 參數的模型。

功能包括本地 AI 對話、文檔分析、語音轉錄等，所有處理都在裝置端完成。對於想要實際感受「資料不出裝置」，這是個很好的實驗工具。

Part B｜給工程主管：優化是多層次的系統工程

現在進入技術視角。基於 MiniCPM-V 論文的實戰經驗，我整理出 Edge AI 優化的完整圖景。

為什麼「換小模型」不足以解決問題？

直覺上，使用 Phi-3 或 Qwen-7B 這類較小的模型似乎就能解決端側部署的問題。但實際執行時，通常會遇到三個技術挑戰：

1. 記憶體瓶頸：處理高解析度圖片時，視覺 token 數量快速增長，記憶體容量成為限制
2. 延遲問題：即使模型成功載入，首 token 延遲可能達 30 秒以上，影響使用體驗
3. 能耗管理：持續推論會導致裝置溫度上升、電量快速消耗

關鍵認知：效能瓶頸往往不只出現在模型大小這個單一面向，而是分散在「模型設計」「推論優化」「硬體適配」等多個層面。

優化的三個層次

根據 MiniCPM-V 的實踐，優化可以分為三大類：

第一層：模型架構層

• 自適應視覺編碼：動態切片 + token 壓縮，控制視覺 token 數量
• 多階段訓練：漸進式學習高解析度，保持訓練穩定性

第二層：部署優化層（本文重點）

1. 量化（Quantization）：4-bit 量化，記憶體從 16GB 降到 5GB
2. 記憶體序列載入：先載 ViT 編碼圖片，釋放後再載 LLM，避免換頁
3. 目標裝置編譯：在實際裝置上編譯，ISA 一致性帶來顯著加速
4. 自動配置搜尋：針對每款裝置找出最佳執行緒數和核心綁定
5. NPU 專核加速：用手機 NPU 加速視覺編碼，降低 CPU 負擔

第三層：硬體適配層

• 針對不同晶片（Snapdragon、Dimensity、Apple Silicon）調整配置
• 利用異構運算（CPU + GPU + NPU）分攤工作負載

實測數據：多層優化的累積效果

以 Xiaomi 14 Pro (Snapdragon 8 Gen 3) 為例，以下數據來自論文 Figure 6e 的逐步優化效果：

記憶體優化：

• 影像處理時間從 45.2s 降至 31.5s（減少 30%）

裝置編譯優化：

• 編碼延遲從 50.5s 降至 17.0s（減少 66%）
• 解碼吞吐從 1.3 提升至 3.2 tokens/s（提升 2.5x）

配置搜尋優化：

• 解碼吞吐從 3.2 提升至 8.2 tokens/s（提升 2.6x）

NPU 加速：

• 視覺編碼時間從 3.7s 降至 1.3s（減少 65%）

關鍵洞察：單一優化的效果有限，但多層次優化的累積效果顯著。最終配置下，Xiaomi 14 Pro 達到約 1.3s 視覺編碼時間和 8.2 tokens/s 解碼速度，超越人類閱讀速度。

裝置矩陣：不同硬體的效能表現

論文測試了四款裝置，以下數據來自 Figure 6f（完整編碼延遲包含視覺編碼與 LLM prefill）：

決策門檻（什麼叫「可以上線」）：

• 完整編碼延遲 < 15s（用戶可接受的首次回應時間）
• 解碼吞吐 ≥ 8 tokens/s（達到或超越人類閱讀速度）
• 能耗 < 5% 電量/次推論（保證實用性）

關鍵發現：在 NPU 加速下，Xiaomi 14 Pro 的視覺編碼速度竟然比 Mac M1 相當更快。此外，四台測試裝置的解碼吞吐都接近或超越人類閱讀速度。

品質驗證：優化不能犧牲準確度

優化追求速度的同時，品質是底線。以下數據來自論文 Figure 4 和 Figure 5 的評測結果：

幻覺率（Object HalBench，分數越低越好）：

• MiniCPM-Llama3-V 2.5：10.3
• GPT-4V-1106：13.6
• 表現優於 GPT-4V，證明可信度更高

多語言能力（Multilingual LLaVA Bench）：

• 支援 30+ 語言
• 在多語言評測中超越 Yi-VL-34B 和 Phi-3-Vision

實務建議：建議建立固定測試集，在每次優化後進行驗證。使用真實場景資料（而非僅依賴 benchmark），並追蹤 P50/P95/P99 等關鍵指標。量化後的模型品質變化需要持續監控。

值得注意的技術陷阱

基於實際專案經驗，以下幾個面向特別容易被低估：

參數縮減 vs. Token 控制 將模型從 70B 縮減到 7B，但在處理高解析度圖片時仍會遇到記憶體瓶頸。關鍵在於同步進行視覺 token 壓縮。

Benchmark 分數 vs. 實際體驗 雲端 benchmark（如 MMMU）分數優異，但端側 prefill 階段的延遲可能影響使用體驗。建議拆解評測路徑，檢視各階段的實際延遲。

能耗與溫度管理 長時間推論會讓 CPU 溫度上升，觸發 throttling 機制，影響體驗穩定性。連續推論場景的測試很重要。

品質驗證機制 量化後的幻覺率可能產生波動。在關鍵應用場景中，建議加入人工抽查機制。

Appendix：技術細節

以下內容提供給想要詳細閱讀論文的讀者作為補充參考。

論文來源： Yuan Yao et al. (2025). “MiniCPM-V: Efficient GPT-4V level multimodal large language model for deployment on edge devices.” Nature Communications 16:5509. https://doi.org/10.1038/s41467-025-61040-5

A1. 模型架構層優化詳解

自適應視覺編碼（Adaptive Visual Encoding）

技術原理： 把高解析度影像切片，每片對齊 ViT 預訓練的解析度和長寬比，然後用 single-layer cross-attention 壓縮成固定數量的 token（MiniCPM-V 使用 96 tokens/slice）。

為什麼有效：

• 避免二次方成長：直接編碼 1344×1344 會產生上萬個 token，切片後每片只有 1024→96 tokens
• 保留空間結構：用 <slice> 標記和 \n 行分隔，讓模型知道圖片的全局佈局
• 匹配預訓練設定：每片的解析度和長寬比接近 ViT 預訓練時的 448×448，減少 OOD 問題

實作要點： 推論時需要動態計算最佳切片策略（m×n grid），這會增加前處理成本，但大幅降低後端 LLM 的計算量。

多階段訓練策略

三階段流程：

• Stage 1：暖身壓縮層 224x224（200M image-text pairs）
• Stage 2：擴展解析度到 448×448（200M pairs）
• Stage 3：引入自適應編碼 + OCR 數據（50M pairs + OCR）

為什麼有效：漸進式擴張讓模型穩定學習，避免一開始就用高解析度導致訓練不穩。

A2. 部署優化層實作指南

量化（Quantization）

效能數據（MiniCPM-Llama3-V 2.5）：

• 記憶體：約 16-17GB → 約 5GB（降約 70%）

記憶體序列載入

實作概念（偽代碼）：

# 先載 ViT 做影像編碼
vit = load_vision_encoder(accel="npu")
image_tokens = vit.encode(image)
unload(vit)  # 釋放 ViT 佔用的記憶體

# 再載 LLM 做文字和視覺 token 編碼
llm = load_llm(model="8b-q4_k_m", kv_cache_limit=4096)
output = llm.generate(prompt, vision_tokens=compress(image_tokens))

效果（Xiaomi 14 Pro）：

• 同時載入：影像處理 45.2s（頻繁 paging）
• 序列載入：影像處理 31.5s（減少 30%）

為什麼有效：ViT 和 LLM 同時載入會佔用 8-10GB 記憶體，超過手機 RAM 上限，導致頻繁換頁。序列載入讓峰值記憶體降到 6GB 以內。

目標裝置編譯

效果（Xiaomi 14 Pro）：

• 編碼延遲：50.5s → 17.0s（減少 66%）
• 解碼吞吐：1.3 → 3.2 tokens/s（提升 2.5x）

為什麼有效：在目標裝置上編譯確保 ISA（指令集架構）一致性，編譯器能針對特定 CPU 生成最優化的機器碼。

自動配置搜尋

效果（Xiaomi 14 Pro）：

• 解碼吞吐：3.2 → 8.2 tokens/s（提升 2.6x）

實務經驗：不同裝置的最佳配置會有差異，建議透過實際參數掃描來確認，並記錄作為該裝置的預設配置。

NPU 加速

Qualcomm QNN 整合（概念）：

MiniCPM-V 使用 Qualcomm QNN (Qualcomm Neural Network SDK) 加速 ViT 視覺編碼，LLM 部分仍用 llama.cpp。

效果（Xiaomi 14 Pro with NPU）：

• 視覺編碼：3.7s → 1.3s（減少 65%）

限制：目前 NPU 對 ViT 這種 Transformer 結構友善，但對 LLM 的加速效果有限。未來隨著 NPU 演進會改善。

A3. 參考資源

論文：

• MiniCPM-V: Efficient GPT-4V level multimodal large language model for deployment on edge devices (Nature Communications, 2025)

關於本文：本文整理自 MiniCPM-V 論文與作者的工程實踐經驗。