Berapa RAM dan Disk yang Dibutuhkan Immich?

Berapa banyak RAM yang dibutuhkan Immich?

Immich membutuhkan RAM (random access memory) sebesar 6 GB sebagai minimum yang didokumentasikan dan merekomendasikan 8 GB, dengan 2 core CPU pada batas bawah dan 4 core untuk instalasi yang nyaman. Angka tersebut mencakup seluruh stack, karena Immich terdiri dari empat container, bukan satu aplikasi. Menjelajahi library yang sudah diimpor tidak membutuhkan banyak sumber daya. Sebagian besar memori digunakan saat proses impor, dan sebagian besar penggunaan tersebut berasal dari satu container yang dapat Anda nonaktifkan.

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

Angka tersebut merupakan angka yang dipublikasikan pada halaman persyaratan Immich per Agustus 2026. Angka itu adalah rekomendasi ukuran, bukan pemeriksaan yang dilakukan software saat startup. Immich tetap dapat dimulai dengan RAM yang lebih kecil. Pada server yang lebih kecil, yang berubah adalah background job yang dapat selesai dan perilaku proses impor saat memori habis.

Ada satu batasan nyata yang tidak dapat diabaikan. Immich versi 3 dan yang lebih baru membutuhkan x86-64-v2 CPU pada host amd64. Persyaratan ini mencakup sebagian besar prosesor yang dijual sejak sekitar 2012. Pada hardware yang lebih lama, container gagal dimulai, bukan berjalan lebih lambat.

Jika Anda belum memulai instalasi, ikuti panduan lengkap instalasi Immich pada VPS dengan Docker Compose, lalu kembali ke sini untuk menentukan ukuran server.

Ke mana memori digunakan: empat container

File Compose resmi menjalankan empat service. Masing-masing memiliki pola penggunaan memori yang berbeda, sehingga satu angka total menyembunyikan bagian yang penting.

immich-server menyediakan antarmuka web dan API, serta menjalankan worker tugas latar belakang. Dua worker berada di dalam satu container tersebut. api menangani permintaan dari browser dan aplikasi seluler. microservices menjalankan antrean, termasuk pembuatan thumbnail dan encoding video. Variabel IMMICH_WORKERS_INCLUDE dan IMMICH_WORKERS_EXCLUDE memisahkan keduanya ke dalam container yang berbeda. Dengan begitu, Anda dapat memberikan batas memori tersendiri kepada bagian yang menghasilkan beban tinggi tanpa membatasi bagian yang menyajikan foto.

database adalah image PostgreSQL 14 dengan ekstensi VectorChord yang sudah disertakan. Service ini menyimpan semua metadata dan satu vektor pencarian untuk setiap aset. Dokumentasi Immich menetapkan batas minimum eksplisit satu-satunya dalam stack ini: jika Anda menerapkan batas resource Docker, database memerlukan setidaknya 2 GB. Halaman yang sama menyatakan bahwa database harus berada pada penyimpanan SSD lokal, bukan pada share jaringan dalam bentuk apa pun. Pencarian vektor dan indeks terdiri dari pembacaan acak berukuran kecil, sehingga volume jaringan mengubah setiap pembacaan menjadi perjalanan pulang-pergi. Jika pilihan paket bergantung pada hal tersebut, perbedaan antara penyimpanan SSD NVMe dan SATA pada VPS lebih penting di sini daripada di bagian lain stack ini.

redis menjalankan image Valkey dan menyimpan antrean tugas. Dari keempat service, service ini memiliki kebutuhan memori yang paling kecil dengan selisih jauh, karena yang disimpan adalah catatan tugas, bukan data foto.

immich-machine-learning adalah service yang menentukan ukuran paket Anda. Service ini memuat model untuk pencarian cerdas, deteksi wajah, dan pengenalan teks. Model yang sudah dimuat tetap berada di memori. MACHINE_LEARNING_MODEL_TTL memiliki nilai default 300, sehingga model dikeluarkan setelah tidak ada permintaan selama lima menit dan dibaca kembali dari volume /cache saat ada permintaan berikutnya. Selama impor massal, tidak pernah ada jeda lima menit. Karena itu, model tetap dimuat sejak aset pertama hingga aset terakhir.

