GPU 예상 시 CPU에서 실행됨
호스트 GPU는 동작하지만(CUDA 컴퓨트 샘플이 통과함) 추론이 예상보다 느리고 Python Inference 카드에 프로비저닝한 것보다 낮은 등급이 표시됩니다:
- TensorRT를 예상했으나 CUDA가 보이거나,
- GPU 공급자를 예상했으나 CPU (fallback) 또는 CPU가 보임.
추론 컨테이너 로그에는 흔히 다음과 같은 무해해 보이는 줄이 포함됩니다:
Failed to load library libonnxruntime_providers_tensorrt.so이것은 공급자 체인이 한 번에 한 등급씩 저하되는 것입니다: TensorRT → CUDA → CPU.
실행 중인 서비스가 실제로 초기화한 공급자를 확인하세요:
docker compose -f docker-compose.release.yml logs inference | grep -E "Active EP|EP enabled|resolved to"TensorRT EP enabled→ 최상위 등급, 할 일 없음.- TensorRT를 예상했는데
CUDA EP enabled→ TensorRT 공급자가 제외됨(네이티브 파서 라이브러리 누락). - GPU가 동작하는데
resolved to CPU only→ 두 GPU 공급자 모두 제외됨.
기본 실행 모드는 auto이며, 이는 실패하기보다 우아하게 저하되도록 설계되어 있습니다.
그 안전망이 곧 누락된 GPU 라이브러리를 숨기는 것이기도 합니다 — 저하된 박스는 더 느릴 뿐
계속 실행됩니다.
-
박스가 반드시 GPU에서 실행되어야 하는지 결정합니다. GPU가 필수라면, 격차가 조용히 묻히지 않고 보이도록 폴백을 시끄럽게 만드세요 — 추론 서비스에서 공급자를 고정하고 엄격한 강제 적용을 켭니다:
EXECUTION_MODE=tensorrt # 또는: cudaSTRICT_EP=1추론을 재시작합니다. 이제 요청한 공급자를 사용할 수 없으면 컨테이너가 저하되는 대신 시작을 거부합니다 — 조용한 속도 저하를 조치 가능한 명백한 시작 실패로 바꿉니다.
-
요청한 등급이 TensorRT인데 제외되었다면, 이미지에서 TensorRT 공급자의 네이티브 파서 라이브러리가 누락된 것입니다. 이 박스에는 CPU 프로필 대신 GPU 지원 추론 이미지 프로필(TensorRT)을 사용하세요. 재배포 전에 이미지 등급이 하드웨어 등급과 일치하는지 확인하세요.
-
재시작 후 활성 공급자를 다시 확인합니다:
Terminal window docker compose -f docker-compose.release.yml restart inferencedocker compose -f docker-compose.release.yml logs inference | grep "EP enabled"
- 이미지 프로필을 하드웨어에 맞추세요. 추론 이미지는 CPU, TensorRT, Jetson 프로필로 제공됩니다. GPU 박스에 CPU 프로필을 배포하면 구조상 CPU에 묶입니다 — 그 이미지에는 폴백할 GPU 공급자가 없습니다.
- GPU 필수 박스에는 고정 + 엄격 적용.
EXECUTION_MODE=auto는 혼합 플릿에 적합한 기본값이지만, 반드시 GPU를 사용해야 하는 박스에서는EXECUTION_MODE=<tier>+STRICT_EP=1이 보이지 않는 저하를 빠른 실패형 시작 오류로 바꿉니다. - 배포할 때마다 공급자 칩을 확인하세요. 대시보드의 Python Inference 카드는 실시간 공급자를 반영합니다. 거기서 등급이 떨어지면 정상적인 변동이 아니라 배포 결함으로 취급하세요.
관련 항목
섹션 제목: “관련 항목”- GPU 미사용 — CUDA 오류 500 — 호스트 GPU 컴퓨트 계층이 실제로 손상된 경우.
- 하드웨어 설정 — 어떤 GPU 등급이 어떤 이미지 프로필에 매핑되는지.
- 관측성 및 알림 — 활성 공급자와 지연 시간 읽기.