Immich peut-il partager un GPU ou un accélérateur avec un autre conteneur ?
Oui, Immich peut partager un GPU ou un accélérateur avec un autre conteneur lorsque l’environnement d’exécution de l’hôte autorise les accès simultanés et que les deux charges de travail restent dans les limites pratiques du périphérique.
Le partage du périphérique ne garantit ni l’isolation ni des performances équivalentes. Immich peut utiliser l’accélération pour le transcodage vidéo ou l’inférence d’apprentissage automatique, tandis qu’un autre service encode des médias, exécute une inférence IA ou utilise le même nœud de rendu. Exposez le périphérique de manière délibérée, testez chaque charge de travail seule, puis exécutez le chevauchement réel en surveillant la mémoire, la latence, la température et les défaillances de pilote.
Vérifiez d’abord que chaque conteneur peut utiliser seul l’accélérateur
Avant de tester le partage, vérifiez le pilote de l’hôte et l’environnement d’exécution des conteneurs avec une seule charge de travail à la fois. Pour Immich, déclenchez la fonction accélérée que vous comptez réellement utiliser et vérifiez l’utilisation du périphérique ainsi que la propreté des journaux de l’application. Répétez l’opération avec le second conteneur en utilisant sa charge de travail habituelle.
L’exemple de l’environnement d’exécution des conteneurs NVIDIA consacré à plusieurs conteneurs compatibles avec les GPU montre que plusieurs conteneurs peuvent être lancés avec un accès au GPU. Cela prouve le fonctionnement du modèle d’exécution, mais pas que toutes les paires d’applications se partageront équitablement le périphérique ou tiendront sur un seul appareil.
Si l’une des applications ne peut pas utiliser l’accélérateur de manière fiable seule, ne cherchez pas encore la cause dans la concurrence. Corrigez d’abord la version du pilote, le mappage du périphérique, les autorisations, la configuration de l’environnement d’exécution, la prise en charge des codecs ou le backend de l’application. Un test partagé ne permettrait pas de distinguer ces problèmes de base d’une véritable contention.
N’exposez que le périphérique nécessaire à chaque charge de travail
Sur les systèmes dotés de plusieurs accélérateurs, attribuez si possible un périphérique précis au lieu d’exposer tous les GPU à chaque conteneur. Avec les circuits graphiques intégrés Intel ou AMD, vérifiez le périphérique de rendu prévu et les autorisations des groupes. Avec NVIDIA, confirmez quel périphérique visible le processus sélectionne réellement.
Une réponse récente sur le forum NVIDIA concernant le partage d’un GPU entre des conteneurs indique que des processus ordinaires exécutés dans des conteneurs peuvent accéder au même GPU lorsque celui-ci leur est exposé à tous les deux. Le point opérationnel important est que les limites des conteneurs ne créent pas automatiquement une répartition fixe des performances.
La visibilité du périphérique doit rester reproductible après la recréation des conteneurs. Redémarrez chaque service et confirmez que le même périphérique apparaît avec les mêmes autorisations. Si une application repasse silencieusement au processeur après un redémarrage, corrigez le mappage avant de mesurer les performances partagées.
Mesurez la contention dans les charges de travail qui se chevauchent réellement
Exécutez Immich seul et notez le débit de traitement, le temps de réponse interactif, l’utilisation du GPU, la mémoire du périphérique, le recours au processeur et la température. Exécutez l’autre conteneur seul avec les mêmes indicateurs. Faites ensuite se chevaucher les deux tâches représentatives et comparez l’évolution au lieu de vous fier au débit théorique maximal.
Une discussion plus récente de NVIDIA sur le comportement du partage d’un GPU entre conteneurs demande si deux conteneurs peuvent sélectionner les mêmes périphériques et entrer en contention. C’est précisément la limite à tester : la visibilité correspond à un accès partagé, pas à un contrôle automatique de l’admission ni à une capacité garantie.
Acceptez le partage si les deux charges de travail restent accélérées, s’achèvent correctement et demeurent dans vos objectifs de latence et de température. Si une tâche épuise la VRAM, force l’autre à utiliser le processeur, provoque des échecs d’allocation de l’encodeur ou entraîne des ralentissements perceptibles par l’utilisateur, réduisez la simultanéité, planifiez séparément les tâches lourdes ou attribuez des périphériques distincts.
Distinguez la pression du transcodage de celle de l’apprentissage automatique
Immich peut imposer des contraintes différentes à un accélérateur selon qu’il encode une vidéo ou exécute une inférence d’apprentissage automatique. L’autre conteneur peut également utiliser différemment les moteurs d’encodage, les unités de calcul ou la mémoire partagée. Une simple « utilisation du GPU » totale peut masquer le moteur réellement saturé.
Le guide ZimaSpace consacré à la validation du partage d’un GPU entre conteneurs propose une méthode de test utile pour un serveur personnel : confirmer d’abord le pilote et le mappage, puis augmenter progressivement le nombre de sessions simultanées représentatives tout en surveillant la mémoire du périphérique, la température, les erreurs et le comportement de repli.
Si le transcodage vidéo et l’apprentissage automatique se chevauchent rarement, la planification peut être plus simple que le partitionnement matériel. Si les deux sont sensibles à la latence toute la journée, un second accélérateur ou un hôte distinct peut offrir une limite de défaillance plus claire. La bonne architecture dépend de la fenêtre de chevauchement, et pas uniquement du fait que Docker autorise les deux conteneurs à ouvrir le périphérique.
Validez le partage après un redémarrage et lors d’un pic normal maximal
Construisez un scénario de pointe reproductible, par exemple un transcodage vidéo Immich accompagné d’un traitement par lots de Smart Search ou des visages, tandis que le second conteneur exécute sa tâche accélérée normale la plus intensive. Notez les taux d’achèvement, la latence de queue, l’utilisation de la mémoire, la température, les erreurs et le recours éventuel de l’un ou l’autre service au processeur.
Redémarrez les conteneurs dans les deux ordres et répétez le test. Une configuration robuste ne doit pas dépendre du service qui a réservé l’accélérateur en premier, sauf si cette priorité constitue un choix explicite de conception. Vérifiez également que les nœuds de périphérique et les attributions de l’environnement d’exécution restent stables après le redémarrage de l’hôte.
Conservez le partage si le chevauchement mesuré reste dans les objectifs de service, avec une marge suffisante du point de vue thermique et mémoire. Cessez d’augmenter la simultanéité dès la première erreur reproductible ou latence inacceptable. Pour approfondir le diagnostic, fournissez le modèle du GPU, les versions du pilote et de l’environnement d’exécution, les mappages des périphériques, l’utilisation de la VRAM, les types de charges de travail et la combinaison exacte qui provoque la contention.
Produits recommandés
Assistance et conseils
Plus à lire
Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés
N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot...
Comment empêcher les tâches ou importations en double dans Immich
Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez...
Comment réparer Immich après le remplissage de son volume de base de données
Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez...