Perubahan selama proses import

Immich yang sedang idle tidak banyak beraktivitas. Masalah pada server kecil biasanya terjadi saat import, karena pengunggahan satu aset memicu rangkaian job dan beberapa queue berjalan secara bersamaan.

Ekstraksi metadata membaca header file dan bebannya ringan. Pembuatan thumbnail membutuhkan lebih banyak sumber daya. Immich membuat tiga output thumbnail untuk setiap aset: placeholder thumbhash yang diburamkan, preview WebP, dan thumbnail JPEG, ditambah satu thumbnail untuk setiap wajah yang terdeteksi. Setiap job tersebut melakukan decoding gambar, dan konkurensi job menentukan jumlah gambar yang didekode secara bersamaan. Konkurensi adalah pengali yang mengubah beban kecil per job menjadi beban di seluruh server. Karena itu, FAQ Immich menyebutnya sebagai hal pertama yang perlu diturunkan pada mesin dengan sumber daya terbatas. Atur konkurensi untuk queue yang berat menjadi 1 melalui Administration, Settings, Job Settings.

Aset video menambahkan proses transcoding. Setiap job transcoding adalah proses FFmpeg terpisah dengan penggunaan memorinya sendiri, dan proses tersebut akan menggunakan setiap thread CPU yang Anda izinkan.

Smart search mengirim setiap aset baru ke container machine learning untuk menghitung satu vektor embedding. Deteksi wajah menjalankan model kedua pada gambar yang sama. Saat pertama kali mengimpor pustaka foto yang sudah ada, kedua queue tersebut memproses setiap aset yang Anda miliki selama berjam-jam. Inilah saat penggunaan memori mencapai titik tertinggi dalam seluruh instalasi, dan kondisi ini hanya terjadi sekali.

Mengapa pengenalan wajah dan objek membutuhkan RAM paling besar

Pemrosesan wajah terdiri dari dua pekerjaan. Deteksi wajah menjalankan model di dalam container machine learning dan menemukan kotak wajah. Pengenalan wajah kemudian mengelompokkan hasil deteksi tersebut berdasarkan orang, lalu langkah ini melakukan kueri ke indeks vektor di Postgres. Jadi, pustaka yang besar membebani kedua service secara bergantian: container model saat deteksi berjalan, lalu database saat pengelompokan berlangsung.

Empat pengaturan memengaruhi isi container machine learning.

• Model wajah. Immich menyertakan buffalo_l secara default, dan FAQ merekomendasikan buffalo_s pada server kecil. Model ini lebih kecil, sehingga menggunakan lebih sedikit memori dan berjalan lebih cepat, tetapi akurasinya pada wajah kecil atau tampak menyamping lebih rendah.
• Jumlah worker. MACHINE_LEARNING_WORKERS memiliki nilai default 1. Setiap worker merupakan proses terpisah yang memuat salinan modelnya sendiri, sehingga menaikkannya menjadi 2 secara kasar menggandakan memori model resident. Biarkan pada 1 kecuali RAM Anda mencukupi.
• Ukuran batch. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION membatasi jumlah wajah yang diproses sekaligus. Batch disimpan bersama di memori, sehingga foto grup dengan empat puluh wajah menggunakan lebih banyak memori daripada foto potret.
• Jenis model yang dijalankan. Smart search, deteksi wajah, dan pengenalan teks masing-masing memuat modelnya sendiri. Menonaktifkan fitur yang tidak digunakan melalui Administration, Settings, Machine Learning Settings akan menghapus penggunaan memorinya secara permanen, bukan hanya di antara proses import.

