在資源有限的邊緣設(shè)備(例如 4GB 的 Jetson Orin Nano)上部署現(xiàn)代對(duì)象檢測模型時(shí)，總是要在準(zhǔn)確性與速度之間進(jìn)行權(quán)衡。雖然像 ultralytics 這樣的 Python 框架非常適合用于訓(xùn)練，但在推理過程中它們往往會(huì)引入較大的開銷。

在這個(gè)項(xiàng)目中，我嘗試突破 Jetson Orin Nano 的性能限制，放棄了使用 Python，轉(zhuǎn)而采用純 C++ 語言并結(jié)合 NVIDIA TensorRT 進(jìn)行實(shí)現(xiàn)。我的目標(biāo)有兩個(gè)方面：

?實(shí)現(xiàn) YOLO 模型的實(shí)時(shí)性能(幀率超過 30 幀/秒)。

?將新發(fā)布的 YOLOv26 與穩(wěn)定的 YOLOv8 進(jìn)行對(duì)比測試，以查看“端到端”架構(gòu)在嚴(yán)格的 TensorRT 環(huán)境中是否依然適用。

挑戰(zhàn)：在邊緣計(jì)算領(lǐng)域，Python 與 C++ 的較量

我在 Jetson Orin Nano(4GB 內(nèi)存)上進(jìn)行的 Python 代碼初步測試遇到了瓶頸。內(nèi)存使用量很高，而 Python 的全局解釋器鎖(GIL)加上其他開銷使得保持穩(wěn)定的高幀率變得困難。為了解決這個(gè)問題，我構(gòu)建了一個(gè)自定義的 C++ 推理管道，該管道負(fù)責(zé)處理：

?媒體輸入/輸出：OpenCV(在可能的情況下啟用硬件加速)。

?預(yù)處理：CUDA 函數(shù)(縮放、歸一化、CHW 轉(zhuǎn)換)。

?推斷：TensorRT 引擎(16 位浮點(diǎn)精度)

?后處理：NMS 和坐標(biāo)映射的 C++ 實(shí)現(xiàn)。

深入探究：YOLOv26 的“奧秘”

該項(xiàng)目的核心實(shí)驗(yàn)之一是嘗試部署實(shí)驗(yàn)性的 YOLOv26 算法。然而，我遇到了一個(gè)重大難題：置信度不一致問題。

雖然 YOLOv8 在轉(zhuǎn)換為 TensorRT 時(shí)表現(xiàn)完美，但 YOLOv26 在 C++ 中卻出現(xiàn)了邊界框漂移和置信度分?jǐn)?shù)不準(zhǔn)確的問題。為了解其原因，我分析了這兩個(gè)模型的 ONNX 圖(與 YOLOv10 進(jìn)行對(duì)比)。

模型架構(gòu)差異

YOLOv10 / v8(優(yōu)化版)：ONNX 導(dǎo)出包含完整的后處理子圖(TopK 和 Gather 操作)。輸出形狀通常為 1x300x6，能夠?qū)崿F(xiàn)真正的端到端無 NMS 的推理。

YOLOv26(默認(rèn)導(dǎo)出)：導(dǎo)出的 v26 模型輸出尺寸為 1x84x8400。它缺少內(nèi)置的端到端后處理子圖。

結(jié)論：v26 版本所宣傳的“無 NMS 處理”功能依賴于特定的 Python 側(cè)處理方式或特定的導(dǎo)出參數(shù)，而這些參數(shù)目前尚未成為標(biāo)準(zhǔn)配置。在純 TensorRT C++ 環(huán)境中，這種轉(zhuǎn)而采用傳統(tǒng)輸出格式的做法導(dǎo)致與標(biāo)準(zhǔn)后處理流程的兼容性出現(xiàn)問題。

注意：為了保證該項(xiàng)目代碼發(fā)布的穩(wěn)定性，我已將 YOLOv8n 設(shè)為默認(rèn)模型，因?yàn)樗芴峁┳罘€(wěn)定的工業(yè)級(jí)性能。

性能基準(zhǔn)測試

我針對(duì)三種不同的配置對(duì)推理流程進(jìn)行了測試。測試結(jié)果清楚地表明，在邊緣硬件上，C++ TensorRT 方法具有明顯的優(yōu)勢(shì)。

1. Mac Mini(M 系列芯片)

CPU 推理：約 21.4 幀每秒

MPS(GPU)推理：約 20.5 幀每秒

要點(diǎn)：在 macOS 系統(tǒng)中，MPS 后端的即時(shí)幀率較高，但存在同步延遲問題，導(dǎo)致其視頻流的平均幀率低于 CPU 的幀率。

MPS(GPU)推理：約 20.5 幀每秒

洞察：在 macOS 系統(tǒng)上，MPS 后端的即時(shí)幀率較高，但存在同步延遲問題，導(dǎo)致其視頻流的平均幀率低于 CPU。

2. Jetson Orin Nano (Python + ONNX)

ONNX 運(yùn)行時(shí)：約 16.0 幀每秒

Python 運(yùn)行時(shí)環(huán)境和 ONNX 解釋過程所產(chǎn)生的開銷限制了其性能。

ONNX 運(yùn)行時(shí)：約 16.0 幀每秒 由于 Python 運(yùn)行時(shí)和 ONNX 解釋過程的存在，其開銷限制了性能。

3. Jetson Orin Nano (C++ + TensorRT)- 勝利者

視頻推理(不顯示畫面)：33.2 幀每秒

延遲：約 12 毫秒(端到端)

吞吐量：約 90 幀每秒(使用 trtexec 進(jìn)行的原始基準(zhǔn)測試)

通過改用 C++ 和 TensorRT，與在相同硬件上使用 Python 實(shí)現(xiàn)相比，我們的性能提升了約 100%，這使得其能夠適用于實(shí)時(shí)機(jī)器人應(yīng)用。

如何運(yùn)行代碼

步驟 1：導(dǎo)出模型

您可以使用我的腳本將 YOLOv8 模型導(dǎo)出為 ONNX 格式。請(qǐng)注意，我們使用 opset=18 以實(shí)現(xiàn)最大程度的兼容性。

Python

第 2 步：構(gòu)建引擎

使用 trtexec 工具將 ONNX 模型轉(zhuǎn)換為高度優(yōu)化的 TensorRT 引擎(對(duì)于 Orin Nano 來說，建議使用 FP16 精度)。

Bash

第 3 步：編譯并運(yùn)行

導(dǎo)航至 C++ 項(xiàng)目目錄，并使用 CMake 進(jìn)行構(gòu)建。

Bash

未來工作

雖然當(dāng)前的系統(tǒng)運(yùn)行著 YOLOv8 沒有出現(xiàn)任何問題，但解決 YOLOv26 的導(dǎo)出問題將是接下來的工作重點(diǎn)。我計(jì)劃：

?檢查自定義的 ONNX 導(dǎo)出腳本，以強(qiáng)制包含 v26 版本中的 TopK 層。

?將這個(gè)感知模塊整合到一個(gè) ROS 2 節(jié)點(diǎn)中，用于我的 RoboCup 救援模擬項(xiàng)目。

?如果您對(duì)嵌入式人工智能的前沿領(lǐng)域感興趣，歡迎自行克隆該代碼庫并進(jìn)行貢獻(xiàn)!

本文編譯自hackster.io