Năm container Docker thiết yếu cho phòng thử nghiệm AI tại nhà

5 container Docker cần thiết cho phòng thử nghiệm AI tại gia - KDnuggets Trang tin Bài viết nổi bật Giới thiệu Chủ đề AI Tư vấn nghề nghiệp Thị giác máy tính Kỹ thuật dữ liệu Khoa học dữ liệu Mô hình ngôn ngữ Học máy MLOps Xử lý ngôn ngữ tự nhiên Lập trình Python SQL Tập dữ liệu Sự kiện Tài nguyên Tài liệu tóm tắt Đề xuất Bản tin công nghệ Quảng cáo Đăng ký nhận bản tin 5 container Docker cần thiết cho phòng thử nghiệm AI tại gia Tổng hợp năm container Docker giúp thiết lập phòng thử nghiệm AI tại gia vận hành ổn định, từ Ollama, Open WebUI đến Qdrant, n8n và Portainer CE; phân tích vai trò cụ thể và những sai sót ban đầu cần tránh đối với từng công cụ. Tác giả: Nahla Davies, KDnuggets, ngày 29/10/2026, chuyên mục Kỹ thuật dữ liệu Giai đoạn đầu thường diễn ra thuận lợi khi mô hình vận hành cục bộ, cửa sổ trò chuyện phản hồi câu hỏi và hệ thống tản nhiệt máy tính hoạt động hết công suất. Tuy nhiên, chỉ sau vài tuần, các phòng thử nghiệm AI tại gia thường rơi vào tình trạng đình trệ. Nhiều container hoạt động trên các cổng kết nối không được ghi chép; tệp PDF chưa được lập chỉ mục; các tác vụ tự động bị thất lạc trong lịch sử dòng lệnh; và quá trình cập nhật xóa sạch các mô hình do lưu trữ trực tiếp bên trong container. Những sự cố này không xuất phát từ bản thân công nghệ AI, mà bắt nguồn từ quy trình quản trị hệ thống. Một phòng thử nghiệm tại gia hiệu quả cần được xây dựng từ một nhóm nhỏ các container có chức năng rõ ràng, thay vì một hệ thống AI cồng kềnh. KDnuggets áp dụng cách tiếp cận phân tầng tương tự khi nghiên cứu cấu trúc AI cục bộ. Việc cung cấp mô hình, giao diện, bộ nhớ truy xuất, tự động hóa và quản trị là các tầng tách biệt; mỗi tầng tương ứng với một container có thể thay thế độc lập. Năm công cụ dưới đây được lựa chọn dựa trên khả năng tối ưu hóa vận hành thay vì mức độ tích hợp yếu tố AI trong tên gọi, trong đó có hai công cụ hoàn toàn không tích hợp AI. Container Vai trò trong hệ thống Lưu ý quan trọng đầu tiên Ollama Cung cấp: vận hành mô hình cục bộ, mở cổng 11434 Mô hình lưu bên trong container sẽ bị xóa khi tạo lại; cần sử dụng volume có tên (named volume) Open WebUI Tương tác: giao diện trò chuyện trên trình duyệt, quản lý người dùng, tệp tin, liên kết nhà cung cấp Việc tạo lại biến WEBUI_SECRET_KEY sẽ đăng xuất toàn bộ người dùng; cần thiết lập cố định ngay từ đầu Qdrant Ghi nhớ: tìm kiếm vector trên hệ thống tài liệu nội bộ Không cần thiết cho nhu cầu trò chuyện thông thường; chỉ tích hợp khi cần truy xuất dữ liệu n8n Tự động hóa: thu thập dữ liệu theo lịch, webhook, xử lý kết nối trung gian Chứa thông tin xác thực; cần sao lưu volume và bảo mật cổng truy cập nội bộ Portainer CE Quản trị: khởi động lại, nhật ký, volume, cập nhật, dọn dẹp hệ thống Quyền truy cập Docker socket cho phép kiểm soát máy chủ; chỉ triển khai trong mạng nội bộ tin cậy Bảng 1. Năm container, vai trò tương ứng trong hệ thống và những sự cố kỹ thuật ban đầu thường gặp. Bảng tham chiếu gốc của bài viết. Nguồn: Ollama Docker Hub, tài liệu hướng dẫn nhanh Open WebUI, tài liệu hướng dẫn nhanh Qdrant, tài liệu Docker Compose n8n, tài liệu cài đặt Portainer CE. 1. Ollama: Môi trường thực thi mô hình Ollama đóng vai trò trung tâm điều hành. Công cụ này tải, vận hành các mô hình cục bộ và mở điểm cuối HTTP trên cổng 11434. Toàn bộ các container khác trong hệ thống kết nối trực tiếp với điểm cuối này, do đó không yêu cầu cấu hình nạp mô hình riêng biệt. Bản dựng chính thức trên Docker Hub hỗ trợ ba phương thức: chỉ sử dụng CPU, hỗ trợ GPU NVIDIA qua NVIDIA Container Toolkit với tham số --gpus=all, và hỗ trợ GPU AMD thông qua thẻ định danh rocm. Yếu tố quan trọng nhất trong quá trình cài đặt là cấu hình phân vùng lưu trữ (volume). Các mô hình có dung lượng lớn; nếu container được tạo lại mà không gắn với một volume có tên cụ thể, hệ thống sẽ phải tải lại toàn bộ dữ liệu. Trường hợp xấu hơn, người dùng có thể mất các mô hình đã tải từ các thẻ phiên bản không còn được duy trì. Lệnh khởi chạy theo tài liệu hướng dẫn như sau: docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama Bỏ tham số --gpus=all nếu sử dụng CPU. Một điểm hạn chế cần lưu ý: khả năng chuyển tiếp GPU (GPU pass-through) phụ thuộc vào máy chủ, không phụ thuộc vào Ollama. Các phương thức hỗ trợ GPU của Docker theo tài liệu chính thức gồm Linux và Windows thông qua WSL2. Docker Desktop trên macOS không phân bổ GPU NVIDIA cho vùng chứa (container); do đó, hệ thống thực nghiệm trên Mac buộc phải chạy trực tiếp Ollama để bảo đảm tốc độ, hoặc chấp nhận suy luận qua CPU trong môi trường Docker. 2. Open WebUI: Lớp giao diện Giao diện dòng lệnh phù hợp cho mục đích thử nghiệm mô hình nhưng không khả thi cho việc vận hành lâu dài. Open WebUI cung cấp giao diện trình duyệt web cho hệ thống: quản lý các phiên trò chuyện, người dùng, tải tệp lên và kết nối với Ollama cùng bất kỳ nhà cung cấp nào khác được bổ sung. Docker là phương thức cài đặt được khuyến nghị chính thức, với quy trình khởi động nhanh qua một câu lệnh: docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data -e WEBUI_SECRET_KEY=your-secret-key --name open-webui --restart always ghcr.io/open-webui/open-webui:main Hai trong số các tham số này giữ vai trò thiết yếu. Phân vùng lưu trữ tại /app/backend/data lưu giữ thông tin người dùng, các đoạn trò chuyện và tệp tải lên. Nếu không có phân vùng này, mỗi lần tạo lại vùng chứa sẽ đưa hệ thống về trang đăng nhập ban đầu. Biến WEBUI_SECRET_KEY dùng để ký các phiên hoạt động, do đó cần thiết lập cố định một lần bằng các công cụ như openssl rand -hex 32 và lưu trữ cẩn thận, bởi việc tạo mới khóa này sẽ làm đăng xuất toàn bộ người dùng. Các biến thể hình ảnh :cuda và :ollama được cung cấp nhằm phục vụ tăng tốc GPU và tích hợp Ollama trong cùng một vùng chứa. Đây là các tùy chọn bổ sung thay vì mặc định, do việc vận hành một vùng chứa Ollama riêng biệt sẽ thuận tiện hơn cho công tác nâng cấp và chia sẻ giữa các công cụ. 3. Qdrant: Bộ nhớ truy xuất cho hệ thống thực nghiệm Cơ sở dữ liệu vector có thực sự cần thiết? Đối với nhu cầu trò chuyện thông thường, câu trả lời là không, và việc bỏ qua thành phần này là hoàn toàn hợp lý. Tuy nhiên, ngay khi hệ thống cần giải đáp thông tin từ các tài liệu, ghi chú hoặc tệp dự án riêng, các tệp đó phải được nhúng (embedding) và tìm kiếm. Đây chính là chức năng của Qdrant: lưu trữ các vector và tìm kiếm các điểm dữ liệu gần nhất. Đây là bộ nhớ để AI tham chiếu, mang tính chất hoàn toàn độc lập với mô hình AI. Quy trình khởi động nhanh cục bộ vận hành Qdrant với hai cổng: cổng 6333 dành cho REST API và bảng điều khiển, cổng 6334 dành cho gRPC. Quy trình này cũng gắn một đường dẫn lưu trữ để các tập hợp dữ liệu không bị xóa sau khi khởi động lại. Bảng điều khiển tại địa chỉ localhost:6333/dashboard cần được kiểm tra, bởi việc theo dõi một tập hợp dữ liệu dần được lấp đầy là phương thức nhanh nhất để xác nhận quy trình tiếp nhận dữ liệu (ingestion pipeline) đang vận hành. Một mô hình đơn lẻ không cấu thành một hệ thống hữu dụng, như bài viết trước đây của KDnuggets về các LLM tự lưu trữ trong thực tế đã phân tích chi tiết. Khả năng truy xuất thường là lớp công nghệ quyết định việc chuyển đổi một bản thử nghiệm thành một công cụ được ứng dụng thường xuyên. 4. n8n: Xương sống tự động hóa Eve