Model 不只是個檔案，當 AI 開始進入產品，真正麻煩的是：這個 Model 到底能不能用？

前一天把 Application Container 化之後，我原本以為事情變得簡單了。

Frontend 有自己的 Container，Backend 有自己的 Container，AI Runtime 也有自己的 Container。

但是很快，我又遇到另一個問題：

Model 呢？

一開始，其實根本不需要 Model Registry

如果今天只有一台 ECU-2200：

ECU-2200
│
├── Application
│
└── /models
      └── person_detection.onnx

很簡單。

Model 放進去，Application 讀出來，AI 跑起來。

這時候做 Model Registry，反而有點大材小用。

所以我後來開始想：

Model Registry 到底是為了解決什麼問題？

問題一：Model 開始有版本了

假設我們開始調整 Person Detection。

很快就會變成：

Person Detection
├── v1.0
├── v1.1
├── v2.0
└── v2.1

這時候第一個問題就出現：

現在到底是哪一版？

更麻煩的是，如果有 100 台 Edge Device：

ECU-001 → Model v1.1
ECU-002 → Model v2.0
ECU-003 → Model v2.0
ECU-004 → Model v1.1
...

我們不只要知道：

「Model 放在哪裡？」

而是要知道：

「哪一台 Device 正在使用哪一個 Model？」

這已經不是 File Storage 可以很好解決的問題。

問題二：有 Model，不代表能跑

這個問題對 Edge AI 更重要。

假設今天從 Qualcomm AI Hub 找到一個 Model。

下載下來：

YOLO xxx

是不是直接放進 QCS6490 就可以？

答案通常不是這麼簡單。

因為還要看：

Model Format
Input / Output
Operator
Datatype
Quantization
Runtime
Hardware
Pre-processing
Post-processing

例如：

Camera
1920 × 1080
NV12
   ↓
Pre-processing
   ↓
640 × 640
RGB
   ↓
Model

Model 本身可能是：

ONNX
FP32

但我們最後希望它：

QNN
INT8
HTP
QCS6490

所以真正的問題變成：

這個 Model 到底適不適合我的 Edge Device？

問題三：Model 不只是 Model File

以前我可能會認為：

person_detection.onnx

就是 Model。

但真的做到 Edge AI，我會開始需要知道：

Person Detection v2.1

Format:
ONNX

Input:
640 × 640
RGB

Output:
Bounding Box
Confidence
Class

Runtime:
QNN

Precision:
INT8

Target:
QCS6490

Accelerator:
HTP

甚至還要知道：

Pre-processing
Post-processing
Quantization
Runtime Version
Validation Result
FPS
Latency

所以 Model 開始變成一個「有很多資訊的產品資產」。

問題四：Model 換了，Application 還能不能跑？

這是我覺得最實際的一個問題。

假設現在：

Unmanned Area AI 1.5

Frontend      1.2
Backend       1.5
AI Runtime    1.0
Person Model  2.1

今天 Model Engineer 給我：

Person Model 2.2

我可以直接換嗎？

不一定。

因為 Model 可能改了：

• Input Shape
• Output Format
• Operator
• Quantization
• Pre-processing
• Post-processing

甚至 Model 雖然可以跑，但：

v2.1 → 31 FPS
v2.2 → 18 FPS

或者 Accuracy 變差。

這時候我才真正發現：

Model 的 Lifecycle，跟 Application 的 Lifecycle，其實不一樣。

Application Version ≠ Model Version

所以我們開始把它拆開。

例如：

Application 1.5
│
├── Frontend 1.2
├── Backend 1.5
├── AI Runtime 1.0
└── Model 2.1

下一次可能變成：

Application 1.6
│
├── Frontend 1.2
├── Backend 1.6
├── AI Runtime 1.0
└── Model 2.1

或者：

Application 1.5
│
├── Frontend 1.2
├── Backend 1.5
├── AI Runtime 1.0
└── Model 2.2

