Bởi Immich cần bao nhiêu RAM và disk?
Immich ghi 6 GB RAM là mức tối thiểu. Xem server, Postgres, Redis và machine learning cần bao nhiêu, cùng cách chạy Immich trên máy 4 GB.
Immich cần bao nhiêu RAM?
Immich yêu cầu 6 GB RAM (bộ nhớ truy cập ngẫu nhiên) theo mức tối thiểu được ghi trong tài liệu và khuyến nghị 8 GB, với 2 lõi CPU ở mức thấp nhất và 4 lõi để cài đặt và sử dụng thoải mái. Con số này áp dụng cho toàn bộ stack, vì Immich gồm 4 container thay vì một ứng dụng duy nhất. Duyệt thư viện đã import không tốn nhiều tài nguyên. RAM chủ yếu được dùng khi import, và phần lớn tập trung ở một container mà bạn có thể tắt.
The data behind this chart
[
{
"label": "Documented minimum",
"ram_gb": 6,
"cpu_cores": 2
},
{
"label": "Documented recommended",
"ram_gb": 8,
"cpu_cores": 4
}
]Đây là các con số được công bố trên trang yêu cầu hệ thống của Immich tính đến tháng 8 năm 2026. Đây là khuyến nghị để ước tính cấu hình, không phải điều kiện kiểm tra khiến phần mềm không thể khởi động. Immich vẫn khởi động được với ít RAM hơn. Trên server nhỏ hơn, điểm khác biệt là các background job nào hoàn tất được và quá trình import xử lý ra sao khi hết RAM.
Có một giới hạn cứng thực sự. Immich phiên bản 3 trở lên cần CPU x86-64-v2 trên host amd64, bao phủ phần lớn các processor được bán từ khoảng năm 2012. Trên phần cứng cũ hơn, container sẽ fail khi khởi động thay vì chỉ chạy chậm.
Nếu bạn chưa bắt đầu cài đặt, hãy xem hướng dẫn cài đặt Immich đầy đủ trên VPS bằng Docker Compose, sau đó quay lại đây để chọn cấu hình máy.
Bộ nhớ được dùng ở đâu: bốn container
File Compose chính thức khởi động bốn service. Mỗi service có kiểu sử dụng bộ nhớ khác nhau, nên một con số tổng sẽ che mất phần thông tin hữu ích.
immich-server cung cấp giao diện web và API, đồng thời chạy các background job worker. Hai worker nằm trong cùng container đó. api xử lý request từ browser và ứng dụng mobile. microservices chạy các queue, bao gồm tạo thumbnail và mã hóa video. Các biến IMMICH_WORKERS_INCLUDE và IMMICH_WORKERS_EXCLUDE tách hai thành phần này thành các container riêng. Nhờ đó, bạn có thể đặt memory limit riêng cho phần gây tải cao mà không giới hạn phần phục vụ ảnh.
database là image PostgreSQL 14 có tích hợp extension VectorChord. Nó lưu toàn bộ metadata và một search vector cho mỗi asset. Tài liệu Immich đặt ra mức tối thiểu rõ ràng duy nhất cho database trong stack này: nếu áp dụng Docker resource limit, database cần ít nhất 2 GB. Trang này cũng nêu rằng database phải dùng local SSD storage, tuyệt đối không dùng network share dưới bất kỳ hình thức nào, vì các thao tác tra cứu vector và index là những lần đọc ngẫu nhiên nhỏ. Network volume sẽ biến mỗi lần đọc thành một round trip. Nếu lựa chọn plan phụ thuộc vào yếu tố này, khác biệt giữa NVMe và SATA SSD trên VPS quan trọng ở đây hơn bất kỳ thành phần nào khác trong stack.
redis chạy Valkey image và lưu các job queue. Đây là service nhỏ nhất trong bốn service với cách biệt lớn, vì nó lưu job record thay vì dữ liệu ảnh.
immich-machine-learning là service quyết định kích thước plan của bạn. Nó load model cho smart search, nhận diện khuôn mặt và nhận dạng văn bản. Model đã load sẽ tiếp tục nằm trong memory. MACHINE_LEARNING_MODEL_TTL mặc định là 300, nên model sẽ bị loại bỏ sau năm phút không có request và được đọc lại từ volume /cache khi có request tiếp theo. Trong quá trình import hàng loạt, không bao giờ có khoảng trống năm phút, nên model tiếp tục được load từ asset đầu tiên đến asset cuối cùng.
Thay đổi trong quá trình import
Immich ở trạng thái nhàn rỗi thường không hoạt động nhiều. Import là lúc các máy chủ nhỏ dễ quá tải, vì tải lên một asset sẽ xếp hàng nhiều job và nhiều queue chạy cùng lúc.
Trích xuất metadata đọc header của file và tiêu tốn ít tài nguyên. Tạo thumbnail nặng hơn. Immich tạo 3 đầu ra thumbnail cho mỗi asset: placeholder thumbhash bị làm mờ, bản preview WebP và thumbnail JPEG, cùng thêm 1 thumbnail cho mỗi khuôn mặt được phát hiện. Mỗi job này đều phải decode một ảnh, còn job concurrency quyết định có bao nhiêu ảnh được decode cùng lúc. Concurrency là hệ số biến chi phí nhỏ của từng job thành tải trên toàn server. Vì vậy, Immich FAQ xác định đây là thông số đầu tiên cần giảm trên máy có tài nguyên hạn chế. Đặt concurrency của các queue nặng thành 1 trong Administration, Settings, Job Settings.
Asset video cần transcoding. Mỗi job transcode chạy trong một tiến trình FFmpeg riêng, có vùng nhớ riêng và sẽ sử dụng mọi CPU thread mà bạn cho phép.
Smart search gửi mỗi asset mới đến machine learning container để tính 1 vector embedding. Face detection chạy model thứ 2 trên cùng ảnh đó. Trong lần import đầu tiên của thư viện ảnh hiện có, cả 2 queue này sẽ xử lý mọi asset bạn có trong nhiều giờ. Đây là thời điểm bộ nhớ bị sử dụng nhiều nhất trong toàn bộ quá trình cài đặt, và chỉ xảy ra 1 lần.
Vì sao nhận diện khuôn mặt và vật thể cần nhiều RAM nhất
Xử lý khuôn mặt gồm 2 công việc. Phát hiện khuôn mặt chạy model trong machine learning container để tìm các bounding box. Nhận diện khuôn mặt sau đó nhóm các kết quả phát hiện thành từng người. Bước này truy vấn vector index trong Postgres. Vì vậy, thư viện ảnh lớn lần lượt gây áp lực lên cả 2 service: trước tiên là container chứa model khi chạy phát hiện, sau đó là database khi thực hiện nhóm.
Bốn thiết lập ảnh hưởng đến lượng dữ liệu mà machine learning container giữ trong bộ nhớ.
- Model khuôn mặt. Immich mặc định dùng
buffalo_l, còn FAQ khuyến nghịbuffalo_strên server nhỏ. Đây là model nhỏ hơn nên chiếm ít memory hơn và chạy nhanh hơn, nhưng độ chính xác với khuôn mặt nhỏ hoặc nhìn nghiêng sẽ thấp hơn. - Số worker.
MACHINE_LEARNING_WORKERSmặc định là 1. Mỗi worker là một process riêng và load một bản sao riêng của các model. Vì vậy, tăng lên 2 sẽ gần như làm tăng gấp đôi resident model memory. Giữ ở mức 1 nếu bạn không dư RAM. - Batch size.
MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITIONgiới hạn số khuôn mặt được xử lý cùng lúc. Một batch được giữ đồng thời trong memory, nên ảnh nhóm có 40 khuôn mặt sẽ tốn nhiều memory hơn ảnh chân dung. - Các loại model được chạy. Smart search, phát hiện khuôn mặt và nhận dạng văn bản đều load model riêng. Tắt những tính năng bạn không dùng trong Administration, Settings, Machine Learning Settings sẽ giải phóng phần memory đó lâu dài, thay vì chỉ giải phóng giữa các lần import.
Ngoài ra còn có MACHINE_LEARNING_MODEL_ARENA. Thiết lập này được mô tả là cấp phát trước CPU memory để tránh fragmentation và mặc định đang bật. Hãy thay đổi nó sau cùng. Tác động của nó phụ thuộc vào memory allocator bên dưới. Vì vậy, cách đánh giá chính xác duy nhất là theo dõi docker stats trước và sau khi thay đổi.
Ba cấu hình mẫu: 2 GB, 4 GB và 8 GB
The data behind this chart
[
{
"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"
}
]Hãy hiểu đây là các giới hạn cần nhập vào Compose, không phải số đo mức sử dụng của Immich. Giới hạn là mức trần. Nó không dự trữ tài nguyên và không làm service nhỏ hơn. Nó quyết định service nào bị kernel kill khi máy hết tài nguyên. Tốt hơn hết là bạn tự quyết định việc này thay vì để cơ chế chấm điểm của kernel quyết định.
Máy 2 GB: gỡ container machine learning
2 GB thấp hơn mức tối thiểu được tài liệu công bố là 6 GB. Vì vậy đây là một phương án đánh đổi và cần nói rõ như vậy. Comment toàn bộ service immich-machine-learning trong docker-compose.yml, hoặc để service tiếp tục chạy và tắt mọi model trong Administration, Settings, Machine Learning Settings. Gỡ container là phương án mạnh hơn, vì model bị tắt vẫn để lại một tiến trình Python trong bộ nhớ.
Bạn vẫn có upload, album, chia sẻ, mobile backup, thumbnail và tìm kiếm theo ngày, địa điểm và tên file. Bạn mất tìm kiếm theo mô tả, tự động gom khuôn mặt thành từng người và nhận dạng văn bản trong ảnh.
Bốn giới hạn cộng lại khoảng 1.7 GB, còn lại khoảng 300 MB cho host. Lưu ý rằng giới hạn 768 MB cho database thấp hơn mức tối thiểu được tài liệu công bố là 2 GB. Đây chính là mức đánh đổi mà máy 2 GB buộc phải chấp nhận. Vì vậy Postgres là service có khả năng bị kill cao nhất ở cấu hình này.
Thứ hỏng trước là quá trình import, không phải việc duyệt thư viện. Thư viện có vài chục nghìn ảnh vẫn duyệt được ở mức chấp nhận được sau khi import xong, vì việc phục vụ một trang chỉ gồm truy vấn metadata và đọc file. Import nhiều video trên cùng máy sẽ khiến hệ thống dùng swap, vì transcode và hàng đợi tạo thumbnail cần bộ nhớ cùng lúc. Đặt concurrency của mọi hàng đợi nặng thành 1 và thêm swap file.
Máy 4 GB: bật machine learning, mỗi lần chỉ chạy một job
4 GB là mức nhỏ nhất mà bạn nên bật nhận dạng khuôn mặt và vật thể. Giới hạn container machine learning ở 0 MB, chuyển nhận dạng khuôn mặt sang buffalo_s và đặt concurrency của các job tạo thumbnail, phát hiện khuôn mặt và smart search thành 1.
Lần xử lý đầu tiên trên thư viện hiện có sẽ chạy trong nhiều giờ. Với thư viện lớn, quá trình này có thể kéo dài hơn một ngày. Đây là giới hạn CPU, không phải giới hạn bộ nhớ. Vì vậy tăng RAM sẽ không rút ngắn thời gian chạy.
Ở cấu hình này, thứ hỏng trước là container machine learning trong lần xử lý hàng loạt đầu tiên. Nếu không giới hạn, container sẽ tăng mức sử dụng bộ nhớ trong khi một job transcode cũng tăng theo, rồi kernel kill tiến trình lớn hơn. Bạn sẽ thấy Exited (137) trong docker ps -a và container được khởi động lại. Hàng đợi cũng âm thầm bị chậm hơn so với lần kiểm tra trước.
Máy 8 GB: mức khuyến nghị trong tài liệu
8 GB với 4 cores đáp ứng mức Immich khuyến nghị. Mọi tính năng chạy với thiết lập mặc định: smart search, phát hiện khuôn mặt, nhận dạng văn bản và transcoding, cùng concurrency mặc định. Thư viện có hơn một trăm nghìn asset vẫn hoạt động thoải mái ở đây. Áp lực lúc này chuyển từ bộ nhớ sang tốc độ disk, vì database phải xử lý vector index và các truy vấn metadata suốt ngày.
Dù máy còn dư tài nguyên, bạn vẫn nên đặt giới hạn. Trên một máy có đủ tài nguyên, giới hạn ngăn một hàng đợi bị runaway kéo database sập theo. Nếu bạn đang so sánh chi phí với các lựa chọn nhỏ hơn, chi phí thực tế của VPS theo từng mức RAM thường khiến gói 8 GB là cách rẻ nhất để không phải tiếp tục tinh chỉnh.
Cách giới hạn memory cho từng service bằng giới hạn của Compose
Không chỉnh sửa docker-compose.yml cho việc này. File đó sẽ bị thay thế mỗi khi bạn upgrade bằng wget. Hãy đặt các giới hạn trong docker-compose.override.yml bên cạnh file đó; docker compose sẽ tự động gộp chúng.
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: 192Mdocker compose up -d
docker stats --no-streamdocker stats bây giờ phải hiển thị ngưỡng giới hạn của bạn trong cột MEM USAGE / LIMIT thay vì tổng memory của host. Nếu cột giới hạn vẫn hiển thị toàn bộ dung lượng của host, file override chưa được nạp: kiểm tra tên file và chạy docker compose config để xem kết quả sau khi gộp.
Giới hạn quá thấp sẽ khiến service đang chạy chậm ngừng hoạt động hoàn toàn, vì vậy hãy tăng giới hạn nếu container liên tục restart. Xem thêm cơ chế hoạt động tại đặt giới hạn memory cho từng service trong Docker Compose, bao gồm lý do deploy hoạt động ngoài Swarm với Compose v2.
Cách tắt hoặc chuyển container machine learning
Trên một máy chủ nhỏ, chuyển container này sang nơi khác là thay đổi lớn nhất bạn có thể thực hiện. Immich hỗ trợ chạy container này trên một máy khác. Tạo file sau trên host thứ hai. Host này có thể là một desktop chỉ bật vào buổi tối:
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/pingSau đó vào Administration, Settings, Machine Learning Settings trong giao diện web, nhấp vào Add URL và nhập http://<host>:3003. Giữ cùng một version trên cả hai host, vì tài liệu Immich cảnh báo rằng version không khớp giữa hai host sẽ gây lỗi và mất ổn định.
Cổng đó truyền ảnh của bạn đến máy kia mà không mã hóa. Vì vậy, chỉ chạy cổng này trên private network hoặc truyền qua một tunnel WireGuard giữa hai host. Không bao giờ expose cổng 3003 ra Internet.
Nếu vấn đề nằm ở việc phải chạy một model container thường trú, bạn cũng có lý do chính đáng để so sánh PhotoPrism và Immich khác nhau thế nào về các thành phần chạy thường trực trước khi chọn plan.
Cần bao nhiêu dung lượng đĩa cho library Immich?
Không có một hệ số duy nhất, vì 4 thành phần khác nhau tăng theo 4 tốc độ khác nhau. Dưới đây là phép tính cho một library gồm 50,000 ảnh và 500 video ngắn.
The data behind this chart
[
{
"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 ảnh và 60 GB video là các giả định. Hãy thay bằng mức trung bình của bạn trước khi mua thiết bị, vì video quyết định con số này: 1 phút video từ điện thoại lớn hơn 100 ảnh.
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}'Dòng 39 GB là tỷ lệ duy nhất được Immich công bố: thumbnail được tạo và video được transcode trung bình làm tăng kích thước library thêm 10 đến 20 phần trăm. Đây là một khoảng ước tính vì còn phụ thuộc vào số asset là video cần re-encode để tương thích với trình duyệt. Library chỉ gồm JPEG thường nằm gần mức thấp của khoảng này.
Database chiếm 3 GB và gần như là chi phí cố định. Immich ghi rõ các file database thường chiếm 1 đến 3 GB, vì chúng lưu metadata và vector tìm kiếm thay vì pixel. Cache của model chiếm 2 GB và tăng lên nếu bạn bật nhiều model hoặc thử các model khác nhau. FAQ nêu rõ volume này tiêu tốn dung lượng vì chính lý do đó.
5 dòng này cộng lại thành hơn 300 GB một chút, nên volume 500 GB vẫn còn chỗ để tăng trưởng, còn volume 250 GB thì không. Kiểm tra phần phân bổ bằng:
grep UPLOAD_LOCATION .env
du -sh /srv/immich/*Có 6 thư mục nằm dưới UPLOAD_LOCATION. upload và library chứa bản gốc, thumbs chứa preview và thumbnail khuôn mặt, encoded-video chứa các bản sao đã re-encode, profile chứa avatar, còn backups chứa các database dump tự động. Chỉ upload, library và profile là không thể thay thế, vì mọi thứ khác đều có thể được tạo lại từ chúng.
Có 2 điều thường khiến người dùng bất ngờ. Asset đã xóa trước tiên được chuyển vào trash và tiếp tục chiếm dung lượng cho đến khi trash được dọn, nên một lần dọn dẹp lớn không giải phóng dung lượng ngay trong ngày thực hiện. Database dump chỉ chứa metadata, nên không có giá trị nếu thiếu các file:
docker exec -t immich_postgres pg_dump --clean --if-exists \
--dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gzKết hợp việc đó với một bản sao cấp file của các bản gốc được lưu ở nơi khác ngoài server. Đây là mục đích của restic backup từ VPS đến storage ngoài server.
Transcoding sử dụng CPU, không phải RAM
Tăng RAM không làm transcoding nhanh hơn. Immich sử dụng FFmpeg để transcoding, và trên VPS thông thường, CPU sẽ decode và encode từng frame. Ngay cả khi có hardware acceleration, tài liệu Immich cho biết chỉ bước encoding được tăng tốc, nên CPU vẫn phải software decode và thực hiện tone mapping.
Hardware acceleration cần thêm file hwaccel.transcoding.yml Compose và một device để pass through, sử dụng NVENC, Quick Sync, RKMPP hoặc VAAPI. Hầu hết gói VPS không cung cấp các thành phần này, vì vậy hãy lập kế hoạch sử dụng CPU.
Thiết lập thực tế cần chú ý là số lượng thread. Trong Administration, Settings, Video Transcoding Settings, giá trị thread bằng 0 nghĩa là sử dụng toàn bộ core. Khi đó, một video có thể làm treo web interface trên gói 2 core. Hãy đặt giá trị này thành 1 hoặc 2 như Immich FAQ khuyến nghị. Transcode sẽ chậm hơn nhưng không làm gián đoạn hệ thống.
Vì sao quá trình import bị swap thrashing trông như bị treo
Đây là lỗi thường bị hiểu nhầm nhất. Khi Immich hết bộ nhớ, có 2 khả năng xảy ra, nhưng chỉ một khả năng trông giống lỗi.
Không có swap, kernel sẽ kill một process. Container khởi động lại trong vài giây, nên trên trình duyệt, hàng đợi tác vụ chỉ tạm dừng rồi tiếp tục. Bằng chứng nằm trong 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) nghĩa là process đã bị kill bằng signal 9. 137 bằng 128 cộng 9. Giá trị OOMKilled là true xác nhận process bị kill do thiếu bộ nhớ, không phải do crash.
Có swap, không process nào bị kill và cũng không có lỗi nào xuất hiện. Kernel bắt đầu chuyển các page lên disk, quá trình import chậm đi hàng chục lần, còn web interface ngừng phản hồi trong thời gian timeout thông thường. Mọi container vẫn đang chạy. Mọi health check vẫn có thể pass. Nó trông như bị treo, nên nhiều người reboot máy ở thời điểm này. Việc đó làm mất tiến độ của hàng đợi nhưng không giải quyết được gì.
free -m
vmstat 1 5Các giá trị khác 0 kéo dài trong các cột si và so của vmstat nghĩa là máy liên tục đọc và ghi swap. Đây chính là thrashing. Hàng free -m của Swap used cũng sẽ tăng cùng lúc.
Dù vậy, hãy thêm swap trên máy có 2 GB hoặc 4 GB RAM, vì một quá trình import chậm nhưng có thể chẩn đoán vẫn tốt hơn một container bị kill mà không thể chẩn đoán:
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/fstabSau đó xử lý nguyên nhân. Giảm concurrency của job xuống 1, giới hạn tài nguyên cho container machine learning hoặc chuyển container đó sang host khác. Swap giúp bạn có thời gian thực hiện việc này. Swap không tự giải quyết được vấn đề.
FAQ
Tôi có thể chạy Immich trên VPS 2 GB không?
Có, nếu comment service immich-machine-learning trong docker-compose.yml và đặt concurrency của job thành 1. Mức này thấp hơn mức tối thiểu được tài liệu công bố là 6 GB, nên hãy xem đây là một đánh đổi đã biết. Bạn vẫn có upload, album, chia sẻ, backup trên mobile và tìm kiếm theo ngày, địa điểm và tên file. Bạn sẽ mất tìm kiếm theo mô tả, tự động nhóm khuôn mặt thành từng người và nhận dạng văn bản bên trong ảnh. Hãy thêm swap file 2 GB để khi import tăng đột biến, server chỉ chậm lại thay vì bị kill container.
Vì sao quá trình import Immich dừng mà không có thông báo lỗi?
Hai nguyên nhân khác nhau có thể trông giống hệt nhau trên browser. Một là container bị kill do thiếu memory; khi đó docker ps -a hiển thị Exited (137) và container đã tự restart. Hai là host đang swap; khi đó mọi container vẫn chạy nhưng toàn bộ hệ thống rất chậm. vmstat 1 5 giúp phân biệt hai trường hợp này: các giá trị khác 0 kéo dài trong các cột si và so cho biết hệ thống đang swap. Trong cả hai trường hợp, hãy giảm concurrency của job tạo thumbnail, phát hiện khuôn mặt và smart search.
Mã exit 137 trong log Immich có nghĩa là gì?
137 bằng 128 cộng signal 9, nên process đã bị kill bằng SIGKILL. Trên thực tế, điều đó có nghĩa là đã chạm giới hạn memory, có thể là giới hạn riêng của container hoặc do host hết memory. Kiểm tra bằng docker inspect immich_machine_learning | grep -i oomkilled. Giá trị true xác nhận kernel đã kill process vì thiếu memory, còn free -m và sudo dmesg -T | grep -i oom-kill cho biết nguyên nhân là giới hạn của container hay toàn bộ host. Machine learning container thường là đối tượng bị kill vì đây thường là process lớn nhất.
Immich cần bao nhiêu dung lượng disk cho mỗi ảnh?
Hãy dự trù dung lượng bằng file gốc cộng thêm 10 đến 20 phần trăm. Tài liệu Immich cho biết thumbnail được tạo và video được transcode làm tăng kích thước library trung bình 10 đến 20 phần trăm. Bản thân database thường chiếm 1 đến 3 GB, ngay cả với library lớn. Video mới là yếu tố quyết định tổng dung lượng, vì vậy hãy đo kích thước file trung bình của chính bạn trước khi chọn plan, thay vì áp dụng một hệ số cho số lượng ảnh.
Tôi có cần GPU cho Immich không?
Không. Mọi thành phần của Immich đều chạy trên CPU. Graphics card giúp tăng tốc model inference trong machine learning container và mã hóa video, nhưng cả hai đều không bắt buộc. Hầu hết plan VPS không cung cấp GPU. Trên hardware chỉ có CPU, hãy đặt số thread transcoding thành 1 hoặc 2, dùng model khuôn mặt buffalo_s và để lần bulk import đầu tiên chạy qua đêm.