Cài Ollama trên Synology NAS bằng Docker

Vì sao chạy Ollama trên NAS phải qua Docker

Search "cài Ollama trên Synology" xong mở Package Center gõ tìm — vô ích. Synology chưa từng làm package chính thức cho Ollama, nên "cài native" bị loại từ vòng gửi xe.

Còn lại hai đường: Virtual Machine Manager hoặc Container Manager. VM Manager bắt bạn cấp riêng CPU/RAM cho một máy ảo, cài hẳn một hệ điều hành khách, rồi mới nhét Ollama vào trong đó. Nghe đã thấy cồng kềnh — NAS vốn RAM ít, CPU yếu, không có dư để nuôi thêm một lớp ảo hóa chỉ để chạy một con AI.

Container Manager (tên mới của gói Docker từ DSM 7.2) dùng chung tài nguyên với DSM, không cấp phát cứng riêng, update hay rollback image đều nhẹ nhàng. Cộng đồng NAS quốc tế — mariushosting, hongkiat và loạt hướng dẫn khác — cũng đi theo hướng này. Bài viết chạy image ollama/ollama qua Project trong Container Manager, kèm Open WebUI làm giao diện chat cho dễ dùng.

Nói trước để khỏi vỡ mộng: NAS Synology không hỗ trợ GPU passthrough cho container. Mọi thứ chạy bằng CPU. Quen xem AI chạy vèo vèo trên máy RTX thì chuẩn bị tinh thần NAS sẽ ì hơn hẳn — bù lại nó chạy 24/7, im lặng, dữ liệu không rời khỏi nhà bạn.

Yêu cầu trước khi bắt tay vào làm

• CPU x86_64 (Intel/AMD) — bắt buộc. Các dòng NAS dùng CPU ARM như Realtek RTD1296, RTD1619B không chạy được vì thiếu tập lệnh SIMD mà Ollama cần. Kiểm tra model CPU trong DSM > Control Panel > Info Center trước khi làm gì khác.
• DSM 7.2 trở lên — vì Container Manager chỉ có từ bản này.
• RAM trống tối thiểu 4GB, nhưng để chạy model có ý nghĩa thì nên có 8GB (model 1-3B) hoặc 16GB+ (model 7B trở lên).

Hai ví dụ để dễ hình dung mức "đủ dùng": DS220+ (Celeron J4025, 2 core, RAM gốc 2GB tối đa 6GB) về lý thuyết cài được Container Manager, nhưng thực tế không đủ lực chạy nổi ngay cả model 1B cho mượt — coi như máy demo để học, đừng kỳ vọng dùng thật. DS923+ (AMD Ryzen R1600, 2 core/4 thread, RAM gốc 4GB tối đa 32GB) khả thi hơn hẳn, nâng lên 16GB là chạy êm model 3B-7B. NAS ngang tầm DS923+ trở lên thì cứ làm theo, còn yếu hơn thì xác định "chạy để biết" hơn là "chạy để dùng".

Bước 1: Cài Container Manager và tạo thư mục chứa dữ liệu

Vào Package Center, tìm Container Manager, cài như bình thường. Xong thì qua File Station, tạo shared folder tên docker nếu chưa có, rồi tạo tiếp thư mục con docker/ollama.

Bước này tưởng lặt vặt nhưng lại là chỗ hay bị bỏ qua nhất, và hậu quả thì khó chịu nhất: quên khai volume ra đường dẫn thật ngoài /volume1/docker/..., mỗi lần update hay xóa container là mất sạch model đã tải, phải tải lại từ đầu — model vài GB tải lại chẳng vui vẻ gì.

Bước 2: Tạo Project với docker-compose

Vào Container Manager > Project > Create. Chọn "Create docker-compose.yml" và dán nội dung sau:

version: "3"
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
ports:
- "11434:11434"
volumes:
- /volume1/docker/ollama/data:/root/.ollama
environment:
- OLLAMA_ORIGINS=*

open-webui:
image: ghcr.io/open-webui/open-webui:latest
container_name: open-webui
restart: unless-stopped
ports:
- "3000:8080"
volumes:
- /volume1/docker/ollama/webui:/app/backend/data
environment:
- OLLAMA_BASE_URL=http://ollama:11434
- WEBUI_SECRET_KEY=doi-chuoi-nay-thanh-random-cua-ban
depends_on:
- ollamaVài điểm cần để ý trong file này:

• OLLAMA_ORIGINS=* cho phép các máy khác trong mạng LAN gọi vào API của Ollama. Thiếu dòng này là lý do phổ biến khiến máy khác trong nhà không kết nối được, dù container vẫn chạy bình thường.
• WEBUI_SECRET_KEY — đừng để nguyên giá trị mẫu ở trên, đổi thành chuỗi random tự sinh (gõ đại một dãy ký tự dài, hoặc dùng lệnh openssl rand -hex 32 nếu có SSH). Đây là khóa ký session của Open WebUI, để mặc định coi như mời sẵn ai biết giá trị mẫu đó vào đăng nhập ké.
• Port Open WebUI map ra 3000:8080 — 8080 là port nội bộ trong container, 3000 là port bạn thật sự truy cập từ trình duyệt. Đổi 3000 thành số khác tùy ý nếu NAS đã dùng port đó cho dịch vụ khác.

Bấm Apply/Next để deploy. Container Manager tự pull hai image này về — lần đầu image Ollama khá nặng nên chờ vài phút là chuyện bình thường, đừng sốt ruột tắt giữa chừng.

Bước 3: Tải model qua Terminal, đừng tải qua UI

