Quanta RAM e disco o Immich precisa?

Quanta RAM o Immich precisa?

O Immich requer 6 GB de RAM (memória de acesso aleatório) como mínimo documentado e 8 GB como recomendação, com 2 núcleos de CPU no limite inferior e 4 para uma instalação confortável. Esse valor abrange toda a stack, porque o Immich é composto por quatro contentores, e não por uma única aplicação. Consultar uma biblioteca que já foi importada consome poucos recursos. A memória é usada durante a importação, sobretudo por um contentor que pode ser desligado.

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

Estes são os valores publicados na página de requisitos do Immich em outubro de 2026. São recomendações de dimensionamento, não uma verificação que o software faça no arranque. A mesma página documenta uma configuração mais pequena, com 4 GB e as funcionalidades de machine learning desativadas, e não apresenta nenhum valor inferior. Num servidor mais pequeno, o que muda é a quantidade de tarefas em segundo plano que termina e o comportamento da importação quando a memória se esgota.

Existe um limite rígido concreto. Desde a versão 3, o contentor de machine learning em hosts amd64 precisa de uma CPU x86-64-v2, presente na maioria dos processadores vendidos desde aproximadamente 2012. Este requisito aplica-se ao contentor, não ao servidor. Em hardware mais antigo, pode desativar o machine learning, executá-lo noutra máquina conforme descrito abaixo ou permanecer na v2.7.5, que a documentação do Immich identifica como a última versão compatível.

Se ainda não iniciou a instalação, comece por a instalação completa do Immich numa VPS com Docker Compose e volte aqui para dimensionar o servidor.

Para onde vai a memória: quatro containers

O ficheiro Compose oficial inicia quatro serviços. Cada um tem uma configuração de memória diferente, por isso um número total esconde a parte útil.

immich-server serve a interface web e a API, e também executa os workers de tarefas em segundo plano. Dois workers vivem dentro desse único container. api responde a pedidos do browser e da aplicação móvel. microservices executa as filas, incluindo a geração de miniaturas e a codificação de vídeo. As variáveis IMMICH_WORKERS_INCLUDE e IMMICH_WORKERS_EXCLUDE separam esses dois em containers distintos, que é como se atribui à metade ruidosa o seu próprio limite de memória sem limitar a metade que serve as suas fotos.

database é uma imagem PostgreSQL 14 com a extensão VectorChord integrada. Armazena cada pedaço de metadados e um vetor de pesquisa por ativo. A documentação do Immich atribui a este serviço o único limite mínimo explícito na stack: se aplicar limites de recursos do Docker, a base de dados precisa de pelo menos 2 GB. A mesma página indica que a base de dados deve idealmente residir em armazenamento SSD local e nunca num volume de rede de qualquer tipo, porque as pesquisas de vetores e índices são pequenas leituras aleatórias, pelo que um volume de rede transforma cada uma num round trip. Se a escolha de um plano depender disso, a diferença entre armazenamento NVMe e SATA SSD num VPS importa mais aqui do que em qualquer outra parte desta stack.

redis executa a imagem Valkey e mantém as filas de tarefas. É o menor dos quatro por uma margem larga, porque armazena registos de tarefas em vez de dados de fotos.

immich-machine-learning é o serviço que determina o tamanho do seu plano. Carrega modelos para pesquisa inteligente, deteção de rostos e reconhecimento de texto, e um modelo carregado permanece residente na memória. MACHINE_LEARNING_MODEL_TTL tem o valor predefinido de 300, pelo que um modelo é descartado após cinco minutos sem pedidos e lido novamente a partir do volume /cache no pedido seguinte. Durante uma importação em massa, nunca existe um intervalo de cinco minutos, pelo que os modelos permanecem carregados desde o primeiro ativo até ao último.

O que muda durante uma importação

O Immich ocioso é silencioso. As importações são o momento em que os servidores pequenos falham, porque o carregamento de um recurso coloca uma sequência de tarefas em fila e várias filas são executadas ao mesmo tempo.

