Gaano karaming RAM at disk ang kailangan ng Immich?

Gaano karaming RAM ang kailangan ng Immich?

Nangangailangan ang Immich ng 6 GB ng RAM (random access memory) bilang nakadokumentong minimum at 8 GB bilang rekomendasyon nito, sa 2 CPU cores sa pinakamababang configuration at 4 para sa komportableng pag-install. Saklaw ng bilang na ito ang buong stack, dahil apat na container ang Immich at hindi isang application lamang. Kaunti lang ang memory na kailangan sa pag-browse ng library na na-import na. Napupunta ang memory sa proseso ng pag-import, at karamihan nito ay ginagamit ng isang container na maaari mong i-off.

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

Ito ang mga inilathalang bilang mula sa Immich requirements page noong August 2026. Rekomendasyon ang mga ito para sa pag-size, hindi check na ginagawa ng software sa startup. Nagsisimula ang Immich kahit mas kaunti ang memory. Sa mas maliit na server, nagbabago kung aling mga background job ang matatapos at kung ano ang mangyayari sa import kapag naubusan ng memory.

May isang tunay na hard limit. Kailangan ng Immich version 3 at mas bago ng x86-64-v2 CPU sa amd64 hosts. Saklaw nito ang karamihan ng mga processor na ibinebenta mula noong humigit-kumulang 2012. Sa mas lumang hardware, hindi nagsisimula ang container sa halip na mabagal lamang itong tumakbo.

Kung hindi mo pa nai-install ang system, magsimula sa buong pag-install ng Immich sa isang VPS gamit ang Docker Compose at bumalik dito para i-size ang server.

Kung saan napupunta ang memory: apat na container

Apat na service ang sinisimulan ng opisyal na Compose file. Magkakaiba ang memory profile ng bawat isa, kaya hindi ipinapakita ng isang pinagsamang total ang mahalagang detalye.

immich-server ang nagsisilbi sa web interface at API, at nagpapatakbo rin ito ng mga background job worker. Dalawang worker ang nasa loob ng iisang container na ito. api ang sumasagot sa mga request mula sa browser at mobile app. microservices ang nagpapatakbo ng mga queue, kabilang ang thumbnail generation at video encoding. Hinahati ng mga variable na IMMICH_WORKERS_INCLUDE at IMMICH_WORKERS_EXCLUDE ang dalawang ito sa magkahiwalay na container. Sa ganitong paraan, mabibigyan mo ng sariling memory limit ang mas maingay na bahagi nang hindi nililimitahan ang bahaging nagsisilbi sa iyong mga larawan.

database ay isang PostgreSQL 14 image na may built-in na VectorChord extension. Dito naka-store ang lahat ng metadata at isang search vector para sa bawat asset. Sa Immich docs, ang service na ito ang may tanging tahasang minimum requirement sa buong stack: kung maglalapat ka ng Docker resource limits, kailangan ng database ng hindi bababa sa 2 GB. Sinasabi rin sa parehong page na dapat nasa local SSD storage ang database at hindi kailanman nasa anumang network share, dahil maliliit at random reads ang vector at index lookup. Dahil dito, nagiging round trip ang bawat lookup kapag network volume ang ginamit. Kung nakasalalay rito ang pagpili ng plan, mas mahalaga rito kaysa sa iba pang bahagi ng stack ang pagkakaiba ng NVMe at SATA SSD storage sa isang VPS.

redis ang nagpapatakbo ng Valkey image at naglalaman ng mga job queue. Ito ang pinakamaliit sa apat, at malaki ang agwat, dahil job record ang iniimbak nito sa halip na photo data.

immich-machine-learning ang service na tumutukoy sa laki ng plan na kailangan mo. Naglo-load ito ng mga model para sa smart search, face detection, at text recognition. Nananatili sa memory ang isang model kapag na-load na. Ang default ng MACHINE_LEARNING_MODEL_TTL ay 300, kaya inaalis ang isang model makalipas ang limang minuto na walang request at muling binabasa mula sa /cache volume sa susunod na request. Sa panahon ng bulk import, walang limang minutong pagitan, kaya nananatiling naka-load ang mga model mula sa unang asset hanggang sa huli.

