M09.08｜Edge AI 與端側部署：讓 AI 在裝置上跑起來

一句話搞懂

Edge AI 就是讓 AI 的大腦從遠端的雲端伺服器，搬到你手邊的手機、相機、智慧型音箱或工廠機台上——這樣 AI 的決策速度可以從「網路來回的 100 毫秒」壓縮到「本地處理的 10 毫秒」，用戶的隱私資料也不需要離開裝置，但代價是必須把本來需要幾百 GB 記憶體的大模型，壓縮、精簡到幾十 MB 甚至幾 MB，同時不能讓準確率掉太多。

白話解說

為什麼要在裝置端跑 AI

絕大多數的深度學習模型開發和訓練，都發生在有強大 GPU 的雲端伺服器上。但是，當模型要真正服務用戶時，「送資料到雲端、等待運算、回傳結果」這個流程在很多場景有根本的限制：

即時性要求：自動駕駛的障礙物偵測需要在 10 毫秒內完成——就算台灣的 5G 網路延遲已低至 15–20 毫秒，光是網路來回的時間就已超過系統的容忍極限，更不用說雲端的排隊等待。手術輔助機器人、工業品管視覺系統，都有類似的即時性需求。

隱私與合規性：醫療影像診斷中，病患的 X 光片如果要送到雲端伺服器，涉及個資法和醫療資料的合規問題（HIPAA、GDPR）。如果模型可以在院內的本地機器甚至醫師的 iPad 上運行，資料就不需要離開院所，合規問題大幅簡化。iPhone 的 Face ID 使用 Edge AI 在本地執行人臉辨識，蘋果可以保證「你的臉部資料從未離開手機」，這是一個強力的隱私賣點。

離線能力：農業物聯網感測器在田間可能完全沒有網路；工廠車間的 Wi-Fi 可能不穩定；零售門市的 POS 系統需要在網路中斷時仍能正常運作。Edge AI 確保了「沒有網路也能做 AI 推論」的能力。

頻寬與成本：工廠的 200 台機台攝影機每秒產生的影像資料量，如果全部上傳到雲端，需要的頻寬和存儲成本極其昂貴。在本地機台上直接做品管判斷，只把「有問題的產品影像」上傳存檔，能節省 99% 以上的頻寬和儲存成本。

挑戰：裝置端的嚴苛限制

把 AI 搬到裝置端，面臨的不是技術問題，而是物理限制：

記憶體：一個 GPT-2（1.5B 參數，FP32）模型需要約 6 GB 的 RAM，而普通的 ARM 嵌入式裝置可能只有 256 MB 到 1 GB 的可用記憶體。就算是高階手機的 iPhone 15 Pro 也只有 8 GB RAM（還需要和其他 App 分享）。

運算能力：雲端 A100 GPU 每秒可以執行 312 TFLOPS（兆次浮點運算），而嵌入式 CPU 可能只有幾十 GFLOPS——差了將近 10,000 倍。

功耗：自動駕駛汽車可以用更多電，但手機上的推論每秒消耗幾瓦就已讓電池快速耗盡；IoT 感測器可能只有幾毫瓦的電力預算，要靠電池撐好幾年。

因此，Edge AI 的核心技術，都是在「盡量維持準確率的前提下，把模型壓縮到裝置能承受的大小和速度」。

量化（Quantization）：把數字精度降低

訓練神經網路時，參數通常用 FP32（32 位元浮點數）表示，每個參數佔 4 個位元組。量化（Quantization） 的核心思想是：推論時不需要那麼高的精度，把 FP32 降為 INT8（8 位元整數）甚至 INT4，可以：

• 模型大小：FP32 → INT8，縮小 4 倍（每個參數從 4 bytes 降到 1 byte）
• 推論速度：整數運算在大多數硬體上比浮點運算快 2–4 倍，且更省電
• 精度損失：對大多數任務而言，INT8 量化的精度損失通常在 0.5–1% 以內，在可接受範圍

量化的方式分為兩種：

訓練後量化（Post-Training Quantization, PTQ）：在模型已經訓練完成後，直接對權重做量化。操作最簡單，只需要一小批校準資料（Calibration Data）來確定量化的縮放因子，但精度損失可能比動態量化稍大。TensorFlow Lite 和 ONNX Runtime 都支援這種方式。

量化感知訓練（Quantization-Aware Training, QAT）：在訓練過程中就模擬量化的效果（在前向傳播中加入量化的近似）。因為模型在訓練時就「知道」自己最終會被量化，可以主動調整參數來適應精度降低的約束，精度損失通常更小，但訓練成本更高。適合對精度要求嚴苛的場景（如醫療診斷、自動駕駛）。

剪枝（Pruning）：去掉不重要的神經元

神經網路中有大量的「冗餘參數」——很多權重的值接近零，對最終輸出的貢獻微乎其微。剪枝（Pruning） 就是識別並移除這些冗餘的連接或神經元，讓模型變得「稀疏」，從而減少參數量和運算量。