Ada juga MACHINE_LEARNING_MODEL_ARENA, yang didokumentasikan sebagai pengalokasian awal memori CPU untuk mencegah fragmentasi dan aktif secara default. Ubah pengaturan ini terakhir. Dampaknya bergantung pada memory allocator yang digunakan, sehingga satu-satunya cara yang dapat diandalkan untuk menilainya adalah memantau docker stats sebelum dan sesudah perubahan.

Tiga profil teruji: 2 GB, 4 GB, dan 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"
  }
]

Anggap nilai tersebut sebagai batas yang dimasukkan ke Compose, bukan sebagai ukuran penggunaan Immich. Batas adalah nilai maksimum. Batas tidak mencadangkan resource dan tidak membuat service menjadi lebih kecil. Batas menentukan service yang akan dihentikan oleh kernel saat resource server habis. Keputusan itu lebih baik Anda tentukan daripada membiarkan scoring kernel yang menentukannya.

Server 2 GB: hapus container machine learning

2 GB berada di bawah minimum terdokumentasi sebesar 6 GB. Jadi, ini adalah kompromi dan perlu disebutkan demikian. Beri komentar pada seluruh service immich-machine-learning di docker-compose.yml, atau biarkan service tersebut berjalan dan nonaktifkan setiap model melalui Administration, Settings, Machine Learning Settings. Menghapus container adalah pilihan yang lebih kuat karena model yang dinonaktifkan masih menyisakan proses Python di memori.

Anda tetap dapat menggunakan upload, album, berbagi, backup seluler, thumbnail, serta pencarian berdasarkan tanggal, lokasi, dan nama file. Anda tidak dapat menggunakan pencarian berdasarkan deskripsi, pengelompokan wajah secara otomatis menjadi orang, dan pengenalan teks di dalam gambar.

Keempat batas tersebut berjumlah sekitar 1.7 GB. Host hanya menyisakan sekitar 300 MB. Perhatikan bahwa 768 MB untuk database berada di bawah batas minimum terdokumentasi sebesar 2 GB. Inilah kompromi yang dipaksakan oleh server 2 GB. Karena itu, Postgres adalah service yang paling mungkin dihentikan di sini.

Yang pertama bermasalah adalah proses import, bukan penelusuran. Library dengan jumlah foto sekitar puluhan ribu masih dapat ditelusuri dengan baik setelah selesai diimpor karena penyajian halaman hanya memerlukan query metadata dan pembacaan file. Import yang banyak berisi video pada server yang sama akan menggunakan swap karena proses transcoding dan antrean thumbnail memerlukan memori pada waktu yang sama. Atur semua antrean berat ke concurrency 1 dan tambahkan file swap.

Server 4 GB: machine learning aktif, satu pekerjaan pada satu waktu

4 GB adalah ukuran terkecil yang membuat pengenalan wajah dan objek layak diaktifkan. Batasi container machine learning hingga 0 MB, ubah pengenalan wajah ke buffalo_s, dan atur concurrency pekerjaan ke 1 untuk pembuatan thumbnail, deteksi wajah, serta smart search.

Pemrosesan pertama pada library yang sudah ada akan berlangsung selama berjam-jam, dan pada library besar dapat berlangsung lebih dari satu hari. Batasnya berada pada CPU, bukan memori. Jadi, penambahan RAM tidak akan mempersingkat proses tersebut.

Pada kondisi ini, yang pertama bermasalah adalah container machine learning selama pemrosesan massal pertama. Jika tidak dibatasi, penggunaan memorinya meningkat saat pekerjaan transcoding juga meningkat. Kernel kemudian menghentikan proses yang lebih besar di antara keduanya. Anda akan melihat Exited (137) di docker ps -a dan container yang dimulai ulang. Saat itu, antrean berjalan lebih lambat daripada sebelumnya tanpa terlihat jelas.

Server 8 GB: rekomendasi terdokumentasi

8 GB dengan 4 core sesuai dengan rekomendasi Immich. Semua fitur berjalan dengan pengaturan default: smart search, deteksi wajah, pengenalan teks, dan transcoding, dengan concurrency default. Library dengan lebih dari seratus ribu aset masih dapat digunakan dengan nyaman. Beban kemudian bergeser dari memori ke kecepatan disk karena indeks vektor dan query metadata merupakan pekerjaan yang terus dilakukan database.