Ano ang nagbabago habang may import

Tahimik ang idle na Immich. Sa panahon ng import madalas bumibigay ang maliliit na server, dahil ang pag-upload ng isang asset ay naglalagay ng magkakasunod na job sa queue at sabay-sabay na tumatakbo ang ilang queue.

Binabasa ng metadata extraction ang file header at magaan ang load nito. Mas mabigat ang thumbnail generation. Gumagawa ang Immich ng tatlong thumbnail output para sa bawat asset: isang blurred thumbhash placeholder, isang WebP preview, at isang JPEG thumbnail. Gumagawa rin ito ng isa pang thumbnail para sa bawat na-detect na mukha. Bawat isa sa mga job na ito ay nagde-decode ng image, at tinutukoy ng job concurrency kung ilang image ang sabay-sabay na ide-decode. Ang concurrency ang multiplier na nagpapalaki sa maliit na per-job cost hanggang maging system-wide load. Kaya ito ang unang ipinapababa ng Immich FAQ sa constrained machine. Itakda sa 1 ang concurrency ng mabibigat na queue sa Administration, Settings, Job Settings.

Nagdudulot ng karagdagang load ang mga video asset dahil kailangan ng transcoding. Ang bawat transcode job ay hiwalay na FFmpeg process na may sariling memory. Gagamit ito ng bawat CPU thread na pinapayagan mo.

Ipinapadala ng Smart Search ang bawat bagong asset sa machine learning container upang mag-compute ng isang embedding vector. Nagpapatakbo ang face detection ng ikalawang model sa parehong image. Sa unang import ng isang dati nang photo library, tatakbo ang dalawang queue na ito sa bawat asset na pagmamay-ari mo, at maaaring tumagal nang ilang oras. Ito ang pinakamabigat na sandali para sa memory sa buong installation, at minsan lamang itong nangyayari.

Bakit pinakamaraming RAM ang kailangan ng pagkilala sa mukha at object

Dalawang trabaho ang pagproseso ng mukha. Nagpapatakbo ang face detection ng isang model sa machine learning container at hinahanap nito ang mga bounding box. Pagkatapos, pinagsasama ng facial recognition ang mga detection na ito ayon sa mga tao, at nagtatanong ang hakbang na iyon sa vector index sa Postgres. Kaya parehong naaapektuhan ang dalawang serbisyo kapag malaki ang library: ang model container habang tumatakbo ang detection, at ang database habang isinasagawa ang grouping.

Apat na setting ang nagbabago sa laman ng machine learning container.

• Ang face model. Bilang default, kasama sa Immich ang buffalo_l, at inirerekomenda ng FAQ ang buffalo_s para sa maliit na server. Mas maliit ang model na ito, kaya mas kaunti ang memory na ginagamit at mas mabilis itong tumatakbo. Kapalit nito, mas mababa ang accuracy sa maliliit o nakatagilid na mukha.
• Ang worker count. Ang default ng MACHINE_LEARNING_WORKERS ay 1. Hiwalay na process ang bawat worker at naglo-load ito ng sarili nitong kopya ng mga model, kaya kapag itinaas ito sa 2, humigit-kumulang dodoble ang resident model memory. Panatilihin ito sa 1 maliban kung may ekstrang RAM ka.
• Ang batch size. Nililimitahan ng MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION kung ilang mukha ang sabay-sabay na pinoproseso. Sabay-sabay na nasa memory ang isang batch, kaya mas maraming memory ang kailangan ng group photo na may forty na mukha kaysa sa isang portrait.
• Kung aling mga model type ang aktuwal na tumatakbo. May sarili nitong model ang smart search, face detection, at text recognition. Kapag pinatay mo ang mga hindi mo ginagamit sa Administration, Settings, Machine Learning Settings, permanente mong inaalis ang memory na ginagamit ng mga ito, sa halip na pansamantala lamang sa pagitan ng mga import.

