做到 Day 21，我又想到一個更實際的問題。

前面我們都是拿 QCS6490 當例子。

但真正做 Edge AI Platform，不可能所有客戶都用同一台設備。

今天可能是：

ECU-2200
QCS6490
NPU / HTP

另一個客戶可能是：

NVIDIA Jetson
GPU

甚至還有一些比較舊的設備：

x86
CPU

那問題就來了：

同一個 Model，可以直接丟到不同 Edge Device 嗎？

答案當然是：

不一定。

Model 不能只記「我是一個 ONNX」

假設客戶上傳：

person.onnx

以前我的 Model Registry 可能只記：

Model Name：Person Detection
Version：2.0
Format：ONNX

但現在看起來這些資訊根本不夠。

因為同一個 ONNX Model：

Person Detection v2.0

可能在：

QCS6490 → QNN / HTP
NVIDIA → TensorRT / CUDA
x86 → ONNX Runtime / CPU

走完全不同的 inference path。

所以我開始覺得：

Model Registry 不能只管理 Model，還要管理 Model 可以怎麼跑。

那我會怎麼設計？

我會把它拆成兩層：

Model

代表「這個 AI Model 本身」。

例如：

Person Detection
Version 2.0

Model Artifact

代表「這個 Model 給特定 Runtime / Hardware 使用的版本」。

例如：

Person Detection v2.0
│
├── ONNX
│
├── QCS6490 / QNN / HTP
│
├── NVIDIA / TensorRT
│
└── CPU / ONNX Runtime

這兩個概念分開之後，整個架構就清楚很多。

我會把 Model Registry 設計成這樣

Model Registry
│
├── Model
│   └── Person Detection v2.0
│
├── Model Artifacts
│   ├── ONNX
│   ├── QCS6490 / QNN / HTP
│   ├── NVIDIA / TensorRT
│   └── CPU / ONNX Runtime
│
└── Validation Results
    ├── QCS6490
    ├── NVIDIA
    └── CPU

這時候就不會把：

Model

跟

可以在某台設備上執行的 Artifact

混在一起。

例如同一個 Model

假設客戶上傳：

Person Detection v2.0

Model Registry 裡面可以有：

Artifact A
Format：ONNX
Runtime：ONNX Runtime
Target：CPU
Status：Validated

Artifact B
Format：TensorRT Engine
Runtime：TensorRT
Target：NVIDIA
Status：Validated

Artifact C
Format：QNN Model
Runtime：QNN
Backend：HTP
Target：QCS6490
Status：Validated

這樣 Cloud 在 Deployment 的時候，就不用問：

「這個 Model 能不能跑？」

而是可以進一步問：

「這台 Edge Device 應該拿哪一個 Artifact？」

Cloud Deployment 就會變得比較聰明

例如今天我要部署到：

ECU-2200
QCS6490

Cloud 查：

Device
   ↓
QCS6490
   ↓
Available Artifact
   ↓
QNN / HTP

最後選：

Person Detection v2.0
QCS6490 / QNN / HTP

如果今天換成 NVIDIA：

NVIDIA Jetson
   ↓
CUDA / TensorRT
   ↓
Person Detection v2.0
TensorRT Artifact

如果是一台 CPU Device：

x86 CPU
   ↓
ONNX Runtime
   ↓
Person Detection v2.0
ONNX Artifact

Model 沒有換。

換的是：

針對不同硬體準備的 Model Artifact / Runtime。

這裡又有一個問題：Artifact 是誰產生的？

這其實又可以拆成兩種。

第一種：平台已經準備好

例如 Qualcomm AI Hub 已經有：

QCS6490
QNN
HTP

我們直接把對應的 Artifact 放進 Registry。

第二種：客戶只有一個原始 Model

例如客戶只上傳：

person.onnx

這時候 Cloud 發現：

Customer Model
       ↓
ONNX
       ↓
Target = QCS6490

但是目前沒有 QNN Artifact。

那就不能直接 Deploy。

可能要進入：

Model Conversion / Compilation
        ↓
QNN Artifact
        ↓
Validation
        ↓
Available

所以 Model Registry 還可以記錄：

Source Model
      ↓
Converted / Compiled Artifact
      ↓
Target Device

這樣 Model 的來源就不會斷掉。

