¿Puede Home Assistant compartir una GPU o un acelerador con otro contenedor?

Sí, las cargas de trabajo relacionadas con Home Assistant a veces pueden compartir una GPU con otro contenedor, pero la respuesta depende de la ruta del acelerador y del límite de virtualización.

El núcleo de Home Assistant normalmente no necesita una GPU; el acelerador suele utilizarse para Frigate, visión o IA local, procesamiento multimedia u otro servicio complementario. En Linux, a menudo se puede dar a varios contenedores acceso al mismo dispositivo de renderizado y dejar que el controlador programe el trabajo. Una máquina virtual que recibe un dispositivo PCIe completo mediante passthrough sigue un modelo diferente y puede hacer que ese dispositivo deje de estar disponible para el host y otros invitados. Identifica al consumidor real antes de cambiar los permisos.

Primero identifica qué carga de trabajo de Home Assistant necesita realmente el acelerador

No asignes una GPU al contenedor de Home Assistant Core simplemente porque el host tenga una. Identifica el proceso que la utilizará: decodificación de vídeo de Frigate, detección de objetos con OpenVINO, un servicio local de lenguaje o visión, procesamiento de voz u otro contenedor al que Home Assistant realice llamadas. La asignación del dispositivo debe corresponder al contenedor y al límite de seguridad de esa carga de trabajo.

Las implementaciones de Frigate muestran claramente el modelo de ruta del dispositivo: la aceleración por hardware depende de que un dispositivo de renderizado específico sea visible en toda la pila de contenedores. Una guía actual de passthrough de iGPU para Frigate muestra por qué deben verificarse la visibilidad del dispositivo, los permisos de grupo y las capas de virtualización, en lugar de deducirse simplemente de que el host tenga una GPU.

Si Home Assistant solo coordina el servicio acelerado mediante una API o MQTT, Core no necesita acceso directo al dispositivo. Mantener la asignación de la GPU en el contenedor consumidor reduce los privilegios y facilita el aislamiento de los fallos.

Los dispositivos de renderizado compartidos de Linux y el passthrough de una GPU completa a una máquina virtual son modelos diferentes

Con contenedores Linux, asignar un nodo de renderizado como /dev/dri/renderD128 a más de un contenedor puede permitir que ambas aplicaciones envíen trabajo mediante el controlador del host. Comparten un planificador y recursos de memoria; no reciben una GPU física independiente cada una. Que una carga de trabajo concreta admita esto de forma segura sigue dependiendo del comportamiento del controlador y de la aplicación.

Una guía de passthrough de GPU para LXC deja claro el límite del contenedor: el host conserva el controlador real de la GPU, mientras que el contenedor recibe nodos de dispositivo seleccionados, como /dev/dri/renderD128. Ese modelo de dispositivo de renderizado compartido permite que varios contenedores accedan a la misma ruta del acelerador, pero siguen compitiendo por los motores de la GPU, el ancho de banda de memoria y los límites específicos del fabricante.

El passthrough PCIe del dispositivo completo a una máquina virtual es diferente. Un tutorial actual de VFIO para Proxmox describe esa transferencia como propiedad exclusiva de la GPU por parte de una máquina virtual, lo que elimina la ruta normal de uso compartido del controlador del host para esa tarjeta. SR-IOV, dispositivos mediados, vGPU u otras funciones similares pueden crear otro modelo de uso compartido en hardware compatible, pero son capacidades independientes y no deben darse por supuestas en un passthrough convencional.

Verifica la visibilidad y los permisos en ambos contenedores antes de probar el rendimiento

Inicia cada consumidor del acelerador por separado e inspecciona desde dentro del contenedor el nodo del dispositivo, los permisos de usuario y grupo, las bibliotecas del controlador y el informe de hardware de la aplicación. Un contenedor privilegiado no es un buen sustituto para comprender qué dispositivo de renderizado y qué grupos se necesitan. Concede el acceso más limitado al dispositivo que permita funcionar a la carga de trabajo prevista.

El mismo flujo de asignación de dispositivos de LXC verifica el nodo de renderizado desde dentro del contenedor y recomienda probarlo con la cuenta de servicio real, en lugar de confiar únicamente en la visibilidad desde el host. Utiliza ese método para confirmar el acceso del contenedor al acelerador antes de comparar el rendimiento; que un dispositivo aparezca en el host no demuestra que la aplicación pueda abrirlo.

Supera la fase de visibilidad solo cuando ambos contenedores demuestren de forma independiente el uso del hardware. Si uno cambia silenciosamente a la CPU, corrige la asignación o la configuración del controlador antes de ejecutar una prueba de concurrencia. De lo contrario, el uso de la CPU puede hacer parecer que el uso compartido de la GPU funciona, cuando en realidad el host está ejecutando una de las cargas de trabajo mediante software.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Ejecuta pruebas por separado y simultáneas para encontrar el límite del uso compartido

Mide primero cada carga de trabajo por separado: tiempo de procesamiento de fotogramas, velocidad de codificación y decodificación, uso del acelerador, consumo de memoria, temperatura, consumo eléctrico y latencia de la aplicación. Después, ejecuta ambas juntas durante su pico normal. La configuración compartida solo es aceptable cuando la carga de trabajo crítica relacionada con Home Assistant mantiene sus plazos y ninguna aplicación empieza a mostrar errores o a cambiar a un modo alternativo.

La prueba existente de ZimaSpace sobre el uso compartido de una GPU entre contenedores ofrece la misma regla operativa: la visibilidad del dispositivo es solo el primer filtro; la estabilidad durante la concurrencia y la competencia por los recursos determinan si compartirla resulta realmente útil.

Mantén un acelerador compartido cuando ambos consumidores permanezcan dentro de los límites de latencia y memoria durante la superposición real. Sepáralos cuando un trabajo provoque pérdida de fotogramas, retrasos en la inferencia, reinicios del controlador, errores de memoria insuficiente, limitación térmica o cambios impredecibles a un modo alternativo. Si la GPU se ha asignado por completo a una máquina virtual mediante passthrough, rediseña la capa de virtualización o añade otro acelerador, en lugar de intentar asignar el dispositivo físico ya reservado a un segundo contenedor.