非結構化剪枝（Unstructured Pruning）：把每個單獨的權重獨立評估，把值最小（貢獻最小）的連接設為零。優點是靈活，可以達到很高的稀疏率（如 90% 的權重被置零）而不顯著損失精度；缺點是產生的「稀疏矩陣」在通用 CPU/GPU 上不一定有加速效果（因為硬體是為稠密矩陣運算優化的），需要專門的稀疏矩陣加速庫。

結構化剪枝（Structured Pruning）：移除整個卷積核（Filter Pruning）、整個通道（Channel Pruning）、甚至整個層。雖然粒度更粗，精度損失相對更大，但剪枝後的模型仍然是「稠密矩陣」，在標準 CPU/GPU 上就能直接獲得速度提升，不需要特殊硬體支援。這也是為何結構化剪枝在實際部署中更常用。

剪枝後通常需要進行微調（Fine-tuning）：用原始訓練資料再訓練幾個 epoch，讓模型從剪枝造成的精度損失中「恢復」部分準確率。剪枝 → 微調 → 再剪枝的迭代過程，稱為「迭代剪枝（Iterative Pruning）」。

知識蒸餾（Knowledge Distillation）：大模型教小模型

知識蒸餾（Knowledge Distillation） 是一種「讓小模型學習大模型」的訓練技術。大模型（Teacher）已被訓練好，小模型（Student）的目標不只是學習真實標籤，而是同時學習 Teacher 的輸出分佈（稱為「軟標籤（Soft Labels）」或「暗知識（Dark Knowledge）」）。

以圖像分類為例，假設一張圖片的真實標籤是「貓（Cat）」。Teacher 模型可能輸出：貓 92%、豹 6%、狐狸 2%。這個「貓 92%、豹 6%」的輸出，比單純的「貓 = 1」的硬標籤包含更多資訊——它告訴我們貓和豹在特徵上有一定的相似性，這個「相似性知識」被 Teacher 模型通過大量訓練「學到」了，但在硬標籤中完全看不出來。Student 通過學習 Teacher 的軟輸出，能用少得多的參數習得接近 Teacher 的泛化能力。

知識蒸餾的損失函數通常是：L = α × L_hard（與真實標籤的交叉熵）+ (1-α) × L_soft（與 Teacher 輸出的 KL 散度），其中 α 是平衡兩個損失的超參數。

知識蒸餾在 NLP 領域非常成功：DistilBERT 是 BERT 的蒸餾版本，參數量僅為 BERT 的 40%，但在 GLUE 基準上保留了 97% 的性能，推論速度提升了 60%。

ONNX：讓模型走遍所有平台

深度學習框架有 PyTorch、TensorFlow、PaddlePaddle 等多種，不同框架訓練的模型格式互不相容。ONNX（Open Neural Network Exchange） 是一個由 Microsoft 和 Facebook 共同推出的開放標準格式，讓模型可以在不同框架之間轉換，並在各種推論引擎上執行。

典型的工作流程是：

1. 訓練：在 PyTorch 上訓練模型（研究人員最熟悉的框架）
2. 匯出：torch.onnx.export(model, ...) 把模型匯出為 .onnx 格式
3. 優化（可選）：使用 ONNX Optimizer 或目標硬體的工具鏈進行圖優化（算子融合、常數折疊）
4. 部署：在目標平台上使用 ONNX Runtime 執行推論（支援 CPU、GPU、NPU）

ONNX 的最大價值是「一次匯出，到處部署」——同一個 .onnx 模型可以在 Windows PC、Linux 伺服器、ARM 板、Android 手機上執行，而不需要重寫推論程式碼。

TensorRT 和 CoreML：硬體最優化的推論引擎

ONNX 提供了通用性，但如果你需要在特定硬體上達到最極致的推論性能，還需要針對硬體的專屬推論引擎：

TensorRT（NVIDIA）：針對 NVIDIA GPU 的推論優化引擎。核心功能包括：算子融合（把多個計算步驟合併成一步，減少記憶體存取）、FP16/INT8 精度優化、動態批次大小支援。在 NVIDIA GPU 上，TensorRT 通常能比原始 PyTorch/TensorFlow 模型快 2–6 倍。工作流程：ONNX → TensorRT Engine（.trt 或 .engine 格式）。特別適合需要在 NVIDIA GPU 上做高吞吐量推論的場景（如影片分析、伺服器端推論）。

CoreML（Apple）：Apple 的推論框架，針對 iPhone、iPad、Mac 上的 Apple Silicon（A 系列晶片）深度優化，能充分利用 CPU、GPU 和 NPU（Neural Engine）三種計算單元。Core ML 模型（.mlmodel 格式）可以直接在 Xcode 中整合，和 iOS/macOS App 無縫結合。Apple 的神經網路引擎（Neural Engine）能以極低功耗執行矩陣運算，這是 Face ID、Siri、即時翻譯等功能的底層基礎。

