Immich non dispone di un rapporto affidabile per il solo spazio delle miniature, quindi le librerie familiari dovrebbero misurare i byte generati per risorsa e riservare spazio separato per i modelli ML.
Un archivio familiare di foto da 2 TB non indica quanto diventerà grande la directory delle miniature di Immich, perché il numero di risorse, la risoluzione originale, le impostazioni delle miniature, la quantità di video e i modelli abilitati modificano tutti lo spazio risultante. Il metodo più sicuro consiste nell'elaborare un campione rappresentativo, misurare separatamente miniature e cache dei modelli, prevedere la crescita della libreria e aggiungere un margine operativo, invece di considerare una singola percentuale come requisito universale.
Separare gli originali dallo spazio generato da Immich
Partite da una distinzione fondamentale: foto e video originali sono solo una parte dello spazio su disco necessario per supportare una libreria Immich. Il server conserva anche risorse generate per la consultazione e la compatibilità, mentre il servizio di machine learning conserva i file dei modelli scaricati nella propria cache. Queste categorie crescono per motivi diversi, quindi combinarle in un'unica percentuale generica rende difficile capire quale impostazione o carico di lavoro stia consumando effettivamente spazio.
Un riferimento della community di Immich, aggiornato nel tempo, segnala che miniature e video transcodificati insieme possono aggiungere in media circa il 10–20%. Questo dato è utile solo come contesto generale: combina due categorie generate e pertanto non deve essere presentato come rapporto relativo alle sole miniature. Una famiglia con molte foto e pochi video può ottenere un risultato molto diverso rispetto a un archivio ricco di video.
Anche l'architettura è importante per decidere dove collocare questo spazio aggiuntivo. L'analisi di ZimaSpace sull'organizzazione delle foto tramite IA considera l'indicizzazione e i dati generati come servizi a supporto della libreria originale, non come suoi sostituti. Nella pianificazione della capacità, mantenete separati gli originali, l'area di miniature/anteprime, i derivati video, il database e la cache ML, anche se condividono lo stesso disco fisico.
Misurare il costo delle miniature per risorsa prima di aumentare la scala
Scegliete un campione rappresentativo della libreria familiare invece dei primi mille file più facili da selezionare. Dovrebbe includere le diverse generazioni di telefoni, le risoluzioni delle fotocamere, i ritratti, le schermate, i panorami e gli altri tipi di immagini che compongono l'uso normale. Lasciate completare i processi relativi alle miniature, registrate il numero di risorse elaborate e misurate la directory delle miniature. Dividendo i byte misurati per il numero di risorse elaborate otterrete un rapporto locale utile per la pianificazione, che riflette già le impostazioni scelte per miniature e anteprime.
Le installazioni reali dimostrano perché questo rapporto locale sia importante. In una discussione su Immich sono stati segnalati 21 GB di miniature insieme a 58 GB di video codificati in quel particolare sistema. Il dato è aneddotico e non rappresenta un obiettivo, ma mostra che le cartelle derivate possono avere dimensioni molto diverse e devono essere misurate separatamente, invece di essere dedotte unicamente dai terabyte della libreria originale.
Per esempio, se 10.000 immagini rappresentative producono 12 GB di miniature e anteprime, il tasso osservato è di circa 1,2 MB per risorsa. Una libreria prevista di 60.000 immagini richiederebbe quindi circa 72 GB con le stesse impostazioni, prima del margine di crescita. Ripetete il campionamento dopo aver modificato la risoluzione o la qualità delle miniature, perché tali cambiamenti invalidano il vecchio rapporto per risorsa anche se i file originali non sono cambiati.
La cache dei modelli ML dipende più dai modelli che dal numero di foto
Lo spazio occupato dal machine learning si comporta in modo diverso da quello delle miniature. La cache dei modelli contiene principalmente file che il servizio ML scarica e riutilizza, quindi la sua dimensione dipende più dai modelli di ricerca intelligente e riconoscimento facciale selezionati che dal fatto che la libreria contenga 20.000 o 200.000 foto. Le dimensioni della libreria determinano la quantità di elaborazione, ma non richiedono una nuova copia del modello per ogni risorsa.
Una recente installazione Immich autogestita descrive una cache persistente dei modelli montata per il servizio di machine learning e segnala che i modelli utilizzati occupavano complessivamente meno di 1 GB. Si tratta di una configurazione specifica, non di una garanzia. Il meccanismo importante è la persistenza con riutilizzo: una volta presenti i file selezionati, la normale crescita del numero di foto non moltiplica i file binari dei modelli.
Per un server familiare che potrebbe cambiare modello in futuro, è ragionevole prevedere una disponibilità maggiore rispetto alla cache minima osservata al momento. Un manutentore di Immich ha suggerito che, in generale, circa 10 GB siano sufficienti, a seconda dei modelli scelti. Consideratelo un margine iniziale prudente, non un requisito, e sostituitelo con le dimensioni effettive della cache della configurazione in uso dopo il completamento dei primi processi ML.
La quantità di video e la cache dei client possono rendere inutilizzabile una stima basata solo sulle foto
La stima basata su miniature più ML smette di descrivere adeguatamente lo spazio totale quando la libreria contiene molti video o quando si considera lo spazio locale dell'app sul dispositivo. La compatibilità video può creare grandi derivati sul server, mentre le cache di telefoni e browser occupano spazio sui client che non fa parte della directory delle miniature del server né della cache dei modelli ML. Mescolare questi valori può far sembrare enormemente errata una normale stima delle miniature.
Una segnalazione relativa a una libreria di grandi dimensioni mostra bene il confine: una libreria di circa 2,4 TB con 179.000 foto e 19.000 video riportava 822 GB di derivati sul server per miniature e video transcodificati, mentre l'app Android aveva accumulato localmente anche decine di gigabyte. È un dato aneddotico, non una regola di dimensionamento, ma mostra come video e cache dei client possano dominare un modello semplice basato solo sulle foto.
Mantenete separate le categorie durante la misurazione: dati delle miniature/anteprime sul server, video codificati, cache dei modelli ML, database e cache locale dei client. Se lo spazio delle miniature sembra insolitamente elevato, controllate direttamente la directory delle miniature invece dell'intero albero dei dati di Immich. Se la cartella dominante è quella dei video codificati, la domanda di pianificazione è cambiata: non riguarda più l'overhead dell'indicizzazione delle foto, ma la compatibilità video e i criteri di transcodifica.
Usare una formula basata su campionamento e crescita per lo spazio familiare
Utilizzate tre dati: i byte misurati delle miniature per risorsa rappresentativa, il numero di immagini previsto per i prossimi uno o due anni e le dimensioni misurate della cache dei modelli ML. Moltiplicate i primi due valori, aggiungete la cache dei modelli e poi un margine operativo per la rigenerazione, le modifiche alle impostazioni e la normale crescita del file system. Un margine del 20–25% è qui un'euristica di pianificazione, non un requisito di Immich; chi dispone di dischi con poco spazio libero dovrebbe misurare più spesso invece di presumere che il margine sia sempre sufficiente.
Un limite prudenziale per la cache dei modelli può partire dall'indicazione del manutentore secondo cui circa 10 GB dovrebbero generalmente bastare, a seconda del modello scelto. Combinate questo valore con la misurazione effettiva delle miniature, non con la percentuale del 10–20% relativa a miniature e transcodifiche insieme. Per una previsione di 72 GB per le miniature, un margine di 10 GB per i modelli e un cuscinetto del 25%, la riserva pianificata sarebbe di circa 103 GB.
Ricalcolate la stima quando cambia una qualsiasi variabile che la determina: risoluzione o qualità delle miniature, un cambiamento significativo nella risoluzione delle fotocamere, un modello ML diverso, una forte crescita dei video o un aumento sostanziale dei familiari che caricano risorse. La soglia decisionale è semplice: se lo spazio generato previsto più il margine si avvicina allo spazio libero disponibile sul volume veloce destinato a questo scopo, spostate il percorso dei derivati, aggiungete capacità o riducete le relative impostazioni di generazione prima che la libreria raggiunga quel punto.
Hub Tecnologico e AI
Altro da leggere

I modelli open stanno raggiungendo l’IA all’avanguardia: il 2026 sarà l’anno in cui l’IA locale diventerà abbastanza valida?
I modelli open stanno diventando abbastanza validi per un numero crescente di carichi di lavoro di IA locali, mentre i modelli cloud di frontiera...

NVIDIA PAIR trasforma la tua rete domestica in un cluster AI locale: ti serve ancora un unico grande server con GPU?
NVIDIA PAIR distribuisce le richieste di IA locale su più PC, rendendo la potenza di calcolo più elastica, mentre un server domestico può mantenere...

Perché Immich sembra più veloce sulla LAN rispetto alle connessioni remote?
Le richieste sulla LAN seguono generalmente un percorso più breve e con una latenza inferiore. L’accesso remoto introduce i limiti di capacità della WAN...

