O Home Assistant pode partilhar uma GPU ou acelerador com outro contentor?

Sim, as cargas de trabalho relacionadas com o Home Assistant podem, por vezes, partilhar uma GPU com outro contentor, mas a resposta depende do caminho do acelerador e da fronteira de virtualização.

O próprio Home Assistant Core normalmente não precisa de uma GPU; o acelerador é geralmente utilizado pelo Frigate, por processamento local de visão ou IA, processamento multimédia ou outro serviço complementar. No Linux, é frequente ser possível dar a vários contentores acesso ao mesmo dispositivo de renderização e deixar que o controlador agende o trabalho. Uma VM que receba um dispositivo PCIe completo através de passthrough segue um modelo diferente e pode tornar esse dispositivo indisponível para o anfitrião e para outros convidados. Identifique o consumidor efetivo antes de alterar permissões.

Identifique primeiro que carga de trabalho do Home Assistant precisa realmente do acelerador

Não atribua uma GPU ao contentor do Home Assistant Core simplesmente porque o anfitrião tem uma. Identifique o processo que a utilizará: descodificação de vídeo do Frigate, deteção de objetos com OpenVINO, um serviço local de linguagem ou visão, processamento de voz ou outro contentor chamado pelo Home Assistant. O mapeamento do dispositivo deve pertencer ao contentor e à fronteira de segurança dessa carga de trabalho.

As implementações do Frigate demonstram claramente o modelo do caminho do dispositivo: a aceleração de hardware depende de um dispositivo de renderização específico estar visível em toda a pilha de contentores. Um guia atual de passthrough de iGPU do Frigate mostra por que motivo a visibilidade do dispositivo, as permissões dos grupos e as camadas de virtualização devem ser verificadas, em vez de serem inferidas pelo simples facto de o anfitrião ter uma GPU.

Se o Home Assistant apenas orquestrar o serviço acelerado através de uma API ou MQTT, o Core não precisa de acesso direto ao dispositivo. Manter o mapeamento da GPU no contentor consumidor reduz os privilégios e facilita o isolamento das falhas.

Os dispositivos de renderização Linux partilhados e o passthrough de uma GPU completa para uma VM são modelos diferentes

Em contentores Linux, mapear um nó de renderização como /dev/dri/renderD128 para mais do que um contentor pode permitir que ambas as aplicações submetam trabalho através do controlador do anfitrião. Estão a partilhar um agendador e recursos de memória, não a receber cada uma uma GPU física independente. A segurança desse modelo para uma carga de trabalho específica continua a depender do comportamento do controlador e da aplicação.

Um guia de passthrough de GPU para LXC torna explícita a fronteira do contentor: o anfitrião mantém o controlador real da GPU, enquanto um contentor recebe nós de dispositivo selecionados, como /dev/dri/renderD128. Esse modelo de dispositivo de renderização partilhado permite que vários contentores acedam ao mesmo caminho do acelerador, mas continuam a competir pelos motores da GPU, pela largura de banda da memória e pelos limites específicos do fabricante.

O passthrough PCIe do dispositivo completo para uma máquina virtual é diferente. Um guia atual de VFIO para Proxmox descreve essa transferência como propriedade exclusiva da GPU por uma VM, removendo o caminho normal de partilha através do controlador do anfitrião para essa placa. SR-IOV, dispositivos mediados, vGPU ou funcionalidades semelhantes podem criar outro modelo de partilha em hardware compatível, mas são capacidades distintas e não devem ser presumidas no passthrough normal.

Verifique a visibilidade e as permissões em ambos os contentores antes de testar o desempenho

Inicie cada consumidor do acelerador separadamente e inspecione, a partir do interior do contentor, o nó do dispositivo, as permissões do utilizador e dos grupos, as bibliotecas do controlador e o relatório de hardware da aplicação. Um contentor privilegiado não é um bom substituto para compreender qual o dispositivo de renderização e quais os grupos necessários. Conceda o acesso mais restrito ao dispositivo que permita o funcionamento da carga de trabalho pretendida.

O mesmo fluxo de trabalho de mapeamento de dispositivos LXC verifica o nó de renderização a partir do interior do contentor e recomenda testá-lo com a conta de serviço real, em vez de confiar apenas na visibilidade no anfitrião. Utilize esse método para confirmar o acesso do contentor ao acelerador antes de comparar o desempenho; um dispositivo listado no anfitrião não prova que a aplicação o consiga abrir.

Só avance da fase de visibilidade quando ambos os contentores demonstrarem de forma independente que estão a utilizar o hardware. Se um deles mudar silenciosamente para a CPU, corrija o mapeamento ou a configuração do controlador antes de executar um teste de simultaneidade. Caso contrário, uma utilização alternativa da CPU pode dar a impressão de que a partilha da GPU está a funcionar, quando, na realidade, o anfitrião está a processar uma das cargas de trabalho por software.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Execute testes isolados e conjuntos para encontrar a fronteira de partilha

Meça primeiro cada carga de trabalho isoladamente: tempo de processamento de fotogramas, velocidade de codificação/descodificação, utilização do acelerador, utilização de memória, temperatura, consumo de energia e latência da aplicação. Em seguida, execute ambas em conjunto, no pico normal. A configuração partilhada só é aceitável quando a carga de trabalho crítica relacionada com o Home Assistant cumpre o seu prazo e nenhuma das aplicações começa a apresentar erros ou a mudar para um modo alternativo.

O teste existente da ZimaSpace sobre partilhar uma GPU entre contentores apresenta a mesma regra operacional: a visibilidade do dispositivo é apenas o primeiro requisito; a estabilidade em simultâneo e a contenção de recursos determinam se a partilha é realmente útil.

Mantenha um acelerador partilhado quando ambos os consumidores permanecerem dentro dos limites de latência e memória durante a sobreposição real. Separe-os quando uma tarefa provocar perda de fotogramas, atrasos na inferência, reinicializações do controlador, erros de falta de memória, limitação térmica ou uma mudança imprevisível para um modo alternativo. Se a GPU tiver sido atribuída integralmente a uma VM através de passthrough, reformule a camada de virtualização ou adicione outro acelerador, em vez de tentar mapear o dispositivo físico já atribuído para um segundo contentor.