De quelle capacité de stockage Immich a-t-il besoin pour les miniatures et le machine learning afin de sauvegarder les photos de famille ?

Immich ne dispose pas d’un ratio fiable de stockage réservé aux seules vignettes. Les bibliothèques familiales devraient donc mesurer le nombre d’octets générés par ressource et prévoir un espace distinct pour les modèles de ML.

Une archive familiale de photos de 2 To ne permet pas de déterminer la taille du répertoire de vignettes Immich, car le nombre de ressources, leur résolution d’origine, les paramètres des vignettes, la proportion de vidéos et les modèles activés modifient tous l’espace occupé. La méthode de dimensionnement la plus sûre consiste à traiter un échantillon représentatif, à mesurer séparément les vignettes et le cache des modèles, à projeter la croissance de la bibliothèque, puis à ajouter une marge d’exploitation au lieu de considérer un pourcentage unique comme une exigence universelle.

Séparez les originaux de l’espace de stockage généré par Immich

Commencez par établir une distinction : les photos et vidéos originales ne représentent qu’une partie de l’espace disque nécessaire à une bibliothèque Immich. Le serveur conserve également des ressources générées pour la navigation et la compatibilité, tandis que le service de machine learning stocke les fichiers de modèles téléchargés dans son propre cache. Ces catégories évoluent pour des raisons différentes ; les réunir en un pourcentage vague complique donc l’identification du paramètre ou de la charge de travail qui consomme réellement l’espace.

Une référence de dimensionnement issue de la communauté Immich, régulièrement mise à jour, indique que les vignettes et les vidéos transcodées peuvent représenter ensemble environ 10 à 20 % en moyenne. Ce chiffre n’est utile qu’à titre de contexte général : il combine deux catégories générées et ne doit donc pas être présenté comme un ratio propre aux seules vignettes. Une famille dont la bibliothèque contient surtout des photos et peu de vidéos peut obtenir un résultat très différent d’une archive principalement composée de vidéos.

L’architecture compte également pour décider où placer cet espace supplémentaire. L’analyse de ZimaSpace consacrée à l’organisation des photos par IA considère l’indexation et les données générées comme des services autour de la bibliothèque originale, et non comme des remplacements de celle-ci. Pour planifier la capacité, gardez séparément les originaux, les vignettes et aperçus, les dérivés vidéo, la base de données et le cache ML, même s’ils partagent un même disque physique.

Mesurez le coût des vignettes par ressource avant de changer d’échelle

Choisissez un échantillon représentatif de la bibliothèque familiale plutôt que les mille fichiers les plus faciles à sélectionner. Il devrait inclure les différentes générations de téléphones, les résolutions d’appareils photo, les portraits, les captures d’écran, les panoramas et les autres types d’images correspondant à l’usage courant. Laissez les tâches liées aux vignettes se terminer, relevez le nombre de ressources traitées et mesurez le répertoire des vignettes. En divisant le nombre d’octets mesuré par le nombre de ressources traitées, vous obtenez un ratio local de planification qui tient déjà compte des paramètres de vignettes et d’aperçus que vous avez choisis.

Les installations réelles montrent pourquoi ce ratio local est important. Une discussion Immich faisait état de 21 Go de vignettes ainsi que de 58 Go de vidéos encodées sur un système donné. Ce chiffre est anecdotique et ne constitue pas un objectif, mais il montre que les répertoires dérivés peuvent avoir des tailles très différentes et doivent être mesurés séparément, plutôt que déduits des seuls téraoctets de la bibliothèque originale.

Par exemple, si 10 000 images représentatives produisent 12 Go de vignettes et d’aperçus, votre taux observé est d’environ 1,2 Mo par ressource. Une bibliothèque projetée de 60 000 images nécessiterait donc environ 72 Go avec les mêmes paramètres, avant l’ajout d’une marge de croissance. Répétez l’échantillonnage après toute modification de la résolution ou de la qualité des vignettes, car ces changements rendent l’ancien ratio par ressource obsolète, même si les fichiers originaux n’ont pas changé.

Le cache des modèles ML dépend davantage des modèles que du nombre de photos

Le stockage lié au machine learning fonctionne différemment des vignettes. Le cache des modèles contient principalement les fichiers de modèles téléchargés et réutilisés par le service ML. Son empreinte disque dépend donc davantage des modèles de recherche intelligente et de reconnaissance faciale sélectionnés que du fait que la bibliothèque contienne 20 000 ou 200 000 photos. La taille de la bibliothèque détermine la quantité de traitement à effectuer, mais elle n’exige pas une nouvelle copie du modèle pour chaque ressource.

