Quanta RAM e spazio su disco richiede Immich?

Quanta RAM richiede Immich?

Immich richiede 6 GB di RAM (memoria ad accesso casuale) come minimo documentato e 8 GB come quantità consigliata, con 2 core CPU nella configurazione minima e 4 per un'installazione con prestazioni adeguate. Questo valore riguarda l'intero stack, perché Immich è composto da quattro container, non da una sola applicazione. Consultare una libreria già importata richiede poche risorse. La memoria viene utilizzata durante l'importazione e, per la maggior parte, da un container che è possibile disattivare.

[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

Questi sono i valori pubblicati nella pagina dei requisiti di Immich ad agosto 2026. Sono indicazioni per il dimensionamento, non un controllo eseguito dal software all'avvio. Immich si avvia anche con una quantità inferiore. Su un server più piccolo cambia il numero di processi in background che terminano correttamente e il comportamento dell'importazione quando la memoria si esaurisce.

Esiste un limite rigido effettivo. Immich versione 3 e successive richiede una x86-64-v2 sui server amd64, una condizione soddisfatta dalla maggior parte dei processori venduti dal 2012 circa. Sull'hardware più vecchio il container non si avvia, invece di funzionare più lentamente.

Se non hai ancora eseguito l'installazione, inizia da l'installazione completa di Immich su un VPS con Docker Compose e torna qui per dimensionare il server.

Dove viene usata la memoria: quattro container

Il file Compose ufficiale avvia quattro servizi. Ognuno ha un profilo di utilizzo della memoria diverso, quindi un unico totale nasconde il dato utile.

immich-server fornisce l'interfaccia web e l'API e avvia anche i worker per i processi in background. Due worker risiedono nello stesso container. api gestisce le richieste dal browser e dall'app mobile. microservices gestisce le code, inclusi la generazione delle miniature e la codifica video. Le variabili IMMICH_WORKERS_INCLUDE e IMMICH_WORKERS_EXCLUDE separano questi due componenti in container distinti. In questo modo puoi assegnare un limite di memoria separato al componente più impegnativo, senza limitare quello che serve le tue foto.

database è un'immagine PostgreSQL 14 con l'estensione VectorChord integrata. Contiene tutti i metadati e un vettore di ricerca per ogni risorsa. La documentazione di Immich indica per questo servizio l'unico limite minimo esplicito dello stack: se applichi limiti alle risorse Docker, il database richiede almeno 2 GB. La stessa pagina specifica che il database deve risiedere su storage SSD locale e mai su una condivisione di rete, perché le ricerche nei vettori e negli indici sono piccole letture casuali; un volume di rete trasforma quindi ogni operazione in un viaggio di andata e ritorno. Se la scelta del piano dipende da questo aspetto, la differenza tra storage NVMe e SSD SATA su un VPS è più importante qui che in qualsiasi altro componente dello stack.

redis esegue l'immagine Valkey e contiene le code dei job. È di gran lunga il più piccolo dei quattro, perché memorizza i record dei job e non i dati delle foto.

immich-machine-learning è il servizio che determina la dimensione del piano. Carica i modelli per la ricerca intelligente, il rilevamento dei volti e il riconoscimento del testo, e un modello caricato resta residente in memoria. MACHINE_LEARNING_MODEL_TTL ha il valore predefinito 300, quindi un modello viene rimosso dopo cinque minuti senza richieste e riletto dal volume /cache alla richiesta successiva. Durante un'importazione massiva non si verifica mai un intervallo di cinque minuti, quindi i modelli restano caricati dalla prima risorsa all'ultima.

Cosa cambia durante un'importazione

Quando è inattivo, Immich usa poche risorse. Le importazioni possono mandare in crisi i server di piccole dimensioni, perché il caricamento di un singolo asset accoda una catena di job e diverse code vengono eseguite contemporaneamente.

L'estrazione dei metadati legge l'header del file e richiede poche risorse. La generazione delle miniature è più pesante. Immich produce tre miniature per ogni asset: un segnaposto thumbhash sfocato, un'anteprima WebP e una miniatura JPEG, oltre a una miniatura aggiuntiva per ogni volto rilevato. Ognuno di questi job decodifica un'immagine e la concorrenza dei job determina quante immagini vengono decodificate contemporaneamente. La concorrenza è il moltiplicatore che trasforma un costo ridotto per job in un carico esteso a tutto il server. Per questo la FAQ di Immich indica la concorrenza come il primo parametro da ridurre su una macchina con risorse limitate. Imposta a 1 la concorrenza delle code più pesanti in Administration, Settings, Job Settings.

Gli asset video aggiungono la transcodifica. Ogni job di transcodifica è un processo FFmpeg separato, con la propria memoria, e utilizza tutti i thread della CPU che gli consenti di usare.

Smart search invia ogni nuovo asset al container di machine learning per calcolare un vettore di embedding. Il rilevamento dei volti esegue un secondo modello sulla stessa immagine. Durante la prima importazione di una libreria di foto esistente, entrambe le code elaborano ogni asset disponibile per ore. Questo è il momento in cui il consumo di memoria raggiunge il valore massimo nell'intera installazione, e si verifica una sola volta.

Perché il riconoscimento dei volti e degli oggetti richiede più RAM

La gestione dei volti comprende due attività. Il rilevamento dei volti esegue un modello nel container di machine learning e individua i riquadri. Il riconoscimento facciale raggruppa quindi questi rilevamenti associandoli alle persone e, durante questa fase, interroga l'indice vettoriale in Postgres. Una libreria di grandi dimensioni sollecita quindi entrambi i servizi in sequenza: prima il container del modello durante il rilevamento, poi il database durante il raggruppamento.

Quattro impostazioni modificano il contenuto del container di machine learning.

• Il modello dei volti. Immich include buffalo_l per impostazione predefinita e la FAQ consiglia buffalo_s sui server di dimensioni ridotte. È un modello più piccolo, quindi occupa meno memoria ed è più veloce, ma può essere meno accurato sui volti piccoli o ripresi di profilo.
• Il numero di worker. MACHINE_LEARNING_WORKERS ha come valore predefinito 1. Ogni worker è un processo separato che carica una propria copia dei modelli; portarlo a 2 raddoppia circa la memoria residente dei modelli. Lascialo impostato su 1, a meno che non disponga di RAM sufficiente.
• La dimensione del batch. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION limita il numero di volti elaborati contemporaneamente. Un batch viene mantenuto interamente in memoria, quindi una foto di gruppo con quaranta volti richiede più memoria di un ritratto.
• I tipi di modello effettivamente utilizzati. La ricerca intelligente, il rilevamento dei volti e il riconoscimento del testo caricano ciascuno i propri modelli. Disattivando quelli che non utilizzi, in Administration, Settings, Machine Learning Settings, la memoria viene liberata in modo permanente e non soltanto tra un'importazione e l'altra.

È disponibile anche MACHINE_LEARNING_MODEL_ARENA, documentato come impostazione che prealloca la memoria della CPU per evitare la frammentazione e attiva per impostazione predefinita. Modificala per ultima. Il suo effetto dipende dall'allocatore di memoria sottostante; l'unico modo affidabile per valutarlo è monitorare docker stats prima e dopo la modifica.

Tre profili pratici: 2 GB, 4 GB e 8 GB

[
  {
    "label": "2 GB VPS",
    "server_limit_mb": 768,
    "db_limit_mb": 768,
    "ml_limit_mb": 0,
    "redis_limit_mb": 128,
    "notes": "machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 1280,
    "ml_limit_mb": 1024,
    "redis_limit_mb": 192,
    "notes": "machine learning on, job concurrency 1, buffalo_s"
  },
  {
    "label": "8 GB VPS",
    "server_limit_mb": 2048,
    "db_limit_mb": 2048,
    "ml_limit_mb": 2560,
    "redis_limit_mb": 256,
    "notes": "everything on at default settings"
  }
]

Considerali limiti da impostare in Compose, non misure delle risorse utilizzate da Immich. Un limite è un tetto massimo. Non riserva memoria e non riduce le dimensioni di un servizio. Stabilisce quale servizio il kernel terminerà quando il server esaurisce la memoria. È una decisione che conviene prendere esplicitamente, invece di lasciarla al criterio di selezione del kernel.

Il server da 2 GB: rimuovere il container di machine learning

2 GB sono inferiori al minimo documentato di 6 GB. Si tratta quindi di un compromesso, che va considerato come tale. Commenta l'intero servizio immich-machine-learning in docker-compose.yml oppure lascialo in esecuzione e disabilita tutti i modelli da Administration, Settings, Machine Learning Settings. Rimuovere il container è l'opzione più efficace, perché un modello disabilitato lascia comunque residente un processo Python.

Conservi caricamenti, album, condivisione, backup da dispositivi mobili, miniature e ricerca per data, luogo e nome file. Rinunci alla ricerca per descrizione, al raggruppamento automatico dei volti in persone e al riconoscimento del testo nelle immagini.

I quattro limiti ammontano a circa 1.7 GB e lasciano all'host circa 300 MB. Nota che 768 MB per il database sono inferiori alla soglia documentata di 2 GB. Questo è esattamente il compromesso imposto da 2 GB e spiega perché Postgres sia il servizio con maggiore probabilità di essere terminato.

Il primo problema riguarda l'importazione, non la consultazione. Una libreria con alcune decine di migliaia di foto viene consultata in modo accettabile dopo l'importazione, perché la visualizzazione di una pagina consiste in una query sui metadati e nella lettura di un file. Sullo stesso server, un'importazione con molti video provocherà l'uso della swap, perché transcodifica e coda delle miniature richiedono memoria nello stesso momento. Imposta la concorrenza di ogni coda pesante su 1 e aggiungi un file di swap.

Il server da 4 GB: machine learning attivo, un'attività alla volta

4 GB sono la configurazione minima in cui vale la pena attivare il riconoscimento di volti e oggetti. Limita il container di machine learning a 0 MB, imposta il riconoscimento facciale su buffalo_s e configura la concorrenza dei processi su 1 per la generazione delle miniature, il rilevamento dei volti e la ricerca intelligente.

La prima elaborazione di una libreria esistente richiederà molte ore e, per una libreria grande, più di un giorno. Il limite principale è la CPU, non la memoria. Aumentare la RAM non ridurrà quindi la durata dell'elaborazione.

In questo caso, il primo problema riguarda il container di machine learning durante la prima elaborazione completa. Senza un limite, il container cresce mentre cresce anche un'attività di transcodifica e il kernel termina quello dei due processi che occupa più memoria. In docker ps -a vedrai Exited (137) e un container riavviato. Quando controllerai di nuovo, la coda sarà rimasta indietro senza segnalarlo chiaramente.

Il server da 8 GB: la configurazione raccomandata nella documentazione

8 GB con 4 core corrispondono alla configurazione raccomandata da Immich. Tutto può funzionare con le impostazioni predefinite: ricerca intelligente, rilevamento dei volti, riconoscimento del testo e transcodifica, con la concorrenza predefinita. Le librerie con più di centomila elementi funzionano senza problemi particolari. Il collo di bottiglia si sposta dalla memoria alla velocità del disco, perché per tutto il giorno il database gestisce l'indice vettoriale e le query sui metadati.

Imposta comunque i limiti. Su un server con risorse disponibili, i limiti impediscono a una coda fuori controllo di causare l'arresto del database. Se stai confrontando il costo con le opzioni più piccole, quanto costa davvero un VPS in base alla quantità di memoria rende spesso il piano da 8 GB il modo più economico per evitare continue regolazioni.

Come impostare un limite di memoria per servizio con i limiti di Compose

Non modificare docker-compose.yml. Quel file viene sostituito ogni volta che esegui l'upgrade con wget. Inserisci i limiti in docker-compose.override.yml, accanto a quel file. docker compose li unisce automaticamente.

services:
  immich-server:
    deploy:
      resources:
        limits:
          memory: 1024M
  immich-machine-learning:
    deploy:
      resources:
        limits:
          memory: 1024M
          cpus: '1.5'
  database:
    deploy:
      resources:
        limits:
          memory: 1280M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

docker stats dovrebbe ora mostrare il limite configurato nella colonna MEM USAGE / LIMIT, invece della memoria totale dell'host. Se la colonna del limite mostra ancora la dimensione completa dell'host, il file di override non è stato acquisito. Controlla il nome del file ed esegui docker compose config per visualizzare il risultato unito.

Un limite troppo basso trasforma un servizio lento in un servizio non operativo. Aumentalo se un container entra in un ciclo continuo di riavvii. Per ulteriori informazioni sul funzionamento, consulta impostazione dei limiti di memoria per servizio in Docker Compose, inclusa la spiegazione del motivo per cui deploy funziona al di fuori di Swarm con Compose v2.

Come disattivare o spostare il container di machine learning

Su un server di piccole dimensioni, spostare questo container altrove è la modifica più importante che si possa fare. Immich supporta l'esecuzione del container su un altro computer. Crea questo file sul secondo host, che può essere un desktop acceso soltanto la sera:

name: immich_remote_ml
services:
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    restart: always
    ports:
      - 3003:3003
volumes:
  model-cache:

docker compose up -d
curl -s http://localhost:3003/ping

Quindi apri Amministrazione, Impostazioni, Impostazioni di machine learning nell'interfaccia web, fai clic su Aggiungi URL e inserisci http://<host>:3003. Mantieni la stessa versione su entrambi gli host, perché la documentazione di Immich avverte che versioni diverse possono causare bug e instabilità.

Quella porta trasmette le tue foto all'altro computer senza cifratura. Mantienila quindi su una rete privata oppure usala tramite un tunnel WireGuard tra i due host. Non esporre mai la porta 3003 a Internet.

Se il problema è la presenza permanente di un container per i modelli, è anche ragionevole confrontare le differenze tra PhotoPrism e Immich rispetto ai componenti eseguiti a riposo prima di scegliere un piano.

Quanto spazio su disco richiede una libreria Immich?

Non esiste un unico moltiplicatore, perché quattro componenti diverse crescono a ritmi diversi. Ecco il calcolo per una libreria con 50,000 foto e 500 video brevi.

[
  {
    "label": "Originals: 50,000 photos at 4 MB",
    "gb": 200
  },
  {
    "label": "Originals: 500 videos at 120 MB",
    "gb": 60
  },
  {
    "label": "Thumbnails and encoded video at 15%",
    "gb": 39
  },
  {
    "label": "Postgres database",
    "gb": 3
  },
  {
    "label": "Machine learning model cache",
    "gb": 2
  }
]

I 200 GB di foto e i 60 GB di video sono ipotesi. Sostituiscili con le tue medie prima di acquistare l’hardware, perché sono i video a determinare questo valore: un minuto di video registrato con il telefono occupa più spazio di cento foto.

find /srv/immich/upload -type f -printf '%s\n' \
  | awk '{n++; s+=$1} END {printf "%d files, %.1f MB average\n", n, s/n/1048576}'

La riga 39 GB è l’unico rapporto pubblicato da Immich: le miniature generate e i video transcodificati aggiungono in media dal 10 al 20 percento alle dimensioni della libreria. Si tratta di un intervallo perché dipende dalla quantità di risorse video che devono essere ricodificate per garantire la compatibilità con il browser. Una libreria composta da file JPEG si avvicina al limite inferiore dell’intervallo.

Il database occupa 3 GB, un costo quasi fisso. Immich indica in genere da 1 a 3 GB per i file del database, perché contengono metadati e vettori di ricerca, non pixel. La cache dei modelli occupa 2 GB e cresce se abiliti più modelli o ne provi di diversi. Le FAQ indicano questo volume come una voce che può consumare spazio proprio per questo motivo.

Le cinque righe totalizzano poco più di 300 GB, quindi un volume da 500 GB lascia spazio per la crescita, mentre uno da 250 GB non è sufficiente. Controlla la suddivisione con:

grep UPLOAD_LOCATION .env
du -sh /srv/immich/*

Sei directory si trovano sotto UPLOAD_LOCATION. upload e library contengono gli originali, thumbs contiene le anteprime e le miniature dei volti, encoded-video contiene le copie ricodificate, profile contiene gli avatar e backups contiene i dump automatici del database. Solo upload, library e profile sono insostituibili, perché tutto il resto può essere rigenerato a partire da questi dati.

Due aspetti sorprendono spesso gli utenti. Le risorse eliminate vengono prima spostate nel cestino e continuano a occupare spazio finché il cestino non viene svuotato, quindi una pulizia significativa non libera spazio il giorno stesso in cui la esegui. Inoltre, un dump del database contiene solo metadati, quindi è inutilizzabile senza i file:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

Affianca a questo una copia a livello di file degli originali in una posizione esterna al server, che è lo scopo dei backup restic da un VPS verso uno storage esterno.

La transcodifica usa la CPU, non la RAM

Aggiungere RAM non rende più veloce la transcodifica. Immich usa FFmpeg e, su un VPS senza accelerazione hardware, ogni fotogramma viene decodificato e codificato dalla CPU. Anche quando l'accelerazione hardware è disponibile, la documentazione di Immich specifica che viene accelerata soltanto la codifica. La CPU continua quindi a occuparsi della decodifica software e del tone mapping.

L'accelerazione hardware richiede il file Compose aggiuntivo hwaccel.transcoding.yml e un dispositivo da esporre al container, usando NVENC, Quick Sync, RKMPP o VAAPI. La maggior parte dei piani VPS non fornisce nessuna di queste opzioni. È quindi necessario pianificare l'uso della CPU.

L'impostazione più importante è il numero di thread. In Administration, Settings, Video Transcoding Settings, un valore di 0 indica l'uso di tutti i core. Su un piano con 2 core, questo può bloccare l'interfaccia web mentre viene elaborato un solo video. Impostare invece il valore su 1 o 2, come suggerito dalle FAQ di Immich. La transcodifica sarà più lenta, ma non interferirà con il servizio.

Perché un'importazione con swap in thrashing sembra bloccata

Questo è il problema che viene interpretato più spesso in modo errato. Quando Immich esaurisce la memoria, si verificano due possibili esiti e solo uno sembra un errore.

Senza swap, il kernel termina un processo. Il container si riavvia entro pochi secondi. Nel browser, quindi, la coda dei job si arresta temporaneamente e poi riprende. Le prove sono in docker ps -a:

docker ps -a --filter name=immich
docker inspect immich_machine_learning | grep -i oomkilled
sudo dmesg -T | grep -i -E 'out of memory|oom-kill'

Exited (137) indica che il processo è stato terminato con il signal 9. 137 è la somma di 128 e 9. Un valore OOMKilled di true conferma che il processo è stato terminato per esaurimento della memoria e non a causa di un crash.

Con lo swap, non viene terminato alcun processo e non si verifica alcun errore. Il kernel inizia a spostare le pagine sul disco, l'importazione rallenta di un ordine di grandezza e l'interfaccia web smette di rispondere entro il normale timeout. Tutti i container sono in esecuzione. Tutti gli health check possono continuare ad avere esito positivo. Sembra un blocco e a questo punto molte persone riavviano il server, perdendo l'avanzamento della coda senza risolvere il problema.

free -m
vmstat 1 5

Valori diversi da zero mantenuti nelle colonne si e so di vmstat indicano che la macchina legge e scrive continuamente nello swap: questa è la definizione di thrashing. Nello stesso momento aumenterà anche la riga free -m relativa a Swap used.

Aggiungi comunque lo swap su un server con 2 GB o 4 GB di RAM, perché un'importazione lenta che puoi diagnosticare è preferibile a un container terminato che non puoi diagnosticare:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Poi risolvi la causa. Riduci la concorrenza dei job a 1, limita il container di machine learning oppure spostalo su un altro host. Lo swap ti dà il tempo necessario per farlo. Da solo non è la soluzione.

FAQ

Posso eseguire Immich su un VPS da 2 GB?

Sì, con il servizio immich-machine-learning commentato in docker-compose.yml e la concorrenza dei job impostata su 1. Questo valore è inferiore al minimo documentato di 6 GB, quindi va considerato un compromesso noto. Restano disponibili caricamenti, album, condivisione, backup da dispositivi mobili e ricerca per data, luogo e nome file. Non sono invece disponibili la ricerca per descrizione, il raggruppamento automatico dei volti nelle persone e il riconoscimento del testo nelle immagini. Aggiungete un file di swap da 2 GB, così un picco durante l'importazione rallenta il server invece di causare l'arresto di un container.

Perché l'importazione di Immich si interrompe senza mostrare messaggi di errore?

Dal browser, due cause diverse producono lo stesso risultato. Un container può essere stato terminato per esaurimento della memoria: in questo caso docker ps -a mostra Exited (137) e il container è già stato riavviato. In alternativa, l'host può usare lo swap: tutti i container sono ancora in esecuzione, ma il sistema è semplicemente molto lento. vmstat 1 5 consente di distinguerle: valori diversi da zero mantenuti nelle colonne si e so indicano l'uso dello swap. In entrambi i casi, riducete la concorrenza dei job per la generazione delle miniature, il rilevamento dei volti e la ricerca intelligente.

Che cosa indica il codice di uscita 137 nei log di Immich?

137 è 128 più il segnale 9, quindi il processo è stato terminato con SIGKILL. In pratica, significa che è stato raggiunto un limite di memoria: quello del container oppure quello dell'host, che ha esaurito la memoria disponibile. Verificate con docker inspect immich_machine_learning | grep -i oomkilled. Un valore di true conferma che il kernel lo ha terminato per mancanza di memoria; free -m e sudo dmesg -T | grep -i oom-kill indicano poi se il problema riguardava il limite del container o l'intero host. Il container di machine learning è generalmente quello interessato, perché di solito contiene il processo più grande.

Quanto spazio su disco serve a Immich per ogni foto?

Considerate il file originale più una quota aggiuntiva dal 10 al 20 percento. La documentazione di Immich indica che le miniature generate e i video transcodificati aumentano in media le dimensioni della libreria dal 10 al 20 percento; anche il database occupa in genere da 1 a 3 GB, persino per una libreria di grandi dimensioni. A determinare il totale è soprattutto la quantità di video. Prima di scegliere un piano, misurate quindi la dimensione media dei vostri file invece di applicare un moltiplicatore al numero di foto.

Serve una GPU per Immich?

No. Ogni componente di Immich può essere eseguito sulla CPU. Una scheda grafica accelera l'inferenza dei modelli nel container di machine learning e la codifica video, ma nessuna delle due è necessaria. La maggior parte dei piani VPS non offre una GPU. Su hardware con sola CPU, impostate a 1 o 2 i thread per la transcodifica, usate il modello facciale buffalo_s e lasciate eseguire la prima importazione completa durante la notte.