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

예, Home Assistant 관련 워크로드는 경우에 따라 다른 컨테이너와 GPU를 공유할 수 있지만, 답은 가속기 경로와 가상화 경계에 따라 달라집니다.

Home Assistant Core 자체에는 일반적으로 GPU가 필요하지 않습니다. 가속기는 보통 Frigate, 로컬 비전 또는 AI, 미디어 처리, 혹은 다른 보조 서비스에 사용됩니다. Linux에서는 여러 컨테이너에 동일한 렌더 장치에 대한 액세스 권한을 부여하고 드라이버가 작업을 스케줄링하도록 할 수 있는 경우가 많습니다. 전체 PCIe 장치를 패스스루로 전달받는 VM은 다른 방식이며, 해당 장치를 호스트와 다른 게스트에서 사용할 수 없게 만들 수 있습니다. 권한을 변경하기 전에 실제 사용 주체를 확인하세요.

먼저 실제로 가속기가 필요한 Home Assistant 워크로드를 확인하세요

호스트에 GPU가 있다는 이유만으로 Home Assistant Core 컨테이너에 GPU를 전달하지 마세요. GPU를 사용할 프로세스를 먼저 특정하세요. 예를 들면 Frigate의 비디오 디코딩, OpenVINO 객체 감지, 로컬 언어 또는 비전 서비스, 음성 처리, 혹은 Home Assistant가 호출하는 다른 컨테이너일 수 있습니다. 장치 매핑은 해당 워크로드의 컨테이너와 보안 경계에 속해야 합니다.

Frigate 배포는 장치 경로 모델을 명확하게 보여 줍니다. 하드웨어 가속이 작동하려면 특정 렌더 장치가 전체 컨테이너 스택을 거쳐 표시되어야 합니다. 최신 Frigate iGPU 패스스루 가이드는 호스트에 GPU가 있다는 사실만으로 추정하지 말고 장치 가시성, 그룹 권한, 가상화 계층을 확인해야 하는 이유를 보여 줍니다.

Home Assistant가 API나 MQTT를 통해 가속 서비스를 조정하기만 한다면 Core에는 장치에 직접 액세스할 필요가 전혀 없습니다. GPU 매핑을 실제로 사용하는 컨테이너에만 유지하면 권한을 줄이고 문제를 더 쉽게 격리할 수 있습니다.

공유 Linux 렌더 장치와 전체 GPU VM 패스스루는 서로 다른 모델입니다

Linux 컨테이너에서는 /dev/dri/renderD128과 같은 렌더 노드를 둘 이상의 컨테이너에 매핑하여 두 애플리케이션이 호스트 드라이버를 통해 작업을 제출하도록 할 수 있습니다. 이 경우 각 컨테이너가 독립적인 물리 GPU를 받는 것이 아니라 스케줄러와 메모리 리소스를 공유합니다. 특정 워크로드가 이를 안전하게 지원하는지는 여전히 드라이버와 애플리케이션의 동작에 따라 달라집니다.

LXC GPU 패스스루 가이드는 컨테이너 경계를 명확히 설명합니다. 호스트는 실제 GPU 드라이버를 유지하고, 컨테이너는 /dev/dri/renderD128과 같은 선택된 장치 노드를 전달받습니다. 이 공유 렌더 장치 모델을 사용하면 여러 컨테이너가 동일한 가속기 경로에 액세스할 수 있지만, GPU 엔진, 메모리 대역폭, 공급업체별 제한을 두고 경쟁하게 됩니다.

전체 장치 PCIe 패스스루를 가상 머신에 전달하는 방식은 다릅니다. 최신 Proxmox VFIO 안내에서는 이를 하나의 VM에 대한 독점적인 GPU 소유권으로 설명하며, 이 경우 해당 카드에 대한 일반적인 호스트 드라이버 공유 경로가 사라집니다. SR-IOV, mediated device, vGPU 또는 유사한 기능은 지원되는 하드웨어에서 또 다른 공유 모델을 만들 수 있지만, 이는 별도의 기능이며 일반적인 패스스루만으로 지원된다고 가정해서는 안 됩니다.

성능을 테스트하기 전에 두 컨테이너에서 가시성과 권한을 확인하세요

각 가속기 사용 주체를 별도로 시작하고 컨테이너 내부에서 장치 노드, 사용자 및 그룹 권한, 드라이버 라이브러리, 애플리케이션의 하드웨어 보고 내용을 확인하세요. 권한이 있는 컨테이너를 사용하는 것은 필요한 렌더 장치와 그룹을 이해하는 것에 대한 좋은 대안이 아닙니다. 의도한 워크로드가 작동하는 데 필요한 최소한의 장치 액세스만 부여하세요.

동일한 LXC 장치 매핑 절차를 사용하면 컨테이너 내부에서 렌더 노드를 확인할 수 있으며, 호스트의 가시성만 믿지 말고 실제 서비스 계정으로 테스트할 것을 권장합니다. 이 방법으로 성능을 비교하기 전에 컨테이너 수준의 가속기 액세스를 확인하세요. 호스트에 장치가 표시된다고 해서 애플리케이션이 해당 장치를 열 수 있다는 뜻은 아닙니다.

두 컨테이너가 각각 하드웨어 사용을 입증했을 때만 가시성 단계를 통과한 것으로 보세요. 한쪽이 아무런 표시 없이 CPU로 대체 실행된다면 동시성 테스트를 진행하기 전에 매핑이나 드라이버 설정을 수정하세요. 그렇지 않으면 CPU 대체 실행으로 인해 GPU 공유가 작동하는 것처럼 보이지만 실제로는 호스트가 한 워크로드를 소프트웨어로 처리하게 될 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

단독 테스트와 동시 테스트를 실행해 공유 경계를 파악하세요

먼저 각 워크로드를 단독으로 측정하세요. 프레임 처리 시간, 인코딩 및 디코딩 속도, 가속기 사용률, 메모리 사용량, 온도, 전력, 애플리케이션 지연 시간을 기록합니다. 그런 다음 두 워크로드를 평소 최대 부하로 동시에 실행하세요. 중요한 Home Assistant 관련 워크로드가 기한을 지키고 어느 애플리케이션에서도 오류나 대체 실행이 발생하지 않을 때만 공유 구성을 허용할 수 있습니다.

ZimaSpace의 기존 컨테이너 간 하나의 GPU 공유 테스트도 동일한 운영 원칙을 제시합니다. 장치 가시성은 첫 번째 관문일 뿐이며, 동시 실행 안정성과 리소스 경합에 따라 공유가 실제로 유용한지가 결정됩니다.

두 사용 주체가 실제 중첩 부하에서 지연 시간과 메모리 한도 내에 머문다면 하나의 가속기를 공유하세요. 한 작업으로 인해 프레임 손실, 추론 지연, 드라이버 재설정, 메모리 부족 오류, 열 스로틀링 또는 예측할 수 없는 대체 실행이 발생한다면 분리하세요. GPU 전체를 VM에 패스스루한 경우에는 이미 소유권이 넘어간 물리 장치를 두 번째 컨테이너에 매핑하려 하지 말고, 가상화 계층을 재설계하거나 다른 가속기를 추가하세요.