¿Cuánta RAM y disco necesita Immich?

¿Cuánta RAM necesita Immich?

Immich necesita 6 GB de RAM (memoria de acceso aleatorio) como mínimo documentado y 8 GB como recomendación, con 2 núcleos de CPU como mínimo y 4 para una instalación con margen. Esa cifra cubre toda la pila, porque Immich consta de cuatro contenedores y no de una sola aplicación. Consultar una biblioteca ya importada consume pocos recursos. La memoria se utiliza durante la importación, y la mayor parte corresponde a un contenedor que puede desactivar.

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

Estas son las cifras publicadas en la página de requisitos de Immich en octubre de 2026. Son una recomendación de dimensionamiento, no una comprobación que el software realice al arrancar. La misma página documenta una configuración más pequeña, de 4 GB con las funciones de machine learning desactivadas, y no indica nada por debajo de ese valor. En un servidor más pequeño cambia qué trabajos en segundo plano terminan y qué ocurre con una importación cuando se agota la memoria.

Existe un límite estricto real. Desde la versión 3, el contenedor de machine learning en hosts amd64 necesita una CPU x86-64-v2, que incluyen la mayoría de los procesadores comercializados desde aproximadamente 2012. El requisito se aplica a ese contenedor, no al servidor. Por tanto, en hardware antiguo puede desactivar machine learning, ejecutarlo en otra máquina como se describe más abajo o mantener la versión v2.7.5, que la documentación de Immich identifica como la última versión compatible.

Si todavía no ha instalado el sistema, empiece por la instalación completa de Immich en un VPS con Docker Compose y vuelva aquí para dimensionar el servidor.

Dónde se asigna la memoria: cuatro contenedores

El archivo Compose oficial inicia cuatro servicios. Cada uno tiene un perfil de memoria distinto, por lo que una cifra total oculta la información útil.

immich-server sirve la interfaz web y la API, y además ejecuta los trabajadores de tareas en segundo plano. Dos trabajadores residen dentro de ese mismo contenedor. api responde a las peticiones del navegador y de la aplicación móvil. microservices gestiona las colas, incluyendo la generación de miniaturas y la codificación de vídeo. Las variables IMMICH_WORKERS_INCLUDE y IMMICH_WORKERS_EXCLUDE separan ambos procesos en contenedores distintos; así es como se asigna un límite de memoria a la mitad más exigente sin restringir la mitad que sirve sus fotos.

database es una imagen de PostgreSQL 14 con la extensión VectorChord integrada. Almacena cada fragmento de metadatos y un vector de búsqueda por recurso. La documentación de Immich establece el único requisito mínimo explícito para este servicio en la pila: si aplica límites de recursos de Docker, la base de datos necesita al menos 2 GB. La misma página indica que la base de datos debería residir idealmente en almacenamiento SSD local y nunca en un recurso compartido de red, ya que las búsquedas de vectores e índices son lecturas aleatorias pequeñas, por lo que un volumen de red convierte cada una en un viaje de ida y vuelta. Si la elección de un plan depende de esto, la diferencia entre almacenamiento NVMe y SATA SSD en un VPS es más relevante aquí que en cualquier otra parte de esta pila.

redis ejecuta la imagen de Valkey y contiene las colas de tareas. Es el más pequeño de los cuatro con diferencia, ya que almacena registros de tareas en lugar de datos de fotos.

immich-machine-learning es el servicio que determina el tamaño de su plan. Carga modelos para búsqueda inteligente, detección de rostros y reconocimiento de texto, y un modelo cargado permanece residente en memoria. MACHINE_LEARNING_MODEL_TTL tiene un valor predeterminado de 300, por lo que un modelo se descarga tras cinco minutos sin peticiones y se vuelve a leer desde el volumen /cache en la siguiente. Durante una importación masiva nunca hay un intervalo de cinco minutos, por lo que los modelos permanecen cargados desde el primer recurso hasta el último.

Qué cambia durante una importación