那 CPU、NPU、GPU 要不要分開做 Model？

我覺得這裡要小心。

不是看到 NPU / GPU / CPU 就一定要做三份 Model。

有時候同一個：

ONNX

就可以在 CPU 上跑。

但 NPU 或 GPU 可能需要另外的：

Compiled Artifact

所以 Registry 不應該設計成：

CPU Model
GPU Model
NPU Model

這樣太死。

比較好的概念是：

Model
 ↓
Artifact
 ↓
Target + Runtime + Backend

我會把 Device Profile 也拉出來

這時候 Cloud 本身其實已經知道 Device 的資訊。

例如：

Device Profile
│
├── Hardware
│   └── QCS6490
│
├── Accelerator
│   └── NPU / HTP
│
├── Runtime
│   └── QNN
│
├── OS / BSP
│
└── Available Memory

NVIDIA：

Device Profile
│
├── GPU
│   └── NVIDIA
│
├── CUDA
├── TensorRT
└── Memory

CPU：

Device Profile
│
├── CPU
├── x86
└── ONNX Runtime

然後 Deployment 的時候做 Matching。

所以最後會變成這個架構

                    Cloud
                       │
              ┌────────┴────────┐
              │                 │
        Model Registry      Device Manager
              │                 │
              │            Device Profile
              │                 │
              ↓                 ↓
        Model v2.0          QCS6490
              │              NVIDIA
              │               CPU
              ↓                 │
       Model Artifacts          │
       │     │     │            │
       ↓     ↓     ↓            │
     QNN   TRT   ONNX           │
      │     │     │             │
      └─────┴─────┴─────────────┘
                    ↓
                Deployment

這樣 Cloud 就可以做：

Device → 找相容 Artifact → Validation → Deploy

Validation 也要跟著改

以前我們可能只記：

Person Detection v2.0
QCS6490
PASS

現在就不夠了。

應該是：

這樣客戶選設備的時候，才真的有東西可以參考。

甚至可以讓客戶選「我要什麼」

例如客戶不是直接選 Model，而是：

Model：
Person Detection v2.0

Target Device：
ECU-2200

Performance Requirement：
≥ 20 FPS

Cloud 自己去找：

QCS6490
↓
QNN / HTP
↓
Person Detection v2.0
↓
28 FPS
↓
✓ Meets Requirement

如果 CPU 只有：

8 FPS

就可以直接提示：

此 Model 可在 CPU 執行，但目前效能低於設定的 20 FPS。

這時候 Model Registry 就不只是「存 Model」。

它開始真的幫 Deployment 做決策。

但我不會在第一版把它做得太複雜

如果現在還是我們的第一版 Edge AI Product，我不會一開始就支援：

QCS
NVIDIA
Intel
AMD
CPU
NPU
GPU
TPU
...

這會直接把產品做爆。

我會先定一個比較清楚的模型：

Model
   ↓
Artifact
   ↓
Target Hardware
   ↓
Runtime
   ↓
Validation

第一階段先把：

QCS6490 + QNN/HTP

做好。

之後再加入：

NVIDIA + TensorRT

最後才考慮：

CPU + ONNX Runtime

這樣架構先留好，但產品 Scope 不要一次開太大。

我最後得到一個新的理解

前面幾天我一直在想：

「Model Registry 是不是就是放 Model 的地方？」

到 Day 22，我開始覺得其實不是。

它真正要處理的是：

同一個 Model，怎麼找到適合不同 Edge Device 的執行方式。

所以我現在會把它想成：

                 One Model
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
       QCS6490    NVIDIA     CPU
          ↓         ↓         ↓
        QNN       TensorRT   ONNX RT
          ↓         ↓         ↓
         NPU       GPU       CPU
          │         │         │
          └─────────┼─────────┘
                    ↓
                Deployment

Model 是同一個，但 Artifact、Runtime、Backend 可以不同。

這樣才比較有機會讓 Cloud 從「管理一台 QCS6490」慢慢變成真正可以管理不同 Edge Device 的 Edge AI Platform。

而下一個問題也就很自然了：

如果同一個 Model 在 QCS6490 可以跑 28 FPS，在 NVIDIA 可以跑 45 FPS，在 CPU 只有 8 FPS，那 Cloud 要不要幫客戶自動選最適合的 Device？