A extração de metadados lê o cabeçalho do ficheiro e consome poucos recursos. A geração de miniaturas é mais pesada. O Immich produz 3 saídas de miniatura por recurso: um marcador de posição thumbhash desfocado, uma pré-visualização WebP e uma miniatura JPEG, além de mais uma miniatura por cada rosto detetado. Cada uma dessas tarefas descodifica uma imagem, e a simultaneidade das tarefas determina quantas imagens são descodificadas ao mesmo tempo. A simultaneidade é o multiplicador que transforma um custo pequeno por tarefa num custo para todo o servidor. Por isso, a FAQ do Immich indica-a como o primeiro parâmetro a reduzir numa máquina com recursos limitados. Defina a simultaneidade das filas pesadas como 1 em Administration, Settings, Job Settings.

Os recursos de vídeo acrescentam a transcodificação. Cada tarefa de transcodificação é um processo FFmpeg separado, com a sua própria memória, e utiliza todas as threads de CPU que lhe permitir.

A pesquisa inteligente envia cada recurso novo para o contentor de machine learning, que calcula um vetor de embedding. A deteção de rostos executa um segundo modelo sobre a mesma imagem. Na primeira importação de uma biblioteca de fotografias existente, ambas as filas processam todos os recursos que possui durante horas. Esse é o momento de maior consumo de memória de toda a instalação, e ocorre apenas uma vez.

Por que o reconhecimento facial e de objetos precisa de mais RAM

O processamento facial consiste em duas tarefas. A deteção facial executa um modelo no contentor de machine learning e encontra as caixas delimitadoras. Em seguida, o reconhecimento facial agrupa essas deteções em pessoas e consulta o índice vetorial no Postgres. Por isso, uma biblioteca grande exerce pressão sobre os dois serviços em sequência: primeiro sobre o contentor do modelo durante a deteção e depois sobre a base de dados durante o agrupamento.

Quatro definições alteram o que o contentor de machine learning mantém em memória.

• O modelo facial. O Immich inclui buffalo_l por predefinição, e a FAQ recomenda buffalo_s num servidor pequeno. É um modelo menor, por isso ocupa menos memória e executa mais depressa, mas é menos preciso em rostos pequenos ou vistos de lado.
• O número de workers. MACHINE_LEARNING_WORKERS tem o valor predefinido 1. Cada worker é um processo separado que carrega a sua própria cópia dos modelos. Por isso, aumentar este valor para 2 duplica aproximadamente a memória residente dos modelos. Mantenha-o em 1, a menos que tenha RAM disponível.
• O tamanho do lote. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION limita o número de rostos processados em simultâneo. Um lote permanece todo em memória, por isso uma fotografia de grupo com quarenta rostos consome mais memória do que um retrato.
• Os tipos de modelos que são executados. A pesquisa inteligente, a deteção facial e o reconhecimento de texto carregam modelos próprios. Desativar os que não utiliza em Administration, Settings, Machine Learning Settings remove a memória que ocupam de forma permanente, e não apenas entre importações.

Existe também MACHINE_LEARNING_MODEL_ARENA, documentado como uma opção que pré-aloca memória de CPU para evitar a fragmentação e que está ativada por predefinição. Altere-a por último. O efeito depende do alocador de memória utilizado. Por isso, a única forma fiável de o avaliar é monitorizar docker stats antes e depois.

Três perfis práticos: 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": "below every documented configuration, machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 2048,
    "ml_limit_mb": 0,
    "redis_limit_mb": 192,
    "notes": "documented 4 GB setup: machine learning disabled or moved to another host, job concurrency 1"
  },
  {
    "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"
  }
]

Leia estes valores como limites para introduzir no Compose, não como medições do consumo do Immich. Um limite é um teto. Não reserva memória nem torna um serviço menor. Determina qual serviço o kernel termina quando o servidor fica sem memória. É melhor que essa decisão seja sua, e não o resultado da pontuação do próprio kernel.

O servidor de 2 GB: remova o contentor de machine learning

