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

Існує одне справжнє жорстке обмеження. Починаючи з version 3, контейнер машинного навчання на хостах amd64 потребує CPU з підтримкою x86-64-v2, яку мають більшість процесорів, випущених приблизно з 2012 року. Ця вимога стосується контейнера, а не сервера. Тому на старішому обладнанні можна вимкнути машинне навчання, запускати його на іншій машині, як описано нижче, або залишитися на v2.7.5, яку документація Immich називає останньою сумісною версією.

Якщо ви ще не встановлювали Immich, почніть із повного встановлення 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, тому для host залишається близько 300 MB. Зверніть увагу, що 768 MB для database менше за задокументований мінімум 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 показує, що він Up, із часом роботи, значно меншим за час роботи сусідніх контейнерів, а не Exited (137). Через це черга непомітно відстає сильніше, ніж під час попередньої перевірки.

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

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

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

Це збій, який найчастіше неправильно інтерпретують. Коли 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, а значно менший час роботи порівняно з іншими контейнерами Immich є важливою ознакою. Сам сигнал 9 не доводить наявність проблеми з пам’яттю, оскільки Docker також надсилає його, коли звичайна зупинка перевищує встановлений час очікування. Значення OOMKilled, що дорівнює true, підтверджує завершення процесу через нестачу пам’яті, а після перезапуску контейнера саме рядки oom-kill з dmesg є надійним джерелом інформації.

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

free -m
vmstat 1 5

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

Усе одно додайте 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 оперативної пам’яті?

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

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

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

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

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

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

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

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

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