做到 Day 24，我開始覺得 Model Registry 已經不是單純「把 Model 存起來」這麼簡單。

客戶的 Model 上傳之後，要先確認 Format、Runtime、Hardware、Operator，再經過 Validation，最後才能 Approved、Deploy。

但這時候我又遇到一個很現實的問題：

如果客戶把 Model 從 v1.2 換成 v1.3，原本的 Application 還能直接跑嗎？

一開始我覺得應該可以。

不就是換一個 Model？

Person Detection v1.2
        ↓
     換掉
        ↓
Person Detection v1.3

但真的把它想下去，就會發現事情沒有這麼簡單。

1. Model 可以換，不代表 Application 可以不動

我們的 Edge AI Application，大概是這樣：

Video
  ↓
Pre-processing
  ↓
AI Model
  ↓
Post-processing
  ↓
Detection
  ↓
Geofence
  ↓
Event
  ↓
Alert

假設 v1.2 的 Model Output 是：

Bounding Box
Class
Confidence

Application 很清楚怎麼處理。

但是客戶換成 v1.3 之後，可能發生很多事情。

例如：

v1.2
Output：
Box / Class / Confidence

v1.3
Output：
Box / Class / Confidence / Tracking ID

看起來只是多一個欄位。

但也可能更麻煩：

Input Size 改變
Output Tensor 改變
Class ID 改變
Pre-processing 改變
Post-processing 改變

甚至 Model Task 都變了。

所以問題就不再只是：

「v1.3 能不能跑在 QCS6490？」

而是：

「v1.3 能不能被現在這個 Application 正確使用？」

2. 這時候我才開始理解 Qualcomm 為什麼把 Model 和 Target Artifact 分開

如果客戶給我們：

customer_person_detection.onnx

這個其實只是 Source Model。

真正要跑在 QCS6490 上，還要經過 Qualcomm 的 Model Compilation / Optimization 流程，產生對應的 Target Artifact。

所以比較像：

Source Model
     ↓
Compile / Optimize
     ↓
QCS6490 Target Artifact
     ↓
QAIRT / QNN
     ↓
HTP

也就是：

Model 本身，不等於最後可以執行的東西。

這件事情對 Model Registry 的設計影響很大。

3. 所以 Model v1.2 → v1.3，不能只是「換檔案」

假設現在 Production 使用：

Model v1.2
    ↓
QCS6490 Artifact v1.2
    ↓
Approved
    ↓
Production

客戶更新 Model：

Model v1.3

我不會直接把 v1.2 的 Artifact 拿掉。

而是重新走一次流程：

Model v1.3
    ↓
Compile / Optimize
    ↓
QCS6490 Artifact v1.3
    ↓
Compatibility Check
    ↓
Performance Validation
    ↓
Application Compatibility
    ↓
Approval
    ↓
Deploy

這樣才知道新的 Model 到底能不能取代舊的 Model。

4. 但這裡又出現一個問題

如果每次 Model 更新，Application 都要跟著修改，那產品會非常難維護。

例如：

Application v0.5.0
        ↓
Model v1.2

Model 更新一次：

Application v0.5.1
        ↓
Model v1.3

再更新一次：

Application v0.5.2
        ↓
Model v1.4

這樣 Model 一直更新，Application 也一直跟著升版。

這不是我們想要的。

所以我開始思考：

Application 到底應該依賴 Model 的哪一部分？

5. 答案是：Model Contract

我不希望 Application 直接綁死：

customer_model_v1.2.onnx

而是定義一個 Model Contract。

例如我們的 Person Detection Application，可以定義：

Task:
Object Detection

Input:
640 × 640 × RGB

Output:
Bounding Box
Class
Confidence

Pre-processing:
Defined

Post-processing:
Defined

Application 只需要知道：

「我需要的是一個符合這個 Contract 的 Object Detection Model。」

至於底下到底是：

Model v1.2

還是：

Model v1.3

Application 不一定需要知道。

6. 這樣 Model 更新就會變得比較合理

例如：

             Model Contract
                   │
        ┌──────────┴──────────┐
        ↓                     ↓
   Model v1.2             Model v1.3
        │                     │
        ↓                     ↓
 QCS6490 Artifact       QCS6490 Artifact
        │                     │
        └──────────┬──────────┘
                   ↓
             Application

