b__ono__ng

onnxruntime-directml 사용하게 되는 경우 본문

IT/AI

onnxruntime-directml 사용하게 되는 경우

b__ono__ng 2026. 2. 26. 17:44

ONNX Runtime이 포함된 패키지를 PyInstaller로 exe로 만들면 유연하게 배포를 못합니다. (onnxruntime-gpu, onnxruntime-openvino, onnxruntime-directml 등) 환경이 다르면 onnxruntime 패키지가 서로 덮어씌워져서, exe 하나로 못 묶기 때문입니다..


문제 상황: exe로 배포하는데, GPU가 다 다름

배포하려는 환경이 예를들어 이렇다면 onnxruntime-gpu로 데스크탑밖에 못 돌리고, onnxruntiem-openvino로는 노트북밖에 못 돌립니다.
- 데스크탑: NVIDIA GPU (CUDA)
- 인텔 노트북: 내장그래픽/CPU (OpenVINO)

PyInstaller는 결국 내 개발 환경에 설치된 패키지 상태 그대로를 얼려서 exe로 만드는거라서 onnxruntime이 뭐가 설치되어있는지에 따라 묶이는게 다른데, 문제는

- `onnxruntime-gpu` (CUDA)
- `onnxruntime-openvino` (OpenVINO)

이 셋은 겉보기엔 패키지 이름이 다르지만,
설치하고 나면 파이썬에서 import 하는 모듈 이름은 결국 onnxruntime 하나로 묶입니다.

즉, pip 입장에서

- pip install onnxruntime-gpu 해놓고
- pip install onnxruntime-directml 하면

같은 위치에 같은 모듈을 다시 설치하는 거라서 덮어씌워집니다.

결론적으로 선택지는 2개정도인 것 같은데

1) exe를 2개 이상으로 나눠서 배포
- `app_cuda.exe` : onnxruntime-gpu
- `app_openvino.exe` : onnxruntime-openvino

성능을 챙기려면 이게 제일 깔끔하긴한데,, 뭐 어느 환경에는 이거 설치하세요 저 환경에서는 저거 설치하세요가 좀 헷갈림.
> “런타임에서 자동 판단”은 가능해도  
> “런타임에서 서로 다른 onnxruntime 바이너리를 동시에 들고 있기”가 난이도가 너무 높음

2) DirectML 하나로 통일해서 윈도우 전 환경 커버하기
DirectML은 DX12 기반이라서 Windows에서 웬만한 GPU(AMD/Intel/NVIDIA 포함)면 다 돌아갑니다. 그래서 배포가 쉽긴 한데,, 속도가 좀 느립니다. cpu보다는 빠르겠지만..

그래서 직접 돌려봤는데 저는 이 정도로 체감했습니다.

- 모델: YOLOv8m (ONNX)
- 입력: FHD (1920x1080)

이 환경에서

- PC (NVIDIA): CUDA → DirectML로 바꾸면 약 80~90% 수준
- 노트북 (Intel): OpenVINO → DirectML로 바꾸면 약 50~60% 수준

그래서 노트북을 위해 DirectML로 통일하면 특히 노트북 계열에서 손해가 꽤 큽더랍니다..