Mayroon din MACHINE_LEARNING_MODEL_ARENA, na ayon sa dokumentasyon ay nag-pre-allocate ng CPU memory upang maiwasan ang fragmentation at naka-enable bilang default. Huli mo itong baguhin. Depende ang epekto nito sa memory allocator na ginagamit sa ilalim, kaya ang tanging maaasahang paraan para suriin ito ay i-monitor ang docker stats bago at pagkatapos.

Tatlong aktuwal na profile: 2 GB, 4 GB at 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"
  }
]

Ituring ang mga iyon bilang mga limitasyong ilalagay sa Compose, hindi bilang sukat ng aktuwal na ginagamit ng Immich. Ang limit ay ceiling lamang. Wala itong nirereserba at hindi nito pinapaliit ang isang service. Tinutukoy nito kung aling service ang papatayin ng kernel kapag naubusan ng memory ang server. Mas mainam na ikaw ang gumawa ng desisyong iyon kaysa ipaubaya ito sa sariling scoring ng kernel.

Ang 2 GB server: alisin ang machine learning container

Mas mababa ang 2 GB sa dokumentadong minimum na 6 GB, kaya kompromiso ito at dapat itong tukuyin bilang ganoon. I-comment out ang buong immich-machine-learning service sa docker-compose.yml, o panatilihin itong tumatakbo at i-disable ang bawat model sa Administration, Settings, Machine Learning Settings. Mas matibay na opsyon ang pag-alis ng container, dahil kahit disabled ang model ay may Python process pa ring nananatili sa memory.

Magagamit mo pa rin ang uploads, albums, sharing, mobile backup, thumbnails, at search ayon sa petsa, lugar at filename. Mawawala ang search ayon sa description, awtomatikong pagpapangkat ng mga mukha sa mga tao, at text recognition sa loob ng mga image.

Umaabot sa humigit-kumulang 1.7 GB ang kabuuan ng apat na limit, kaya nasa 300 MB na lang ang natitira sa host. Tandaan na mas mababa sa dokumentadong 2 GB floor ang 768 MB para sa database. Iyan mismo ang kompromisong ipinapataw ng 2 GB, kaya ang Postgres ang service na pinakamalamang mapatay rito.

Ang unang masisira ay ang import, hindi ang pag-browse. Katanggap-tanggap ang pag-browse sa library na nasa mababang sampu-sampung libong photo kapag na-import na ito, dahil ang pagsisilbi ng page ay metadata query kasama ng file read. Mag-swap ang server kapag video-heavy ang import sa parehong box, dahil sabay na nangangailangan ng memory ang transcode at thumbnail queue. Itakda sa concurrency 1 ang bawat heavy queue at magdagdag ng swap file.

Ang 4 GB server: naka-enable ang machine learning, tig-iisang job

Ang 4 GB ang pinakamaliit na size kung saan sulit nang i-enable ang face at object recognition. Limitahan ang machine learning container sa 0 MB, ilipat ang facial recognition sa buffalo_s, at itakda sa 1 ang job concurrency para sa thumbnail generation, face detection at smart search.

Tatagal nang maraming oras ang unang pagproseso sa kasalukuyang library, at mahigit isang araw sa malaking library. Limitasyon ito ng CPU, hindi ng memory, kaya hindi ito paiikliin ng dagdag na RAM.

Ang unang masisira rito ay ang machine learning container habang isinasagawa ang unang bulk pass. Kapag walang limit, lumalaki ito habang lumalaki rin ang transcode job, at papatayin ng kernel ang mas malaki sa dalawa. Makikita mo ang Exited (137) sa docker ps -a at isang nag-restart na container, habang tahimik na mas nahuhuli ang queue kaysa noong huli mo itong tiningnan.

