Системные требования Immich: RAM и место на диске

Сколько оперативной памяти требуется для Immich?

Для работы Immich требуется 6 GB оперативной памяти в качестве задокументированного минимума и 8 GB в качестве рекомендуемого объема при использовании 2 ядер CPU для базовой конфигурации и 4 для комфортной работы. Этот показатель учитывает весь стек, так как Immich состоит из четырех контейнеров, а не из одного приложения. Просмотр уже импортированной библиотеки потребляет мало ресурсов. Основной объем памяти расходуется на импорт, причем большая часть уходит на один контейнер, который можно отключить.

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

Это опубликованные данные со страницы системных требований Immich по состоянию на октябрь 2026 года. Это рекомендация по выбору оборудования, а не проверка работоспособности ПО при запуске. На той же странице описана более компактная конфигурация: 4 GB с отключенными функциями машинного обучения, конфигураций меньше этого объема не предусмотрено. На сервере с меньшим объемом памяти меняется лишь то, какие фоновые задачи завершаются успешно и как ведет себя процесс импорта при нехватке памяти.

Существует одно реальное жесткое ограничение. Начиная с версии 3, контейнер машинного обучения на хостах amd64 требует наличия x86-64-v2 CPU, что охватывает большинство процессоров, выпущенных примерно с 2012 года. Это требование относится к конкретному контейнеру, а не ко всему серверу, поэтому на старом оборудовании можно отключить машинное обучение, запустить его на другой машине, как описано ниже, или остаться на версии v2.7.5, которая в документации Immich указана как последняя совместимая версия.

Если вы еще не приступили к установке, начните с полной установки Immich на VPS с помощью Docker Compose, а затем вернитесь сюда для подбора параметров сервера.

Куда уходит память: четыре контейнера

Официальный файл Compose запускает четыре сервиса. У каждого из них свои требования к памяти, поэтому общая цифра не дает представления о реальном потреблении.

immich-server обслуживает веб-интерфейс и API, а также запускает воркеры фоновых задач. Внутри этого контейнера работают два воркера. api отвечает на запросы из браузера и мобильного приложения. microservices управляет очередями, включая создание миниатюр и кодирование видео. Переменные IMMICH_WORKERS_INCLUDE и IMMICH_WORKERS_EXCLUDE позволяют разделить эти две функции на отдельные контейнеры. Это дает возможность ограничить потребление памяти «шумной» частью, не затрагивая ту, что отвечает за отображение ваших фотографий.

database — это образ PostgreSQL 14 со встроенным расширением VectorChord. В нем хранятся все метаданные и по одному поисковому вектору на каждый объект. В документации Immich для этого сервиса указано единственное жесткое требование: если вы устанавливаете лимиты ресурсов Docker, базе данных требуется не менее 2 GB. На той же странице сказано, что база данных должна располагаться на локальном SSD и ни в коем случае не на сетевом хранилище. Поиск по векторам и индексам состоит из множества мелких случайных операций чтения, поэтому сетевой том превращает каждую из них в сетевой запрос. Если выбор тарифа зависит от этого, разница между NVMe и SATA SSD на VPS здесь критичнее, чем в любой другой части стека.

redis запускает образ Valkey и хранит очереди задач. Это самый легкий из четырех контейнеров, так как он хранит записи о задачах, а не данные фотографий.

immich-machine-learning — это сервис, который определяет требования к размеру вашего плана. Он загружает модели для интеллектуального поиска, распознавания лиц и текста, причем загруженная модель остается в оперативной памяти. Значение MACHINE_LEARNING_MODEL_TTL по умолчанию равно 300, поэтому модель выгружается через пять минут отсутствия запросов и считывается обратно с тома /cache при следующем обращении. Во время массового импорта пятиминутных пауз не бывает, поэтому модели остаются загруженными с первого до последнего объекта.

Что происходит во время импорта

В режиме ожидания Immich не потребляет ресурсы. Проблемы на слабых серверах возникают именно во время импорта, так как загрузка одного файла ставит в очередь цепочку задач, которые выполняются параллельно.