Un Immich inactivo apenas genera actividad. Las importaciones son el momento en que los servidores pequeños pueden fallar, porque cargar un recurso pone en cola una cadena de tareas y varias colas se ejecutan al mismo tiempo.

La extracción de metadatos lee la cabecera del archivo y requiere pocos recursos. La generación de miniaturas es más exigente. Immich genera tres resultados de miniatura por recurso: un marcador de posición thumbhash desenfocado, una vista previa WebP y una miniatura JPEG. También genera otra miniatura por cada rostro detectado. Cada una de esas tareas decodifica una imagen, y la concurrencia de las tareas determina cuántas imágenes se decodifican a la vez. La concurrencia es el multiplicador que convierte un coste pequeño por tarea en un coste para todo el servidor. Por eso las preguntas frecuentes de Immich la señalan como el primer valor que se debe reducir en una máquina con recursos limitados. Establezca en 1 la concurrencia de las colas pesadas en Administration, Settings, Job Settings.

Los recursos de vídeo añaden transcodificación. Cada tarea de transcodificación es un proceso independiente de FFmpeg con su propia memoria. Utilizará todos los hilos de CPU que permita.

Smart search envía cada recurso nuevo al contenedor de machine learning para calcular un vector de embedding. La detección de rostros ejecuta un segundo modelo sobre la misma imagen. Durante la primera importación de una biblioteca de fotos existente, ambas colas procesan todos los recursos disponibles durante horas. Ese es el momento de mayor consumo de memoria de toda la instalación, y ocurre una sola vez.

Por qué el reconocimiento facial y de objetos necesitan más RAM

El procesamiento facial consta de dos tareas. La detección facial ejecuta un modelo en el contenedor de machine learning y localiza los cuadros. Después, el reconocimiento facial agrupa esas detecciones por persona y consulta el índice vectorial de Postgres. Por tanto, una biblioteca grande afecta a ambos servicios en distintos momentos: primero al contenedor del modelo durante la detección y después a la base de datos durante la agrupación.

Cuatro opciones cambian lo que mantiene el contenedor de machine learning.

• El modelo facial. Immich incluye buffalo_l de forma predeterminada, y las preguntas frecuentes recomiendan buffalo_s en un servidor pequeño. Es un modelo más pequeño, por lo que consume menos memoria y se ejecuta más rápido, a cambio de una menor precisión con rostros pequeños o de perfil.
• El número de workers. MACHINE_LEARNING_WORKERS tiene el valor predeterminado 1. Cada worker es un proceso independiente que carga su propia copia de los modelos, por lo que aumentarlo a 2 aproximadamente duplica la memoria residente de los modelos. Manténgalo en 1 salvo que disponga de RAM suficiente.
• El tamaño del lote. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION limita cuántos rostros se procesan a la vez. Un lote se mantiene completo en memoria, por lo que una foto de grupo con cuarenta rostros consume más que un retrato.
• Los tipos de modelos que se ejecutan. La búsqueda inteligente, la detección facial y el reconocimiento de texto cargan sus propios modelos. Desactive los que no utilice en Administration, Settings, Machine Learning Settings. Así libera esa memoria de forma permanente, no sólo entre importaciones.

También existe MACHINE_LEARNING_MODEL_ARENA, que está documentado como una opción que preasigna memoria de CPU para evitar la fragmentación y que está activada de forma predeterminada. Cámbiela en último lugar. Su efecto depende del asignador de memoria subyacente, por lo que la única forma fiable de evaluarlo es observar docker stats antes y después.

Tres perfiles completos: 2 GB, 4 GB y 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"
  }
]

Interprételos como límites que debe introducir en Compose, no como mediciones del consumo de Immich. Un límite es un techo. No reserva recursos ni reduce el tamaño de un servicio. Determina qué servicio termina el kernel cuando el servidor se queda sin memoria. Es mejor que esa decisión la tome usted y no la puntuación interna del kernel.

El servidor de 2 GB: eliminar el contenedor de machine learning