TensorFlow Lite（TFLite）：Google 的行動端推論框架，主要針對 Android 裝置和 Raspberry Pi 等嵌入式 Linux 平台。支援多種委派（Delegate）機制，可以將計算委派給 GPU、DSP 或高通的 AI 加速器（NNAPI）。TFLite 模型（.tflite 格式）非常輕量，適合資源極為受限的裝置。

應用場景

常見誤區

誤區 1：「量化一定會讓模型變差，能不做就不做」

這個誤解把「精度損失存在」和「精度損失不可接受」混為一談。INT8 量化在大多數任務上的精度損失確實存在，但通常在 0.5–1% 的範圍內，對絕大多數業務場景而言是完全可接受的代價。更重要的是：如果你的模型因為太大而無法在目標裝置上執行，量化不是「讓它變差」，而是「讓它能跑起來」——一個能在手機上執行的 INT8 模型，和一個需要伺服器卻永遠無法到達用戶手邊的 FP32 模型相比，前者顯然更有價值。

此外，量化感知訓練（QAT）能進一步縮小精度損失。研究顯示，在 MobileNet 和 EfficientNet 等針對行動端設計的架構上，INT8 QAT 的精度損失可以壓縮到 0.1–0.3%，幾乎可忽略不計。真正需要謹慎評估的，是那些對精度極度敏感的場景（如精密醫療診斷中辨別良性/惡性的細微差異），在這些場景需要做詳盡的量化精度測試，而非其他所有場景。

誤區 2：「ONNX 匯出後就可以直接在所有裝置上跑，不需要再做任何工作」

ONNX 是「讓模型能在不同平台上運行的格式標準」，不是「讓模型在所有平台上都快速高效地運行的魔法」。匯出 ONNX 格式後，仍然需要根據目標平台做進一步的工作：

首先，並非所有模型使用的算子（Operator）都被 ONNX Runtime 的所有後端支援。如果你的模型使用了一些非標準的自定義層或最新版本才支援的算子，在特定平台的 ONNX Runtime 上可能會出現「不支援的算子」錯誤，需要找替代實作或手動實現。

其次，為了在特定硬體上達到最優性能，通常還需要進行額外的優化步驟：若目標是 NVIDIA GPU，需要用 TensorRT 將 ONNX 模型進一步編譯成 .trt 引擎；若目標是 Apple 裝置，需要用 CoreML Tools 將 ONNX 轉換為 .mlmodel；若目標是 Android，需要轉換為 TFLite 格式。每個平台都有自己的「最後一哩路」工作，ONNX 解決的是「框架互通性」問題，而非「硬體優化」問題。

誤區 3：「Edge AI 只是把雲端模型縮小，架構和雲端一樣」

一個真正優秀的 Edge AI 系統，從訓練資料準備、模型架構選擇、訓練策略，就已經和純雲端系統有本質上的不同，而不是「最後縮小一下」。

架構設計：EdgeAI 的模型架構從一開始就要考慮部署硬體的特性。MobileNetV3 使用深度可分離卷積（Depthwise Separable Convolution），把計算量壓縮到 VGG-16 的 1/30，但準確率差距不大；EfficientNet 用複合縮放（Compound Scaling）在準確率和模型大小之間取得最優平衡。如果你用 ResNet-50 訓練，再試圖用各種壓縮技術把它塞進手機，效果通常不如直接用為行動端設計的 MobileNet 或 EfficientNet。「為目標硬體設計架構」的思維，遠比「先設計，後壓縮」更有效率。

訓練策略：Edge AI 模型的訓練，應該從一開始就加入正則化（防止過擬合，因為模型容量有限）、使用量化感知訓練（而非訓練完再量化），並在訓練時就對剪枝目標進行約束（稀疏訓練）。把 Edge AI 的「壓縮」留到最後才做，不如把對效率的要求融入整個訓練過程。

小練習

練習 1：選擇壓縮技術

你是一家台灣醫療設備公司的 AI 工程師，需要把一個已在雲端驗證的「皮膚病變分類模型」部署到醫師使用的 iPad Pro 上。原始模型是 ResNet-50，FP32 格式，大小 98 MB，在 GPU 伺服器上推論延遲 50ms。

iPad Pro 的硬體限制：Apple M2 晶片，8 GB RAM，App 大小建議 < 100 MB（含其他資源），要求推論延遲 < 200ms（醫師在診間等待時間）。

模型目前的性能指標：AUC = 0.94，敏感性（Recall）= 89%，特異性（Precision）= 91%。

請選擇適合的壓縮技術組合，並說明：

1. 你會使用哪些壓縮技術？為什麼選這個組合？
2. 壓縮後預期的模型大小和推論延遲大約是多少？
3. 你最擔心的精度指標是什麼？為什麼？如何驗證壓縮後的模型仍然符合醫療要求？

練習 2：診斷 Edge AI 部署問題

你的公司在台灣一家量販店部署了邊緣 AI 貨架補貨系統：每個貨架有一個 Raspberry Pi 5，跑一個 YOLOv8 物件偵測模型，偵測哪些商品數量低於安全庫存，並通知補貨人員。

部署一個月後，遇到以下問題，請逐一診斷原因並提出解決方案：