Coding agent VPS cần bao nhiêu RAM?

Một coding agent VPS cần bao nhiêu RAM?

Bắt đầu với 4 GB RAM và 2 vCPU cho một coding agent chạy liên tục trong một repository. Chuyển lên 8 GB RAM và 4 vCPU ngay khi session có thêm language server hoặc một Docker build. Với hầu hết repository, việc này xảy ra ngay từ ngày đầu. Bản thân tiến trình agent khá nhẹ. Phần chiếm tài nguyên chủ yếu là toolchain mà agent điều khiển thay bạn.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

Mọi dòng ở trên đều giả định model chạy ở nơi khác, phía sau một API mà bạn gọi qua network. Đây là giả định quyết định toàn bộ bài toán sizing, nên hãy xác định điều đó trước.

Bạn đang chạy agent hay đang chạy model?

Coding agent gọi cloud model thực chất là một network client có shell đi kèm. Nó gửi file và plan đến API, chờ phản hồi, sau đó chỉnh sửa file và chạy lệnh locally. Trong thời gian chờ, nó gần như không dùng CPU. Lượng memory mà agent sử dụng chỉ khoảng vài trăm megabyte. Vì vậy, máy có CPU vừa phải là lựa chọn phù hợp.

Tự chạy model là một sản phẩm khác trên phần cứng khác. Weights được giữ trong memory trong suốt thời gian server hoạt động. Model có 7 tỷ parameter, được quantise xuống 4 bit, cần khoảng 5 GB chỉ cho weights, chưa tính key/value cache tăng theo độ dài context. Nếu chỉ dùng CPU, một shared vCPU chỉ tạo được vài token mỗi giây. Một agent task có thể tạo ra hàng nghìn token. Vì vậy, tác vụ chạy dưới một phút khi gọi API có thể mất gần một giờ nếu chạy locally. Nếu đó là mục tiêu của bạn, hãy chọn phần cứng theo VRAM (video memory trên GPU) và đọc VPS có GPU thực sự cung cấp những gì thay vì trang này.

Phần còn lại giả định bạn sử dụng cloud model.

Thực tế thành phần nào sử dụng bộ nhớ

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

Đây là các số liệu thường được công bố cho những dự án quy mô trung bình. Hãy xem chúng như một hình mẫu, không phải cam kết về code của bạn.

Biểu đồ có 6 dòng và agent là thành phần ít tốn bộ nhớ nhất. Khi idle, agent sử dụng khoảng 250 MB vì chỉ giữ một cuộc hội thoại, một file cache nhỏ và không làm gì khác. TypeScript language server sử dụng khoảng 2000 MB trong lúc index, vì nó xây dựng type graph cho mọi file có thể truy cập từ tsconfig.json rồi giữ graph đó trong memory để xử lý request tiếp theo nhanh hơn. rust-analyzer trên workspace lớn thường vượt 4000 MB vì cùng lý do, trên toàn bộ crate trong workspace.

Headless Chrome sử dụng khoảng 350 MB cho browser và một tab. Mỗi tab bổ sung là một operating system process khác. Một lần chạy test Node với 4 worker sẽ tạo 4 Node process, nên mức sử dụng bộ nhớ đạt gần 3000 MB. Docker image build đạt đỉnh gần 2500 MB vì quá trình build chạy compiler của chính project bên trong container, đồng thời daemon ghi các layer.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

Đọc cột available của free -h, không đọc cột free. Linux dùng mọi page còn trống cho disk cache, nên free có thể nhỏ trên một máy hoàn toàn khỏe mạnh và không cho bạn biết điều gì. available mới là lượng memory mà process mới thực sự có thể nhận.

Ba cấu hình có thể dùng được

Mức tối thiểu: 4 GB RAM, 2 vCPU, 50 GB disk. Một phiên agent, một repository, một language server và các lần build mà bạn chấp nhận phải chờ. Cấu hình này vẫn hoạt động, nhưng sẽ gặp out-of-memory killer ngay lần đầu một lần chạy test lớn trùng với lúc language server lập chỉ mục. Hãy thêm swap và giới hạn số build worker.