Извлечение метаданных считывает заголовок файла и требует минимум ресурсов. Генерация миниатюр более ресурсоемка. Immich создает три варианта миниатюр для каждого объекта: размытый плейсхолдер thumbhash, превью в формате WebP и миниатюру в формате JPEG, а также дополнительную миниатюру для каждого распознанного лица. Каждая такая задача декодирует изображение, а параметр параллелизма (concurrency) определяет, сколько задач выполняется одновременно. Параллелизм — это множитель, который превращает небольшую нагрузку от одной задачи в значительную нагрузку на весь сервер. Именно поэтому в FAQ Immich рекомендуется снизить этот параметр в первую очередь на ограниченном оборудовании. Установите значение параллелизма для тяжелых очередей равным 1 в разделе Administration, Settings, Job Settings.

Видеофайлы требуют перекодирования. Каждая задача транскодирования — это отдельный процесс FFmpeg со своей памятью, который использует все доступные потоки CPU, которые вы ему разрешите.

Функция интеллектуального поиска отправляет каждый новый объект в контейнер машинного обучения для вычисления одного вектора встраивания (embedding vector). Распознавание лиц запускает вторую модель для того же изображения. При первом импорте существующей библиотеки фотографий обе эти очереди обрабатывают каждый ваш файл в течение нескольких часов. Это самый критический момент для потребления оперативной памяти за все время работы установки, и он происходит только один раз.

Почему распознавание лиц и объектов требует больше всего оперативной памяти

Обработка лиц состоит из двух задач. Детекция лиц запускает модель в контейнере машинного обучения и находит границы объектов. Распознавание лиц затем группирует эти результаты по людям, и этот этап отправляет запросы к векторному индексу в Postgres. Таким образом, большая библиотека поочередно нагружает оба сервиса: контейнер с моделью во время детекции и базу данных во время группировки.

Четыре настройки определяют объем данных, удерживаемых в контейнере машинного обучения.

• Модель распознавания лиц. Immich по умолчанию поставляет buffalo_l, а в FAQ рекомендуется buffalo_s для небольших серверов. Это более компактная модель, поэтому она занимает меньше памяти и работает быстрее, но с меньшей точностью при распознавании лиц в профиль или на мелких изображениях.
• Количество воркеров. MACHINE_LEARNING_WORKERS по умолчанию равно 1. Каждый воркер — это отдельный процесс, который загружает собственную копию моделей, поэтому увеличение этого значения до 2 примерно удваивает объем оперативной памяти, занимаемой моделями. Оставьте значение 1, если у вас нет избытка RAM.
• Размер пакета (batch size). MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION ограничивает количество лиц, обрабатываемых одновременно. Пакет целиком удерживается в памяти, поэтому групповое фото с сорока лицами требует больше ресурсов, чем портрет.
• Типы используемых моделей. Умный поиск, детекция лиц и распознавание текста загружают собственные модели. Отключение неиспользуемых функций в разделе Administration, Settings, Machine Learning Settings полностью освобождает память, занимаемую этими моделями, а не только в промежутках между импортами.

Также существует MACHINE_LEARNING_MODEL_ARENA, которая, согласно документации, выполняет предварительное выделение памяти CPU для предотвращения фрагментации и включена по умолчанию. Изменяйте её в последнюю очередь. Её эффект зависит от используемого аллокатора памяти, поэтому единственный объективный способ оценить результат — отслеживать docker stats до и после внесения изменений.

Три рабочих профиля: 2 ГБ, 4 ГБ и 8 ГБ

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

Воспринимайте эти значения как лимиты для ввода в Compose, а не как показатели потребления ресурсов Immich. Лимит — это верхний предел. Он не резервирует ресурсы и не уменьшает размер сервиса. Он определяет, какой сервис будет принудительно завершен ядром при нехватке памяти, и лучше вам принять это решение самостоятельно, чем полагаться на алгоритмы ядра.

