Скільки RAM і диска потрібно Immich

Скільки RAM потрібно Immich?

Immich потребує 6 GB RAM (оперативної пам’яті) як задокументований мінімум і 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 станом на August 2026. Це рекомендація щодо розміру сервера, а не перевірка, яку програмне забезпечення виконує під час запуску. Immich запускається і з меншим обсягом пам’яті. На менш потужному сервері змінюється те, які фонові завдання завершуються і що відбувається під час імпорту, коли пам’ять закінчується.

Є одне реальне жорстке обмеження. Immich version 3 і новіші версії потребують x86-64-v2 CPU на хостах amd64; це стосується більшості процесорів, проданих приблизно з 2012 року. На старішому обладнанні контейнер не запускається, а не працює повільніше.

Якщо ви ще не почали встановлення, спочатку перейдіть до повної інструкції зі встановлення Immich на VPS за допомогою Docker Compose, а потім поверніться сюди, щоб визначити необхідні ресурси сервера.

Куди витрачається пам’ять: чотири контейнери

Офіційний файл Compose запускає чотири сервіси. Кожен має власний профіль використання пам’яті, тому одне загальне число приховує важливі деталі.

immich-server обслуговує вебінтерфейс і API, а також запускає фонові worker-процеси. Два worker-процеси працюють у цьому одному контейнері. 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 визначає, скільки зображень декодується одночасно. Саме concurrency перетворює невелике навантаження від одного завдання на загальносистемне навантаження. Тому в FAQ Immich його названо першим параметром, який слід зменшити на сервері з обмеженими ресурсами. У розділі Administration, Settings, Job Settings встановіть concurrency для ресурсоємних черг у значення 1.

Відеоресурси додають транскодування. Кожне завдання транскодування запускає окремий процес FFmpeg із власним обсягом пам’яті та використовує всі дозволені йому потоки CPU.

Smart search передає кожен новий ресурс контейнеру машинного навчання для обчислення одного вектора embedding. Виявлення облич запускає другу модель для того самого зображення. Під час першого імпорту наявної бібліотеки фотографій обидві черги обробляють кожен ваш ресурс протягом кількох годин. У всій інсталяції саме в цей момент використовується найбільше пам’яті. Це відбувається один раз.

Чому розпізнавання облич і об’єктів потребує найбільше RAM

Обробка облич складається з двох етапів. Виявлення облич запускає модель у контейнері машинного навчання та знаходить обмежувальні рамки. Потім розпізнавання облич об’єднує ці результати за людьми, звертаючись до векторного індексу в Postgres. Тому велика бібліотека послідовно навантажує обидва сервіси: спочатку контейнер моделі під час виявлення, потім базу даних під час групування.

Чотири параметри визначають, що зберігає контейнер машинного навчання.

• Модель облич. Immich постачається з buffalo_l за замовчуванням, а в FAQ для невеликого сервера рекомендовано buffalo_s. Це менша модель, тому вона споживає менше пам’яті та працює швидше, але менш точно розпізнає маленькі обличчя та обличчя в профіль.
• Кількість worker-процесів. MACHINE_LEARNING_WORKERS має значення 1 за замовчуванням. Кожен worker є окремим процесом і завантажує власну копію моделей, тому збільшення значення до 2 приблизно подвоює обсяг резидентної пам’яті моделей. Залиште значення 1, якщо у вас немає вільної RAM.
• Розмір batch. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION обмежує кількість облич, які обробляються одночасно. Один batch зберігається в пам’яті цілком, тому групове фото із сорока обличчями потребує більше пам’яті, ніж портрет.
• Типи моделей, які взагалі запускаються. Smart search, face detection і text recognition завантажують власні моделі. Якщо вимкнути непотрібні функції в Administration, Settings, Machine Learning Settings, їхня пам’ять звільнятиметься постійно, а не лише між імпортами.

Є також MACHINE_LEARNING_MODEL_ARENA, який у документації описано як параметр попереднього виділення CPU-пам’яті для запобігання фрагментації. За замовчуванням він увімкнений. Змінюйте його в останню чергу. Його вплив залежить від використовуваного алокатора пам’яті, тому об’єктивно оцінити результат можна лише за допомогою моніторингу docker stats до та після зміни.

Три готові профілі: 2 GB, 4 GB і 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"
  }
]

Сприймайте їх як ліміти, які потрібно вказати в Compose, а не як вимірювання фактичного використання Immich. Ліміт — це верхня межа. Він нічого не резервує і не зменшує розмір сервісу. Він визначає, який сервіс kernel завершить, коли на сервері закінчиться пам’ять. Це рішення краще прийняти вам, а не залишати його на розсуд власного алгоритму оцінювання kernel.

Сервер із 2 GB: видаліть контейнер machine learning

