Plusieurs conteneurs multimédias peuvent-ils partager un même GPU sans conflits de périphériques ?
Oui, plusieurs conteneurs multimédias peuvent partager un même GPU lorsque le pilote et l’environnement d’exécution de l’hôte prennent en charge l’accès concurrent et que chaque conteneur reçoit correctement le périphérique.
Les conteneurs ne s’approprient généralement pas un GPU de manière exclusive, contrairement à une machine virtuelle bénéficiant d’un véritable passthrough. Intel Quick Sync et AMD VA-API exposent généralement des périphériques de rendu partagés, tandis que les conteneurs NVIDIA peuvent partager une même pile de pilotes et un même GPU, sous réserve des limites matérielles, des pilotes, des codecs, de la mémoire et des sessions. Les conflits surviennent lorsque l’orchestrateur alloue le périphérique exclusivement, lorsque les permissions diffèrent, lorsque les conteneurs embarquent des bibliothèques incompatibles ou lorsque des transcodages simultanés dépassent la capacité pratique du GPU.
Vérifier que l’hôte prend en charge les charges GPU simultanées
Installez et vérifiez d’abord le pilote de l’hôte, puis exécutez un transcodage accéléré matériellement en dehors d’un conteneur connu comme fonctionnel ou à l’intérieur de celui-ci. Notez le modèle du GPU, le pilote, les codecs d’encodage et de décodage pris en charge, la mémoire et l’utilisation observée.
Une discussion de la communauté TrueNAS rapporte que plusieurs applications peuvent partager le même GPU lorsque celui-ci est exposé pour être utilisé plutôt qu’alloué comme ressource exclusive à une application. La distinction se situe entre l’accès partagé au périphérique et le passthrough exclusif.
Si un conteneur ne peut pas utiliser le GPU de manière fiable, n’en ajoutez pas un autre. Corrigez le pilote de l’hôte, le périphérique du noyau, le firmware ou l’environnement d’exécution avant de tester la simultanéité.
Exposer le bon périphérique à chaque conteneur
Pour Intel et AMD, comparez les nœuds de carte et de rendu /dev/dri transmis à chaque conteneur. Pour NVIDIA, comparez l’environnement d’exécution ou la demande de périphérique, les variables des périphériques visibles et les capacités du pilote.
Un cas Jellyfin sur NixOS décrit un même GPU hôte se comportant différemment selon les conteneurs, car l’environnement du système d’exploitation et des périphériques avait changé. Il montre pourquoi une exposition cohérente des périphériques et des bibliothèques est plus importante que la simple copie d’une ligne Compose.
Utilisez le nombre minimal de périphériques requis par chaque application et évitez le mode privilégié comme solution de facilité. Après une reconstruction, vérifiez que le nœud de rendu ou le périphérique NVIDIA attendu apparaît dans chaque conteneur.
Harmoniser les permissions et les groupes d’utilisateurs entre les conteneurs
Notez le propriétaire et le groupe numériques du périphérique de rendu sur l’hôte, puis vérifiez que le processus de chaque conteneur dispose du groupe supplémentaire correspondant ou des permissions nécessaires. Les noms d’utilisateur propres aux images peuvent correspondre à des identifiants numériques différents.
Un conteneur qui détecte le GPU mais ne peut pas l’ouvrir peut basculer vers le transcodage logiciel ou signaler un refus d’accès. Cet échec peut ressembler à un conflit de périphérique alors que l’autre conteneur multimédia continue de fonctionner.
Testez chaque conteneur seul avec le même fichier et le même codec. Déclarez explicitement les corrections de permissions dans Compose afin que les mises à niveau et les recréations des images ne les suppriment pas.
Vérifier la compatibilité des codecs, du pilote et de l’environnement d’exécution
Comparez les codecs et les filtres que chaque application demande au GPU d’exécuter, notamment H.264, HEVC, AV1, le tone mapping, les sous-titres, la mise à l’échelle et les filtres OpenCL ou CUDA. Une charge de travail peut nécessiter des capacités qu’une autre n’utilise jamais.
Un guide actuel sur le passthrough GPU pour Jellyfin souligne l’importance d’adapter la configuration du conteneur à Intel QSV, NVIDIA NVENC ou AMD VA-API, plutôt que de considérer toutes les voies d’accélération matérielle comme interchangeables. L’environnement d’exécution doit correspondre à la famille du GPU.
Maintenez la compatibilité entre le pilote de l’hôte et les bibliothèques de l’environnement d’exécution du conteneur, et évitez d’intégrer des pilotes incompatibles dans les conteneurs multimédias individuels. Testez séparément le décodage, l’encodage et le tone mapping.
Mesurer les sessions simultanées, la mémoire et les limites thermiques
Lancez un transcodage matériel dans chaque conteneur et surveillez les processus du GPU, son utilisation, la charge de l’encodeur et du décodeur, la mémoire, la température, les erreurs et la stabilité des flux. Augmentez progressivement le nombre de sessions en utilisant des fichiers multimédias représentatifs.
Une configuration communautaire Proxmox décrit plusieurs instances Jellyfin transcodant simultanément et vérifie leur activité depuis l’hôte. Elle montre également que les sessions simultanées ont des limites pratiques imposées par le matériel et les logiciels.
Un GPU partagé fonctionne lorsque les deux applications restent accélérées et réactives. Des saccades, l’échec de la création de l’encodeur, des erreurs de mémoire insuffisante, des réinitialisations thermiques ou une application qui force l’autre à utiliser le logiciel indiquent que la charge dépasse la marge disponible.
Conserver des chemins de configuration et de transcodage distincts tout en partageant le GPU
Attribuez à chaque conteneur multimédia sa propre base de données de configuration, son cache, son répertoire de transcodage, ses ports et son identité. Ne partagez que la bibliothèque multimédia en lecture seule et le périphérique GPU, sauf si les applications prennent explicitement en charge un répertoire d’état commun.
Le guide ZimaSpace consacré à l’isolation des dépendances entre conteneurs aide à distinguer un conflit GPU d’une défaillance de base de données, de cache, de réseau ou de montage.
La conception n’est validée que lorsque les deux conteneurs survivent aux reconstructions, utilisent simultanément l’accélération matérielle, respectent leurs propres permissions et leur propre état, et restent dans les limites de sessions, de mémoire et de température. Utilisez des GPU distincts ou un repli logiciel lorsque les charges simultanées ne permettent pas d’atteindre de manière fiable la qualité requise.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