Сервер на 2 ГБ: удаление контейнера машинного обучения

Объем 2 ГБ ниже официально заявленного минимума в 6 ГБ и ниже единственной описанной в документации Immich конфигурации с пониженными требованиями (4 ГБ с отключенным машинным обучением). Immich не публикует конфигураций для 2 ГБ, поэтому данный профиль является неподдерживаемым компромиссом, а не готовым решением. Если вы все же решите его использовать, закомментируйте весь сервис immich-machine-learning в файле docker-compose.yml или оставьте его запущенным, отключив все модели в разделе Administration, Settings, Machine Learning Settings. Удаление контейнера — более надежный вариант, так как отключенная модель все равно оставляет резидентный процесс Python.

Вы сохраните возможность загрузки, создания альбомов, обмена файлами, мобильного резервного копирования, создания миниатюр и поиска по дате, месту и имени файла. Вы потеряете поиск по описанию, автоматическую группировку лиц и распознавание текста на изображениях.

Сумма четырех лимитов составляет около 1.7 ГБ, что оставляет хосту примерно 300 МБ. Документация Immich гласит, что одной базе данных требуется не менее 2 ГБ при использовании лимитов ресурсов Docker, которые охватывают весь сервер. Таким образом, 768 МБ для базы данных значительно ниже этого порога, и именно поэтому Postgres здесь чаще всего подвергается принудительному завершению.

Первым делом при нехватке ресурсов ломается импорт. Отображение страницы — это запрос метаданных плюс чтение файла, поэтому просмотр уже существующей библиотеки требует от сервера минимум усилий. Однако импорт большого количества видео приведет к использованию swap, так как перекодирование и очередь создания миниатюр требуют память одновременно. Если у вас всего 2 ГБ, установите параллелизм для всех тяжелых очередей в значение 1 и добавьте файл подкачки. Если вы только выбираете тариф, считайте 4 ГБ реальным минимумом.

Сервер на 4 ГБ: машинное обучение включено, задачи по одной

Immich указывает 4 ГБ как рабочий объем при отключенных функциях машинного обучения, и это единственная конфигурация с пониженными требованиями на странице документации. При базе данных на уровне 2 ГБ, указанном в документации, сумма трех лимитов в таблице составляет около 3.2 ГБ, что оставляет хосту примерно 800 МБ. Установите параллелизм задач в значение 1 для генерации миниатюр и ограничьте количество потоков перекодирования.

Чтобы сохранить распознавание лиц и объектов, рекомендуется вынести контейнер машинного обучения на другой сервер, как описано ниже, и настроить этот сервер на работу с ним. Запуск на том же сервере с 4 ГБ выходит за рамки документации Immich, так как порог базы данных оставляет около 2 ГБ для сервера, Redis, моделей и самой ОС вместе взятых. Если вы все же пробуете этот вариант, ограничьте контейнер машинного обучения лимитом в Compose, переключите распознавание лиц на buffalo_s и установите параллелизм задач в значение 1 для генерации миниатюр, обнаружения лиц и умного поиска.

Первичное сканирование существующей библиотеки будет длиться много часов, а для большой библиотеки — более суток. Это ограничение по CPU, а не по памяти, поэтому увеличение RAM не ускорит процесс.

Если машинное обучение работает на этом же сервере, первым при массовой обработке «падает» именно этот контейнер. Без лимитов он разрастается одновременно с задачей перекодирования, и ядро завершает тот процесс, который потребляет больше памяти. Поскольку он перезапускается за секунды, docker ps -a показывает его Up с временем работы (uptime), значительно меньшим, чем у соседних контейнеров, а не Exited (137), и очередь оказывается заметно более отстающей, чем при последней проверке.

Сервер на 8 ГБ: рекомендуемая конфигурация

8 ГБ с 4 ядрами соответствуют рекомендациям Immich, и все работает на настройках по умолчанию: умный поиск, обнаружение лиц, распознавание текста и перекодирование с заданным по умолчанию параллелизмом. Библиотеки объемом более ста тысяч объектов здесь работают комфортно, и нагрузка смещается с памяти на скорость диска, так как векторный индекс и запросы к метаданным — это то, чем база данных занята постоянно.