Ang 8 GB server: ang dokumentadong rekomendasyon

Ang 8 GB na may 4 cores ay tugma sa rekomendasyon ng Immich, at tatakbo ang lahat gamit ang default settings: smart search, face detection, text recognition at transcoding, na may default concurrency. Komportable rito ang mga library na lampas isang daang libong asset. Lumilipat ang pressure mula memory papunta sa bilis ng disk, dahil ang vector index at metadata queries ang buong araw na pinoproseso ng database.

Itakda pa rin ang mga limit. Sa server na may sapat na resources, pinipigilan ng mga limit na ibagsak ng isang runaway queue ang database. Kung ikinukumpara mo ito sa mas maliliit na opsyon, karaniwang ipinapakita ng aktuwal na gastos ng VPS ayon sa memory tier na ang 8 GB plan ang pinakamurang paraan para hindi na kailangang patuloy na mag-tune.

Paano magtakda ng memory cap bawat service gamit ang Compose limits

Huwag i-edit ang docker-compose.yml para rito. Pinapalitan ang file na iyon sa bawat upgrade gamit ang wget. Ilagay ang limits sa docker-compose.override.yml sa tabi nito. Awtomatikong mina-merge ng docker compose ang mga ito.

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

Dapat nang ipakita ng docker stats ang itinakda mong ceiling sa column na MEM USAGE / LIMIT sa halip na ang kabuuang memory ng host. Kung ipinapakita pa rin ng limit column ang buong laki ng host, hindi nabasa ang override file. Suriin ang file name at patakbuhin ang docker compose config upang makita ang pinagsamang resulta.

Ang limit na masyadong mababa ay maaaring magdulot na tuluyang huminto ang mabagal na service. Taasan ito kung paulit-ulit na nagre-restart ang isang container. May higit pang detalye tungkol sa mekanismo sa pagtatakda ng memory limits bawat service sa Docker Compose, kabilang kung bakit gumagana ang deploy sa labas ng Swarm gamit ang Compose v2.

Paano i-off o ilipat ang machine learning container

Sa maliit na server, ang paglilipat ng container na ito sa ibang lugar ang pinakamalaking pagbabagong maaari mong gawin. Sinusuportahan ng Immich ang pagpapatakbo nito sa ibang machine. Gawin ang file na ito sa second host, na maaaring isang desktop na naka-on lamang tuwing gabi:

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

Pagkatapos, pumunta sa Administration, Settings, Machine Learning Settings sa web interface, i-click ang Add URL, at ilagay ang http://<host>:3003. Panatilihing pareho ang version sa dalawang host, dahil nagbababala ang Immich docs na nagdudulot ng mga bug at instability ang magkaibang version.

Ipinapadala ng port na iyon ang mga photo mo sa kabilang machine nang walang encryption. Kaya panatilihin ito sa private network o patakbuhin ito sa WireGuard tunnel sa pagitan ng dalawang host. Huwag kailanman i-expose ang 3003 sa internet.

Kung ang mismong ideya ng resident model container ang problema, makatuwiran ding ikumpara muna ang pagkakaiba ng PhotoPrism at Immich sa mga component na tumatakbo habang idle bago magpasya sa plan size.

Gaano karaming disk space ang kailangan ng isang Immich library?

Walang iisang multiplier, dahil apat na magkakaibang bagay ang lumalaki sa magkakaibang bilis. Narito ang pagkukuwenta para sa isang library na may 50,000 larawan at 500 maiikling video.

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

Mga palagay ang 200 GB ng mga larawan at 60 GB ng video. Palitan ang mga ito ng sarili mong average bago bumili ng anumang hardware, dahil video ang nagtatakda ng numerong ito: mas malaki ang isang minutong phone video kaysa sa isang daang larawan.

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