Tetapkan batas tersebut meskipun server masih memiliki resource yang cukup. Pada server dengan ruang memadai, batas mencegah satu antrean yang tidak terkendali ikut menghentikan database. Jika Anda membandingkan biayanya dengan opsi yang lebih kecil, biaya VPS berdasarkan tier memori biasanya membuat paket 8 GB menjadi pilihan termurah untuk menghindari penyesuaian berulang.

Cara membatasi memori per service dengan limit Compose

Jangan mengedit docker-compose.yml untuk ini. File tersebut diganti setiap kali Anda melakukan upgrade dengan wget. Letakkan limit di docker-compose.override.yml di sebelahnya. File tersebut akan digabungkan secara otomatis oleh 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 sekarang seharusnya menampilkan batas memori Anda pada kolom MEM USAGE / LIMIT, bukan total memori host. Jika kolom limit masih menampilkan ukuran penuh host, file override tidak dimuat. Periksa nama file, lalu jalankan docker compose config untuk melihat hasil penggabungannya.

Limit yang terlalu rendah dapat membuat service yang lambat berhenti sepenuhnya. Naikkan limit jika container mulai terus-menerus restart. Penjelasan tentang mekanismenya tersedia di mengatur limit memori per service di Docker Compose, termasuk alasan deploy dapat digunakan di luar Swarm dengan Compose v2.

Cara mematikan atau memindahkan container machine learning

Pada server kecil, memindahkan container ini ke tempat lain adalah perubahan terbesar yang dapat Anda lakukan. Immich mendukung pengoperasiannya pada mesin lain. Buat file ini pada host kedua. Host tersebut dapat berupa desktop yang hanya dinyalakan pada malam hari:

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

Selanjutnya, buka Administration, Settings, Machine Learning Settings pada antarmuka web, klik Add URL, lalu masukkan http://<host>:3003. Gunakan versi yang sama pada kedua host karena dokumentasi Immich memperingatkan bahwa ketidakcocokan versi di antara keduanya dapat menyebabkan bug dan ketidakstabilan.

Port tersebut mengirimkan foto Anda ke mesin lain tanpa enkripsi. Karena itu, gunakan port tersebut hanya pada jaringan privat atau jalankan melalui tunnel WireGuard antara kedua host. Jangan pernah mengekspos 3003 ke Internet.

Jika masalahnya adalah keberadaan container model yang terus berjalan, Anda juga dapat membandingkan perbedaan PhotoPrism dan Immich dalam hal komponen yang tetap berjalan saat idle sebelum menentukan ukuran paket.

Berapa kapasitas disk yang diperlukan library Immich?

Tidak ada satu pengali yang berlaku untuk semua kasus, karena empat komponen berbeda bertambah dengan laju yang berbeda. Berikut perhitungannya untuk library yang berisi 50,000 foto dan 500 video pendek.

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

Angka 200 GB untuk foto dan 60 GB untuk video adalah asumsi. Ganti dengan rata-rata Anda sendiri sebelum membeli perangkat apa pun, karena video paling menentukan angka ini: video ponsel berdurasi satu menit berukuran lebih besar daripada seratus foto.

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

Baris 39 GB adalah satu-satunya rasio yang dipublikasikan Immich: thumbnail yang dibuat dan video yang ditranskode menambah rata-rata 10 hingga 20 persen dari ukuran library. Rentang ini bergantung pada jumlah aset video yang perlu dienkode ulang agar kompatibel dengan browser. Library yang berisi file JPEG biasanya berada di batas bawah rentang tersebut.

Database berukuran 3 GB, dan angka ini hampir merupakan biaya tetap. Immich mendokumentasikan ukuran file database yang biasanya mencapai 1 hingga 3 GB, karena file tersebut menyimpan metadata dan vektor pencarian, bukan piksel. Cache model berukuran 2 GB dan bertambah jika Anda mengaktifkan beberapa model atau menguji model yang berbeda. FAQ menandai volume ini sebagai pengguna ruang yang besar karena alasan tersebut.