Установите лимиты в любом случае. На сервере с запасом ресурсов лимиты не дадут одной вышедшей из-под контроля очереди «потянуть за собой» базу данных. Если вы сравниваете стоимость с более дешевыми вариантами, реальная стоимость VPS в зависимости от объема памяти обычно делает тариф на 8 ГБ самым дешевым способом избежать необходимости в тонкой настройке.

Ограничение потребления памяти для сервиса через лимиты Compose

Не редактируйте docker-compose.yml для этой цели. Этот файл перезаписывается при каждом обновлении с помощью wget. Укажите лимиты в docker-compose.override.yml рядом с ним, который docker compose объединяет автоматически.

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 теперь должен отображать ваш предел в столбце MEM USAGE / LIMIT вместо общего объема памяти хоста. Если в столбце лимита по-прежнему указан полный объем памяти хоста, значит, файл переопределения не был применен: проверьте имя файла и выполните docker compose config, чтобы увидеть итоговую объединенную конфигурацию.

Установите для базы данных значение 2048M или выше. В документации Immich указано, что 2 GB — это минимальный порог для базы данных при использовании лимитов ресурсов Docker. Слишком низкий лимит превращает медленно работающий сервис в нерабочий, поэтому увеличьте его, если контейнер начинает постоянно перезапускаться. Подробнее о механике работы можно прочитать в настройке лимитов памяти для сервиса в Docker Compose, включая информацию о том, почему deploy работает вне Swarm с использованием Compose v2.

Как отключить или перенести контейнер машинного обучения

На небольшом сервере перенос этого контейнера на другую машину — самый эффективный способ оптимизации ресурсов. Immich поддерживает запуск этого компонента на отдельном узле. Создайте следующий файл на втором хосте, которым может быть даже домашний компьютер, работающий только по вечерам:

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

Затем перейдите в веб-интерфейсе в раздел Administration, Settings, Machine Learning Settings, нажмите Add URL и введите http://<host>:3003. Версии Immich на обоих хостах должны совпадать, так как документация предупреждает, что расхождение версий может привести к ошибкам и нестабильной работе.

Этот порт передает превью изображений на другую машину в незашифрованном виде. Документация Immich указывает, что контейнер машинного обучения не имеет встроенных средств защиты, поэтому используйте его только в частной сети или настройте туннель WireGuard между двумя хостами. Никогда не открывайте порт 3003 для доступа из Интернета.

Если проблема заключается в самом факте постоянной работы контейнера с моделью, стоит изучить различия в требованиях к ресурсам PhotoPrism и Immich, прежде чем планировать дальнейшие действия.

Сколько дискового пространства требуется для библиотеки Immich?

Единого коэффициента не существует, так как четыре разных компонента растут с разной скоростью. Ниже приведен расчет для библиотеки из 50 000 фотографий и 500 коротких видео.

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

Значения 200 ГБ для фотографий и 60 ГБ для видео являются оценочными. Замените их на свои средние показатели перед покупкой оборудования, так как именно видео определяет итоговый объем: одна минута видео с телефона занимает больше места, чем сотня фотографий.

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

Строка 39 ГБ — это единственное опубликованное соотношение, которое предоставляет Immich: созданные миниатюры и перекодированные видео в среднем увеличивают размер библиотеки на 10–20 процентов. Этот диапазон зависит от того, какая доля ваших медиафайлов требует перекодирования для совместимости с браузерами. Библиотека, состоящая из JPEG, будет ближе к нижней границе этого диапазона.

База данных занимает 3 ГБ, что близко к фиксированным затратам. В документации Immich указано, что файлы базы данных обычно занимают от 1 до 3 ГБ, так как они содержат метаданные и поисковые векторы, а не сами пиксели изображений. Кэш моделей занимает 2 ГБ и увеличивается, если вы активируете несколько моделей или тестируете разные варианты. В FAQ этот объем отмечен как значимый потребитель пространства именно по этой причине.