Mức thoải mái: 8 GB RAM, 4 vCPU, 100 GB disk. Một agent, thêm Docker và một headless browser để chạy test, vẫn còn đủ tài nguyên dự phòng cho một đợt build tăng tải. Đây là cấu hình mà hầu hết developer làm việc một mình nên chọn. Tăng gấp đôi số vCPU cũng gần như giảm một nửa thời gian chờ build, và bạn sẽ nhận thấy điều này thường xuyên hơn nhiều so với việc nhận thấy dung lượng memory.

Mức team: 16 GB RAM, 8 vCPU, 200 GB disk. Bốn phiên chạy đồng thời, mỗi phiên có checkout riêng và toolchain riêng. Hãy sizing theo mức tải đỉnh, vì bốn agent idle gần như không tốn tài nguyên, trong khi bốn lần chạy test cùng lúc sẽ tốn gấp bốn lần mức đỉnh ở cột phía trên.

Tính đến tháng 8 năm 2026, mức tăng từ hàng đầu tiên lên hàng cuối cùng tương đương khoảng 4 lần giá hàng tháng khi thanh toán VPS theo năm: từ mức một chữ số mỗi tháng ở cấu hình thấp nhất đến mức hàng chục dollar ở cấu hình cao nhất. Hãy kiểm tra bảng giá hiện tại trước khi lập kế hoạch, vì các con số này có thể thay đổi. Server hiếm khi là khoản tốn kém nhất. Với người dùng agent hằng ngày, chi phí model API nhanh chóng vượt chi phí server, vì vậy hãy giới hạn số tiền agent được phép chi trước khi giảm cấu hình máy. Đối với quá trình build, hướng dẫn chạy coding agent trên VPS trình bày cách thiết lập account và giữ phiên chạy sau khi bạn ngắt kết nối.

Vì sao bạn hết dung lượng đĩa trước khi hết RAM

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

Cộng các mục đó lại, bạn sẽ thấy ổ đĩa 50 GB gần đầy trước khi viết dòng code đầu tiên. Mục lớn nhất là Docker, khoảng 20 GB, vì BuildKit giữ mọi layer trung gian của mọi lần build cho đến khi bạn yêu cầu nó dọn.

docker system df
docker builder prune --filter until=168h

docker system df in ra dung lượng có thể thu hồi theo từng danh mục, nên hãy chạy lệnh này trước và sau khi dọn. Bộ lọc until=168h xóa build cache cũ hơn một tuần và giữ lại cache của tuần này, vì cache đó vẫn giúp bạn tiết kiệm thời gian. docker image prune -a dọn mạnh hơn và xóa mọi image không được container nào sử dụng, nên lần build tiếp theo sẽ phải pull lại.

Các project Node gặp lỗi theo cách khó đoán hơn. npm install tạo ra hàng trăm nghìn file nhỏ, nên filesystem có thể hết inode trong khi df -h vẫn báo còn trống hàng gigabyte. Khi đó thao tác ghi thất bại với No space left on device trên một disk trông như vẫn còn trống một nửa.

df -h /
df -i /

Nếu IUse% trả về 100, hãy xóa node_modules thư mục của các branch bạn không còn dùng, hoặc chuyển sang pnpm. Cách này chỉ lưu mỗi phiên bản package một lần rồi tạo hard link đến nó trong từng project.

Log là phần thường bị bỏ qua. Một agent luôn chạy sẽ ghi transcript của các session, còn systemd journal mặc định sẽ tăng lên và chiếm một phần dung lượng disk.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

Đặt SystemMaxUse=200M trong /etc/systemd/journald.conf rồi chạy sudo systemctl restart systemd-journald để giới hạn này có hiệu lực lâu dài, vì vacuum một lần chỉ giải phóng được dung lượng của hôm nay.

Swap: lợi ích và những gì nó che giấu