這兩種更新其實是不一樣的。

Application 可以更新。

Model 也可以獨立更新。

所以我開始覺得：

Model 需要自己的 Lifecycle。

那 Model Registry 到底存在的意義是什麼？

不是「幫我放 Model」。

真正的意義是：

讓 Model 從一個檔案，變成一個可以被辨識、驗證、部署與追蹤的產品資產。

我會把它整理成：

Model
   ↓
Version
   ↓
Compatibility
   ↓
Validation
   ↓
Deployment
   ↓
Device

例如：

Person Detection v2.1
        │
        ├── QCS6490 ✓
        ├── QNN ✓
        ├── HTP ✓
        ├── INT8 ✓
        │
        ↓
Validation PASS
        │
        ↓
Unmanned Area AI 1.5
        │
        ↓
ECU-001 / 002 / 003

這時候 Cloud 才真的知道：

「這個 Model 是什麼、能不能用、驗證過沒有、現在被哪些 Device 使用。」

但 Validation 誰做？

這裡我也遇到另一個問題。

如果 Model Registry 在 Cloud：

Cloud
Model Registry

它怎麼知道：

「這個 Model 在 QCS6490 HTP 上可以跑 31 FPS？」

Cloud 本身當然不知道。

因為真正的 Runtime 在 Edge。

所以我們後來會變成：

     Cloud 
       │
       │ Validation Job
       ↓
Validation Device
       │
       ↓
QCS6490
       │
       ↓
QNN / HTP
       │
       ↓
Validation Result
       │
       ↓
     Cloud

也就是：

Cloud 管理 Validation，Edge 執行 Validation。

這個架構其實跟我們做 Edge AI 很合理。

這時候 Model Registry 就不只是「Model Repository」

它開始變成：

                    Model Registry
                          │
        ┌─────────────────┼─────────────────┐
        ↓                 ↓                 ↓
    Model Version    Compatibility      Validation
        │                 │                 │
        ↓                 ↓                 ↓
    v2.1             QCS6490 ✓          31 FPS
                     QNN ✓               4.48 ms
                     HTP ✓               PASS

而 Cloud EdgeHub 再負責：

Model
   ↓
Application
   ↓
Device
   ↓
Deployment

那 Harbor 呢？

這時候也很容易搞混。

我會把它分成：

Harbor
→ 管 Docker Image

Model Registry
→ 管 AI Model

Cloud EdgeHub
→ 管 Device / Application / Deployment

例如：

Harbor
├── frontend:1.2
├── backend:1.5
└── ai-runtime:1.0

Model Registry：

Person Detection
├── v1.0
├── v2.0
└── v2.1

Application：

Unmanned Area AI 1.5
├── frontend:1.2
├── backend:1.5
├── ai-runtime:1.0
└── Person Model:2.1

最後由 Cloud EdgeHub 把這個 Application 部署到 Edge Device。

所以 Day 17 我真正學到的是

一開始：

Model 就是一個檔案。

後來：

Model 有版本。

再後來：

不同 Model 對 Hardware、Runtime、Input/Output 都有不同要求。

最後我才發現：

Model 其實也需要自己的 Lifecycle。

所以 Model Registry 存在的原因，不是因為我們缺一個地方放 Model。

而是因為：

當 AI 從 PoC 走向產品，Model 開始需要被管理。

Day 17 結尾

但是問題又來了。

我們說要管理 Model。

那到底要管理什麼？

例如：

• Model Format 要不要記？
• Input / Output 要不要記？
• QCS6490 Compatibility 怎麼判斷？
• QNN / HTP 要不要記？
• Validation 怎麼做？
• FPS、Latency、Accuracy 要不要存？
• 原始 Model 跟轉換後的 Model 要不要分開？

這時候我才發現：

「做一個 Model Registry」很容易，真正困難的是定義：一個 Model 到底需要哪些資訊，才能讓 Edge AI 真正用得起來。