前幾天，我一直在研究 Model Registry。

從 Model Upload、Validation、Version Management，到不同硬體需要不同的 Model Artifact，越整理越覺得事情不太對勁。

我們明明是想做一個 Edge AI Application，怎麼最後變成客戶還要懂 Model Format、Runtime、Operator、HTP，甚至還要知道自己的設備到底適合哪一種 Artifact？

如果連我自己都覺得複雜了，那客戶呢？

假設今天有一個工廠客戶，他的需求很簡單：

「我想知道有沒有人闖入管制區，有人進去就通知我。」

就這樣。

客戶沒有說要 ONNX，也沒有說要 QNN，更不會特別指定 HTP。

他要的是入侵警報，不是來上 Qualcomm SDK 課程的。

這讓我開始思考：Model Registry 除了管理 Model，能不能讓客戶根本不需要知道底下有多少技術細節？

1. 客戶選的是 Use Case，不應該是 Runtime

先想像一下，如果今天讓客戶自己設定，畫面可能長這樣：

• Model：person_detection_v1.3.onnx
• Runtime：QNN
• Backend：HTP
• Input Size：640 × 640
• Pre-processing：RGB / Normalize
• Post-processing：NMS
• Target Device：QCS6490

這些設定對工程師可能很合理，但對只想完成入侵偵測的客戶來說，未必是必要的資訊。

更何況，換一台設備，設定可能又要全部重新確認。

所以我開始把使用者真正想做的事，跟平台底下要處理的事分開。

客戶只需要選擇：

Use Case：Restricted Area Intrusion Detection

接著設定：

• 要監控哪一路攝影機？
• 哪個區域是禁區？
• 偵測到人員進入後，要做什麼？
• 要通知誰？

至於使用哪個 Model、要跑在哪個 Runtime、需不需要特定的硬體加速，就讓平台根據設備能力和驗證結果來決定。

當然，這不代表平台可以憑空猜出所有設定。Model、攝影機與事件規則仍然需要有明確的對應關係，只是沒有必要把所有底層細節都交給客戶操作。

2. 那 Cloud 背後到底要做什麼？

假設客戶有三台 Edge Device：

• Device A：Qualcomm QCS6490
• Device B：NVIDIA Jetson
• Device C：x86 CPU

客戶的需求完全一樣，都是人員入侵偵測。

但平台不能因此就把同一個 Model 檔案直接推送到三台設備。

背後至少要經過幾個步驟。

第一步：確認設備能力。

Cloud 先知道每台設備的硬體、Runtime、可用加速器及系統環境。

第二步：找出符合條件的 Model Artifact。

例如 QCS6490 使用經過驗證的 QNN / HTP 部署產物；NVIDIA 設備則選擇符合其執行環境的產物。

不是檔案名稱相同就可以使用，而是必須確認目標設備與 Artifact 相容。

第三步：確認 Validation 結果。

即使 Artifact 技術上可以執行，也要確認它是否符合這個 Use Case 的效能、準確度及穩定性要求。

第四步：再進行部署。

確認通過之後，平台才把正確的 Artifact 與必要的設定送到目標設備。

整個流程可以整理成：

Customer Use Case
↓
Cloud
↓
Device Capability Check
↓
Model Artifact Selection
↓
Compatibility & Validation
↓
Deployment

這裡要注意：自動選擇不等於自動保證成功。如果找不到符合條件、已完成必要驗證的 Artifact，平台就應該明確告訴使用者目前無法部署，而不是隨便挑一個 Model 試試看。

3. Model Registry 不應該只是 Model 的倉庫

做到這裡，我對 Model Registry 的想法又有一點改變。

如果它只負責存檔案、列出版本，那它比較像一個 Model Repository。

但如果我們希望 EdgeHub 能協助完成跨設備部署，就需要讓它掌握更多資訊：

• Model：這個模型要解決什麼問題？
• Model Version：目前使用哪個版本？
• Model Artifact：針對哪種硬體與 Runtime 產生？
• Device Profile：目標設備具備什麼能力？
• Validation Result：這個 Artifact 在目標環境驗證得如何？
• Deployment Status：目前部署到哪裡？是否成功？

這些資訊放在一起，平台才有辦法判斷：

「客戶要做人員入侵偵測，而這台設備有一個符合條件、已經驗證過的 Artifact，可以拿來部署。」

這才是我希望 Model Registry 最後能做到的事情。

4. 但我也發現，自動化不是把所有事情都自動化

這裡其實有一個很重要的產品取捨。

如果每個 Model 都要 RD 手動轉換、手動測試、手動指定設備，產品就很難規模化。

但如果我們讓系統看到一個新 Model，就自動轉換、自動部署到所有設備，也可能把尚未驗證的模型送進正式環境。

所以我會把流程拆成兩個階段：

開發與驗證階段

Model 上傳 → 轉換 → 相容性檢查 → 效能測試 → Use Case 驗證 → 核准。

正式部署階段

選擇 Use Case → 確認設備 → 選擇已核准的 Artifact → 部署 → 監控。

前面的工作可以逐步自動化；但正式部署仍然需要遵守核准狀態、設備相容性與客戶的部署政策。

這樣才不會為了追求自動化，反而增加產品風險。

5. 我希望客戶最後看到的是什麼？

我不希望客戶進入 Cloud 後，第一件事就是研究：

「我的設備應該使用哪一個 Model Artifact？」

我希望他看到的是：

Use Case：人員入侵偵測

1. 選擇攝影機。
2. 畫出管制區域。
3. 設定告警條件。
4. 選擇目標設備。
5. 確認部署。

剩下的工作，由平台根據已驗證的 Model、Artifact 與設備能力協助處理。

這不代表底層技術不重要。恰恰相反，正因為底層有這麼多複雜的事情，產品才更需要把它們整理好。

好的平台，不是讓使用者看到更多技術選項，而是讓使用者不用理解所有技術細節，也能安全地完成工作。

回頭看這幾天，我從一開始想做 Model Registry，只是希望 Model 可以快速替換，到現在開始思考：

當 Model 越來越多、設備越來越多，我們能不能讓部署這件事變得更簡單？

對我來說，這才是從 PoC 走向 Edge AI Product 的重要差別。

PoC 證明技術可以跑。

Product 則要想辦法，讓更多人能夠重複使用這個能力，而不需要每次都從頭研究一次。

而當 Model 可以被管理、驗證、選擇與部署之後，我又想到另一個問題：

如果一台工廠設備有十路攝影機，甚至同時執行多個 AI Use Case，平台要怎麼決定哪些工作該跑在 CPU、哪些交給 HTP？又該如何避免資源被用光？

這就不只是 Model Management 了。

而是下一個更接近真實產品的問題：Edge AI 的資源管理與多工作負載調度。