Nên thêm swap vì nó biến một lần dùng RAM vượt nhẹ thành quá trình chạy chậm thay vì tiến trình bị dừng. Đặt kích thước swap bằng một nửa RAM, tối đa khoảng 4 GB. Trên một máy build, thường không có lý do để tăng thêm.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show hiện phải liệt kê /swapfile với kích thước bạn đã yêu cầu. Nếu thiếu dòng /etc/fstab, swap sẽ biến mất sau lần reboot tiếp theo và máy sẽ âm thầm quay lại hành vi cũ. Nếu fallocate trả về Operation not supported, hãy tạo file bằng sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 rồi tiếp tục từ chmod.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Giá trị swappiness thấp cho kernel biết phải reclaim disk cache trước khi đẩy memory của chương trình ra disk. Nhờ đó, language server vẫn phản hồi tốt.

Đây là phần swap che giấu. Khi một job thực sự cần nhiều memory hơn dung lượng máy có, kernel sẽ dành thời gian di chuyển các page giữa RAM và disk thay vì chạy build. Không có gì bị crash. Mọi thứ trở nên ì ạch, còn load average tăng trong khi CPU gần như idle.

vmstat 1 10

Các giá trị khác 0 ổn định trong các cột si và so cho thấy máy đang swapping liên tục. Cách xử lý là giảm concurrency hoặc tăng RAM, tuyệt đối không phải tăng swap. Trên máy nhỏ, sudo apt install -y zram-tools cung cấp swap được nén và giữ trong RAM, được tinh chỉnh trong /etc/default/zramswap. Cách này nhanh hơn nhiều so với swap file và dùng RAM để tiết kiệm RAM, nên hữu ích với các page lạnh nhưng không giúp ích cho build thực sự cần thêm working memory.

Vì sao coding agent của bạn có vẻ bị treo

Đây là lỗi thường bị chẩn đoán sai nhất trên một máy chạy agent nhỏ. Một command không trả về gì, agent chờ và session có vẻ bị đóng băng. Tiến trình đã bị kernel OOM killer kết thúc. Nó nhận SIGKILL nên không thể in lỗi, flush log hoặc báo cho agent biết chuyện gì đã xảy ra. Agent chỉ thấy kết quả rỗng và không có thông báo thoát.

Kernel vẫn ghi lại sự kiện này:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

Một dòng thực tế có dạng như sau:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss là lượng memory mà tiến trình đó đang giữ khi bị kết thúc. Hãy chú ý tiến trình được chọn: kernel chủ yếu chấm điểm dựa trên lượng memory đang sử dụng, nên thường kill language server hoặc agent thay vì build đã đẩy máy vượt quá giới hạn. Đó chính là lý do triệu chứng trông như “agent bị hỏng”.

Trong Docker, cùng sự kiện này để lại dấu vết rõ hơn. Container thoát với code 137, tức 128 cộng với signal 9.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true xác nhận container đã chạm memory limit thay vì tự crash.

Cách xử lý là đặt một giới hạn riêng cho command tốn nhiều tài nguyên, để build bị kết thúc thay vì agent:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

Build hiện bị kill ở mức 4 GB còn agent vẫn hoạt động. Một lỗi treo bí ẩn trở thành một command thất bại thông thường với exit code có thể đọc được. Cách này cần systemd user session, nên hãy chạy loginctl enable-linger $USER trên máy mà bạn chỉ truy cập qua SSH. MemoryHigh= giới hạn tiến trình ở ngưỡng thay vì kill nó. Đây thường là lựa chọn phù hợp hơn cho build mà bạn muốn để chạy chậm nhưng hoàn tất.

Đặt giới hạn một lần bằng memory limits của Compose

Nếu các tool của agent chạy trong container, hãy đặt giới hạn trong file Compose để giới hạn này được áp dụng ở mọi lần chạy.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

Docker Compose v2 áp dụng deploy.resources.limits trên một docker compose up thông thường, nên không liên quan đến swarm mode. Key mem_limit: 2g cũ vẫn hoạt động. Hướng dẫn đầy đủ về memory limits của Compose giải thích reservations và điều gì xảy ra khi container chạm giới hạn. Nếu server chưa có Docker, trước tiên hãy cài Docker trên VPS.

