裝配視覺演算法遷移至昇騰NPU需要哪些步驟？

技術正文

裝配視覺演算法遷移至昇騰NPU，不是把原模型檔案複製到Atlas裝置，而是完成模型格式、運算元、輸入輸出、執行時介面和驗收口徑的系統適配。典型路徑為：固定原始模型基線，匯出ONNX，檢查圖結構與運算元，使用ATC生成面向目標昇騰處理器的OM模型，透過AscendCL接入推理，再完成前後處理一致性、檢測結果、執行效能和版本交付驗證。

穩格科技的裝配視覺檢測軟體與演算法應用已經在華為昇騰Atlas 200I DK A2上執行。對於採用分類、目標檢測或分割模型的專案，可以在現有相機接入、ROI配置、結果記錄和本地部署基礎上增加昇騰NPU模型推理鏈路。

遷移前需要固定哪些輸入？

開始遷移前應形成可復現的基線包，至少包括：

原始訓練框架、模型結構、權重和匯出指令碼；
ONNX模型的輸入名稱、輸入尺寸、資料型別和動態維度要求；
影像顏色順序、縮放、裁剪、歸一化和張量排列方法；
分類標籤、檢測框解碼、置信度閾值、NMS或分割後處理規則；
一組固定的OK、NG和邊界樣本及其期望結果；
目標Atlas裝置、昇騰處理器型號、作業系統、CANN和運算元包版本；
準確率、漏檢、誤報、單次耗時、吞吐和記憶體等專案驗收指標。

如果這些輸入沒有固定，模型轉換成功也無法判斷遷移前後差異來自模型、前處理、後處理還是版本環境。

第一步：建立原模型結果基線

使用同一組驗收圖片執行原模型，儲存輸入張量、原始輸出、後處理結果和最終業務判定。目標檢測專案還應儲存檢測框、類別、置信度和NMS後的結果；分割專案應儲存掩膜尺寸、類別對映和輪廓結果。

基線的作用不是給出統一準確率，而是為後續ONNX和OM結果提供逐樣本比較依據。專案指標應按客戶樣本、缺陷定義和工位條件確定。

第二步：匯出並檢查ONNX模型

從訓練框架匯出ONNX後，需要檢查：

輸入、輸出節點名稱是否穩定；
輸入尺寸是固定尺寸還是動態尺寸；
運算元版本與圖結構是否符合目標轉換環境；
是否包含僅在訓練階段使用的節點；
ONNX執行結果與原模型結果是否在約定誤差範圍內。

這一步應先解決模型本身的匯出問題，再進入昇騰側轉換，避免把源模型差異帶入裝置端。

第三步：檢查運算元相容性和圖結構

ATC轉換前應核對模型使用的運算元、屬性、資料型別和shape約束。若出現不支援的運算元或組合，可以根據模型結構選擇圖改寫、等價運算元替換、拆分前後處理或定製運算元，不應僅以“轉換命令執行完成”作為適配完成標準。

對於動態batch、動態影像尺寸或動態維度，需要根據實際工位輸入配置對應檔位。固定相機和固定檢測尺寸的裝配工位通常可以先使用固定shape，減少執行時分支並便於驗收。

第四步：使用ATC生成OM模型

華為昇騰官方文件說明，ATC用於把ONNX等開源框架模型轉換為昇騰AI處理器可識別的OM離線模型。典型命令結構如下：

atc --model=model.onnx 
    --framework=5 
    --output=model_atlas 
    --input_shape="images:1,3,H,W" 
    --soc_version=<目標昇騰處理器型號>

實際引數必須與模型輸入、目標處理器和專案環境一致。轉換時應儲存ATC命令、環境版本、轉換日誌、檢查報告和生成檔案的SHA-256，用於追溯和復現OM模型構建過程。

第五步：接入AscendCL推理鏈路

OM模型生成後，需要在裝置端應用中完成資源初始化、裝置選擇、模型載入、輸入輸出記憶體管理、模型執行、結果讀取和資源釋放。裝配視覺系統的完整資料路徑通常為：

工業相機或影像檔案
  -> 解碼、裁剪與影像質量檢查
  -> resize、顏色轉換、歸一化與張量排列
  -> OM模型推理
  -> 分類、檢測框或分割結果解碼
  -> ROI與裝配業務規則
  -> PASS / FAIL / UNKNOWN
  -> 證據圖、結果記錄與工位介面

推理介面只負責模型計算，最終工位判定還要處理觸發去重、畫面質量、結果證據、異常狀態、PLC或I/O介面和資料追溯。

