Immich는 다른 컨테이너와 GPU 또는 가속기를 공유할 수 있나요?

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

예, 호스트 런타임이 동시 액세스를 허용하고 두 워크로드가 실제 장치 한도 내에서 유지된다면 Immich는 다른 컨테이너와 GPU 또는 가속기를 공유할 수 있습니다.

장치를 공유한다고 해서 격리나 동일한 성능이 보장되는 것은 아닙니다. Immich는 동영상 트랜스코딩 또는 머신러닝 추론에 가속을 사용하는 동시에, 다른 서비스가 미디어를 인코딩하거나 AI 추론을 실행하거나 동일한 렌더 노드를 사용할 수 있습니다. 장치를 의도적으로 노출하고, 각 워크로드를 단독으로 테스트한 다음 실제 동시 실행을 진행하면서 메모리, 지연 시간, 발열 또는 드라이버 오류를 확인하세요.

먼저 각 컨테이너가 가속기를 단독으로 사용할 수 있는지 확인하세요

공유를 테스트하기 전에 한 번에 하나의 워크로드만 실행하여 호스트 드라이버와 컨테이너 런타임을 확인하세요. Immich의 경우 실제로 사용하려는 가속 기능을 실행하고 장치 사용량과 애플리케이션 로그가 정상인지 확인하세요. 두 번째 컨테이너도 일반 워크로드로 동일하게 반복합니다.

NVIDIA 컨테이너 런타임의 여러 GPU 지원 컨테이너 예시는 여러 컨테이너를 GPU 액세스 상태로 실행할 수 있음을 보여줍니다. 이는 런타임 모델을 입증할 뿐이며, 모든 애플리케이션 조합이 공정하게 공유하거나 하나의 장치에 수용된다는 뜻은 아닙니다.

어느 애플리케이션이든 가속기를 단독으로 안정적으로 사용하지 못한다면 아직 동시성 문제를 진단하지 마세요. 실제 경합과 기준선 문제를 구분할 수 있도록 먼저 드라이버 버전, 장치 매핑, 권한, 런타임 설정, 코덱 지원 또는 애플리케이션 백엔드를 수정하세요.

각 워크로드에 필요한 장치만 노출하세요

가속기가 여러 개인 시스템에서는 가능하면 모든 컨테이너에 모든 GPU를 노출하는 대신 특정 장치를 할당하세요. 통합 Intel 또는 AMD 그래픽에서는 의도한 렌더 장치와 그룹 권한을 확인하세요. NVIDIA에서는 프로세스가 실제로 선택하는 표시 장치를 확인하세요.

NVIDIA 포럼의 컨테이너 간 GPU 하나 공유에 관한 최근 답변은 동일한 GPU가 두 컨테이너에 노출되면 일반 컨테이너 프로세스가 해당 GPU에 액세스할 수 있다고 설명합니다. 중요한 운영상의 요점은 컨테이너 경계가 자동으로 고정된 성능 할당량을 만들지는 않는다는 것입니다.

컨테이너를 다시 생성한 후에도 장치 표시 상태가 재현 가능해야 합니다. 각 서비스를 재시작하고 동일한 장치가 동일한 권한으로 표시되는지 확인하세요. 재시작 후 애플리케이션 하나가 CPU로 조용히 폴백한다면 공유 성능을 측정하기 전에 매핑을 수정하세요.

실제로 겹치는 워크로드에서 경합을 측정하세요

Immich를 단독으로 실행하여 처리 속도, 대화형 응답 시간, GPU 사용률, 장치 메모리, CPU 폴백 및 온도를 기록하세요. 동일한 지표로 다른 컨테이너도 단독 실행합니다. 그런 다음 대표적인 작업 두 개를 동시에 실행하고, 이론상 최대 처리량에 의존하지 말고 변화량을 비교하세요.

NVIDIA의 최신 컨테이너 간 GPU 공유 동작 논의에서는 두 컨테이너가 동일한 장치를 선택하여 경합할 수 있는지 질문합니다. 테스트해야 할 경계가 바로 이것입니다. 표시 상태는 공유 액세스를 의미할 뿐, 자동 입장 제어나 용량 보장을 의미하지 않습니다.

두 워크로드가 모두 가속 상태를 유지하고 정상적으로 완료되며 지연 시간과 발열 목표 범위 안에 있다면 공유를 허용하세요. 한 작업이 VRAM을 모두 사용하거나 다른 작업을 CPU로 전환시키거나 인코더 할당 오류를 만들거나 사용자가 체감할 수 있는 지연을 유발한다면 동시성을 줄이고, 무거운 작업을 시간적으로 분리하거나 별도의 장치를 할당하세요.

-15% OFF

트랜스코딩 부하와 머신러닝 부하를 분리해서 확인하세요

Immich가 동영상 인코딩을 수행하는지 머신러닝 추론을 실행하는지에 따라 가속기에 가하는 부하가 달라질 수 있습니다. 다른 컨테이너 역시 인코드 엔진, 컴퓨트 유닛 또는 공유 메모리를 다르게 사용할 수 있습니다. 전체 “GPU 사용률”만으로는 실제로 어떤 엔진이 포화되었는지 알기 어렵습니다.

ZimaSpace의 컨테이너 간 GPU 공유 검증 가이드는 유용한 홈 서버 테스트 방식을 제공합니다. 먼저 드라이버와 매핑을 확인한 다음, 장치 메모리, 온도, 오류 및 폴백 동작을 확인하면서 대표적인 동시 세션 수를 늘리세요.

동영상 트랜스코딩과 ML 작업이 거의 겹치지 않는다면 하드웨어 분할보다 예약 실행이 더 간단할 수 있습니다. 두 작업 모두 하루 종일 지연 시간에 민감하다면 두 번째 가속기나 별도의 호스트를 사용하는 편이 장애 경계를 더 명확하게 만들 수 있습니다. 적절한 아키텍처는 Docker가 두 컨테이너의 장치 열기를 허용하는지뿐 아니라 작업이 겹치는 시간대에 따라 결정됩니다.

재시작과 정상적인 최악의 피크 상황에서 공유를 검증하세요

Immich 동영상 트랜스코딩 하나와 Smart Search 또는 얼굴 관련 처리 배치를 실행하는 동시에, 두 번째 컨테이너가 평소 가장 바쁜 가속 작업을 수행하는 방식처럼 반복 가능한 피크 상황을 구성하세요. 완료율, 꼬리 지연 시간, 메모리 사용량, 온도, 오류 및 어느 서비스든 CPU로 폴백하는지를 기록하세요.

두 가지 순서로 컨테이너를 재시작한 뒤 테스트를 반복하세요. 명시적인 설계 선택으로 우선순위를 설정한 경우가 아니라면 견고한 구성은 어느 서비스가 먼저 가속기를 점유했는지에 의존해서는 안 됩니다. 호스트를 재시작한 후에도 장치 노드와 런타임 할당이 안정적으로 유지되는지 확인하세요.

측정된 동시 실행이 발열 및 메모리 여유를 확보한 상태에서 서비스 목표 범위 안에 있다면 공유를 유지하세요. 반복적으로 발생하는 첫 번째 오류 또는 허용할 수 없는 지연 시간에서 동시성 증가를 중단하세요. 문제가 계속되면 GPU 모델, 드라이버 및 런타임 버전, 장치 매핑, VRAM 사용량, 워크로드 유형 및 경합을 유발한 정확한 조합을 함께 제시하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.