1. 從 QCS6490 開始，我才發現 Model 不是通用的執行檔

假設客戶有一個 Person Detection Model。

Person Detection Model
          │
          ├── Qualcomm QCS6490
          │      └── QAIRT / QNN / HTP
          │
          ├── NVIDIA Jetson
          │      └── TensorRT / CUDA
          │
          └── x86 CPU
                 └── ONNX Runtime / CPU

這裡要特別說明：這是常見的部署路徑示意，不代表每一個 Model 都必須使用這些 Runtime。

同一個模型的來源可以相同，但針對不同平台，可能需要不同的轉換、最佳化、執行環境與部署 Artifact。

2. 為什麼不能把 QCS6490 的 Artifact 直接放到 NVIDIA？

因為兩邊的硬體架構、Runtime 與加速機制不同。

所以，不能只因為副檔名相同，或模型架構相同，就認定 Artifact 可以互換。

3. 那是不是每個平台都要重新訓練 Model？

不一定。這是這一天很值得解釋的觀念。

如果原始 Model 的架構與運算可以被目標平台支援，有機會沿用相同的模型權重，再針對不同平台進行轉換或最佳化。

但如果碰到不支援的 Operator、量化差異、精度問題，或者模型本身不符合目標 Runtime 的要求，就可能需要調整。

因此要分清楚三件事：

• Model：模型架構與權重。
• Artifact：針對目標平台產生的可部署模型產物。
• Runtime：負責載入模型並執行推論的軟體環境。

這三個概念分開，才有辦法設計跨硬體的 Model Registry。

4. 這就是 Model Registry 要處理的問題

如果只有 QCS6490，一開始可能只需要管理一種主要的部署路徑。

但未來客戶可能有不同設備，Model Registry 就不能只存：

Model Name
Model Version
Model File

而應該能管理：

Model
 ├── Model Version
 ├── Model Contract
 │
 └── Model Artifacts
      ├── QCS6490 Artifact
      │    ├── Runtime: QAIRT / QNN
      │    └── Backend: HTP
      │
      ├── NVIDIA Artifact
      │    └── Runtime: TensorRT
      │
      └── CPU Artifact
           └── Runtime: ONNX Runtime

注意，以上是目標架構的示意；實際支援哪些格式、Runtime 與硬體組合，仍要依平台驗證結果決定。

5. Cloud 要怎麼知道該部署哪個 Artifact？

這就是產品設計真正開始發揮作用的地方。

假設客戶有三台設備：

• Device A：Qualcomm QCS6490
• Device B：NVIDIA Jetson
• Device C：x86 CPU

Cloud 不應該只把同一個模型檔案推送到所有設備，而是要先確認每台設備的能力，再選擇符合條件的 Artifact。

              Model Registry
                    │
              Model + Version
                    │
                    ▼
              Device Profile
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
   QCS6490        NVIDIA        x86 CPU
       │            │            │
    QNN/HTP      TensorRT     ONNX Runtime
       │            │            │
       ▼            ▼            ▼
   Validation   Validation   Validation
       │            │            │
       ▼            ▼            ▼
    Deploy       Deploy       Deploy

Device Profile 可以包含硬體型號、架構、可用加速器、Runtime 版本與系統環境等資訊。部署之前，再確認 Artifact 是否與目標環境相容。

做到這裡，我才發現，Model Registry 真正困難的地方，不是把 Model 存進資料庫，也不是多加幾個版本欄位。

當我們只有 QCS6490 時，可以先把一條部署路徑做好；但當產品開始支援不同硬體，就必須開始管理 Model、Artifact、Runtime 與 Device 之間的關係。

我不希望客戶每換一台設備，就得重新研究一次模型要怎麼部署。

我希望客戶選擇的是「我要解決什麼問題」，而平台負責判斷「這台設備應該使用哪個經過驗證的 Model Artifact」。

這也是我開始思考 Cloud Model Registry，如何從 Model 管理功能，進一步走向跨硬體部署平台的原因。