Сумма пяти строк составляет чуть более 300 ГБ, поэтому том на 500 ГБ оставляет место для роста, а том на 250 ГБ — нет. Отслеживайте распределение с помощью:

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

Внутри UPLOAD_LOCATION находятся шесть папок. upload и library хранят оригиналы, thumbs — превью и миниатюры лиц, encoded-video — перекодированные копии, profile — аватары, а backups — автоматические дампы базы данных. Только upload, library и profile являются незаменимыми, так как всё остальное можно восстановить на их основе.

Две вещи часто становятся неожиданностью. Удаленные объекты сначала попадают в корзину и продолжают занимать место, пока она не будет очищена, поэтому масштабная очистка не освобождает пространство в день её проведения. Дамп базы данных содержит только метаданные, поэтому он бесполезен без самих файлов:

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

Дополните это файловой копией оригиналов в хранилище вне сервера, для чего и предназначены резервные копии restic с VPS на внешнее хранилище.

Транскодирование ограничено мощностью CPU, а не объемом RAM

Увеличение объема RAM не ускорит транскодирование. Immich выполняет транскодирование с помощью FFmpeg, и на обычном VPS каждый кадр декодируется и кодируется силами CPU. Каждый процесс FFmpeg удерживает буферы декодированных кадров в оперативной памяти, поэтому в разделе импорта транскодирование учитывается как потребление памяти, но его скорость определяется CPU. Даже при наличии аппаратного ускорения в документации Immich указано, что по умолчанию ускоряется только кодирование, поэтому CPU всё равно выполняет декодирование и тональную компрессию (tone mapping), если вы дополнительно не включили аппаратное декодирование.

Для аппаратного ускорения требуется дополнительный файл hwaccel.transcoding.yml Compose, а также устройство для проброса с использованием NVENC, Quick Sync, RKMPP или VAAPI. Большинство тарифных планов VPS не предоставляют таких возможностей, поэтому рассчитывайте на ресурсы CPU.

Практически важным параметром является количество потоков. В разделе Administration, Settings, Video Transcoding Settings значение 0 означает использование всех ядер, из-за чего одно видео может «заморозить» веб-интерфейс на тарифе с 2 ядрами. Установите там значение 1 или 2, как рекомендуется в FAQ Immich, и транскодирование станет медленным, но не будет мешать работе системы.

Почему импорт при swap thrashing выглядит как зависание

Это сбой, который чаще всего интерпретируют неверно. Когда у Immich заканчивается память, возможны два исхода, и только один из них выглядит как явная ошибка.

Без swap ядро убивает процесс. Контейнер перезапускается в течение нескольких секунд, поэтому в браузере очередь задач просто останавливается, а затем возобновляется. Доказательства находятся в 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) означает, что процесс был завершен сигналом 9. 137 — это 128 плюс 9. Вы видите этот статус только пока контейнер остановлен. Как только политика перезапуска вернет его в строй, docker ps -a снова покажет Up, а время работы (uptime), значительно меньшее, чем у других контейнеров Immich, станет подсказкой. Сам по себе сигнал 9 не доказывает проблему с памятью, так как Docker отправляет его и при обычном завершении, если оно превышает таймаут. Значение OOMKilled, равное true, подтверждает, что процесс был убит из-за нехватки памяти, а после перезапуска контейнера строкам oom-kill из dmesg можно доверять как источнику истины.

При наличии swap ничего не завершается и ошибок не возникает. Ядро начинает перемещать страницы памяти на диск, скорость импорта падает на порядок, а веб-интерфейс перестает отвечать в рамках обычного таймаута. Все контейнеры запущены. Все проверки работоспособности (health checks) могут проходить успешно. Это выглядит как зависание, и в этот момент пользователи перезагружают сервер, что приводит к потере прогресса очереди и ничего не исправляет.

free -m
vmstat 1 5