Có một lỗi dễ khiến bạn mất cả buổi chiều. Container bị giới hạn ở 2 GB vẫn đọc /proc/meminfo của host và số CPU của host, vì cả hai đều không được namespace hóa. Một test runner lấy số worker từ số CPU sẽ khởi động tám worker bên trong container 2 GB trên host có tám vCPU, rồi bị dừng với mã 137. Hãy đặt các giá trị này thủ công:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size tính bằng MB và giới hạn V8 heap. Hãy đặt giá trị này thấp hơn giới hạn của container để Node báo lỗi mà bạn có thể đọc, thay vì biến mất:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Thông báo đó rất hữu ích vì nó cho biết giới hạn nào đã bị chạm và process nào đã chạm giới hạn. OOM killer thì không.

Chạy nhiều phiên agent trên cùng một máy

Lập kế hoạch theo từng phiên, không theo từng người. Hai phiên trên cùng một repository vẫn có nghĩa là có hai language server, hai bộ build cache trong memory và hai lần chạy test nếu cả hai agent đều bận cùng lúc. Vì vậy, dòng tổng của team tăng lên 16 GB.

Đặt giới hạn cứng cho từng user để một phiên bị runaway không thể làm toàn bộ máy chủ dừng hoạt động:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

Thay 1001 bằng UID mà id -u đã in ra. systemctl show phải trả về MemoryMax=6442450944 sau khi user đăng nhập. Khi mọi tiến trình trong session của user đó vượt quá 6 GB, kernel sẽ kill một tiến trình bên trong slice của user đó và các session khác vẫn tiếp tục hoạt động. Với agent chạy dưới dạng service thay vì trong terminal, hãy đặt MemoryMax= trong file unit của service đó. Đây là cách nên dùng khi bạn tự host agent dưới dạng service luôn chạy.

FAQ

2 GB RAM có đủ để chạy coding agent không?

Đủ cho tiến trình agent. Nhưng hiếm khi đủ cho công việc mà agent thực hiện. Agent thường dùng khoảng 250 MB, nhưng một language server TypeScript có thể dùng tới 2000 MB trên một repository cỡ trung bình. Chỉ riêng việc đó cũng có thể khiến máy 2 GB bắt đầu dùng swap. 2 GB phù hợp để chỉnh sửa file cấu hình và script nhỏ. Hãy dùng 4 GB làm mức tối thiểu cho mọi tác vụ có biên dịch hoặc chạy test suite.

Tôi có cần GPU để chạy coding agent trên VPS không?

Không, nếu agent gọi model cloud qua API. Workload này phụ thuộc vào network, nên VPS chỉ có CPU là lựa chọn phù hợp. GPU sẽ không được sử dụng nhưng chi phí cao hơn nhiều. Bạn chỉ cần GPU khi model chạy ngay trên máy đó. Khi ấy, vấn đề cần quan tâm chuyển từ RAM sang VRAM và kích thước model.

Tôi nên thêm bao nhiêu swap cho VPS chạy agent?

Bằng một nửa RAM, tối đa khoảng 4 GB. Swap giúp xử lý tình trạng sử dụng RAM tăng vượt mức trong thời gian ngắn, vì kernel có thể chuyển các page ít được dùng sang disk thay vì kill một process. Swap không làm tăng lượng memory có thể sử dụng. Nếu vmstat 1 hiển thị traffic liên tục ở các cột si và so, máy đang thrashing. Khi đó, hãy giảm số worker chạy song song hoặc nâng lên plan lớn hơn.

Tại sao coding agent bị treo giữa lúc build?

Build gần như chắc chắn đã bị kernel OOM killer kill. OOM killer gửi SIGKILL, nên không có output nào được in ra và agent chờ trên một pipe không bao giờ có thêm dữ liệu. Chạy sudo dmesg -T | grep -i "killed process", rồi kiểm tra tên process và giá trị anon-rss của nó. Để khắc phục, hãy giới hạn build bằng systemd-run --user --scope -p MemoryMax=4G và giảm số worker, hoặc nâng lên tier RAM tiếp theo.