前面幾天一直在講 Model Registry。

講到最後，我突然想到一個很現實的問題。

如果這個平台最後是給客戶用，那 Model 不可能永遠都是我們準備的。

客戶可能已經有自己的 Model。

可能是自己訓練的，也可能是第三方 Model，甚至可能是從其他平台轉過來的。

那我們是不是做一個：

Upload Model

讓客戶自己上傳就好了？

一開始看起來好像很簡單。

Customer
   ↓
Upload Model
   ↓
Model Registry
   ↓
Deploy
   ↓
QCS6490

但我後來發現，這個流程其實不能這麼直接。

第一個問題：客戶的 Model 真的能跑嗎？

例如客戶丟進來：

person.onnx

檔案成功上傳，不代表它可以跑。

可能遇到：

ONNX Format OK
        ↓
Operator 不支援
        ↓
QNN Compile Failed

或者：

Model Load OK
        ↓
Inference OK
        ↓
FPS 太低
        ↓
不符合產品需求

所以我會把「Upload」跟「可以使用」拆開。

Uploaded
   ↓
Format Check
   ↓
Metadata Check
   ↓
Compatibility Check
   ↓
QCS6490 Validation
   ↓
Validated
   ↓
Available for Deployment

上傳成功 ≠ 可以部署。

這個我覺得是 Model Registry 很重要的一個觀念。

第二個問題：客戶根本不一定知道自己的 Model 是什麼

我們做工程的人看到：

ONNX
INT8
640 × 640
QNN
HTP

可能覺得很正常。

但客戶不一定知道。

他可能只跟我們說：

「這是我們公司的 Person Detection Model，你幫我跑看看。」

所以如果 UI 要求客戶填一堆：

Input Tensor
Output Tensor
Quantization
Runtime
Pre-processing
Post-processing

客戶可能第一步就卡住了。

所以我會比較傾向：

Basic Upload

客戶先提供：

Model File
Model Name
Version
Task

剩下的資訊，Platform 能自動解析就自動解析。

解析不了，再請客戶補。

這樣比較像產品，而不是把工程師的工作全部丟給客戶。

第三個問題：客戶上傳的 Model，有沒有安全風險？

這個其實是我覺得更值得寫進來的地方。

因為 Model 不是單純一張圖片。

它可能包含：

• 不明來源的 Model
• 第三方 Model
• 不可信的檔案
• 惡意或異常的 Model
• 不符合公司規範的內容

而且我們最後還可能把它送到 Edge Device 執行。

所以不能變成：

客戶上傳
   ↓
直接放進 ECU
   ↓
直接執行

這個流程風險太高。

所以我會多加一層 Model Validation

變成：

                 Customer
                    │
                    ↓
               Upload Model
                    │
                    ↓
              Model Registry
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
     File Check          Metadata Check
          │                   │
          └─────────┬─────────┘
                    ↓
              Compatibility
                    ↓
             QCS6490 Test
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
       PASS                  FAIL
          │                   │
          ↓                   ↓
    Available             Rejected
    for Deploy

這樣至少不會因為：

「客戶說這個 Model 可以跑」

我們就直接相信。

第四個問題：Validation 也不能只測「能不能跑」

這也是我覺得 PM 很容易漏掉的地方。

假設 Model：

Inference PASS

不代表它就適合產品。

例如：

FPS：8
CPU：90%
Memory：接近上限

它 technically 可以跑。

但是放進我們的 Edge AI Application，可能根本不能接受。

所以 Validation 最好至少分成幾個結果：

Model Load
✓

Inference
✓

Performance
✕

Resource Usage
⚠

最後可能得到：

Compatible

或：

Compatible with Warning

或：

Not Compatible

這就比單純 PASS / FAIL 有用很多。

第五個問題：客戶的 Model 可能不是我們支援的格式

例如現在我們主要驗證：

ONNX

但客戶拿：

TensorFlow SavedModel
PyTorch
TFLite

過來。

那我們到底要不要全部支援？

我覺得這個不能一開始就全部答應。

因為：

支援格式越多，後面的轉換、Validation、Runtime 維護成本就越高。

所以產品初期可以很明確：

Supported
✓ ONNX

Coming Later
○ TFLite
○ TensorFlow
○ PyTorch

甚至可以要求：

客戶先把 Model 轉成我們支援的格式，再上傳。

這其實也是產品 Scope 的一部分。

還有一個很現實的問題：Model 是誰的？

假設客戶上傳自己的 Model。

那這個 Model 的：

所有權、使用權、版本、來源

要不要記？

我覺得至少要留下：

Owner
Source
Version
Upload Time
Uploaded By

因為未來很可能會出現：

「這個 Model 是誰上傳的？」

「為什麼 ECU-2200 上面跑的是這一版？」

「誰把 Model 從 v1.1 換成 v1.2？」

這其實已經開始跟 Audit / Governance 有關。

所以最後我會把客戶 Model 的流程設計成

Customer Model
      ↓
    Upload
      ↓
Model Registry
      ↓
 ┌───────────────┐
 │ Format Check  │
 │ Metadata      │
 │ Compatibility │
 │ Security      │
 └───────┬───────┘
         ↓
   QCS6490 Validation
         ↓
 ┌───────┴────────┐
 ↓                ↓
PASS             FAIL
 ↓                ↓
Validated       Rejected
 ↓
Deployment
 ↓
ECU-2200

這時候我才發現：

讓客戶上傳 Model，看起來是一個 Upload 功能，其實背後牽涉到 Compatibility、Performance、Security、Ownership、Version Control。

所以 Model Registry 的價值也不只是：

「讓客戶把 Model 放進來。」

而是：

讓客戶的 Model 有一個安全、可驗證、可追蹤的方式進入 Edge AI Platform。

Day 21 最後可以留一個伏筆

做到這裡，我又遇到一個問題：

如果客戶的 Model 通過 Validation 了，但半年後換了一台設備，還需要重新驗證嗎？

因為：

Model
+
Runtime
+
Hardware

三個東西其實是有關係的。