2 GB — це менше за задокументований мінімум у 6 GB, тому це компроміс, який варто прямо позначити як такий. Закоментуйте весь сервіс immich-machine-learning у docker-compose.yml або залиште його запущеним і вимкніть усі моделі в Administration, Settings, Machine Learning Settings. Видалення контейнера — надійніший варіант, оскільки вимкнена модель усе одно залишає процес Python у пам’яті.

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

Чотири ліміти разом становлять приблизно 1.7 GB, тому хосту залишається близько 300 MB. Зверніть увагу, що ліміт бази даних у 768 MB менший за задокументований мінімум у 2 GB. Саме цього компромісу вимагає конфігурація з 2 GB, тому Postgres тут найімовірніше буде завершено першим.

Першим ламається імпорт, а не перегляд. Бібліотека з кількома десятками тисяч фотографій працює прийнятно після імпорту, оскільки відображення сторінки — це запит метаданих і читання файлу. Імпорт із великою кількістю відео на цьому сервері спричинить використання swap, оскільки транскодування та черга створення мініатюр одночасно потребують пам’яті. Встановіть для кожної важкої черги concurrency 1 і додайте swap-файл.

Сервер із 4 GB: machine learning увімкнено, по одному завданню

4 GB — це мінімальний обсяг, за якого варто ввімкнути розпізнавання облич і об’єктів. Обмежте контейнер machine learning значенням 0 MB, перемкніть розпізнавання облич на buffalo_s і встановіть concurrency 1 для створення мініатюр, виявлення облич і smart search.

Перший аналіз наявної бібліотеки триватиме багато годин, а для великої бібліотеки — понад добу. Тут обмеженням є CPU, а не пам’ять, тому більший обсяг RAM не скоротить цей час.

У цьому профілі під час першого масового аналізу першим ламається контейнер machine learning. Без ліміту він збільшується, поки одночасно збільшується завдання транскодування, і kernel завершує більший із двох процесів. У docker ps -a ви побачите Exited (137) і перезапущений контейнер, а черга непомітно відстане ще більше, ніж під час попередньої перевірки.

Сервер із 8 GB: задокументована рекомендація

8 GB і 4 ядер відповідають рекомендаціям Immich, тому все працює з типовими параметрами: smart search, розпізнавання облич, розпізнавання тексту та транскодування з типовим concurrency. Бібліотеки розміром понад сто тисяч об’єктів тут працюють без проблем, а навантаження зміщується з пам’яті на швидкість диска, оскільки база даних постійно працює з векторним індексом і запитами метаданих.

Усе одно встановіть ліміти. На сервері з достатнім запасом ресурсів ліміти не дадуть одній неконтрольованій черзі призвести до падіння бази даних. Якщо ви порівнюєте цей варіант із меншими конфігураціями, скільки насправді коштує VPS у різних категоріях обсягу пам’яті зазвичай показує, що план із 8 GB є найдешевшим способом уникнути постійного налаштування.

Як обмежити пам’ять для кожного сервісу за допомогою Compose limits

Не редагуйте 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: 1280M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

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

Тепер docker stats має показувати встановлену верхню межу в стовпці MEM USAGE / LIMIT, а не загальний обсяг пам’яті хоста. Якщо в стовпці обмеження й далі вказано повний обсяг пам’яті хоста, файл перевизначень не було застосовано. Перевірте ім’я файлу та виконайте docker compose config, щоб переглянути об’єднаний результат.

Занадто низьке обмеження перетворює повільний сервіс на непрацюючий. Збільште його, якщо контейнер починає постійно перезапускатися. Докладніше про механізм див. у матеріалі як встановити обмеження пам’яті для кожного сервісу в 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 зазначено, що розбіжності версій між ними спричиняють помилки та нестабільну роботу.

Цей порт передає ваші фотографії на іншу машину без шифрування, тому використовуйте приватну мережу або передавайте трафік через тунель 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 GB для фотографій і 60 GB для відео є припущеннями. Перед купівлею обладнання замініть їх власними середніми значеннями, оскільки саме відео визначає цей показник: одна хвилина відео з телефона займає більше місця, ніж сто фотографій.

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 GB — це єдине опубліковане співвідношення, яке наводить Immich: згенеровані мініатюри й перекодоване відео в середньому додають від 10 до 20 відсотків до розміру бібліотеки. Це діапазон, оскільки значення залежить від кількості відеофайлів, які потрібно перекодувати для сумісності з браузером. Бібліотека JPEG-файлів буде ближчою до нижньої межі цього діапазону.

База даних займає 3 GB, і це майже фіксований обсяг. У документації Immich зазначено, що файли бази даних зазвичай займають від 1 до 3 GB, оскільки містять метадані й пошукові вектори, а не пікселі. Кеш моделей займає 2 GB і збільшується, якщо ввімкнути кілька моделей або тестувати різні моделі. У FAQ цей том зазначено як споживач дискового простору саме з цієї причини.

