Home Assistant peut-il partager un GPU ou un accélérateur avec un autre conteneur ?

Oui, les charges de travail liées à Home Assistant peuvent parfois partager un GPU avec un autre conteneur, mais la réponse dépend du chemin d’accélération et de la frontière de virtualisation.

Home Assistant Core lui-même n’a normalement pas besoin d’un GPU ; l’accélérateur sert généralement à Frigate, à la vision ou à l’IA locales, au traitement multimédia ou à un autre service complémentaire. Sous Linux, plusieurs conteneurs peuvent souvent accéder au même périphérique de rendu et laisser le pilote planifier les tâches. Une machine virtuelle qui reçoit un périphérique PCIe entier par passthrough relève d’un autre modèle et peut rendre ce périphérique indisponible pour l’hôte et les autres invités. Identifiez le véritable utilisateur avant de modifier les autorisations.

Identifiez d’abord quelle charge de travail Home Assistant a réellement besoin de l’accélérateur

Ne transmettez pas de GPU au conteneur Home Assistant Core simplement parce que l’hôte en possède un. Identifiez le processus qui l’utilisera : décodage vidéo de Frigate, détection d’objets avec OpenVINO, service local de traitement du langage ou de la vision, traitement vocal ou tout autre conteneur appelé par Home Assistant. Le mappage du périphérique doit appartenir au conteneur et à la frontière de sécurité de cette charge de travail.

Les déploiements de Frigate illustrent clairement le modèle de chemin du périphérique : l’accélération matérielle dépend de la visibilité d’un périphérique de rendu précis à travers toute la pile de conteneurs. Un guide actuel du passthrough d’iGPU pour Frigate montre pourquoi la visibilité du périphérique, les autorisations des groupes et les couches de virtualisation doivent être vérifiées plutôt que déduites de la simple présence d’un GPU sur l’hôte.

Si Home Assistant se contente d’orchestrer le service accéléré via une API ou MQTT, Core n’a pas besoin d’un accès direct au périphérique. Conserver le mappage du GPU dans le conteneur consommateur réduit les privilèges et facilite l’isolation des défaillances.

Les périphériques de rendu Linux partagés et le passthrough d’un GPU entier à une VM sont deux modèles différents

Avec les conteneurs Linux, le mappage d’un nœud de rendu tel que /dev/dri/renderD128 dans plusieurs conteneurs peut permettre aux deux applications de soumettre des tâches via le pilote de l’hôte. Elles partagent un ordonnanceur et des ressources mémoire, et ne reçoivent pas chacune un GPU physique indépendant. La prise en charge sûre d’une charge de travail donnée dépend néanmoins du comportement du pilote et de l’application.

Un guide du passthrough de GPU pour LXC explicite la frontière du conteneur : l’hôte conserve le véritable pilote du GPU tandis qu’un conteneur reçoit certains nœuds de périphérique, comme /dev/dri/renderD128. Ce modèle de périphérique de rendu partagé permet à plusieurs conteneurs d’accéder au même chemin d’accélération, mais ils se disputent toujours les moteurs du GPU, la bande passante mémoire et les limites propres au fournisseur.

Le passthrough PCIe d’un périphérique entier vers une machine virtuelle est différent. Un guide actuel du VFIO pour Proxmox décrit ce transfert comme une propriété exclusive du GPU par une VM, ce qui supprime pour cette carte le chemin normal de partage via le pilote de l’hôte. Le SR-IOV, les périphériques médiés, les vGPU et les fonctions similaires peuvent créer un autre modèle de partage sur le matériel compatible, mais il s’agit de capacités distinctes qui ne doivent pas être présumées dans le cadre d’un passthrough classique.

Vérifiez la visibilité et les autorisations dans les deux conteneurs avant de tester les performances

Démarrez séparément chaque consommateur de l’accélérateur et inspectez depuis le conteneur le nœud de périphérique, les autorisations des utilisateurs et des groupes, les bibliothèques du pilote ainsi que le rapport matériel de l’application. Un conteneur privilégié ne remplace pas une compréhension précise du périphérique de rendu et des groupes requis. Accordez uniquement l’accès minimal au périphérique nécessaire au fonctionnement de la charge de travail prévue.

Le même flux de mappage de périphérique LXC vérifie le nœud de rendu depuis l’intérieur du conteneur et recommande de le tester avec le véritable compte de service plutôt que de se fier à la seule visibilité sur l’hôte. Utilisez cette méthode pour confirmer l’accès de niveau conteneur à l’accélérateur avant de comparer les performances ; un périphérique répertorié sur l’hôte ne prouve pas que l’application peut l’ouvrir.

Ne franchissez l’étape de visibilité que lorsque les deux conteneurs ont chacun démontré leur utilisation du matériel. Si l’un d’eux bascule silencieusement sur le processeur, corrigez le mappage ou la configuration du pilote avant d’effectuer un test de concurrence. Sinon, un basculement vers le processeur peut donner l’impression que le partage du GPU fonctionne alors que l’hôte exécute en réalité une charge de travail en logiciel.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Effectuez des tests séparés puis simultanés pour déterminer la limite de partage

Mesurez d’abord chaque charge de travail seule : temps de traitement des images, vitesse d’encodage et de décodage, utilisation de l’accélérateur, consommation mémoire, température, puissance et latence de l’application. Exécutez ensuite les deux charges simultanément à leur niveau de pointe habituel. La configuration partagée n’est acceptable que si la charge de travail essentielle liée à Home Assistant respecte ses délais et si aucune application ne commence à générer des erreurs ou à basculer sur le processeur.

Le test existant de ZimaSpace sur le partage d’un GPU entre conteneurs fournit la même règle opérationnelle : la visibilité du périphérique n’est que la première étape ; la stabilité en fonctionnement simultané et la concurrence pour les ressources déterminent si le partage est réellement utile.

Conservez un accélérateur partagé lorsque les deux consommateurs restent dans les limites de latence et de mémoire pendant le chevauchement réel. Séparez-les lorsqu’une tâche provoque des images perdues, des retards d’inférence, des réinitialisations du pilote, des erreurs de mémoire insuffisante, une limitation thermique ou un basculement imprévisible. Si le GPU est entièrement transmis à une VM, repensez la couche de virtualisation ou ajoutez un autre accélérateur au lieu d’essayer de mapper le périphérique physique déjà attribué dans un second conteneur.