第 18 天開始整理 Model Registry 之後，我又遇到一個問題。

我們不是已經有 Harbor 了嗎？

Harbor 本來就可以管理 Image、版本，也可以讓設備下載。

那為什麼還要再弄一個 Model Registry？

一開始我也覺得，這兩個東西好像有點重複。

但真的把 Application 跟 Model 拆開來想，就比較清楚了。

Harbor 管的是 Application

例如我們的 Edge AI Application 可能會有：

edge-ai-app:v1.0
edge-ai-app:v1.1
video-service:v2.0
ai-runtime:v1.3

這些是 Container Image。

所以 Harbor 解決的主要是：

Application 要怎麼打包、管理版本，然後部署到設備？

流程大概是：

AI Application
      ↓
Docker Image
      ↓
Harbor
      ↓
ECU-2200

這件事情 Harbor 做得很好。

那 Model Registry 是管什麼？

Model Registry 管的是 AI Model。

例如：

Person Detection v1.0
Person Detection v1.1
Person Detection v2.0
Helmet Detection v1.0
Pose Detection v2.1

但它跟一般檔案管理最大的差別是：

它不只是把 Model 存起來。

還要知道：

Model：Person Detection
Version：v2.1

Format：ONNX
Input：640 × 640
Precision：INT8

Target：QCS6490
Runtime：QNN
Backend：HTP

以及：

Validation：
QCS6490 → PASS
FPS → 28.6
Latency → 35ms

所以我會很簡單地分：

Harbor 管 Container Image。
Model Registry 管 AI Model。

那 Model 為什麼不直接包進 Container？

其實可以。

如果今天只是做 PoC，我甚至覺得這樣最簡單。

例如：

AI Container
│
├── Application
├── Runtime
└── person.onnx

整包放到 ECU。

問題是，Model 跟 Application 的更新頻率不一定一樣。

假設 Application：

edge-ai-app:v1.0

可能一段時間才更新一次。

但是 Model 可能一直在調：

Person Detection v1.0
        ↓
Person Detection v1.1
        ↓
Person Detection v1.2
        ↓
Person Detection v2.0

如果 Model 每換一次，就要重新 Build Container，再 Push Harbor，再重新部署整個 Application。

其實會變得很重。

所以我開始覺得：

Application 跟 Model 可以分開管理。

這時候 Cloud 就接上來了

我現在會把架構想成：

                       Cloud
                          │
             ┌────────────┴────────────┐
             │                         │
       Application                 Model
       Management                 Registry
             │                         │
             ↓                         ↓
          Harbor                 Model Storage
             │                         │
             └────────────┬────────────┘
                          ↓
                     Deployment
                          ↓
                       ECU-2200

Cloud 最後負責把：

Application + Model + Device

串在一起。

舉一個比較實際的例子

假設我要在 ECU-2200 上部署：

Unmanned Area Detection

Application：

edge-ai-app:v1.2

這個 Image 在 Harbor。

Model：

Person Detection:v2.1

這個由 Model Registry 管理。

Device：

ECU-2200 #001
QCS6490

那 EdgeHub 就可以建立一個 Deployment：

Application
    ↓
edge-ai-app:v1.2

Model
    ↓
Person Detection:v2.1

Device
    ↓
ECU-2200 #001

最後部署到設備。

這樣換 Model 就簡單很多

假設我們後來做了一個：

Person Detection:v2.2

Application 本身沒有修改。

那就可以：

Model Registry
      ↓
Person Detection v2.2
      ↓
Validation
      ↓
QCS6490 PASS
      ↓
EdgeHub Deployment
      ↓
ECU-2200

不用為了換 Model，把整個 Application 重新 Build 一次。

這也是我當初開始想 Model Registry 的原因。

但這裡又有一個細節

Model Registry 不一定要自己存 Model Binary。

這點我覺得產品設計時要先想清楚。

例如 Model 可能來自：

公司自己訓練
        │
Qualcomm AI Hub
        │
第三方 Model
        │
客戶自己的 Model

所以 Model Registry 可以主要管理：

Model Metadata
Version
Format
Target
Compatibility
Validation Result
Source
Deployment History

真正的 Model File 可以放在：

Model Storage
Object Storage
或其他 Repository

Registry 只需要知道：

這個 Model 在哪裡，以及它到底是什麼。

所以我現在會把三個東西分得很清楚

Harbor

管理：

Container Image

edge-ai-app:v1.2

Model Registry

管理：

AI Model

Person Detection:v2.2

以及它的：

Version
Specification
Compatibility
Validation
Deployment

Cloud

管理：

Application + Model + Device

最後決定：

哪一個 Application，用哪一個 Model，部署到哪一台 Device。

我覺得這樣才比較像產品

一開始我只是想：

「Model 要放哪裡？」

後來才發現，其實真正的問題不是「放哪裡」。

而是：

Model 怎麼被管理、驗證，最後安全地送到正確的 Edge Device 上。

所以 Model Registry 不是為了再做一個「存檔案的地方」。

它是把 Model 從：

一個 .onnx 檔案

變成：

一個可以被管理、驗證、部署的 AI Asset。

而做到這裡，我下一個問題就來了：