VPS chạy AI agent tự động, cấu hình thế nào cho đúng

Bạn vừa cài OpenClaw hoặc n8n lên VPS, chạy thử vài workflow thấy ổn. Nhưng khi cho agent chạy nền liên tục, gọi thêm model qua Ollama, thì VPS bắt đầu thở. Swap đầy, CPU rất cao, webhook trả lời chậm. Đây là tình huống mình gặp khá nhiều khi nhận hỗ trợ từ khách dùng VPS chạy AI agent tại Việt Nam. Vấn đề không phải agent xấu, mà là cấu hình VPS không khớp với workload.

Bài này viết cho sysadmin đang đau đầu chọn cấu hình VPS chạy AI agent tự động. Mình sẽ chỉ cụ thể: RAM bao nhiêu là đủ theo từng loại agent, CPU nên chọn mấy core, disk nên để dung lượng bao nhiêu, và quan trọng nhất là lệnh kiểm tra để biết VPS hiện tại có đủ sức không. Tất cả lệnh đều chạy trên Ubuntu 24.04 LTS, môi trường phổ biến nhất cho loại workload này.

• AI agent dạng workflow (n8n) cần tối thiểu 2 GB RAM, thoải mái ở 4 GB.
• Agent có trình duyệt (OpenClaw) cần từ 4 GB RAM, mỗi phiên Chromium ngốn 300-500 MB.
• Model ngôn ngữ nhỏ qua Ollama (Phi-3, Llama 3.2 3B) cần thêm 2-4 GB RAM tùy kích thước.
• VPS 2 GB RAM chỉ nên chạy agent dạng text thuần, không kèm model local.

Yêu cầu trước khi bắt đầu

• VPS chạy Ubuntu 24.04 LTS hoặc Debian 12, quyền root hoặc user sudo.
• Ít nhất 2 GB RAM, khuyến nghị 4 GB nếu chạy agent có headless browser.
• Hiểu cơ bản về SSH, systemd, và Docker Compose (đa số agent hiện nay chạy bằng container).
• Tên miền trỏ về VPS nếu muốn lộ webhook ra ngoài, kèm chứng chỉ SSL.

Vì sao AI agent ngốn tài nguyên hơn web app thường

Web app thường chỉ xử lý request rồi trả response, xong là giải phóng bộ nhớ. AI agent thì khác. Nó chạy vòng lặp: nhận task, gọi LLM, phân tích kết quả, thực thi hành động, rồi quay lại gọi LLM tiếp. Mỗi vòng lặp giữ ngữ cảnh trong RAM, và nếu agent dùng tool calling, nó còn phải giữ luôn kết quả trung gian.

Lấy ví dụ OpenClaw - framework phổ biến để chạy AI agent có điều khiển trình duyệt. Mỗi lần agent mở Chromium là một tiến trình riêng, ngốn 300-500 MB RAM. Chạy 2-3 tab song song là hết 1.5 GB chỉ riêng trình duyệt, chưa tính node chính và model. Tương tự, n8n khi chạy workflow có gọi LLM node sẽ giữ toàn bộ payload trong RAM đến khi workflow kết thúc. Workflow dài, nhiều branch, là RAM tăng vọt.

Đây là lý do mình hay khuyên khách: đừng nhìn RAM lúc mới cài, hãy nhìn RAM sau khi agent chạy 1-2 giờ liên tục. Con số lúc khởi động luôn thấp hơn nhiều so với steady state.

Bước 1 - Xác định loại AI agent bạn định chạy

Không có cấu hình VPS chạy AI agent chung cho mọi loại. Bạn phải xác định agent của mình thuộc nhóm nào, vì mỗi nhóm có profile tài nguyên khác hẳn nhau:

Nếu bạn chạy OpenClaw nhưng gọi API GPT-4o từ OpenAI thay vì model local, bạn không cần RAM khủng như chạy Ollama. Ngược lại, nếu muốn self-host hoàn toàn để khỏi tốn phí API, bạn phải chấp nhận VPS RAM lớn. Đây là đánh đổi cơ bản khi chọn VPS chạy AI agent tự động.