2 GB fica abaixo do mínimo documentado de 6 GB e abaixo da única configuração reduzida documentada pelo Immich: 4 GB com o machine learning desativado. O Immich não publica uma configuração para 2 GB. Portanto, este perfil é um compromisso sem suporte, não uma receita. Se quiser experimentá-lo mesmo assim, comente todo o serviço immich-machine-learning em docker-compose.yml ou deixe-o em execução e desative todos os modelos em Administration, Settings, Machine Learning Settings. Remover o contentor é a opção mais segura, porque um modelo desativado continua a deixar um processo Python residente.

Mantém os uploads, os álbuns, a partilha, a cópia de segurança móvel, as miniaturas e a pesquisa por data, local e nome de ficheiro. Perde a pesquisa por descrição, o agrupamento automático de rostos em pessoas e o reconhecimento de texto dentro das imagens.

Os quatro limites somam cerca de 1.7 GB, deixando aproximadamente 300 MB para o host. A documentação do Immich indica que só a base de dados precisa de pelo menos 2 GB quando são usados limites de recursos do Docker. Esse valor corresponde a todo o servidor. Portanto, 768 MB para a base de dados fica muito abaixo desse mínimo. É por isso que o Postgres é o serviço com maior probabilidade de ser terminado neste cenário.

O primeiro problema surge durante a importação. Servir uma página requer uma consulta de metadados e uma leitura de ficheiro. Por isso, navegar numa biblioteca já importada exige menos do servidor. Uma importação com muitos vídeos, porém, vai usar swap, porque a transcodificação e a fila de miniaturas precisam de memória ao mesmo tempo. Se 2 GB for tudo o que tem, defina a concorrência de todas as filas pesadas como 1 e adicione um ficheiro de swap. Se estiver a escolher um plano, trate 4 GB como o mínimo real.

O servidor de 4 GB: machine learning ativo, um trabalho de cada vez

O Immich documenta 4 GB como suficiente quando as funcionalidades de machine learning estão desativadas. Essa é a única configuração reduzida na página de requisitos. Com a base de dados no mínimo documentado de 2 GB, os três limites do quadro somam cerca de 3.2 GB, deixando aproximadamente 800 MB para o host. Defina a concorrência dos trabalhos como 1 para a geração de miniaturas e mantenha baixo o número de threads de transcodificação.

Para manter o reconhecimento de rostos e objetos, a opção documentada é executar o contentor de machine learning noutra máquina, como descrito abaixo, e apontar este servidor para essa máquina. Executá-lo no mesmo servidor de 4 GB ultrapassa o que o Immich documenta, porque o mínimo da base de dados deixa cerca de 2 GB para o servidor, o Redis, os modelos e o host em conjunto. Se quiser experimentá-lo mesmo assim, limite o contentor de machine learning com um limite do Compose, altere o reconhecimento facial para buffalo_s e defina a concorrência dos trabalhos como 1 para a geração de miniaturas, a deteção de rostos e a pesquisa inteligente.

A primeira passagem por uma biblioteca existente demora muitas horas. Numa biblioteca grande, pode demorar mais de um dia. Isto é uma limitação de CPU, não de memória. Mais RAM não reduz esse tempo.

Se o machine learning for executado neste servidor, o primeiro problema será o contentor durante a primeira passagem em massa. Sem limite, o consumo cresce enquanto um trabalho de transcodificação também cresce, e o kernel termina o maior dos dois. Como reinicia em poucos segundos, docker ps -a mostra-o Up com um uptime muito inferior ao dos serviços vizinhos, em vez de Exited (137). A fila também fica silenciosamente mais atrasada do que estava na última verificação.

O servidor de 8 GB: a recomendação documentada

8 GB com 4 cores corresponde ao que o Immich recomenda. Tudo é executado com as definições predefinidas: pesquisa inteligente, deteção de rostos, reconhecimento de texto e transcodificação, com a concorrência predefinida. Bibliotecas com mais de cem mil ativos funcionam confortavelmente neste perfil. A pressão passa da memória para a velocidade do disco, porque o índice vetorial e as consultas de metadados são as principais tarefas da base de dados ao longo do dia.

