NVIDIA GPU를 Intel Arc 카드로 교체하면 한 셀프 호스팅 애플리케이션은 계속 작동하는 반면 다른 애플리케이션의 가속 기능은 중단될 수 있습니다. 2026년 6월부터 8월까지의 이 원본 스레드에서 바로 그런 일이 발생했습니다. RTX 2070을 Intel Arc A310으로 교체한 후 Jellyfin 하드웨어 트랜스코딩은 계속 작동했고 intel-gpu-top ZimaOS 호스트에서는 작동했지만 Immich 얼굴 인식은 중단되었고 ZimaOS 홈 페이지의 GPU 위젯도 사라졌습니다.
게시된 Immich YAML을 보면 애플리케이션이 서로 다르게 동작한 이유가 드러납니다. 머신러닝 서비스에 여전히 NVIDIA 방식의 Docker GPU 예약 설정이 남아 있었습니다. Immich의 Intel 경로는 OpenVINO와 직접 액세스를 사용하며, /dev/dri원글 작성자는 결국 최신 ZimaOS 인터페이스에서 YAML을 편집했고, 머신러닝이 다시 작동하기 시작했다고 확인했습니다.
Jellyfin이 작동한다고 해서 Immich ML에 GPU 액세스 권한이 있다는 뜻은 아닙니다
Jellyfin과 Immich 머신러닝은 별도의 컨테이너입니다. 각 컨테이너에는 자체 이미지, 장치, 환경 변수 및 런타임 권한이 할당됩니다. Intel GPU를 Jellyfin에 전달한다고 해서 Immich ML에 GPU 액세스 권한이 부여되는 것은 아닙니다. /dev/dri 내부에 자동으로 표시됨 immich-machine-learning.
이것이 해당 스레드에서 가장 중요한 개념적 수정이었습니다. 호스트 수준 GPU 감지, Jellyfin 트랜스코딩, Immich ML, ZimaOS GPU 위젯은 서로 다른 네 계층입니다.
머신러닝 서비스는 여전히 기존 NVIDIA 설정처럼 보였습니다
원본 YAML에는 다음과 유사한 Docker 장치 예약 설정이 포함되어 있었습니다.
deploy:
resources:
reservations:
devices:
- capabilities:
- gpu
device_ids:
- "0"
일반적인 GPU 예약 설정은 이전 RTX 2070 구성에서 그대로 이어진 것이었습니다. 이는 Immich에서 사용하는 일반적인 Intel OpenVINO 경로와 맞지 않았습니다.
먼저 ZimaOS 호스트에 Intel GPU가 존재하는지 확인하세요
원글 작성자는 이미 두 가지 중요한 사실을 확인한 상태였습니다.
-
intel-gpu-topZimaOS 터미널에서 작동했습니다. - Jellyfin은 하드웨어 트랜스코딩에 Arc A310을 사용할 수 있었습니다.
이 결과는 호스트 커널과 최소 하나의 사용자 공간 미디어 경로에서 GPU를 사용할 수 있음을 보여 줍니다. 따라서 “Arc 카드가 전혀 감지되지 않는다”는 설명은 Immich 오류의 원인으로 보기 어렵습니다.
그런 다음 Immich ML 컨테이너 내부에서 /dev/dri를 확인하세요
커뮤니티 답변자는 호스트와 컨테이너를 각각 확인해 보라고 제안했습니다. 가장 유용한 진단 방법은 머신러닝 컨테이너에서 다음을 확인할 수 있는지 여부입니다. /dev/dri.
호스트에 Intel 렌더 장치가 있지만 컨테이너에 없다면, 수정해야 할 부분은 메인보드 BIOS나 PCIe 구성이 아니라 컨테이너 정의입니다.
현재 Immich Intel ML은 OpenVINO 사용
현재 Immich의 Intel 하드웨어 가속 머신러닝 지원은 OpenVINO를 사용합니다. 머신러닝 컨테이너에는 적절한 OpenVINO 이미지 또는 이미지 변형이 필요하며 렌더 장치에 액세스할 수 있어야 합니다.
현재 스택을 편집하기 전에 Immich의 현재 Intel OpenVINO 하드웨어 가속 머신러닝 요구 사항을 확인하세요. Immich 릴리스에 따라 이미지 태그와 지원되는 가속기 옵션이 변경될 수 있기 때문입니다.
커뮤니티에서 NVIDIA 예약 제거 및 Intel 장치 액세스 추가를 제안함
응답자는 기존 항목을 제거할 것을 제안했습니다 deploy.resources.reservations.devices ML 서비스에 해당 섹션을 추가하고 Intel 렌더 장치가 전달되도록 보장하는 방식으로, 개념적으로 다음을 사용합니다.
devices:
- /dev/dri:/dev/dri
또한 답변에서는 사용자가 게시한 버전에 맞는 OpenVINO 전용 머신러닝 이미지를 제안했습니다.
해당 버전 태그는 원문이 작성된 시점에 사용되던 것입니다. 2026 버전 번호를 고정하지 말고 현재 Immich 태그를 사용하세요.
가속기 프로바이더 확인을 위해 머신러닝 로그 사용
정상 작동하는 /dev/dri mount는 필요하지만 충분하지 않습니다. YAML을 변경한 후 Immich를 다시 시작하고 가속기 초기화, 모델 로드 또는 프로바이더 오류가 있는지 머신러닝 로그를 확인하세요.
특정 ML 서비스가 실제로 의도한 백엔드를 사용하고 있는지는 애플리케이션 로그에서 확인할 수 있으므로, ZimaOS GPU 위젯으로 성공 여부를 판단하는 것보다 이 방법이 더 적절합니다.
최신 ZimaOS의 YAML 편집으로 수정이 더 쉬워짐
원래 게시자가 8월 24일에 돌아와 최신 ZimaOS 버전에서는 서버 홈페이지에서 YAML 편집 기능에 더 직접적으로 접근할 수 있게 되었다고 구체적으로 언급했습니다. 이로써 기본 앱 YAML을 찾기 어려웠던 이전 문제가 해결되었습니다.
이는 중요한 버전 경계입니다. ZimaOS App Store 2.0에서 네이티브 YAML 편집 기능이 추가된 후에는 생성된 Compose 파일을 수동으로 찾으라는 이전 안내의 관련성이 낮아졌습니다.
원글 작성자가 머신 러닝 복구를 확인했습니다.
최종 원본 답변에 따르면 기존 GPU 예약 블록을 제거하고 장치 구성을 조정한 후 Immich 머신 러닝이 다시 작동하기 시작했습니다.
따라서 이 사례는 해결된 원본 사례입니다. 모든 Intel Arc 모델이나 모든 Immich 버전이 정확히 동일한 YAML을 사용한다는 뜻은 아니지만, 진단을 강하게 뒷받침합니다. ML 컨테이너가 이전 GPU 모델에 맞게 계속 구성되어 있었던 것입니다.
ZimaOS GPU 위젯이 표시되지 않은 문제는 별개의 문제였습니다.
Arc A310으로 전환한 후 홈 페이지의 GPU 위젯이 사라졌지만 Jellyfin은 이미 GPU를 사용하고 있었습니다. 따라서 대시보드 위젯을 GPU 지원 여부를 판단하는 절대적인 지표로 볼 수 없었습니다.
애플리케이션 문제를 해결할 때는 장식용 사용률 위젯보다 호스트 장치 감지, 컨테이너의 장치 가시성, 애플리케이션 로그를 우선적으로 확인하세요.
더 나은 GPU 마이그레이션 체크리스트
- ZimaOS 호스트 수준에서 새 GPU와 드라이버를 확인하세요.
- 가속을 사용하는 각 애플리케이션을 별도로 확인하세요.
- 이전 공급업체에만 해당하는 장치 예약을 제거하세요.
- 새 공급업체에 필요한 가속기 백엔드를 사용하세요.
- 필요한 렌더링 장치를 관련 각 컨테이너에 전달하세요.
- 영향받은 스택만 다시 시작하고 로그를 확인하세요.
- 새 Immich 머신 러닝 작업을 트리거하고 결과가 표시되는지 확인하세요.
Immich Intel Arc FAQ
Immich 얼굴 인식은 중단되었는데 Jellyfin은 왜 계속 작동했나요?
두 애플리케이션은 서로 다른 컨테이너에서 실행되므로 GPU를 별도로 구성해야 합니다.
현재 Immich는 Intel GPU 머신 러닝에 어떤 백엔드를 사용하나요?
OpenVINO.
원래 Arc A310 문제는 해결되었나요?
예. 사용자는 YAML을 편집한 후 머신 러닝이 복구되었다고 확인했습니다.
ZimaOS GPU 위젯이 Immich에서 GPU를 사용할 수 있는지 여부를 결정하나요?
아니요. Jellyfin GPU 가속은 계속 작동했지만 원래 소스 사례에서는 위젯이 표시되지 않았습니다.