2 GB está por debajo del mínimo documentado de 6 GB y por debajo de la única configuración reducida que documenta Immich: 4 GB con machine learning deshabilitado. Immich no publica ninguna configuración para 2 GB. Por tanto, este perfil es un compromiso no admitido, no una receta. Si aun así quiere probarlo, comente todo el servicio immich-machine-learning en docker-compose.yml, o déjelo en ejecución y deshabilite todos los modelos en Administration, Settings, Machine Learning Settings. Eliminar el contenedor es la opción más sólida, porque un modelo deshabilitado todavía deja un proceso de Python residente.

Conserva las cargas, los álbumes, el uso compartido, la copia de seguridad del móvil, las miniaturas y las búsquedas por fecha, lugar y nombre de archivo. Pierde las búsquedas por descripción, la agrupación automática de rostros en personas y el reconocimiento de texto dentro de las imágenes.

Los cuatro límites suman aproximadamente 1.7 GB, por lo que quedan unos 300 MB para el host. La documentación de Immich indica que la base de datos necesita al menos 2 GB cuando se usan límites de recursos de Docker. Esa cantidad coincide con toda la memoria del servidor. Por tanto, 768 MB para la base de datos está muy por debajo de ese mínimo. Por eso Postgres es el servicio que probablemente terminará primero.

La importación es lo primero que falla. Servir una página requiere una consulta de metadatos y una lectura de archivo. Por eso, navegar por una biblioteca ya importada exige menos recursos al servidor. En cambio, una importación con muchos vídeos usará swap, porque la transcodificación y la cola de miniaturas necesitan memoria al mismo tiempo. Si sólo tiene 2 GB, establezca en 1 la concurrencia de todas las colas pesadas y añada un archivo de swap. Si está eligiendo un plan, considere 4 GB como el mínimo real.

El servidor de 4 GB: machine learning habilitado, un trabajo cada vez

Immich documenta 4 GB como una configuración viable con las funciones de machine learning deshabilitadas. Es la única configuración reducida de su página de requisitos. Con la base de datos en su mínimo documentado de 2 GB, los tres límites del gráfico suman aproximadamente 3.2 GB, por lo que quedan unos 800 MB para el host. Establezca en 1 la concurrencia de los trabajos de generación de miniaturas y mantenga bajo el número de hilos de transcodificación.

Para conservar el reconocimiento de rostros y objetos, la opción documentada es ejecutar el contenedor de machine learning en otra máquina, como se describe más abajo, y dirigir este servidor hacia ella. Ejecutarlo en el mismo servidor de 4 GB supera lo que documenta Immich, porque el mínimo de la base de datos deja unos 2 GB para el servidor, Redis, los modelos y el host en conjunto. Si aun así quiere probarlo, limite el contenedor de machine learning con un límite de Compose, cambie el reconocimiento facial a buffalo_s y establezca en 1 la concurrencia de los trabajos de generación de miniaturas, detección de rostros y búsqueda inteligente.

La primera pasada por una biblioteca existente tardará muchas horas y, en una biblioteca grande, más de un día. Esto depende de la CPU y no de la memoria. Por tanto, añadir RAM no la hará más rápida.

Si machine learning se ejecuta en este servidor, lo primero que falla es ese contenedor durante la primera pasada masiva. Sin límites, crece mientras también crece un trabajo de transcodificación, y el kernel termina el proceso que ocupa más memoria. Como se reinicia en unos segundos, docker ps -a lo muestra Up con un tiempo de actividad muy inferior al de los servicios vecinos en lugar de Exited (137). Además, la cola queda discretamente más atrasada que antes.

El servidor de 8 GB: la recomendación documentada

8 GB con 4 núcleos coincide con la recomendación de Immich. Todo se ejecuta con la configuración predeterminada: búsqueda inteligente, detección de rostros, reconocimiento de texto y transcodificación, con la concurrencia predeterminada. Las bibliotecas de más de cien mil recursos funcionan con margen en este perfil. La presión pasa de la memoria a la velocidad del disco, porque el índice vectorial y las consultas de metadatos son las tareas que la base de datos realiza durante todo el día.