Defina os limites mesmo assim. Num servidor com margem disponível, os limites impedem que uma fila descontrolada faça a base de dados cair com ela. Se estiver a comparar o custo com as opções menores, o custo real de uma VPS por escalão de memória normalmente faz do plano de 8 GB a forma mais barata de evitar ajustes constantes.

Como limitar a memória por serviço com limites do Compose

Não edite docker-compose.yml para isto. Esse ficheiro é substituído sempre que atualiza com wget. Coloque os limites em docker-compose.override.yml, junto dele. docker compose faz a fusão 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: 2048M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

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

docker stats deve agora mostrar o limite definido na coluna MEM USAGE / LIMIT, em vez da memória total do host. Se a coluna do limite continuar a mostrar o tamanho total do host, o ficheiro de substituição não foi carregado. Verifique o nome do ficheiro e execute docker compose config para ver o resultado da fusão.

Mantenha a base de dados em 2048M ou acima. A documentação do Immich define 2 GB como o mínimo para a base de dados quando são usados limites de recursos do Docker. Um limite demasiado baixo transforma um serviço lento num serviço indisponível. Aumente o limite se um contentor começar a reiniciar continuamente. Consulte como definir limites de memória por serviço no Docker Compose para obter mais informações sobre o funcionamento, incluindo o motivo por que deploy funciona fora do Swarm com o Compose v2.

Como desativar ou mover o container de machine learning

Num servidor pequeno, mover este container para outro local é a maior alteração que pode fazer. O Immich permite executá-lo noutra máquina. Crie este ficheiro no segundo host. Pode ser um desktop que só fica ligado à noite:

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

Depois, aceda a Administration, Settings, Machine Learning Settings na interface web, clique em Add URL e introduza http://<host>:3003. Mantenha a mesma versão nos dois hosts. A documentação do Immich avisa que versões diferentes entre os dois podem causar bugs e instabilidade.

Essa porta transporta as pré-visualizações das fotografias para a outra máquina sem encriptação. A documentação do Immich também avisa que o container de machine learning não tem medidas de segurança próprias. Mantenha-o numa rede privada ou execute-o através de um túnel WireGuard entre os dois hosts. Nunca exponha a porta 3003 à internet.

Se o problema for a existência de um container de modelos sempre em execução, também é razoável comparar as diferenças entre o PhotoPrism e o Immich relativamente ao que executam em segundo plano antes de escolher o tamanho do plano.

De quanto espaço em disco precisa uma biblioteca do Immich?

Não existe um multiplicador único, porque quatro componentes crescem a ritmos diferentes. Eis o cálculo para uma biblioteca com 50,000 fotografias e 500 vídeos curtos.

[
  {
    "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
  }
]

Os valores de 200 GB para fotografias e 60 GB para vídeo são pressupostos. Substitua-os pelas suas próprias médias antes de comprar qualquer equipamento, porque o vídeo determina este valor: um minuto de vídeo de telemóvel ocupa mais espaço do que uma centena de fotografias.

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}'

A linha de 39 GB é o único rácio publicado pelo Immich: as miniaturas geradas e o vídeo transcodificado acrescentam, em média, 10 a 20 por cento ao tamanho da biblioteca. É um intervalo porque depende de quantos dos seus ficheiros são vídeos que precisam de ser recodificados para garantir a compatibilidade com o browser. Uma biblioteca de ficheiros JPEG fica perto do limite inferior desse intervalo.

A base de dados ocupa 3 GB, um custo quase fixo. A documentação do Immich indica que os ficheiros da base de dados ocupam normalmente entre 1 e 3 GB, porque contêm metadados e vetores de pesquisa, não pixels. A cache de modelos ocupa 2 GB e cresce se ativar vários modelos ou testar modelos diferentes. A FAQ identifica este volume como consumidor de espaço precisamente por esse motivo.

