本文是有關 AMD Vitis? AI 6.2 的文章，目標是在不編寫代碼、不進行模型量化與編譯的前提下，使用發布包中提供的預編譯模型，在 VEK385 開發板上完成端到端推理（圖像分類與目標檢測），從而快速驗證第二代 AMD Versal? AI 引擎（以下簡稱 2VE）的 NPU 加速鏈路是否正常工作（本文聚焦"執行"環節，全程使用預編譯模型）。
與以往基于 DPU 的 Vitis AI 相比，面向 2VE 的 Vitis AI 6.2 在工具鏈層面變化較大：神經處理單元（NPU）取代了深度學習處理單元（DPU），模型入口統一為 ONNX，量化工作由 AMD Quark 完成，運行時同時支持 ONNX Runtime（搭配 Vitis AI Execution Provider）與 VART 兩條路徑。主要差異如下表所示。
一、環境準備
硬件
VEK385 開發板一塊
USB 線（同時提供 JTAG 與串口）、網線、電源
SD 卡一張
RevA 與 RevB 對應不同的板卡版本，請根據實際硬件選擇對應的預編譯鏡像包。本文以 RevB 為例。
主機軟件
本文僅運行預編譯模型，主機端只需安裝 AMD Vivado? Lab Edition 2025.2（輕量版，可滿足刷板需求），以及 expect 與 bmap-tools 兩個工具：
源碼與啟動鏡像
本文需要準備以下兩樣東西：
預編譯啟動鏡像：從 AMD 官方下載頁獲取對應板子版本的鏡像包，本文用 RevB，文件 vitis_ai_2ve_prebuilt_boot_images_v6.2_RevB.tar，下載地址：
https://account.amd.com/en/forms/downloads/amd-software-license-agreement-xef.html?filename=vitis_ai_2ve_prebuilt_boot_images_v6.2_RevB.tar
可解壓到 boot_images/ 目錄。
源碼（含刷板腳本與示例）：自 6.2 起改為從 AMD 官方 GitHub 倉庫 amd/Vitis-AI 克隆，命令為 git clone -b release/6.2 https://github.com/amd/Vitis-AI.git ，不再單獨提供源碼 tar 包。
克隆完成后，刷板腳本位于 versal_2ve/tools/ospi_sd_flash/，主要文件如下：
預編譯鏡像包解壓后的目錄結構如下：
二、板卡啟動（OSPI + SD）
AMD Vitis AI 6.2 將板卡 bring-up 的各項步驟封裝為腳本，整個過程分三步完成。
第 1 步：刷寫 OSPI（JTAG 模式）
將板卡斷電，把 SW1 撥碼開關設置為 JTAG 模式（0000，全部 ON），通過 USB 連接主機后上電。三種啟動模式對應的撥碼設置如下表。
建議先執行 dry-run 校驗環境與路徑，確認無誤后再正式刷寫：
刷寫耗時與鏡像大小有關，通常需要數分鐘；擦除與編程過程中每 5 秒輸出一個點（.）作為進度提示。
第 2 步：刷寫 SD 卡
將 SD 卡插入主機，執行以下命令。強烈建議先運行 dry-run，確認目標設備識別無誤，避免誤寫其他磁盤：
第 3 步：啟動板卡
插入 SD 卡
將 SW1 設置為 OSPI 模式（0001 = ON, ON, ON, OFF）
打開串口終端（波特率 115200）
上電后登錄板卡，使用用戶名 and-edf 登錄（密碼可由用戶自行選擇）。登錄后確認開機自動配置服務已成功運行：
當顯示 Active: active (exited)，且兩個 ExecStart 進程均報告 status=0/SUCCESS 時，說明 overlay 與運行時環境已自動配置完成。這是 Vitis AI 6.2 在易用性上的改進之一：overlay 加載與運行時配置由 systemd 服務在開機時自動完成，無需手動執行命令。
三、推理驗證與性能測試
通過串口控制臺或 SSH 連接到開發板（默認用戶名 amd-edf，密碼用戶自行選擇）。NPU 設備僅 root 用戶可訪問，因此后續所有推理操作均需切換至 root：
隨后可對環境做一次基本檢查：
使用 VART 驗證鏈路
運行預編譯的 ResNet50 INT8 模型，驗證推理流水線工作正常：
正常輸出如下，其中 Run completed successfully 表示推理已在 NPU 上正確執行：
進一步與參考輸出對比，驗證結果正確性：
若 diff 無任何輸出，說明推理結果與參考完全一致。
性能測試
運行 1000 次推理取平均，測量單幀推理延遲：
ResNet50 INT8 單幀推理延遲約為 2 ms 量級，可直觀體現 NPU 的加速效果。
四、Python 推理（ONNX Runtime + VitisAI EP）
除 C++ 的 ml_vart 外，Vitis AI 6.2 同樣支持通過 Python 使用 ONNX Runtime 進行推理。板卡上預裝了示例腳本 run_ResNet50_vitisai.py：
該腳本的工作流程為：使用 VitisAIExecutionProvider 創建 InferenceSession，讀取一個 float32 NCHW 的 .bin 文件作為輸入特征圖，調用 sess.run() 在 NPU 上執行推理，再將輸出張量寫回 .bin 文件。完整參數（含默認值）如下：
需要說明的是，Vitis AI EP 是 ONNX Runtime 的一個 Execution Provider。開發者按常規方式調用 ONNX Runtime 接口，將算子調度到 NPU 執行的工作由 EP 在底層完成。這一路徑對 Python 用戶及快速原型開發較為友好。
五、圖像分類
同一個預編譯模型可通過兩條運行時路徑部署，輸入一張 JPEG 圖像，輸出 Top-5 ImageNet 類別，兩條路徑結果一致。
方式 A：C++（x_plus_ml_vart）
x_plus_ml_vart 提供完整的端到端流水線（圖像解碼、預處理、NPU 推理、softmax 后處理），由 JSON 配置文件驅動：
輸出（節選）：
Top-1 預測為 brain coral，置信度 0.99，與輸入圖像內容相符。
方式 B：Python（VitisAI EP）
復用前述 Python 腳本，開啟后處理以打印 Top-5 類別：
輸出（節選）：
兩條路徑的 Top-1 結果均為 brain coral，表明同一編譯產物既可通過 C++ VART 運行時部署，也可通過 Python ONNX Runtime（VitisAI EP）部署。
六、目標檢測（YOLOX-M）
x_plus_ml_vart 同樣支持目標檢測，流程與分類一致，僅需更換 JSON 配置（檢測模型 + NMS 后處理）。本例使用預編譯的 YOLOX-M INT8 模型（640×640 輸入）：
輸出（節選）：
后處理還會生成一張繪制了邊界框的疊加圖像，保存在當前目錄的 output/ 下，圖中電視、椅子、餐桌、花瓶、時鐘等目標均被框出并標注了類別與置信度，可作為 NPU 推理結果的直觀確認。
七、常見問題
看不到 amdxdna 模塊或推理報權限錯誤：通常是未切換到 root。NPU 設備僅 root 可訪問，請先執行 sudo -i。
vek385-setup.service 狀態非 SUCCESS：多為 overlay 未刷入或 SD 卡內容不完整，請返回第二節重新刷寫，并留意 dry-run 的校驗信息。
撥碼開關設置混淆：刷寫 OSPI 使用 JTAG 模式（全 ON），啟動使用 OSPI 模式（ON, ON, ON, OFF），注意區分。
串口無法連接：確認設備號（常見為 /dev/ttyUSB1）與波特率 115200。
總結
本文介紹了如何使用預編譯模型在 VEK385 開發板上完成端到端推理：從 OSPI + SD 卡自動化啟動，到使用 ResNet50 INT8 驗證推理鏈路并進行性能測試，再到通過 C++（VART）與 Python（ONNX Runtime + VitisAI EP）兩條路徑完成圖像分類，最后使用 YOLOX-M 完成目標檢測并可視化結果。通過這一流程，可以快速建立對 Vitis AI 6.2 核心概念的認識：NPU、ONNX、VitisAI EP，以及雙運行時（VART + ONNX Runtime）。
瑞士硬核 FPGA 模組全家桶！—— 硬件大佬來鑒定實力！
IC Coder 2.0全面開放：Level-5級AI自主FPGA設計時代來臨
航空高清視頻鏈路國產化提速：ARINC818背后的“隱形戰場”
雷達架構正在重構：RFSoC如何開啟下一代數字敏捷雷達時代？
AMD放出“大招”：機器人終于迎來自己的AI大腦？
50美元，把FPGA拉回“人人可玩”的時代？Adiuvo Forgix背后的產業變化