Ang row na 39 GB lamang ang published ratio na ibinibigay ng Immich: ang mga generated thumbnail at transcoded video ay karaniwang nagdaragdag ng 10 hanggang 20 porsiyento sa laki ng library. Saklaw ito dahil nakadepende ito sa dami ng asset mong video na kailangang i-re-encode para maging compatible sa browser. Ang library na puro JPEG ay karaniwang nasa mababang bahagi ng saklaw na ito.

Ang database ay 3 GB, at malapit ito sa fixed cost. Sinasabi sa dokumentasyon ng Immich na karaniwang 1 hanggang 3 GB ang database files, dahil metadata at search vectors ang laman ng mga ito, hindi pixels. Ang model cache ay 2 GB at lumalaki kapag nag-enable ka ng maraming model o sumubok ng iba’t ibang model. Tinutukoy ng FAQ ang volume na ito bilang kumokonsumo ng space dahil mismo sa kadahilanang iyon.

Ang limang row ay may kabuuang bahagyang higit sa 300 GB, kaya may sapat na puwang para lumaki ang 500 GB volume, samantalang kulang ang 250 GB volume. I-monitor ang pagkakahati ng space gamit ang:

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

May anim na folder sa ilalim ng UPLOAD_LOCATION. Nasa upload at library ang mga original, nasa thumbs ang mga preview at face thumbnail, nasa encoded-video ang mga re-encoded copy, nasa profile ang mga avatar, at nasa backups ang mga automatic database dump. Ang upload, library at profile lamang ang hindi maaaring palitan, dahil nare-regenerate ang lahat ng iba pa mula sa mga ito.

May dalawang bagay na ikinagugulat ng mga tao. Unang napupunta sa trash ang mga dinelete na asset at nananatili roon ang space ng mga ito hanggang sa ma-empty ang trash, kaya walang nalilikhang bakanteng space sa araw na gawin mo ang malaking cleanup. At metadata lamang ang database dump, kaya wala itong silbi kung wala ang mga file:

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

Ipares ito sa file-level copy ng mga original sa isang lokasyong nasa labas ng server. Ito ang gamit ng restic backups mula sa VPS papunta sa off-server storage.

Ang transcoding ay gumagamit ng CPU, hindi RAM

Hindi bibilis ang transcoding kapag nagdagdag ka ng RAM. Gumagamit ang Immich ng FFmpeg para sa transcoding, at sa isang karaniwang VPS, ang CPU ang nagde-decode at nag-e-encode ng bawat frame. Kahit may hardware acceleration, ayon sa dokumentasyon ng Immich, encoding lang ang pinabibilis nito. Software decoding at tone mapping pa rin ang ginagawa ng CPU.

Kailangan sa hardware acceleration ang karagdagang hwaccel.transcoding.yml Compose file at isang device na ipapasa sa container, gamit ang NVENC, Quick Sync, RKMPP, o VAAPI. Karamihan sa mga VPS plan ay walang alinman sa mga ito. Kaya magplano para sa CPU.

Ang praktikal na setting ay ang bilang ng thread. Sa Administration, Settings, Video Transcoding Settings, ang thread value na 0 ay nangangahulugang gagamitin ang lahat ng core. Dahil dito, maaaring ma-freeze ng isang video ang web interface sa isang 2 core plan. Itakda ito sa 1 o 2, gaya ng mungkahi sa Immich FAQ. Sa ganitong paraan, magiging mabagal ang transcoding sa halip na makaabala sa buong system.

Why a swap thrashing import looks like a hang

This is the failure people misread most often. When Immich runs out of memory there are two outcomes, and only one of them looks like a failure.

Without swap, the kernel kills a process. The container restarts within seconds, so from the browser the job queue simply stalls and then resumes. The evidence is in 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) means the process was killed with signal 9. 137 is 128 plus 9. An OOMKilled value of true confirms it was killed for memory rather than by a crash.

With swap, nothing is killed and nothing errors. The kernel starts moving pages to disk, the import slows by an order of magnitude, and the web interface stops answering within a normal timeout. Every container is running. Every health check may still pass. It looks like a hang, and people reboot the box at this point, which loses the queue progress and changes nothing.