Establezca los límites de todos modos. En un servidor con margen, los límites impiden que una cola descontrolada provoque también la caída de la base de datos. Si compara el precio con las opciones más pequeñas, el coste real de un VPS por nivel de memoria suele hacer que el plan de 8 GB sea la forma más barata de evitar ajustes continuos.

Cómo limitar la memoria por servicio con los límites de Compose

No edite docker-compose.yml para esto. Ese archivo se reemplaza cada vez que actualiza con wget. Coloque los límites en docker-compose.override.yml, junto a él. docker compose los fusiona automáticamente.

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 ahora debería mostrar el límite configurado en la columna MEM USAGE / LIMIT, en lugar de la memoria total del host. Si la columna del límite sigue mostrando el tamaño completo del host, no se cargó el archivo de sustitución: compruebe el nombre del archivo y ejecute docker compose config para ver el resultado fusionado.

Mantenga la base de datos en 2048M o más. Immich documenta 2 GB como mínimo para la base de datos cuando se utilizan límites de recursos de Docker. Un límite demasiado bajo convierte un servicio lento en un servicio detenido, así que auméntelo si un contenedor entra en un ciclo de reinicios. Encontrará más información sobre el funcionamiento en configurar límites de memoria por servicio en Docker Compose, incluido el motivo por el que deploy funciona fuera de Swarm con Compose v2.

Cómo desactivar o mover el contenedor de machine learning

En un servidor pequeño, mover este contenedor a otro equipo es el cambio individual más importante que puede hacer. Immich permite ejecutarlo en otra máquina. Cree este archivo en el segundo host. Puede ser un equipo de escritorio que sólo esté encendido por las tardes:

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

A continuación, vaya a Administration, Settings, Machine Learning Settings en la interfaz web, haga clic en Add URL e introduzca http://<host>:3003. Mantenga la misma versión en ambos hosts, porque la documentación de Immich advierte que las diferencias de versión entre los dos pueden causar errores e inestabilidad.

Ese puerto transmite las previsualizaciones de las imágenes al otro equipo sin cifrar. La documentación de Immich también advierte que el contenedor de machine learning no tiene medidas de seguridad propias. Manténgalo en una red privada o ejecútelo mediante un túnel de WireGuard entre los dos hosts. Nunca exponga el puerto 3003 a Internet.

Si el problema es la idea de mantener un contenedor de modelos en ejecución, también es razonable comparar las diferencias entre PhotoPrism e Immich en cuanto a lo que ejecutan de forma permanente antes de elegir un tamaño de plan.

¿Cuánto espacio de disco necesita una biblioteca de Immich?

No existe un multiplicador único, porque cuatro elementos distintos crecen a ritmos diferentes. Este es el cálculo para una biblioteca con 50,000 fotos y 500 videos cortos.

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

Los 200 GB de fotos y 60 GB de video son supuestos. Sustitúyalos por sus propios promedios antes de comprar hardware, porque el video determina esta cifra: un minuto de video de un teléfono ocupa más espacio que cien fotos.

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 fila de 39 GB es la única proporción publicada por Immich: las miniaturas generadas y el video transcodificado añaden entre 10 y 20 por ciento al tamaño de la biblioteca, como promedio. Es un intervalo porque depende de cuántos recursos sean videos que necesiten volver a codificarse para que sean compatibles con el navegador. Una biblioteca de archivos JPEG se sitúa cerca del extremo inferior de ese intervalo.

La base de datos ocupa 3 GB, y ese valor es casi fijo. Immich documenta que los archivos de la base de datos suelen ocupar entre 1 y 3 GB, porque contienen metadatos y vectores de búsqueda, no píxeles. La caché de modelos ocupa 2 GB y crece si habilita varios modelos o prueba modelos diferentes. Las preguntas frecuentes señalan este volumen como consumidor de espacio precisamente por ese motivo.