П’ять рядків разом займають трохи більше ніж 300 GB, тому том на 500 GB залишає запас для зростання, а том на 250 GB — ні. Перевіряйте розподіл за допомогою:

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. Навіть якщо доступне апаратне прискорення, документація Immich зазначає, що воно прискорює лише кодування. Декодування та tone mapping усе одно виконуються програмно на CPU.

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

Практичний параметр — кількість потоків. У розділі Administration, Settings, Video Transcoding Settings значення потоків 0 означає використання всіх ядер. Через це одне відео може повністю заблокувати вебінтерфейс на тарифі з 2 ядрами. Встановіть там значення 1 або 2, як рекомендує FAQ Immich. Тоді транскодування буде повільним, але не заважатиме роботі системи.

Чому імпорт із надмірним використанням swap виглядає як зависання

Цю проблему найчастіше неправильно діагностують. Коли Immich вичерпує доступну пам’ять, можливі два результати, і лише один із них схожий на збій.

Без swap kernel завершує процес. Контейнер перезапускається за кілька секунд, тому в браузері черга завдань просто зупиняється, а потім продовжується. Докази наведено в 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. Значення OOMKilled у true підтверджує, що процес завершено через нестачу пам’яті, а не через аварійне завершення.

Із swap нічого не завершується і жодної помилки не виникає. Kernel починає переміщувати сторінки пам’яті на диск, імпорт сповільнюється на порядок, а вебінтерфейс перестає відповідати протягом стандартного тайм-ауту. Усі контейнери продовжують працювати. Усі health check можуть і надалі проходити успішно. Це схоже на зависання, тому на цьому етапі користувачі перезавантажують сервер. Унаслідок цього прогрес черги втрачається, але проблема не змінюється.

free -m
vmstat 1 5

Стабільні ненульові значення у стовпцях si і so у vmstat означають, що машина безперервно читає та записує swap. Це і є thrashing. Одночасно зростатиме ряд free -m для Swap used.

У будь-якому разі додайте swap на машині з 2 GB або 4 GB пам’яті, оскільки повільний імпорт, який можна діагностувати, кращий за завершений контейнер, причину збою якого неможливо встановити:

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, обмежте споживання ресурсів контейнером machine learning або перенесіть його на інший хост. Swap дає час для цього. Сам по собі swap не є рішенням.

FAQ

Чи можна запустити Immich на VPS із 2 GB RAM?

Так, якщо закоментувати сервіс immich-machine-learning у docker-compose.yml і встановити паралельність завдань на 1. Це менше за задокументований мінімум у 6 GB, тому вважайте це відомим компромісом. Ви збережете завантаження, альбоми, спільний доступ, мобільне резервне копіювання та пошук за датою, місцем і назвою файлу. Ви втратите пошук за описом, автоматичне групування облич за людьми та розпізнавання тексту всередині зображень. Додайте swap-файл розміром 2 GB, щоб під час імпорту сервер сповільнювався, а не завершував роботу контейнера.

Чому імпорт в Immich зупиняється без повідомлення про помилку?

З боку браузера дві різні причини виглядають однаково. Контейнер міг бути завершений через нестачу пам’яті; у такому разі docker ps -a показує Exited (137), а контейнер уже перезапущено. Або хост використовує swap; тоді всі контейнери продовжують працювати, але все стає дуже повільним. vmstat 1 5 дає змогу розрізнити ці випадки: стабільні ненульові значення у стовпцях si і so означають використання swap. В обох випадках зменште паралельність завдань для створення мініатюр, виявлення облич і інтелектуального пошуку.

Що означає код завершення 137 у журналах Immich?

137 — це 128 плюс сигнал 9, тому процес було завершено сигналом SIGKILL. На практиці це означає досягнення обмеження пам’яті: або власного ліміту контейнера, або нестачі пам’яті на хості. Перевірте це за допомогою docker inspect immich_machine_learning | grep -i oomkilled. Значення true підтверджує, що ядро завершило процес через нестачу пам’яті, а free -m і sudo dmesg -T | grep -i oom-kill показують, чи спрацював ліміт контейнера, чи пам’ять закінчилася на всьому хості. Зазвичай завершується контейнер machine learning, оскільки в ньому працює найбільший процес.

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

Заплануйте місце для оригінального файлу плюс 10–20 відсотків. В документації Immich зазначено, що згенеровані мініатюри й транскодоване відео в середньому збільшують розмір бібліотеки на 10–20 відсотків, а сама база даних зазвичай займає 1–3 GB навіть для великої бібліотеки. Загальний обсяг фактично визначає відео, тому перед вибором тарифу виміряйте власний середній розмір файлу, а не застосовуйте коефіцієнт до кількості фотографій.

Чи потрібен GPU для Immich?

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