Сколько RAM нужно для Immich

MAATRIX

Immich заводится демо-запуском на честных 2 ГБ и там же начинает тормозить, стоит включить распознавание лиц и умный поиск по содержимому фото. Разница не в объёме библиотеки — фото сами по себе лежат на диске и почти не трогают память, — а в том, что machine learning-контейнер держит в оперативке модели весом сотни мегабайт на каждый параллельный воркер. Ниже — по каким контейнерам расходится память, что именно её ест и сколько закладывать под свой сценарий: от личного архива на телефоне до общего альбома на всю семью.

Короткий ответ: сколько закладывать

Ориентир для стандартного docker-compose из четырёх контейнеров (immich-server, immich-machine-learning, PostgreSQL с векторным расширением, Redis) на Ubuntu 24.04. Цифры — не измеренный бенчмарк, а практический запас с учётом того, что каждый ML-джоб держит модель в памяти отдельно.

Правило простое: библиотека растит диск, а не память. Память растёт от числа одновременных фоновых задач — распознавание лиц на партии новых фото, транскодирование видео, генерация превью — и от того, сколько таких задач вы разрешили обрабатывать параллельно.

Из чего состоит Immich и куда уходит память

Стандартная поставка — это не один процесс, а стек из нескольких контейнеров, и у каждого своя роль в потреблении RAM.

Сервер на Node.js сам по себе лёгкий — он раздаёт API и складывает задачи в очередь Redis. Реальная нагрузка на диск и сеть при загрузке с телефона тоже не про RAM. А вот всё, что связано с анализом содержимого фото, живёт в отдельном ML-контейнере, и именно он определяет, влезете вы в 4 ГБ или нет.

Machine learning — главный пожиратель памяти

immich-machine-learning — это Python-процесс с ONNX Runtime, который держит в памяти две категории моделей: детекцию и распознавание лиц (модели семейства InsightFace, обычно 300–500 МБ) и CLIP-модель для умного поиска по тексту («найди фото с собакой на пляже»). Размер CLIP-модели задаётся в настройках job — от компактной ViT-B-32 (сотни мегабайт) до более точной ViT-L-14 (полтора-два гигабайта и выше). Модель загружается один раз на контейнер, но каждый параллельный воркер, обрабатывающий партию фото, добавляет свою долю к пиковому потреблению.

Параллельность настраивается в админке (Administration → Settings → Job Settings) отдельно для Face Detection, Smart Search, Thumbnail Generation и Video Transcoding — по умолчанию она рассчитана на многоядерный сервер, и на слабой машине её стоит снизить вручную:

Machine Learning → Concurrency: 1
Face Detection → Concurrency: 1
Smart Search → Concurrency: 1

Environment-переменные ML-контейнера, которые реально экономят память:

# docker-compose.yml, сервис immich-machine-learning
environment:
  MACHINE_LEARNING_MODEL_TTL: 300       # выгружать модель из памяти через 5 минут простоя
  MACHINE_LEARNING_MODEL_TTL_POLL_S: 10

MODEL_TTL — не панацея: пока задача идёт, модель занимает память в любом случае, а выгрузка после простоя просто не даёт ей висеть в фоне между сессиями массовой загрузки. Проверить, сколько реально забрал контейнер, проще всего живьём:

docker stats immich_machine_learning --no-stream

Если после первой же партии новых фото значение MEM USAGE держится на 1,5–2 ГБ и не спадает — это загруженные модели, не утечка.

Postgres и векторный индекс: растёт вместе с библиотекой

Каждое фото после обработки ML получает векторный эмбеддинг — числовой вектор на несколько сотен измерений, — и он хранится в PostgreSQL через расширение с поддержкой векторов. В отличие от файлов на диске, этот индекс живёт частично в оперативной памяти через shared_buffers, и на больших библиотеках именно он, а не сами фото, начинает требовать памяти под базу.

Грубая прикидка: вектор на 512 измерений в float32 — это 2 КБ на фото без учёта индекса; для приближённого поиска (HNSW-подобные индексы) накладные расходы обычно кратно больше самих векторов. Для библиотеки в 50 000 фото это единицы, а не десятки гигабайт, но при 500 000+ фото и активном текстовом поиске стоит явно выделить базе больше shared_buffers, а не оставлять дефолт:

# postgresql.conf внутри контейнера
shared_buffers = 512MB
work_mem = 16MB
maintenance_work_mem = 128MB

Если у вас уже есть опыт расчёта памяти под векторные индексы отдельно — тот же принцип разбирали в статье сколько RAM нужно для Qdrant: логика роста индекса от числа векторов и их размерности идентична, разница только в том, что в Immich это встроено в Postgres, а не вынесено в отдельную базу.

