Remplacer un GPU NVIDIA par une carte Intel Arc peut laisser une application auto-hébergée fonctionner tandis qu’une autre perd son accélération. C’est exactement ce qui s’est produit dans cette discussion source de juin à août 2026. Après avoir remplacé une RTX 2070 par une Intel Arc A310, le transcodage matériel de Jellyfin a continué de fonctionner et intel-gpu-top fonctionnait sur l’hôte ZimaOS, mais la reconnaissance faciale d’Immich s’est arrêtée et le widget GPU de la page d’accueil de ZimaOS a disparu.
Le fichier YAML d’Immich publié expliquait pourquoi les applications se comportaient différemment : le service d’apprentissage automatique conservait une réservation de GPU Docker de type NVIDIA. Le chemin Intel d’Immich utilise OpenVINO et un accès direct à /dev/dri. L’auteur du message a finalement modifié le fichier YAML dans la nouvelle interface de ZimaOS et confirmé que l’apprentissage automatique fonctionnait de nouveau.
Le fonctionnement de Jellyfin ne prouve pas qu’Immich ML a accès au GPU
Jellyfin et l’apprentissage automatique d’Immich sont des conteneurs distincts. Chacun reçoit sa propre image, ses périphériques, ses variables d’environnement et ses autorisations d’exécution. Attribuer un GPU Intel à Jellyfin ne donne pas automatiquement à Immich un accès au GPU. /dev/dri apparaître automatiquement dans immich-machine-learning.
Il s’agissait de la correction conceptuelle la plus importante de la discussion. La détection du GPU au niveau de l’hôte, le transcodage de Jellyfin, l’apprentissage automatique d’Immich et le widget GPU de ZimaOS constituent quatre couches distinctes.
Le service d’apprentissage automatique ressemblait toujours à l’ancienne configuration NVIDIA
Le fichier YAML source contenait une réservation de périphérique Docker similaire à ceci :
deploy:
resources:
reservations:
devices:
- capabilities:
- gpu
device_ids:
- "0"Cette réservation générique du GPU avait été conservée de la configuration précédente avec la RTX 2070. Elle ne correspondait pas au chemin Intel OpenVINO normalement utilisé par Immich.
Vérifiez d’abord que le GPU Intel existe sur l’hôte ZimaOS
L’auteur du message avait déjà établi deux faits importants :
-
intel-gpu-topfonctionnait depuis le terminal de ZimaOS ; - Jellyfin pouvait utiliser l’Arc A310 pour le transcodage matériel.
Ces résultats montrent que le noyau de l’hôte et qu’au moins un chemin multimédia de l’espace utilisateur pouvaient utiliser le GPU. Ils rendent peu plausible l’explication selon laquelle « la carte Arc n’est pas détectée du tout » serait à l’origine de l’échec d’Immich.
Ensuite, vérifiez /dev/dri dans le conteneur ML d’Immich
Le membre de la communauté a suggéré de vérifier séparément l’hôte et le conteneur. Le diagnostic le plus utile consiste à déterminer si le conteneur d’apprentissage automatique peut voir /dev/dri.
Si l’hôte dispose du périphérique de rendu Intel, mais pas le conteneur, la correction doit être apportée à la définition du conteneur plutôt que dans le BIOS de la carte mère ou la configuration PCIe.
Le ML Intel actuel d’Immich utilise OpenVINO
La prise en charge actuelle par Immich du machine learning accéléré matériellement sur Intel utilise OpenVINO. Le conteneur de machine learning doit utiliser l’image OpenVINO appropriée, ou une variante de celle-ci, et avoir accès aux périphériques de rendu.
Avant de modifier une pile actuelle, consultez les exigences actuelles d’Immich pour le machine learning accéléré matériellement avec Intel OpenVINO, car les balises d’image et les options d’accélérateur prises en charge peuvent changer d’une version d’Immich à l’autre.
La communauté a suggéré de supprimer la réservation NVIDIA et d’ajouter l’accès aux périphériques Intel
L’intervenant a proposé de supprimer l’ancienne deploy.resources.reservations.devices section du service ML et en transmettant les périphériques de rendu Intel, conceptuellement avec :
devices:
- /dev/dri:/dev/driLa réponse suggérait également une image de machine learning spécifique à OpenVINO pour la version indiquée par l’utilisateur.
Ces balises de version exactes correspondent à la période de la source. Utilisez les balises Immich actuelles plutôt que de figer le numéro de version 2026.
Utilisez les journaux du machine learning pour confirmer le fournisseur de l’accélérateur
Un fonctionnement /dev/dri mount est nécessaire, mais pas suffisant. Après avoir modifié le fichier YAML, redémarrez Immich et examinez les journaux du machine learning pour vérifier l’initialisation de l’accélérateur, le chargement du modèle ou la présence d’erreurs du fournisseur.
Cette méthode est préférable à l’évaluation de la réussite à partir du widget GPU de ZimaOS, car le journal de l’application indique si le service ML concerné utilise réellement le backend prévu.
La nouvelle modification YAML de ZimaOS a simplifié la résolution du problème
Lorsque l’auteur du message initial est revenu le 24 août, il a indiqué que la dernière version de ZimaOS permettait d’accéder plus directement à la modification YAML depuis la page d’accueil du serveur. Cela supprimait la difficulté précédente consistant à trouver le fichier YAML sous-jacent de l’application.
Il s’agit d’une limite de version importante : les anciens conseils concernant la recherche manuelle des fichiers Compose générés sont moins pertinents depuis que l’App Store ZimaOS 2.0 a ajouté la modification native des fichiers YAML.
L’auteur de la publication initiale a confirmé le rétablissement de l’apprentissage automatique
La réponse finale de la source indique qu’après la suppression du bloc de réservation de l’ancien GPU et l’ajustement de la configuration des périphériques, l’apprentissage automatique d’Immich a recommencé à fonctionner.
Cela en fait un cas source résolu. Cela ne prouve pas que chaque modèle Intel Arc ou chaque version d’Immich utilise exactement le même fichier YAML, mais valide fortement le diagnostic : le conteneur d’apprentissage automatique était toujours configuré pour le modèle de GPU précédent.
La disparition du widget GPU de ZimaOS était un problème distinct
Le widget GPU de la page d’accueil a disparu après le passage à l’Arc A310, mais Jellyfin utilisait déjà le GPU. Le widget du tableau de bord ne pouvait donc pas être considéré comme l’indicateur faisant autorité de la prise en charge du GPU.
Pour le dépannage des applications, donnez la priorité à la détection des périphériques par l’hôte, à la visibilité des périphériques dans les conteneurs et aux journaux des applications plutôt qu’à un widget décoratif d’utilisation.
Une meilleure liste de contrôle pour la migration du GPU
- Confirmer la présence du nouveau GPU et du pilote au niveau de l’hôte ZimaOS.
- Vérifier séparément chaque application accélérée.
- Supprimer les réservations de périphériques propres à l’ancien fournisseur.
- Utiliser le moteur d’accélération requis par le nouveau fournisseur.
- Transmettre les périphériques de rendu requis à chaque conteneur concerné.
- Redémarrer uniquement la pile concernée et examiner les journaux.
- Lancer une nouvelle tâche d’apprentissage automatique dans Immich et vérifier que les résultats apparaissent.
FAQ sur les GPU Intel Arc dans Immich
Pourquoi Jellyfin a-t-il continué à fonctionner alors que la reconnaissance faciale d’Immich s’est arrêtée ?
Les deux applications s’exécutent dans des conteneurs différents et nécessitent une configuration GPU distincte.
Quel moteur utilise actuellement Immich pour l’apprentissage automatique sur GPU Intel ?
OpenVINO.
Le problème initial de l’Arc A310 a-t-il été résolu ?
Oui. L’utilisateur a confirmé que la modification du fichier YAML a rétabli l’apprentissage automatique.
Le widget GPU de ZimaOS détermine-t-il si Immich peut utiliser le GPU ?
Non. Le boîtier source avait un widget manquant alors que l’accélération GPU de Jellyfin fonctionnait toujours.