As cinco linhas totalizam pouco mais de 300 GB. Assim, um volume de 500 GB deixa espaço para crescer, mas um volume de 250 GB não. Monitorize a distribuição com:

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

Seis pastas ficam sob UPLOAD_LOCATION. upload e library contêm os originais, thumbs contém pré-visualizações e miniaturas de rostos, encoded-video contém cópias recodificadas, profile contém avatares e backups contém dumps automáticos da base de dados. Apenas upload, library e profile são irrecuperáveis, porque todo o restante pode ser regenerado a partir deles.

Há dois aspetos que surpreendem muitas pessoas. Os ficheiros eliminados vão primeiro para a reciclagem e continuam a ocupar espaço até esta ser esvaziada. Por isso, uma limpeza grande não liberta espaço no próprio dia. Além disso, um dump da base de dados contém apenas metadados e não tem utilidade sem os ficheiros:

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

Combine isso com uma cópia ao nível dos ficheiros dos originais para um local fora do servidor. É esse o objetivo de backups restic de um VPS para armazenamento fora do servidor.

A transcodificação é limitada pela CPU, não pela RAM

Adicionar RAM não tornará a transcodificação mais rápida. O Immich utiliza o FFmpeg para transcodificar e, numa VPS comum, cada frame é descodificado e codificado pela CPU. Cada processo do FFmpeg mantém buffers de frames descodificados na memória, razão pela qual a secção de importação contabiliza a transcodificação como um custo de memória, mas a sua velocidade é definida pela CPU. Mesmo quando a aceleração por hardware está disponível, a documentação do Immich indica que, por predefinição, apenas a codificação é acelerada; portanto, a CPU continua a realizar a descodificação e o tone mapping, a menos que também ative a descodificação por hardware.

A aceleração por hardware requer o ficheiro hwaccel.transcoding.yml Compose adicional, além de um dispositivo para passar através do sistema, utilizando NVENC, Quick Sync, RKMPP ou VAAPI. A maioria dos planos de VPS não oferece nenhum destes recursos, por isso planeie com base na CPU.

A configuração prática é a contagem de threads. Em Administration, Settings, Video Transcoding Settings, um valor de thread igual a 0 significa utilizar todos os núcleos, o que permite que um único vídeo congele a interface web num plano de 2 núcleos. Defina este valor para 1 ou 2, conforme sugerido no FAQ do Immich, e a transcodificação tornar-se-á lenta em vez de disruptiva.

Por que o thrashing de swap parece um travamento

Esta é a falha que as pessoas interpretam mal com mais frequência. Quando o Immich fica sem memória, existem dois resultados, e apenas um deles parece uma falha.

Sem swap, o kernel encerra um processo. O container reinicia em segundos, então, a partir do navegador, a fila de tarefas simplesmente para e depois retoma. A evidência está em 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) significa que o processo foi encerrado com o sinal 9. 137 é 128 mais 9. Você só vê esse status enquanto o container está parado. Assim que a política de reinício o traz de volta, docker ps -a mostra que ele está Up novamente, e um tempo de atividade (uptime) muito menor do que o dos outros containers do Immich é a pista. O sinal 9 por si só não prova um problema de memória, porque o Docker também o envia quando uma parada normal ultrapassa o seu tempo limite. Um valor OOMKilled de true confirma que ele foi encerrado por falta de memória e, uma vez que o container reiniciou, as linhas oom-kill do dmesg são o registro em que se deve confiar.

Com swap, nada é encerrado e nenhum erro ocorre. O kernel começa a mover páginas para o disco, a importação desacelera em uma ordem de magnitude e a interface web para de responder dentro de um tempo limite normal. Todos os containers estão em execução. Todas as verificações de integridade (health checks) podem continuar passando. Parece um travamento, e as pessoas reiniciam a máquina neste ponto, o que faz perder o progresso da fila e não altera nada.

free -m
vmstat 1 5