Une installation Immich auto-hébergée récente décrit un cache de modèles persistant monté pour le service de machine learning et indique que les modèles utilisés occupaient au total moins de 1 Go. Il s’agit d’une configuration particulière, et non d’une garantie. Le point essentiel réside dans la persistance et la réutilisation : une fois les fichiers sélectionnés présents, la croissance normale du nombre de photos ne multiplie pas les fichiers binaires des modèles.

Pour un serveur familial susceptible de changer de modèles ultérieurement, il est raisonnable de prévoir une réserve supérieure au plus petit cache actuellement observé. Un mainteneur d’Immich a indiqué qu’un espace de l’ordre de 10 Go est généralement suffisant, selon les modèles choisis. Considérez cela comme une réserve de départ prudente plutôt que comme une exigence, puis remplacez-la par la taille réelle du cache de votre configuration une fois les premiers traitements ML terminés.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

La proportion de vidéos et le cache des clients peuvent fausser une estimation fondée uniquement sur les photos

L’estimation combinant vignettes et ML cesse de décrire correctement le stockage total lorsque la bibliothèque contient beaucoup de vidéos ou lorsque vous examinez l’espace de stockage local d’un appareil. La compatibilité vidéo peut générer d’importants dérivés côté serveur, tandis que les caches des téléphones et des navigateurs occupent un espace client qui ne fait pas partie du répertoire de vignettes ni du cache des modèles ML du serveur. Mélanger ces chiffres peut donner l’impression qu’une estimation normale des vignettes est totalement erronée.

Le témoignage d’un utilisateur disposant d’une grande bibliothèque illustre cette distinction : une bibliothèque d’environ 2,4 To contenant 179 000 photos et 19 000 vidéos faisait état de 822 Go de dérivés côté serveur pour les vignettes et les vidéos transcodées, tandis que l’application Android avait également accumulé plusieurs dizaines de gigaoctets en local. Il s’agit d’un exemple, et non d’une règle de dimensionnement, mais il montre comment les vidéos et la mise en cache côté client peuvent dominer un modèle simple fondé uniquement sur les photos.

Conservez les catégories séparées lors de vos mesures : données de vignettes et d’aperçus du serveur, vidéos encodées, cache des modèles ML, base de données et cache local des clients. Si l’espace occupé par les vignettes semble anormalement élevé, inspectez directement le répertoire des vignettes plutôt que l’ensemble de l’arborescence de données Immich. Si les vidéos encodées constituent le répertoire dominant, la question de planification n’est plus celle de la surcharge liée à l’indexation des photos, mais celle de la compatibilité vidéo et de la politique de transcodage.

Utilisez une formule fondée sur l’échantillonnage et la croissance pour le stockage familial

Utilisez trois données : le nombre d’octets de vignettes mesuré par ressource représentative, le nombre d’images prévu pour les une à deux prochaines années et la taille mesurée du cache des modèles ML. Multipliez les deux premières valeurs, ajoutez le cache des modèles, puis prévoyez une marge d’exploitation pour la régénération, les changements de paramètres et la croissance normale du système de fichiers. Une marge de 20 à 25 % constitue ici une heuristique de planification, et non une exigence d’Immich ; les utilisateurs disposant de disques presque pleins devraient mesurer plus fréquemment plutôt que supposer que cette marge sera toujours suffisante.

Un plafond prudent pour le cache des modèles peut partir de l’indication du mainteneur selon laquelle environ 10 Go devraient généralement suffire, selon le choix des modèles. Combinez cette valeur avec votre propre mesure des vignettes, et non avec le chiffre de 10 à 20 % correspondant aux vignettes et aux transcodages. Pour une empreinte de vignettes projetée de 72 Go, une réserve de 10 Go pour les modèles et une marge de 25 %, la réserve de planification serait d’environ 103 Go.

Recalculez l’estimation chaque fois qu’une variable déterminante change : résolution ou qualité des vignettes, changement important de résolution des appareils photo, autre modèle ML, forte croissance du volume vidéo ou augmentation substantielle du nombre de membres de la famille qui importent des ressources. Le seuil de décision est simple : si le stockage généré projeté, marge comprise, approche l’espace libre disponible sur le volume rapide prévu à cet effet, déplacez le chemin des dérivés, ajoutez de la capacité ou réduisez les paramètres de génération concernés avant que la bibliothèque n’atteigne ce seuil.