Kelima baris tersebut jika dijumlahkan menghasilkan sedikit lebih dari 300 GB. Jadi, volume 500 GB masih menyediakan ruang untuk pertumbuhan, sedangkan volume 250 GB tidak. Pantau pembagiannya dengan:

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

Enam folder berada di bawah UPLOAD_LOCATION. upload dan library menyimpan file asli, thumbs menyimpan pratinjau dan thumbnail wajah, encoded-video menyimpan salinan yang dienkode ulang, profile menyimpan avatar, dan backups menyimpan dump database otomatis. Hanya upload, library dan profile yang tidak dapat digantikan, karena semua komponen lainnya dapat dibuat ulang dari file tersebut.

Ada dua hal yang sering mengejutkan pengguna. Aset yang dihapus terlebih dahulu masuk ke trash dan tetap menggunakan ruang sampai trash dikosongkan. Karena itu, pembersihan besar tidak langsung membebaskan ruang pada hari yang sama. Selain itu, dump database hanya berisi metadata, sehingga tidak berguna tanpa file terkait:

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

Gabungkan langkah tersebut dengan penyalinan file asli pada level file ke lokasi di luar server. Itulah fungsi backup restic dari VPS ke penyimpanan di luar server.

Transcoding menggunakan CPU, bukan RAM

Menambah RAM tidak akan mempercepat transcoding. Immich melakukan transcoding dengan FFmpeg, dan pada VPS biasa setiap frame didekode dan dikodekan oleh CPU. Meskipun akselerasi perangkat keras tersedia, dokumentasi Immich menyebutkan bahwa hanya proses encoding yang dipercepat. CPU tetap melakukan decoding perangkat lunak dan tone mapping.

Akselerasi perangkat keras memerlukan file Compose tambahan hwaccel.transcoding.yml serta perangkat yang diteruskan ke container, menggunakan NVENC, Quick Sync, RKMPP, atau VAAPI. Sebagian besar paket VPS tidak menyediakan semua itu. Karena itu, rencanakan penggunaan CPU.

Pengaturan yang paling penting adalah jumlah thread. Di Administration, Settings, Video Transcoding Settings, nilai thread 0 berarti menggunakan semua core. Akibatnya, satu video dapat membuat antarmuka web tidak responsif pada paket 2 core. Atur nilainya menjadi 1 atau 2, seperti yang disarankan dalam FAQ Immich. Dengan begitu, proses transcoding menjadi lambat, tetapi tidak mengganggu layanan lain.

Mengapa proses import yang mengalami swap thrashing terlihat seperti hang

Ini adalah kegagalan yang paling sering disalahartikan. Saat Immich kehabisan memori, ada dua kemungkinan, dan hanya satu yang terlihat seperti kegagalan.

Tanpa swap, kernel menghentikan sebuah proses. Container dimulai ulang dalam hitungan detik, sehingga dari browser antrean pekerjaan hanya berhenti sementara lalu berjalan kembali. Buktinya ada di 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) berarti proses dihentikan dengan signal 9. 137 adalah 128 ditambah 9. Nilai OOMKilled sebesar true mengonfirmasi bahwa proses dihentikan karena masalah memori, bukan karena crash.

Dengan swap, tidak ada proses yang dihentikan dan tidak ada error. Kernel mulai memindahkan page ke disk, proses import melambat hingga satu tingkat besaran, dan antarmuka web berhenti merespons dalam batas waktu normal. Semua container tetap berjalan. Semua health check mungkin masih berhasil. Kondisinya terlihat seperti hang, lalu orang biasanya me-reboot mesin pada tahap ini. Tindakan tersebut menghilangkan progres antrean dan tidak mengubah penyebabnya.

free -m
vmstat 1 5