free -m
vmstat 1 5

Sustained non zero values in the si and so columns of vmstat mean the machine is reading and writing swap continuously, which is the definition of thrashing. The free -m row for Swap used will be climbing at the same time.

Add swap anyway on a 2 GB or 4 GB box, because a slow import you can diagnose beats a killed container you cannot:

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

Then fix the cause. Lower job concurrency to 1, cap the machine learning container, or take it off this host. Swap buys you time to do that. It is not the answer on its own.

FAQ

Maaari ko bang patakbuhin ang Immich sa isang 2 GB VPS?

Oo, kapag naka-comment out ang immich-machine-learning service sa docker-compose.yml at nakatakda sa 1 ang job concurrency. Mas mababa ito sa dokumentadong minimum na 6 GB, kaya ituring itong isang alam na compromise. Mananatili ang uploads, albums, sharing, mobile backup, at paghahanap ayon sa petsa, lugar, at filename. Mawawala ang paghahanap ayon sa description, awtomatikong paggrupo ng mga mukha bilang mga tao, at text recognition sa loob ng mga image. Magdagdag ng 2 GB swap file upang bumagal ang server kapag may biglang import sa halip na ma-kill ang isang container.

Bakit humihinto ang Immich import ko nang walang error message?

May dalawang magkaibang sanhi na pareho ang hitsura sa browser. Maaaring na-kill ang isang container dahil sa memory; sa ganitong kaso, ipinapakita ng docker ps -a ang Exited (137) at nakapag-restart na ang container. Maaari ring nagso-swap ang host; sa ganitong kaso, tumatakbo pa rin ang lahat ng container at napakabagal lang ng buong system. Pinaghihiwalay ng vmstat 1 5 ang dalawang ito: ang tuloy-tuloy na non-zero na value sa mga column na si at so ay nangangahulugang may swapping. Ibaba ang job concurrency para sa thumbnail generation, face detection, at smart search sa alinmang kaso.

Ano ang ibig sabihin ng exit code 137 sa Immich logs?

Ang 137 ay 128 dagdag sa signal 9, kaya na-kill ang process gamit ang SIGKILL. Sa praktika, nangangahulugan itong naabot ang memory ceiling, alinman sa sariling limit ng container o dahil naubusan ng memory ang host. Suriin ito gamit ang docker inspect immich_machine_learning | grep -i oomkilled. Kinukumpirma ng value na true na na-kill ito ng kernel dahil sa memory, at ipinapakita naman ng free -m at sudo dmesg -T | grep -i oom-kill kung container limit o buong host ang sanhi. Karaniwang naaapektuhan ang machine learning container dahil ito ang karaniwang may pinakamalaking process.

Gaano karaming disk space ang kailangan ng Immich para sa bawat photo?

Maglaan ng espasyo para sa original file at karagdagang 10 hanggang 20 percent. Ayon sa dokumentasyon ng Immich, karaniwang nadaragdagan ng 10 hanggang 20 percent ang library size dahil sa generated thumbnails at transcoded video. Karaniwan ding umaabot sa 1 hanggang 3 GB ang database kahit malaki ang library. Ang video ang tunay na nagtatakda ng kabuuang kailangan mong espasyo, kaya sukatin ang sarili mong average file size bago pumili ng plan sa halip na maglapat ng multiplier sa bilang ng mga photo.

Kailangan ko ba ng GPU para sa Immich?

Hindi. Tumatakbo sa CPU ang bawat bahagi ng Immich. Pinabibilis ng graphics card ang model inference sa machine learning container at ang video encoding, ngunit hindi kinakailangan ang alinman sa mga ito. Karamihan sa VPS plan ay walang GPU. Sa CPU-only hardware, itakda sa 1 o 2 ang transcoding threads, gamitin ang buffalo_s face model, at hayaang tumakbo magdamag ang unang bulk import.