Las cinco filas suman algo más de 300 GB, por lo que un volumen de 500 GB deja espacio para crecer y uno de 250 GB no. Supervise la distribución con:

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

Hay seis carpetas bajo UPLOAD_LOCATION. upload y library contienen los originales, thumbs contiene las vistas previas y las miniaturas de rostros, encoded-video contiene las copias recodificadas, profile contiene los avatares y backups contiene los volcados automáticos de la base de datos. Sólo upload, library y profile son irremplazables, porque todo lo demás se puede regenerar a partir de ellos.

Hay dos aspectos que suelen sorprender. Los recursos eliminados pasan primero a la papelera y conservan su espacio hasta que se vacía. Por tanto, una limpieza grande no libera espacio el mismo día en que se realiza. Además, un volcado de la base de datos sólo contiene metadatos, por lo que no sirve sin los archivos:

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

Combine esto con una copia a nivel de archivo de los originales en una ubicación fuera del servidor. Para eso sirven las copias de seguridad de restic desde un VPS a almacenamiento externo.

La transcodificación está limitada por la CPU, no por la RAM

Añadir RAM no acelerará la transcodificación. Immich transcodifica mediante FFmpeg y, en un VPS estándar, cada fotograma es decodificado y codificado por la CPU. Cada proceso de FFmpeg mantiene búferes de fotogramas decodificados en la memoria, razón por la cual la sección de importación contabiliza la transcodificación como un coste de memoria propio, pero su velocidad depende de la CPU. Incluso cuando hay aceleración por hardware disponible, la documentación de Immich indica que, por defecto, solo se acelera la codificación; por tanto, la CPU sigue realizando la decodificación y el mapeo de tonos a menos que también habilite la decodificación por hardware.

La aceleración por hardware requiere el archivo hwaccel.transcoding.yml Compose adicional, además de un dispositivo que pasar a través del sistema, utilizando NVENC, Quick Sync, RKMPP o VAAPI. La mayoría de los planes VPS no ofrecen ninguna de estas opciones, así que planifique basándose en la CPU.

El ajuste práctico es el número de hilos. En Administration, Settings, Video Transcoding Settings, un valor de 0 en los hilos significa que se utilizarán todos los núcleos, lo que permite que un solo vídeo bloquee la interfaz web en un plan de 2 núcleos. Establezca este valor en 1 o 2, tal como sugiere el FAQ de Immich, y la transcodificación pasará a ser lenta en lugar de disruptiva.

Por qué el thrashing de swap parece un bloqueo

Este es el fallo que la gente interpreta mal con más frecuencia. Cuando Immich se queda sin memoria hay dos resultados, y solo uno de ellos parece un fallo.

Sin swap, el kernel mata un proceso. El contenedor se reinicia en segundos, por lo que desde el navegador la cola de tareas simplemente se detiene y luego se reanuda. La evidencia está en 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 el proceso fue terminado con la señal 9. 137 es 128 más 9. Solo verá ese estado mientras el contenedor esté detenido. Una vez que la política de reinicio lo haya levantado, docker ps -a mostrará que está Up de nuevo, y un tiempo de actividad mucho menor que el de los otros contenedores de Immich es la pista. La señal 9 por sí sola no prueba un problema de memoria, porque Docker también la envía cuando una parada normal supera su tiempo de espera. Un valor de OOMKilled de true confirma que fue terminado por memoria, y una vez que el contenedor se ha reiniciado, las líneas oom-kill de dmesg son el registro en el que confiar.

Con swap, nada es terminado y no hay errores. El kernel comienza a mover páginas al disco, la importación se ralentiza un orden de magnitud y la interfaz web deja de responder dentro de un tiempo de espera normal. Todos los contenedores están ejecutándose. Todos los chequeos de salud pueden seguir pasando. Parece un bloqueo, y la gente reinicia la máquina en este punto, lo cual pierde el progreso de la cola y no cambia nada.

free -m
vmstat 1 5