只要 v1.3 還符合原本的 Model Contract：

Compatibility = PASS

Application 就可以繼續使用。

反過來，如果 v1.3 改了：

Output Format
Input Size
Pre/Post Processing
Task

導致 Contract 不相容：

Compatibility = FAIL

那就不能直接換。

7. 所以我開始把 Version 拆成三層

這時候我發現，原來「Version」不能只看一個數字。

① Model Version

Person Detection v1.3

代表 AI Model 本身的版本。

② Model Artifact

QCS6490
QAIRT / QNN
HTP

代表針對特定硬體與 Runtime 產生的可部署 Artifact。

③ Application Version

Edge AI Application v0.5.0

代表整個 Edge AI Application 的版本。

所以真正的關係比較像：

Application v0.5.0
       │
       ↓
Model Contract
       │
       ↓
Model v1.3
       │
       ↓
QCS6490 Artifact
       │
       ↓
QAIRT / QNN / HTP

這比單純把：

Application v0.5.0
      =
Model v1.3

綁在一起彈性大很多。

8. 但 Qualcomm 的思路還提醒我一件事

Compile 成功，不代表 Application 就一定沒問題。

所以 Model v1.3 還是要重新驗證。

例如：

Model v1.3
      ↓
Compile
      ↓
QCS6490
      ↓
HTP
      ↓
Inference

我們還要看：

• Compatibility
• Accuracy
• Latency
• Memory
• HTP / Compute Unit 使用狀況
• Stability
• Application E2E Performance

尤其是我們之前已經踩過一次坑：

31 FPS 的 Model Benchmark，不代表整個 Application 有 31 FPS。

所以 Model 換版之後，不能只重新跑一次 inference benchmark。

還是要回到真正的 Application：

RTSP
 ↓
Decode
 ↓
Pre-processing
 ↓
NPU Inference
 ↓
Post-processing
 ↓
Geofence
 ↓
Event

確認整條 Pipeline 沒有被新的 Model 影響。

9. 那舊 Model 要不要留？

我覺得一定要。

假設：

v1.2 → Production
v1.3 → New

v1.3 上線後發現誤報突然變高。

這時候最怕的是：

「舊的 Model 已經被刪掉了。」

所以 Model Registry 應該保留：

Person Detection
│
├── v1.2
│   └── Production
│
└── v1.3
    └── Candidate / Approved

如果 v1.3 出問題：

v1.3
 ↓
Rollback
 ↓
v1.2

這時候 Version Management 才真正有意義。

10. 最後我把它整理成一個我比較喜歡的流程

Customer Model v1.3
        ↓
      Upload
        ↓
   Model Registry
        ↓
 Compatibility Check
        ↓
Compile / Optimize
        ↓
QCS6490 Artifact
        ↓
 Application Compatibility
        ↓
Performance / Stability
        ↓
     Approval
        ↓
      Deploy
        ↓
     Monitor
        ↓
   ┌────┴────┐
   ↓         ↓
  OK       Problem
   ↓         ↓
Production  Rollback
             ↓
            v1.2

這時候我才真正理解：

Model Registry 管理的不是「Model 檔案」，而是 Model 從版本、Artifact、Compatibility、Validation 到 Deployment 的完整生命週期。

而 Application 也不應該直接綁死某一個 Model File。

它真正需要的是：

一個符合 Application Contract 的 Model。

這一天最大的收穫

做到這裡，認知 Model Version ≠ Application Version。

Model 可以快速迭代，但 Application 不應該每換一次 Model 就跟著改。

所以中間需要一層：

Model Contract + Compatibility Validation

把這三件事情拆開：

Model
   ↓
Model Contract
   ↓
Application

這樣未來 Model 才有可能快速替換，而不會每次都把整個 Edge AI Application 一起打掉重做。

但做到這裡，又出現下一個問題。

現在我們討論的都是 QCS6490。

那如果同一個 Model，客戶今天要跑在：

QCS6490、NVIDIA GPU、甚至一般 CPU Edge Device 呢？

難道每一台設備都要重新管理一份 Model？