Valores sustentados diferentes de zero nas colunas si e so do vmstat significam que a máquina está lendo e gravando no swap continuamente, o que é a definição de thrashing. A linha free -m para Swap usado estará subindo ao mesmo tempo.

Adicione swap de qualquer forma em uma máquina de 2 GB ou 4 GB, porque uma importação lenta que você pode diagnosticar é melhor do que um container encerrado que você não consegue:

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

Depois, corrija a causa. Reduza a concorrência de tarefas para 1, limite o container de aprendizado de máquina ou remova-o deste host. O swap lhe dá tempo para fazer isso. Ele não é a solução por si só.

FAQ

Posso executar o Immich num VPS com 2 GB?

Não numa configuração documentada pelo Immich. A página de requisitos define 6 GB como mínimo, indica 4 GB com as funcionalidades de aprendizagem automática desativadas como a única configuração inferior e afirma que só a base de dados precisa de pelo menos 2 GB quando são usados limites de recursos do Docker. Comentar o serviço immich-machine-learning e definir a concorrência das tarefas como 1 pode permitir que o serviço arranque, mas esse compromisso não é suportado, e o Postgres é o serviço com maior probabilidade de ser terminado durante uma importação. Se só tiver 2 GB, adicione um ficheiro swap de 2 GB para que um pico durante a importação torne o servidor mais lento, em vez de causar o término de um contentor. Se estiver a escolher um plano, comece com 4 GB.

Porque é que a minha importação do Immich para sem apresentar uma mensagem de erro?

Duas causas diferentes parecem idênticas no browser. Um contentor pode ter sido terminado por falta de memória e já ter reiniciado. Nesse caso, docker ps -a mostra-o Up com um uptime suspeitosamente curto. Exited (137) só aparece se o observar enquanto está parado. Em alternativa, o host pode estar a usar swap. Nesse caso, todos os contentores continuam em execução e tudo fica simplesmente muito lento. vmstat 1 5 permite distingui-las: valores diferentes de zero mantidos nas colunas si e so significam que existe swapping. Em ambos os casos, reduza a concorrência das tarefas de geração de miniaturas, deteção de rostos e pesquisa inteligente.

O que significa o código de saída 137 nos logs do Immich?

137 é 128 mais o sinal 9, por isso o processo foi terminado com SIGKILL. Num servidor com Immich, isso normalmente indica um limite de memória. Pode ser o limite do próprio contentor ou o esgotamento da memória do host. No entanto, o código por si só não prova a causa. O Docker também envia SIGKILL quando um contentor não para dentro do respetivo timeout, que no Linux é de 10 segundos por predefinição. Verifique com docker inspect immich_machine_learning | grep -i oomkilled. Um valor de true confirma que o kernel o terminou por falta de memória. Em seguida, free -m e sudo dmesg -T | grep -i oom-kill indicam se a causa foi o limite do contentor ou o host inteiro. O contentor de aprendizagem automática é normalmente afetado, porque costuma conter o processo maior.

De quanto espaço em disco precisa o Immich por fotografia?

Reserve o tamanho do ficheiro original mais 10 a 20 por cento. O Immich documenta que as miniaturas geradas e o vídeo transcodificado aumentam o tamanho da biblioteca em 10 a 20 por cento, em média. A própria base de dados ocupa normalmente 1 a 3 GB, mesmo numa biblioteca grande. O vídeo é o fator que realmente determina o total. Por isso, meça o tamanho médio dos seus próprios ficheiros antes de escolher um plano, em vez de aplicar um multiplicador ao número de fotografias.

Preciso de uma GPU para o Immich?

Não. Todas as partes do Immich funcionam com CPU. Uma placa gráfica acelera a inferência dos modelos no contentor de aprendizagem automática e a codificação de vídeo, mas nenhuma das duas é necessária. A maioria dos planos VPS não oferece uma GPU. Em hardware apenas com CPU, defina as threads de transcodificação como 1 ou 2, use o modelo de rostos buffalo_s e deixe a primeira importação em massa decorrer durante a noite.