Valores sostenidos distintos de cero en las columnas si y so de vmstat significan que la máquina está leyendo y escribiendo en el swap continuamente, lo cual es la definición de thrashing. La fila free -m para el uso de Swap estará subiendo al mismo tiempo.

Añada swap de todos modos en una máquina de 2 GB o 4 GB, porque una importación lenta que puede diagnosticar es mejor que un contenedor terminado que no puede:

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

Luego solucione la causa. Reduzca la concurrencia de tareas a 1, limite el contenedor de aprendizaje automático o muévalo a otro host. El swap le da tiempo para hacer eso. No es la solución por sí sola.

FAQ

¿Puedo ejecutar Immich en un VPS de 2 GB?

No con ninguna configuración documentada por Immich. La página de requisitos establece 6 GB como mínimo, indica que 4 GB con las funciones de machine learning deshabilitadas es la única configuración inferior y señala que la base de datos necesita al menos 2 GB cuando se aplican límites de recursos de Docker. Comentar el servicio immich-machine-learning y establecer la concurrencia de trabajos en 1 puede permitir que arranque, pero es una solución no compatible. Postgres es el servicio que más probablemente será terminado durante una importación. Si sólo dispone de 2 GB, añada un archivo de swap de 2 GB para que un pico durante la importación ralentice el servidor en lugar de provocar que se termine un contenedor. Si está eligiendo un plan, empiece con 4 GB.

¿Por qué se detiene mi importación de Immich sin mostrar ningún mensaje de error?

Desde el navegador, dos causas distintas parecen idénticas. Puede que un contenedor haya sido terminado por falta de memoria y ya se haya reiniciado. En ese caso, docker ps -a lo muestra Up con un tiempo de actividad sospechosamente corto. Exited (137) sólo aparece si lo comprueba mientras está detenido. La otra posibilidad es que el host esté usando swap. En ese caso, todos los contenedores siguen en ejecución y todo funciona simplemente muy despacio. vmstat 1 5 permite distinguir ambos casos: los valores distintos de cero sostenidos en las columnas si y so indican uso de swap. En ambos casos, reduzca la concurrencia de trabajos para la generación de miniaturas, la detección de caras y la búsqueda inteligente.

¿Qué significa el código de salida 137 en los registros de Immich?

137 es 128 más la señal 9, por lo que el proceso terminó con SIGKILL. En un servidor con Immich, normalmente indica un límite de memoria, ya sea el límite propio del contenedor o el agotamiento de memoria del host. Sin embargo, el código por sí solo no lo demuestra: Docker también envía SIGKILL cuando un contenedor no se detiene dentro de su tiempo de espera, que en Linux es de 10 segundos de forma predeterminada. Compruébelo con docker inspect immich_machine_learning | grep -i oomkilled. Un valor de true confirma que el kernel lo terminó por falta de memoria. Después, free -m y sudo dmesg -T | grep -i oom-kill indican si la causa fue el límite del contenedor o el host completo. El contenedor de machine learning suele ser la víctima porque normalmente contiene el proceso más grande.

¿Cuánto espacio de disco necesita Immich por foto?

Calcule el tamaño del archivo original más entre un 10 y un 20 por ciento. Immich documenta que las miniaturas generadas y el vídeo transcodificado aumentan el tamaño de la biblioteca entre un 10 y un 20 por ciento de media. La base de datos suele ocupar entre 1 y 3 GB incluso en una biblioteca grande. El vídeo es el factor que realmente determina el total. Por eso, mida el tamaño medio de sus propios archivos antes de elegir un plan, en lugar de aplicar un multiplicador al número de fotos.

¿Necesito una GPU para Immich?

No. Todas las partes de Immich se ejecutan en la CPU. Una tarjeta gráfica acelera la inferencia de modelos en el contenedor de machine learning y la codificación de vídeo, pero ninguna de las dos es necesaria. La mayoría de los planes VPS no ofrecen una. En hardware que sólo tiene CPU, establezca los hilos de transcodificación en 1 o 2, use el modelo de caras buffalo_s y deje que la primera importación masiva se ejecute durante la noche.