Транскодирование видео и импорт с телефона — пиковые нагрузки

Живые видео и обычные видеозаписи с телефона Immich перекодирует через ffmpeg, чтобы получить единый формат для веб-плеера и превью. Задача разовая, но прожорливая: память под транскодирование растёт с разрешением исходника, и 4K-ролик с айфона — это заметно больше, чем видео 1080p. Отдельная переменная задаёт кодек и профиль:

Settings → Video Transcoding → 
Accepted quality/codec, hardware acceleration (если сервер это поддерживает)

На VPS без GPU аппаратного ускорения обычно нет, и вся перекодировка идёт на CPU — это в первую очередь вопрос процессора и времени, а не памяти, но при высокой параллельности несколько одновременных ffmpeg-процессов на 4K-видео вполне могут добавить по 200–400 МБ каждый.

Второй источник пиков — фоновая синхронизация с телефона: приложение Immich по умолчанию грузит фото и видео пачками при подключении к Wi-Fi, и сервер получает разом десятки-сотни файлов, которые сразу встают в очередь на превью, детекцию лиц и эмбеддинги. Если пользователей несколько и у всех включён автобэкап, такие всплески могут совпадать по времени — держите это в уме при выборе Concurrency, а не только средней загрузки.

Как ограничить и замерить память по контейнерам

Прежде чем менять тариф, полезно понять, кто из четырёх контейнеров реально упирается в потолок:

docker stats --no-stream immich_server immich_machine_learning immich_postgres immich_redis

Если контейнеры регулярно уходят в OOM, а не просто тормозят, ищите в dmesg:

dmesg -T | grep -i "out of memory"

Жёсткие лимиты по контейнерам в docker-compose.yml дисциплинируют ML-сервис, не давая ему забрать всё свободное:

services:
  immich-machine-learning:
    deploy:
      resources:
        limits:
          memory: 2g

Правило здесь простое: лимит должен быть выше реального пика (замеренного через docker stats), иначе контейнер начнёт падать по OOM прямо посреди обработки партии фото — это не экономит память, а просто переносит проблему из «тормозит» в «падает». Общие принципы работы с лимитами cgroup для Docker разобраны в статье про ресурсы и лимиты CPU и памяти; если после настройки лимитов сервер всё равно регулярно упирается в потолок — гайд что делать при нехватке RAM описывает порядок действий: своп, earlyoom, приоритеты процессов.

Какой сервер под Immich взять в MAATRIX

Минимум для личного архива: 2 vCPU, 4 ГБ RAM, от 60 ГБ NVMe. С такой конфигурацией распознавание лиц и умный поиск лучше держать на Concurrency: 1, чтобы не спорить за память с базой и веб-сервером. Для одного человека и библиотеки в несколько тысяч фото этого достаточно с запасом.

Комфортный вариант для семьи: 4 vCPU, 8 ГБ RAM, 160–250 ГБ NVMe. Это конфигурация, при которой можно спокойно включить и распознавание лиц, и умный поиск по CLIP на 3–6 человек с автобэкапом с телефонов. Диск здесь важнее процессора — фото и видео копятся быстро, и NVMe нужен в первую очередь под объём, а не под скорость случайного доступа.

Активная библиотека и видео: 6–8 vCPU, 16 ГБ RAM, от 300 ГБ NVMe. Если в семье несколько активных фотографов, много видео в 4K и библиотека перевалила за сотню тысяч фото — здесь пригодится и запас памяти под параллельные ML-джобы, и процессор под транскодирование.

Локация. Автобэкап с телефона — это постоянный фоновый трафик небольшими порциями, и задержка тут менее критична, чем для интерактивной синхронизации файлов: важнее стабильность канала, чем миллисекунды RTT. Если все пользователи в России — берите российский сервер, это снимает вопрос трансграничной передачи персональных данных (фото с геометками лиц — как раз такие данные) и даёт более предсказуемую скорость закачки с российских мобильных сетей. Для доступа из-за рубежа или если важна независимость от российской юрисдикции — Лондон или США подойдут без разницы по нагрузке на RAM, разница будет только в задержке интерфейса при просмотре альбомов.

Immich можно развернуть на сервере из каталога apps.maatrix.io — автоустановка настраивает docker-compose со всеми четырьмя контейнерами, а доступ и пароль появляются в личном кабинете. Дальше вы уже сами подгоняете Concurrency в настройках job под свой тариф и включаете распознавание лиц, когда убедитесь, что памяти хватает с запасом. Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT, без необходимости в иностранной карте даже для лондонской или американской площадки.

Частые вопросы