Hoeveel opslagruimte voor miniaturen en machine learning heeft Immich nodig voor het maken van back-ups van familiefoto’s?

Immich heeft geen betrouwbare opslagverhouding voor alleen miniaturen. Daarom moeten gezinsbibliotheken het aantal gegenereerde bytes per item meten en afzonderlijke ruimte reserveren voor ML-modellen.

Een fotoarchief van 2 TB vertelt niet hoe groot de map met Immich-miniaturen zal worden, omdat het aantal items, de bronresolutie, de instellingen voor miniaturen, de videomix en de ingeschakelde modellen allemaal van invloed zijn op de uiteindelijke omvang. De veiligste methode voor capaciteitsplanning is om een representatief voorbeeld te verwerken, miniaturen en de modelcache afzonderlijk te meten, de groei van de bibliotheek te voorspellen en vervolgens operationele reserve toe te voegen, in plaats van één percentage als universele vereiste te beschouwen.

Houd originelen en door Immich gegenereerde opslag gescheiden

Begin met een duidelijke afbakening: originele foto's en video's vormen slechts één deel van de schijfruimte die een Immich-bibliotheek ondersteunt. De server bewaart ook gegenereerde bestanden voor bladeren en compatibiliteit, terwijl de machinelearningservice gedownloade modelbestanden in een eigen cache bewaart. Deze categorieën groeien om verschillende redenen. Door ze samen te voegen tot één vaag percentage wordt het moeilijk te zien welke instelling of werklast daadwerkelijk ruimte inneemt.

Een langdurig gebruikte referentie voor Immich-capaciteitsplanning vanuit de community vermeldt dat miniaturen en getranscodeerde video samen gemiddeld ongeveer 10–20% kunnen toevoegen. Dat cijfer is alleen bruikbaar als algemene context: het combineert twee gegenereerde categorieën en mag daarom niet worden gepresenteerd als een verhouding voor alleen miniaturen. Een gezinsbibliotheek met vooral foto's en weinig video kan heel anders uitkomen dan een archief met veel video.

De architectuur is ook belangrijk bij de beslissing waar je die extra ruimte plaatst. ZimaSpace beschrijft in zijn artikel over AI-fotobeheer indexering en gegenereerde gegevens als diensten rond de oorspronkelijke bibliotheek, niet als vervanging daarvan. Houd voor capaciteitsplanning de originelen, miniaturen/voorbeelden, videoderivaten, database en ML-cache als afzonderlijke posten bij, ook als ze dezelfde fysieke schijf gebruiken.

Meet de kosten van miniaturen per item voordat je opschaalt

Kies een representatief deel van de gezinsbibliotheek in plaats van de eenvoudigste duizend bestanden. Het moet de verschillende generaties telefoons, cameraresoluties, portretten, schermafbeeldingen, panorama's en andere afbeeldingstypen bevatten die normaal gebruik kenmerken. Laat taken die met miniaturen te maken hebben voltooien, noteer het aantal verwerkte items en meet de map met miniaturen. Door het gemeten aantal bytes te delen door het aantal verwerkte items krijg je een lokale planningsverhouding die al rekening houdt met de gekozen instellingen voor miniaturen en voorbeelden.

Praktijkinstallaties laten zien waarom die lokale verhouding belangrijk is. In één Immich-discussie werd 21 GB aan miniaturen gemeld naast 58 GB aan gecodeerde video in die specifieke installatie. Het getal is anekdotisch en geen doelwaarde, maar het laat zien dat gegenereerde mappen aanzienlijk verschillende groottes kunnen hebben en afzonderlijk moeten worden gemeten, in plaats van alleen uit de terabytes van de oorspronkelijke bibliotheek te worden afgeleid.

Als bijvoorbeeld 10.000 representatieve afbeeldingen 12 GB aan miniaturen en voorbeelden opleveren, is je gemeten verhouding ongeveer 1,2 MB per item. Een bibliotheek met naar verwachting 60.000 afbeeldingen zou bij dezelfde instellingen dus ongeveer 72 GB nodig hebben, nog vóór een groeimarge wordt toegevoegd. Herhaal het voorbeeld nadat je de resolutie of kwaliteit van de miniaturen hebt gewijzigd, want zulke wijzigingen maken de oude verhouding per item ongeldig, ook al zijn de oorspronkelijke bestanden niet veranderd.

De ML-modelcache hangt meer van modellen dan van het aantal foto's af