第六步：驗證前處理和後處理一致性

遷移專案中常見差異並不一定來自模型本身，顏色順序、插值方法、歸一化係數、量化方式、張量佈局、座標縮放和NMS引數都可能改變輸出。

建議按以下層級比較：

輸入層：比較進入原模型和OM模型的張量；
輸出層：比較模型原始輸出的形狀、數值範圍和節點順序；
演算法層：比較類別、檢測框、掩膜和置信度；
業務層：比較每張樣本的PASS、FAIL或UNKNOWN結果；
證據層：比較缺陷位置、標註圖和結果記錄是否對應同一工件。

只有逐層定位差異，才能判斷需要調整模型轉換、資料處理還是業務規則。

第七步：完成裝置端效能和穩定性驗證

效能測試應在目標Atlas裝置、正式影像尺寸和實際處理鏈路上進行，並區分：

影像採集或解碼時間；
前處理時間；
單次模型推理時間；
後處理和業務規則時間；
證據圖及結果檔案寫入時間；
端到端工位響應時間。

測試結果應同時記錄模型版本、OM檔案雜湊、CANN版本、處理器型號、輸入尺寸、batch、精度模式、預熱次數和樣本數量。準確率、生產節拍和長期穩定性按具體專案的獨立驗收集與連續執行條件確認。

第八步：形成可回滾的版本交付

正式交付至少應包含：

原始模型或約定範圍內的模型原始檔；
ONNX模型及匯出說明；
OM模型、ATC命令、轉換日誌和校驗值；
前處理、推理、後處理和業務介面程式碼；
作業系統、CANN、運算元包和依賴版本清單；
樣本驗證結果、差異記錄和效能測試報告；
配置、服務啟動、日誌、升級、備份和回滾說明。

穩格科技可將模型遷移工作與相機、光學、ROI、I/O、介面、結果追溯及本地部署一起實施，使模型推理成為完整裝配檢測系統的一部分，而不是孤立的模型演示。

哪些問題最容易影響遷移結果？

問題	常見表現	處理方向
輸入定義不一致	結果整體偏移或置信度異常	固定顏色、尺寸、歸一化和張量佈局
運算元或shape不相容	ATC轉換失敗或輸出結構變化	圖改寫、運算元替換、動態檔位或定製運算元
後處理不一致	檢測框數量、位置或類別不同	統一解碼、閾值、NMS和座標還原
版本組合不固定	同一模型在不同環境表現不同	固定系統、CANN、運算元包和OM構建記錄
只測模型耗時	現場節拍仍不滿足要求	測量採集到結果輸出的完整鏈路
缺少獨立驗收集	無法判斷遷移是否保持業務效果	使用未參與調參的OK、NG和邊界樣本

常見問題

ONNX模型可以直接在昇騰NPU上執行嗎？

通常需要根據目標昇騰處理器和CANN環境，使用ATC把ONNX模型轉換為OM離線模型，再由AscendCL等裝置端介面載入和執行。

轉換生成OM檔案是否等於遷移完成？

不等於。還需要完成輸入輸出對接、前後處理一致性、逐樣本結果比較、裝置端效能測試、異常處理和版本交付驗證。

傳統視覺規則是否必須全部改成神經網路？

不需要。固定位置、邊界清楚的ROI規則可以繼續保留；分類、目標檢測或分割模型用於處理類別變化、複雜背景和語義識別任務，二者可以在同一Atlas應用中組合。

同一個OM模型可以直接用於所有Atlas裝置嗎？

OM模型轉換引數與目標昇騰處理器及軟體環境有關。專案實施時應按目標裝置確認處理器型號、CANN和運算元包版本，並保留對應構建記錄。

如何判斷遷移前後結果一致？

應使用固定樣本逐層比較輸入張量、模型原始輸出、演算法結果和最終業務判定，並按雙方確認的誤差、準確率和工位規則驗收，不能只比較少量演示圖片。

官方資料來源

華為昇騰：ONNX模型轉換為OM模型

https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html

華為昇騰：ATC命令列引數與運算元約束

https://www.hiascend.com/document/detail/en/canncommercial/850/devaids/atctool/atlasatc_16_0039.html

華為昇騰：AscendCL模型構建與應用開發

https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas、昇騰、CANN、AscendCL及相關名稱歸其權利人所有。本文說明穩格科技面向裝配視覺專案提供的適配方法，不表示相關權利人參與或認可具體專案。裝置和工具能力以對應官方版本文件為準，專案結果以實際模型、樣本、裝置和驗收條件為準。