Nilai non-zero yang terus muncul pada kolom si dan so di vmstat berarti mesin terus membaca dan menulis swap. Inilah yang disebut thrashing. Baris free -m untuk Swap yang digunakan juga akan terus meningkat pada saat yang sama.

Tetap tambahkan swap pada mesin dengan RAM 2 GB atau 4 GB, karena import lambat yang masih dapat didiagnosis lebih baik daripada container yang dihentikan dan tidak dapat didiagnosis:

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

Kemudian perbaiki penyebabnya. Turunkan konkurensi pekerjaan menjadi 1, batasi penggunaan resource container machine learning, atau pindahkan container tersebut dari host ini. Swap memberi Anda waktu untuk melakukan tindakan tersebut. Swap bukan solusi tunggal.

FAQ

Dapatkah saya menjalankan Immich pada VPS 2 GB?

Ya, dengan service immich-machine-learning yang dikomentari di docker-compose.yml dan konkurensi job diatur ke 1. Jumlah tersebut berada di bawah minimum terdokumentasi sebesar 6 GB, jadi anggap ini sebagai kompromi yang diketahui. Anda tetap dapat menggunakan upload, album, berbagi, pencadangan seluler, serta pencarian berdasarkan tanggal, lokasi, dan nama file. Anda tidak dapat menggunakan pencarian berdasarkan deskripsi, pengelompokan wajah secara otomatis ke dalam people, dan pengenalan teks di dalam gambar. Tambahkan file swap 2 GB agar lonjakan beban saat import hanya memperlambat server, bukan menyebabkan container dihentikan.

Mengapa import Immich saya berhenti tanpa pesan error?

Dua penyebab yang berbeda dapat terlihat sama dari browser. Container mungkin dihentikan karena kekurangan memori; dalam kasus ini, docker ps -a menampilkan Exited (137) dan container sudah dimulai ulang. Atau, host mungkin menggunakan swap; dalam kasus ini, semua container masih berjalan dan seluruh sistem hanya menjadi sangat lambat. vmstat 1 5 membedakan kedua kondisi tersebut: angka non-zero yang terus muncul pada kolom si dan so berarti sistem sedang menggunakan swap. Dalam kedua kasus, turunkan konkurensi job untuk pembuatan thumbnail, deteksi wajah, dan pencarian cerdas.

Apa arti exit code 137 dalam log Immich?

137 adalah 128 ditambah signal 9, sehingga proses dihentikan dengan SIGKILL. Dalam praktiknya, ini berarti batas memori tercapai, baik batas milik container maupun karena host kehabisan memori. Periksa dengan docker inspect immich_machine_learning | grep -i oomkilled. Nilai true mengonfirmasi bahwa kernel menghentikannya karena masalah memori. Selanjutnya, free -m dan sudo dmesg -T | grep -i oom-kill menunjukkan apakah penyebabnya adalah batas container atau seluruh host. Container machine learning biasanya menjadi proses yang dihentikan karena umumnya merupakan proses terbesar.

Berapa banyak ruang disk yang diperlukan Immich untuk setiap foto?

Siapkan ruang sebesar file asli ditambah 10 hingga 20 persen. Dokumentasi Immich menyatakan bahwa thumbnail yang dibuat dan video yang ditranskode meningkatkan ukuran library rata-rata sebesar 10 hingga 20 persen. Database itu sendiri biasanya berukuran 1 hingga 3 GB, bahkan untuk library besar. Video yang paling menentukan total penggunaan ruang. Karena itu, ukur sendiri ukuran file rata-rata sebelum memilih paket, bukan menerapkan pengali pada jumlah foto.

Apakah saya memerlukan GPU untuk Immich?

Tidak. Semua bagian Immich dapat berjalan pada CPU. Kartu grafis mempercepat inferensi model di container machine learning dan encoding video, tetapi keduanya tidak wajib digunakan. Sebagian besar paket VPS tidak menyediakan GPU. Pada perangkat keras yang hanya menggunakan CPU, atur thread transcoding ke 1 atau 2, gunakan model wajah buffalo_s, dan biarkan import massal pertama berjalan semalaman.