Постоянные ненулевые значения в столбцах si и so утилиты vmstat означают, что машина непрерывно читает и записывает данные в swap, что и является определением thrashing. В это же время значение в строке free -m для используемого Swap будет расти.

В любом случае добавьте swap на машину с 2 ГБ или 4 ГБ памяти, потому что медленный импорт, который можно диагностировать, лучше, чем убитый контейнер, причину которого вы не видите:

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

Затем устраните причину. Уменьшите параллелизм задач до 1, ограничьте ресурсы контейнера машинного обучения или перенесите его на другой хост. Swap дает вам время на это. Сам по себе swap не является решением проблемы.

FAQ

Можно ли запустить Immich на VPS с 2 ГБ ОЗУ?

Ни в одной из конфигураций, описанных в документации Immich, это не предусмотрено. На странице системных требований указано 6 ГБ как минимум, 4 ГБ — как единственный вариант для работы с отключенными функциями машинного обучения, при этом база данных сама по себе требует не менее 2 ГБ при использовании лимитов ресурсов Docker. Комментирование сервиса immich-machine-learning и установка параллелизма задач (job concurrency) на 1 могут позволить запустить систему, но это неподдерживаемый компромисс, и Postgres — это сервис, который вероятнее всего будет завершен при импорте. Если у вас есть только 2 ГБ, добавьте файл подкачки (swap) объемом 2 ГБ, чтобы при пиковой нагрузке во время импорта сервер замедлялся, а не приводил к завершению контейнера. Если вы только выбираете тарифный план, начинайте с 4 ГБ.

Почему импорт в Immich останавливается без сообщения об ошибке?

Две разные причины выглядят в браузере одинаково. Либо контейнер был завершен из-за нехватки памяти и уже перезапустился (в этом случае docker ps -a показывает его Up с подозрительно малым временем работы, а Exited (137) появляется только если вы застанете его в остановленном состоянии), либо хост использует swap, и тогда все контейнеры продолжают работать, но всё просто очень медленно. vmstat 1 5 помогает их различить: устойчивые ненулевые значения в столбцах si и so означают использование swap. В любом случае уменьшите параллелизм задач для генерации миниатюр, распознавания лиц и интеллектуального поиска.

Что означает код завершения 137 в логах Immich?

137 — это 128 плюс сигнал 9, значит, процесс был завершен сигналом SIGKILL. На сервере с Immich это обычно означает достижение лимита памяти — либо собственного лимита контейнера, либо исчерпание памяти хоста. Однако сам по себе код это не доказывает: Docker также отправляет SIGKILL, если контейнер не останавливается в течение таймаута (по умолчанию 10 секунд в Linux). Проверьте с помощью docker inspect immich_machine_learning | grep -i oomkilled. Значение true подтверждает, что ядро завершило процесс из-за нехватки памяти, а free -m вместе с sudo dmesg -T | grep -i oom-kill покажут, был ли это лимит контейнера или всего хоста. Контейнер машинного обучения обычно становится жертвой, так как это самый ресурсоемкий процесс.

Сколько дискового пространства нужно Immich на одну фотографию?

Закладывайте объем исходного файла плюс 10–20 процентов. В документации Immich указано, что сгенерированные миниатюры и перекодированное видео увеличивают размер библиотеки в среднем на 10–20 процентов, а сама база данных обычно занимает от 1 до 3 ГБ даже для большой библиотеки. Видео — это основной фактор, определяющий итоговый объем, поэтому перед выбором тарифа измерьте средний размер ваших файлов, а не просто умножайте количество фотографий на коэффициент.

Нужен ли для Immich GPU?

Нет. Все компоненты Immich работают на CPU. Видеокарта ускоряет инференс моделей в контейнере машинного обучения и кодирование видео, но ни то, ни другое не является обязательным. Большинство тарифов VPS не предоставляют GPU. На оборудовании только с CPU установите количество потоков перекодирования на 1 или 2, используйте модель распознавания лиц buffalo_s и оставьте первый массовый импорт на ночь.