콘텐츠로 이동

GPU 예상 시 CPU에서 실행됨

호스트 GPU는 동작하지만(CUDA 컴퓨트 샘플이 통과함) 추론이 예상보다 느리고 Python Inference 카드에 프로비저닝한 것보다 낮은 등급이 표시됩니다:

  • TensorRT를 예상했으나 CUDA가 보이거나,
  • GPU 공급자를 예상했으나 CPU (fallback) 또는 CPU가 보임.

추론 컨테이너 로그에는 흔히 다음과 같은 무해해 보이는 줄이 포함됩니다:

Failed to load library libonnxruntime_providers_tensorrt.so

이것은 공급자 체인이 한 번에 한 등급씩 저하되는 것입니다: TensorRT → CUDA → CPU.

실행 중인 서비스가 실제로 초기화한 공급자를 확인하세요:

Terminal window
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 라이브러리를 숨기는 것이기도 합니다 — 저하된 박스는 더 느릴 뿐 계속 실행됩니다.

  1. 박스가 반드시 GPU에서 실행되어야 하는지 결정합니다. GPU가 필수라면, 격차가 조용히 묻히지 않고 보이도록 폴백을 시끄럽게 만드세요 — 추론 서비스에서 공급자를 고정하고 엄격한 강제 적용을 켭니다:

    EXECUTION_MODE=tensorrt # 또는: cuda
    STRICT_EP=1

    추론을 재시작합니다. 이제 요청한 공급자를 사용할 수 없으면 컨테이너가 저하되는 대신 시작을 거부합니다 — 조용한 속도 저하를 조치 가능한 명백한 시작 실패로 바꿉니다.

  2. 요청한 등급이 TensorRT인데 제외되었다면, 이미지에서 TensorRT 공급자의 네이티브 파서 라이브러리가 누락된 것입니다. 이 박스에는 CPU 프로필 대신 GPU 지원 추론 이미지 프로필(TensorRT)을 사용하세요. 재배포 전에 이미지 등급이 하드웨어 등급과 일치하는지 확인하세요.

  3. 재시작 후 활성 공급자를 다시 확인합니다:

    Terminal window
    docker compose -f docker-compose.release.yml restart inference
    docker 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 카드는 실시간 공급자를 반영합니다. 거기서 등급이 떨어지면 정상적인 변동이 아니라 배포 결함으로 취급하세요.