Pull to refresh
4K+
4

User

6
Rating
1
Subscribers
Send message

Спасибо за вопрос! Для ONNX я использовал CUDA Execution Provider (вот здесь происходит инициализация). TensorRT EP подключать не стал, так как в пайплайне уже реализован нативный бэкенд на чистом TensorRT API (enqueueV3), а CPU как целевая платформа изначально не рассматривался.
Мне было важно сохранить честный Zero-Host-Copy даже в ONNX-бэкенде, поэтому к CUDA EP привязан собственный cudaStream_t, а тензоры передаются напрямую из детектора в CUDA-ядра постпроцессинга без пересылок на хост через Ort::IoBinding и OrtDeviceAllocator. Что касается производительности, то свои 38 FPS ORT выдал на модели в FP16. Разница с TRT (38 против 118 FPS на одной и той же FP16-модели) обусловлена отсутствием сильного фьюзинга слоев, который делает TensorRT под конкретное железо. А попытка запустить INT8 + QDQ ноды на ORT вообще приводила к фоллбэку части графа на CPU и сильной просадке производительности, поэтому для боевого режима (165 FPS) я оставил только TRT.
История с NPU очень жизненная. На встраиваемых устройствах (вроде Rockchip) кастомные рантаймы действительно нередко проигрывают хорошо настроенному ORT из-за того, что неподдерживаемые операторы фоллбэчатся на CPU, и пересылки данных по памяти съедают весь профит от аппаратного ускорителя.

Information

Rating
889-th
Registered
Activity

Specialization

Senior C++/CUDA Engineer | HPC & AI Inference | Computer Vision
Старший
Git
Python
C++
Cuda
CI/CD
Docker
Английский язык
Linux