Machinelearningopslag werkt anders dan miniaturen. De modelcache bevat voornamelijk modelbestanden die de ML-service downloadt en hergebruikt. De omvang wordt daarom vooral bepaald door de gekozen modellen voor slim zoeken en gezichtsherkenning, en niet door de vraag of de bibliotheek 20.000 of 200.000 foto's bevat. De omvang van de bibliotheek bepaalt hoeveel verwerking plaatsvindt, maar voor elk item is geen nieuwe kopie van het model nodig.

Een recente zelf gehoste Immich-installatie beschrijft een permanente modelcache die aan de machinelearningservice is gekoppeld en meldt dat de daar gebruikte modellen in totaal minder dan 1 GB in beslag namen. Dat is één configuratie en geen garantie. Het belangrijke mechanisme is persistentie en hergebruik: zodra de geselecteerde bestanden aanwezig zijn, vermenigvuldigt normale groei van het aantal foto's de modelbinaries niet.

Voor een gezinsserver die later mogelijk van model wisselt, is een ruimere planningsmarge verstandig dan de kleinste momenteel gemeten cache. Een Immich-onderhouder heeft aangegeven dat doorgaans ongeveer 10 GB opslag voldoende is, afhankelijk van de modelkeuze. Beschouw dat als een conservatieve beginmarge en niet als een vereiste. Vervang die vervolgens door de werkelijke cachegrootte van je actieve configuratie nadat de eerste ML-taken zijn voltooid.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

De videomix en clientcaches kunnen een schatting voor alleen foto's verstoren

De schatting voor miniaturen plus ML is geen bruikbare beschrijving van de totale opslag meer wanneer de bibliotheek veel video bevat of wanneer je naar lokale opslag van apparaten kijkt. Compatibiliteit voor video kan grote server-side afgeleide bestanden maken, terwijl caches op telefoons en in browsers clientopslag innemen die geen deel uitmaakt van de servermap met miniaturen of de ML-modelcache. Door die cijfers te combineren kan een normale schatting voor miniaturen veel te hoog lijken.

Een gebruikersrapport over een grote bibliotheek illustreert die grens: bij een bibliotheek van ongeveer 2,4 TB met 179.000 foto's en 19.000 video's werd 822 GB aan serverderivaten voor miniaturen en getranscodeerde video gemeld, terwijl de Android-app lokaal ook tientallen gigabytes verzamelde. Dit is een anekdote en geen capaciteitsregel, maar het laat zien hoe video en clientcaches een eenvoudig model voor alleen foto's kunnen overheersen.

Houd de categorieën bij het meten gescheiden: servergegevens voor miniaturen/voorbeelden, gecodeerde video, ML-modelcache, database en lokale clientcache. Als de opslag voor miniaturen onverwacht groot lijkt, controleer dan de map met miniaturen zelf en niet de volledige Immich-gegevensstructuur. Als gecodeerde video de grootste map is, is de relevante planningsvraag veranderd van overhead voor foto-indexering naar videocompatibiliteit en het transcoderingsbeleid.

Gebruik een formule op basis van steekproef en groei voor gezinsopslag

Gebruik drie invoerwaarden: het gemeten aantal bytes aan miniaturen per representatief item, het verwachte aantal afbeeldingen in de komende één tot twee jaar en de gemeten omvang van de ML-modelcache. Vermenigvuldig de eerste twee, tel de modelcache erbij op en voeg vervolgens een operationele buffer toe voor opnieuw genereren, wijzigingen in instellingen en normale groei van het bestandssysteem. Een buffer van 20–25% is hier een planningsrichtlijn en geen vereiste van Immich; gebruikers met weinig schijfruimte moeten vaker meten in plaats van ervan uit te gaan dat de buffer altijd voldoende is.

Een conservatieve bovengrens voor de modelcache kan beginnen bij de richtlijn van de onderhouder dat ongeveer 10 GB doorgaans voldoende moet zijn, afhankelijk van de modelkeuze. Combineer dat met je eigen meting van miniaturen, niet met het cijfer van 10–20% voor miniaturen plus transcoderingen. Bij een verwachte opslag voor miniaturen van 72 GB, een modelmarge van 10 GB en een buffer van 25% komt de geplande reserve uit op ongeveer 103 GB.

Bereken opnieuw wanneer een variabele verandert die de schatting beïnvloedt: de resolutie of kwaliteit van miniaturen, een grote verschuiving in cameraresolutie, een ander ML-model, sterke groei van video of een aanzienlijke toename van het aantal gezinsleden dat bestanden uploadt. De beslisdrempel is eenvoudig: als de verwachte gegenereerde opslag plus buffer de beschikbare vrije ruimte op het beoogde snelle volume begint te benaderen, verplaats dan het pad voor afgeleide bestanden, voeg capaciteit toe of verlaag de relevante instellingen voor het genereren ervan voordat de bibliotheek dat punt bereikt.