Immich 3.3 accélère son inférence IA et réduit sa RAM avec une simple variable opt-in
Le 7 octobre 2026, Immich publie la version 3.3, qui introduit une révision opt-in de ses modèles de machine learning : MACHINE_LEARNING_MODEL_REVISION=v2 rend l’inférence nettement plus rapide et moins gourmande en RAM sur tous les backends, y compris le CPU. Si votre NAS photo tourne à l’étroit, c’est la variable à ajouter — mais comprenez d’abord ce qu’elle change.
7 octobre 2026. L’équipe d’Immich publie v3.3.0, la version stable du gestionnaire de photos auto-hébergé. Une variable. La principale nouveauté technique tient dans une ligne de configuration : MACHINE_LEARNING_MODEL_REVISION=v2. Tous les backends. L’optimisation concerne l’inférence CPU autant que les accélérations matérielles. Pourquoi c’est important : sur un NAS modeste — le cas d’usage central d’Immich — cette révision promet une inférence « significativement plus rapide » et « moins gourmande en mémoire », ce qui change concrètement ce que peut faire une machine à faible puissance.
Ce que change la révision v2 des modèles
Depuis v3.3.0, le conteneur machine-learning d’Immich accepte une variable d’environnement qui bascule vers une révision v2 des modèles d’IA. Le bénéfice est double : une inférence plus rapide et une consommation mémoire réduite. La formulation de l’équipe est sobre — « après une longue liste d’optimisations, le ML est à la fois significativement plus rapide et utilise moins de mémoire » — mais elle est précise sur un point décisif : l’effet vaut pour tous les backends, y compris l’inférence CPU.
C’est ce dernier point qui compte pour l’auto-hébergement. La plupart des homelabs font tourner la détection d’objets, la reconnaissance faciale et la recherche sémantique sur le CPU d’un Synology, d’un mini-PC ou d’un NUC, sans GPU. Une révision qui réduit la pression mémoire et accélère le traitement sur CPU élargit mécaniquement le parc de machines capables de tenir les fonctions d’IA d’Immich sans thrashing. Les tests de la communauté, relayés par les guides NAS de mi-octobre, décrivent des gains notables sur les configurations basse consommation, au point que Marius Hosting recommande désormais la variable pour profiter des « optimisations massives de performance » qui « consomment moins de RAM et de ressources système ».
Pourquoi c’est opt-in, et ce que cela implique
Le choix de l’opt-in n’est pas anodin. Changer de révision de modèle, ce n’est pas un simple réglage : c’est remplacer les poids et le format d’inférence qui alimentent les index de recherche et les embeddings existants. L’équipe d’Immich a donc choisi de ne pas l’activer par défaut, pour laisser à chaque utilisateur le soin de déclencher la bascule en connaissance de cause.
Concrètement, deux conséquences. D’une part, les traitements déjà effectués avec la révision v1 ne sont pas automatiquement migrés : après bascule, il faut relancer les tâches ML concernées (détection de visages, embeddings de recherche sémantique, nouveaux modèles OCR) pour reconstruire les résultats avec les nouveaux modèles. D’autre part, la révision v2 introduit de nouveaux modèles OCR, ce qui améliore la qualité de la reconnaissance de texte dans les photos, mais nécessite là aussi un re-traitement du catalogue concerné.
La bascule se fait dans la définition du service immich-machine-learning du fichier docker-compose.yml, puis par une recréation du conteneur :
services:
immich-machine-learning:
image: ghcr.io/immich-app/immich-machine-learning:release
environment:
MACHINE_LEARNING_MODEL_REVISION: v2
# ... reste de la configuration inchangéAprès docker compose up -d, vérifiez la version embarquée et relancez les jobs ML depuis l’interface d’administration d’Immich (onglet Jobs), en commençant par Facial Recognition et Smart Search, les deux consommateurs les plus lourds.
Le contexte : une 3.3 riche, mais pas seulement technique
La v3.3.0 n’est pas qu’une révision de modèles. Elle apporte le partage de personnes — on peut désormais partager une personne identifiée avec un autre utilisateur du groupe, avec un contrôle du sens de partage —, des souvenirs d’anniversaire, l’empilement automatique des retouches mobiles, des miniatures de meilleure qualité et la synchronisation des claims OAuth à chaque connexion. Le tout s’inscrit dans la trajectoire d’un projet qui, fort de plus de 115 000 étoiles sur GitHub et du soutien de FUTO, s’est imposé comme l’alternative de référence à Google Photos en auto-hébergement.
La séquence des versions raconte aussi la maturation : v3.2.4 avait corrigé fin septembre une fuite mémoire introduite par une dépendance, et v3.3.0-rc avait introduit l’inférence TensorRT sur GPU NVIDIA RTX. La révision v2 des modèles s’ajoute à cette montée en puissance matérielle : d’un côté les accélérations GPU, de l’autre une optimisation qui profite à ceux qui n’ont pas de GPU du tout.
Verdict
La recommandation est simple à formuler, mais conditionnelle. Si vous faites tourner Immich sur un CPU seul ou sur un NAS à RAM limitée, activez MACHINE_LEARNING_MODEL_REVISION=v2 : vous récupérez de la vitesse et de la marge mémoire là où elles manquent le plus, et le coût se résume à relancer les jobs ML une fois. Si vous êtes déjà sur un GPU NVIDIA RTX avec TensorRT ou si votre catalogue est énorme et votre configuration stable, vous pouvez attendre une version de plus avant de basculer — l’opt-in signifie précisément qu’il n’y a aucune urgence, et re-traiter un gros catalogue a un coût en temps. Dans tous les cas, testez d’abord sur une copie de votre bibliothèque, surveillez la RAM après bascule, et gardez la révision v1 en repli documenté si un comportement vous surprend.