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

Sí, Immich puede compartir una GPU o un acelerador con otro contenedor cuando el entorno de ejecución del host permite el acceso simultáneo y ambas cargas de trabajo se mantienen dentro de los límites prácticos del dispositivo.

Compartir el dispositivo no garantiza aislamiento ni un rendimiento equitativo. Immich puede usar aceleración para la transcodificación de vídeo o la inferencia de aprendizaje automático mientras otro servicio codifica contenido multimedia, ejecuta inferencia de IA o utiliza el mismo nodo de renderizado. Expón el dispositivo deliberadamente, prueba cada carga de trabajo por separado y, después, ejecuta la superposición real mientras vigilas la memoria, la latencia, la temperatura y los fallos del controlador.

Demuestra primero que cada contenedor puede usar el acelerador por separado

Antes de probar el uso compartido, verifica el controlador del host y el entorno de ejecución de contenedores con una sola carga de trabajo cada vez. En Immich, activa la función acelerada que realmente piensas usar y confirma la utilización del dispositivo y que los registros de la aplicación estén limpios. Repite el proceso con el segundo contenedor usando su carga de trabajo habitual.

El ejemplo del entorno de ejecución de contenedores de NVIDIA sobre varios contenedores con GPU demuestra que se pueden iniciar varios contenedores con acceso a la GPU. Eso demuestra el modelo del entorno de ejecución, no que todas las parejas de aplicaciones vayan a compartirla de forma equitativa o que quepan en un solo dispositivo.

Si alguna de las aplicaciones no puede usar el acelerador de forma fiable por separado, no diagnostiques todavía la concurrencia. Primero corrige la versión del controlador, la asignación del dispositivo, los permisos, la configuración del entorno de ejecución, la compatibilidad con códecs o el backend de la aplicación. Una prueba compartida no puede distinguir esos problemas básicos de la contención real.

Expón únicamente el dispositivo que necesita cada carga de trabajo

En sistemas con varios aceleradores, asigna un dispositivo específico cuando sea posible en lugar de exponer todas las GPU a todos los contenedores. En gráficos integrados de Intel o AMD, verifica el dispositivo de renderizado previsto y los permisos del grupo. En NVIDIA, confirma qué dispositivo visible selecciona realmente el proceso.

Una respuesta reciente en el foro de NVIDIA sobre compartir una GPU entre contenedores señala que los procesos normales de los contenedores pueden acceder a la misma GPU cuando esta se expone a ambos. El punto operativo importante es que los límites de los contenedores no crean automáticamente una cuota fija de rendimiento.

La visibilidad del dispositivo debe ser reproducible después de recrear el contenedor. Reinicia cada servicio y confirma que aparece el mismo dispositivo con los mismos permisos. Si una aplicación cambia silenciosamente a la CPU después del reinicio, corrige la asignación antes de medir el rendimiento compartido.

Mide la contención en las cargas de trabajo que realmente se superponen

Ejecuta Immich por separado y registra la velocidad de procesamiento, el tiempo de respuesta interactivo, la utilización de la GPU, la memoria del dispositivo, el uso alternativo de la CPU y la temperatura. Ejecuta el otro contenedor por separado con las mismas métricas. Después, superpón los dos trabajos representativos y compara el cambio en lugar de basarte en el rendimiento teórico máximo.

Un debate más reciente de NVIDIA sobre el comportamiento del uso compartido de GPU entre contenedores plantea si dos contenedores pueden seleccionar los mismos dispositivos y competir por ellos. Ese es exactamente el límite que debes probar: la visibilidad proporciona acceso compartido, no un control automático de admisión ni una capacidad garantizada.

Acepta el uso compartido cuando ambas cargas de trabajo sigan aceleradas, finalicen correctamente y se mantengan dentro de tus objetivos de latencia y temperatura. Si un trabajo agota la VRAM, obliga al otro a usar la CPU, provoca fallos de asignación del codificador o causa interrupciones perceptibles para el usuario, reduce la concurrencia, programa los trabajos pesados por separado o asigna dispositivos distintos.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separa la presión de la transcodificación de la presión del aprendizaje automático

Immich puede ejercer una presión diferente sobre el acelerador según esté codificando vídeo o ejecutando inferencia de aprendizaje automático. El otro contenedor también puede utilizar de forma distinta los motores de codificación, las unidades de cálculo o la memoria compartida. La “utilización de la GPU” total puede ocultar qué motor está realmente saturado.

La guía de ZimaSpace sobre la validación del uso compartido de GPU entre contenedores ofrece un patrón de prueba útil para servidores domésticos: confirma primero el controlador y la asignación, y después aumenta las sesiones simultáneas representativas mientras observas la memoria del dispositivo, la temperatura, los errores y el comportamiento alternativo.

Si la transcodificación de vídeo y el aprendizaje automático rara vez se superponen, la programación puede ser más sencilla que la partición del hardware. Si ambos requieren baja latencia durante todo el día, un segundo acelerador o un host separado puede proporcionar un límite de fallo más claro. La arquitectura adecuada depende de la ventana de superposición, no solo de si Docker permite que ambos contenedores abran el dispositivo.

Valida el uso compartido mediante reinicios y un pico máximo normal

Diseña un pico reproducible, como una transcodificación de vídeo de Immich junto con un lote de procesamiento de Búsqueda inteligente o relacionado con rostros, mientras el segundo contenedor ejecuta su tarea acelerada normal más exigente. Registra las tasas de finalización, la latencia de cola, el uso de memoria, la temperatura, los errores y si alguno de los servicios cambia a la CPU.

Reinicia los contenedores en ambos órdenes y repite la prueba. Una configuración sólida no debe depender de qué servicio reclame primero el acelerador, a menos que esa prioridad sea una decisión de diseño explícita. Comprueba también que los nodos de dispositivo y las asignaciones del entorno de ejecución se mantengan estables después de reiniciar el host.

Mantén el uso compartido cuando la superposición medida permanezca dentro de los objetivos del servicio y deje margen térmico y de memoria. Deja de aumentar la concurrencia ante el primer error repetible o una latencia inaceptable. Si necesitas escalar el problema, incluye el modelo de GPU, las versiones del controlador y del entorno de ejecución, las asignaciones de dispositivos, el uso de VRAM, los tipos de carga de trabajo y la combinación exacta que provoca la contención.