Đây là chỗ dễ dính lỗi thứ hai: nhiều người vào tab Terminal trên giao diện Container Manager để gõ lệnh pull model, xong thấy nó treo hoặc timeout với model lớn mà không hiểu vì sao. Cách chắc ăn hơn là SSH thẳng vào NAS rồi chạy qua docker exec, để thấy log tải về theo thời gian thực:

docker exec -it ollama ollama pull llama3.2:3b
docker exec -it ollama ollama run llama3.2:3bModel nào phù hợp thì tùy RAM máy bạn. Xếp theo mức độ nhẹ dần:

• qwen3:0.6b — khoảng 0.5GB, tốc độ 5-6 tok/s, hợp máy yếu hoặc muốn thử nghiệm nhanh.
• llama3.2:1b — khoảng 1.3GB, 3-4 tok/s.
• llama3.2:3b — khoảng 2GB, mức "vừa đủ dùng" phổ biến nhất cho NAS CPU-only.
• Model 7B — chỉ nên thử nếu máy có 16GB RAM trở lên, thực tế chỉ đạt 0.5-2 tok/s, không hợp chat qua lại kiểu real-time, chỉ hợp chạy tác vụ nền rồi quay lại xem kết quả sau.

Bước 4: Kiểm tra chạy

Test API trực tiếp bằng curl từ máy khác trong mạng:

curl http://:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "Xin chào"
}'Hoặc mở trình duyệt vào http://<NAS-IP>:3000 để dùng giao diện Open WebUI — tạo tài khoản admin lần đầu, chọn model đã pull, gõ chat như ChatGPT bình thường. Load được model trong dropdown mà không ra câu trả lời, khả năng cao container Ollama chưa kịp nạp model vào RAM — đợi thêm chút hoặc kiểm tra log container.

Benchmark thực tế: đừng kỳ vọng quá vào NAS yếu

Chạy cùng một model nhỏ (ví dụ llama3.2:1b) trên DS220+ và DS923+ cho ra tốc độ token/giây chênh lệch rõ rệt. DS220+ với CPU 2 core yếu và RAM giới hạn thường ì ạch ngay cả với model nhỏ nhất, trong khi DS923+ với Ryzen R1600 và RAM nâng lên 16GB xử lý mượt hơn nhiều, đủ để trò chuyện với độ trễ chấp nhận được. Định mua NAS chỉ để chạy AI cục bộ thì DS923+ (hoặc dòng tương đương CPU AMD, RAM nâng cấp được) nên là mức sàn — đừng đặt cược vào mấy con Celeron yếu.

Dùng để làm gì thì hợp, dùng để làm gì thì đừng

Với tốc độ CPU-only trên NAS, các việc sau là hợp lý:

• Tóm tắt tài liệu offline, không cần phản hồi tức thì.
• Chatbot nội bộ cho một, hai người dùng, chấp nhận độ trễ vài giây.
• Tự động phân loại ghi chú, email, hoặc file cá nhân theo lô.
• Tích hợp với Home Assistant để xử lý lệnh nhà thông minh đơn giản.

Không hợp: chatbot phục vụ nhiều người cùng lúc, hay bất kỳ tác vụ nào cần phản hồi real-time. Công việc cần nhanh thì giải pháp thực tế hơn là chạy Ollama trên một PC hoặc server có GPU rời trong cùng mạng LAN, còn NAS chỉ nên đóng vai kho lưu trữ.

Lỗi thường gặp và cách xử lý

• Container bị OOM-kill, cả NAS treo phải restart: RAM vật lý không đủ cho size model đã pull. Chọn model nhỏ hơn hoặc nâng RAM máy — không có "tối ưu phần mềm" nào bù được thiếu RAM vật lý.
• Áp máy móc hướng dẫn tiếng Anh có --gpus hay CUDA_VISIBLE_DEVICES: Synology consumer NAS không hỗ trợ GPU passthrough cho Container Manager, các biến này hoàn toàn vô nghĩa trên NAS. Bỏ hẳn ra khỏi file docker-compose, đừng cố nhét vào "cho chắc".
• Pull model qua UI bị treo với model lớn: chuyển sang pull qua SSH/terminal bằng docker exec như bước 3, để nhìn thấy log tiến trình tải rõ ràng.
• Mất model sau khi update hoặc xóa container: do không khai volume tường minh ra /volume1/docker/.... Luôn kiểm tra lại phần volumes trong docker-compose trước khi deploy.
• Máy khác trong mạng không truy cập được: kiểm tra DSM Firewall có chặn port 11434/3000 không, và đảm bảo đã set OLLAMA_ORIGINS=*.

Bảo mật và bảo trì

Tuyệt đối không port forward port 11434 hay port Open WebUI ra Internet. API của Ollama mặc định không có xác thực — mở thẳng ra ngoài chẳng khác nào mời người lạ vào dùng ké tài nguyên NAS, hoặc tệ hơn là đọc luôn lịch sử chat của bạn.

Cần dùng từ xa thì đi qua VPN (Tailscale hoặc WireGuard qua gói VPN Server của Synology), hoặc dựng reverse proxy có lớp xác thực riêng. Đừng bao giờ nghĩ "chắc không ai biết port này đâu" — bot quét port trên Internet không phân biệt NAS nhà bạn với server công ty, nó gõ cửa tất.

Cuối cùng, nhớ giới hạn CPU/RAM cho container Ollama trong Container Manager nếu NAS còn chạy các dịch vụ khác như Photos, Drive hay Surveillance Station. Không giới hạn, AI ăn hết tài nguyên là các dịch vụ kia lag theo — vừa mất công debug vừa mất luôn buổi tối.