Mình khuyên thật: đa số người dùng cá nhân và doanh nghiệp nhỏ nên chạy agent bằng API ngoài (OpenAI, Anthropic, Gemini) và chỉ self-host phần orchestration. Chi phí VPS thấp hơn hẳn, và model API chất lượng cao hơn những gì bạn tự chạy trên CPU.

Bước 2 - Đo tài nguyên VPS hiện tại trước khi quyết định nâng cấp

Trước khi đi thuê VPS mới, hãy đo VPS hiện tại xem nó đang thiếu gì. Lệnh sau cho biết RAM đang dùng bao nhiêu, swap ra sao:

free -h
#               total        used        free      shared  buff/cache   available
# Mem:           3.8Gi       3.1Gi       210Mi        45Mi       486Mi       478Mi
# Swap:          2.0Gi       1.8Gi       220Mi

Chú ý cột available, không phải free. Nếu available dưới 500 MB trong khi agent chạy bình thường, VPS đang thiếu RAM trầm trọng. Swap dùng gần hết cũng là dấu hiệu xấu, vì agent sẽ chậm kinh khủng khi phải đọc ghi swap liên tục.

Kiểm tra CPU có bị nghẽn không bằng lệnh:

top -bn1 | head -20
# hoặc dùng htop nếu đã cài

Xem giá trị %Cpu(s) ở dòng đầu. Nếu us + sy thường xuyên trên 80% trong nhiều phút, CPU là nút thắt. Lúc đó nâng RAM không giải quyết gì, phải tăng vCPU.

Cuối cùng, đo I/O vì agent ghi log và cache liên tục:

iostat -x 2 3
# Kiểm tra %util của disk, nếu trên 80% là nghẽn I/O

VPS dùng NVMe thường không nghẽn I/O ở mức agent cá nhân. Nhưng nếu bạn chạy nhiều workflow n8n cùng lúc, mỗi cái ghi log riêng, thì I/O có thể thành vấn đề. Lúc này chọn VPS NVMe là quyết định đúng.

Bước 3 - Chọn cấu hình theo ngân sách và nhu cầu

Sau khi biết workload của mình thuộc nhóm nào, bạn quy ra cấu hình cụ thể. Mình tổng kết theo kinh nghiệm vận hành thực tế, không lý thuyết suông:

Một lưu ý: đừng chạy Ollama và Chromium trên cùng một VPS 8 GB nếu bạn cần cả hai hoạt động cùng lúc. model 7B quantized Q4 chiếm khoảng 4.5 GB RAM, Chromium thêm 1.5 GB, agent node thêm 500 MB. Đã chạm trần 8 GB trước khi tính đến hệ điều hành và log. Muốn chạy cả hai, bạn cần 16 GB hoặc tách model ra VPS riêng.

Nếu bạn đang phân vân giữa các gói, mình gợi ý bắt đầu từ mức 4 GB RAM, 2 vCPU. Đây là điểm cân bằng giữa chi phí và khả năng chạy đa số agent phổ biến. Chạy thử 1-2 tuần, đo lại bằng lệnh free -h và top, rồi quyết định nâng hay giảm. Đừng mua VPS 16 GB ngay từ đầu vì "phòng xa", đa số trường hợp lãng phí.

Bước 4 - Cài đặt và kiểm tra agent trên VPS thực tế

Giả sử bạn chọn VPS Ubuntu 24.04 với 4 GB RAM. Cách nhanh nhất để chạy n8n kèm workflow AI là dùng Docker Compose. Tạo file docker-compose.yml:

version: "3.8"
services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=matkhau_manh
      - GENERIC_TIMEZONE=Asia/Ho_Chi_Minh
    volumes:
      - n8n_data:/home/node/.n8n
volumes:
  n8n_data:

Chạy lệnh:

docker compose up -d

Kiểm tra container hoạt động:

docker ps
# CONTAINER ID   IMAGE           STATUS         PORTS
# a1b2c3d4e5f6   n8nio/n8n:latest   Up 2 minutes   0.0.0.0:5678->5678/tcp

docker stats --no-stream
# Kiểm tra RAM container đang dùng, thường 300-600 MB cho n8n cơ bản

Nếu chạy OpenClaw, cài bằng lệnh:

curl -fsSL https://openclaw.ai/install.sh | bash

Sau khi cài, khởi động và kiểm tra:

openclaw start
openclaw status

Mở tab trình duyệt của agent và xem RAM:

free -h
# Nếu RAM available tụt dưới 500 MB khi agent mở browser, VPS không đủ sức

Đây là lúc bạn biết chính xác cấu hình của mình có phù hợp hay không. Nếu RAM available luôn trên 1 GB và CPU dưới 50%, cấu hình đang dư. Nếu available dưới 300 MB thường xuyên, hãy nâng RAM hoặc giảm số phiên agent chạy song song.

Bước 5 - Tối ưu VPS để agent chạy ổn định lâu dài

Có vài thứ nên làm ngay sau khi cài agent, trước khi chạy production. Đầu tiên là tăng swap lên 4 GB nếu VPS có 4 GB RAM. Agent dùng headless browser hay bị nhảy memory đột biến, swap là đệm an toàn:

# Tạo swap file 4 GB (chạy bằng root)
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Thêm vào /etc/fstab để tự động bật khi reboot
echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab

Thứ hai, giới hạn RAM container bằng Docker để tránh một container ngốn hết tài nguyên. Thêm vào docker-compose.yml:

    deploy:
      resources:
        limits:
          memory: 2G

Áp dụng thay đổi:

docker compose up -d

Thứ ba, cấu hình logrotate để log của agent không phình to. Tạo file /etc/logrotate.d/agent:

/var/lib/docker/containers/*/*.log {
    rotate 7
    daily
    compress
    missingok
    notifempty
    copytruncate
}

Cuối cùng, nếu chạy VPS chạy AI agent tự động có lộ webhook ra ngoài, nhớ bật firewall và chỉ mở đúng port cần thiết. Chặn port 5678 của n8n từ ngoài nếu bạn chỉ dùng nội bộ, hoặc đặt sau Nginx reverse proxy có SSL.

Xử lý lỗi thường gặp khi chạy agent trên VPS

Lỗi 1: Container bị OOM kill. Kiểm tra bằng lệnh:

dmesg | tail -20
# Hoặc
docker inspect n8n --format '{{.State.OOMKilled}}'

Nếu kết quả là true, container đã bị kill do thiếu RAM. Giải pháp: tăng RAM VPS, hoặc giảm số workflow chạy song song, hoặc thêm swap. Đừng chỉ tăng limit trong Docker vì swap không cứu được OOM nếu host thực sự cạn RAM.

Lỗi 2: Agent phản hồi rất chậm dù RAM còn nhiều. Kiểm tra CPU:

top -bn1 | head -15

Nếu CPU ở mức rất cao liên tục, model local đang nghẽn. Giải pháp: giảm context length, dùng model nhỏ hơn, hoặc chuyển sang gọi API ngoài. CPU server thường không mạnh như laptop, nên model 7B trên CPU có thể mất 5-10 giây cho mỗi token.

Lỗi 3: VPS bị treo, không SSH vào được. Đây thường là thiếu RAM trầm trọng, kernel phải kill process. Vào control panel của nhà cung cấp, hard reboot. Sau đó giảm tải: tắt bớt agent, thêm swap, hoặc nâng cấp RAM. Nếu tái diễn nhiều lần, đã đến lúc chuyển sang gói VPS RAM lớn hơn.

Câu hỏi thường gặp

Bài viết liên quan

• Cài OpenClaw trên VPS Ubuntu từ đầu tới lần chạy đầu tiên
• OpenClaw là gì và chạy trên VPS cần cấu hình bao nhiêu
• Tự động hóa công việc bằng n8n và AI trên VPS
• Self-host API LLM với Ollama trên VPS