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?

Một coding agent gọi cloud model thực chất là một network client có gắn shell. Nó gửi file và plan đến API, chờ phản hồi, sau đó chỉnh sửa file và chạy command cục bộ. Trong lúc chờ, nó gần như không dùng CPU. Lượng memory của chính agent chỉ tính bằng hàng trăm megabyte, vì vậy một 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 chừng nào server còn chạy. Một model 7 billion parameter được quantise xuống 4 bit cần khoảng 4 GB weights (Llama 2 7B được phát hành ở mức 3.83 GB với Q4_0 và 4.08 GB với Q4_K_M), và publisher của model này liệt kê mức 6.3 đến 6.6 GB RAM để chạy không có GPU sau khi tính cả overhead của runtime. Context dài hơn cần nhiều memory hơn vì key/value cache tăng theo độ dài của context. Chỉ dùng CPU, một shared vCPU chỉ tạo được vài token mỗi giây, trong khi một agent task có thể sinh ra hàng nghìn token. Vì vậy, một tác vụ mất chưa đến một phút khi gọi API có thể mất gần cả giờ khi chạy cục bộ. Nếu đó là mục tiêu của bạn, hãy sizing 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.

Toàn bộ phần bên dưới giả định trường hợp 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 disk 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 dòng đó lại, một disk 50 GB gần như đã đầy trước khi bạn viết một dòng code. Mục lớn nhất là Docker, khoảng 20 GB, vì BuildKit giữ lại mọi intermediate layer của mọi build cho đến khi bạn yêu cầu nó dừng.

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 category, vì vậy hãy chạy nó trước và sau khi dọn dẹp. Filter until=168h giữ lại các cache record mà build đã dùng trong tuần qua và xóa phần còn lại. Nó dựa trên lần sử dụng gần nhất, không dựa trên tuổi của cache. Vì vậy, một layer được tạo từ một tháng trước nhưng được dùng lại hôm qua vẫn còn nguyên; đó là cache vẫn giúp bạn tiết kiệm thời gian. docker image prune -a đi xa hơn và xóa mọi image mà không container nào đang dùng, vì vậy hãy dự kiến build tiếp theo sẽ phải pull lại.

Node project 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 vẫn còn trống một nửa.

df -h /
df -i /

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

Log là nguyên nhân âm thầm. Một agent luôn chạy sẽ ghi session transcript, còn systemd journal mặc định sẽ tăng dần và chiếm một phần 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ì một lần vacuum đơn lẻ 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 trông như bị treo

Đây là lỗi thường bị chẩn đoán sai nhất trên một agent box nhỏ. Một command không trả về gì, agent tiếp tục chờ, và session trông như bị freeze. Process đã bị kernel out-of-memory (OOM) killer terminate. 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ó exit message.

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

Bên trong Docker, cùng sự kiện này để lại dấu hiệu rõ hơn. Container thoát với code 137, tức là 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 ceiling riêng cho command tốn nhiều tài nguyên, để build bị dừng thay vì agent:

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

Build hiện bị kill ở mức 4 GB và agent vẫn chạy. Một lần treo khó hiểu nay 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 manager. Một SSH login thông thường sẽ khởi động manager này cho bạn, nên command hoạt động qua SSH như hiện tại. loginctl enable-linger $USER chỉ dùng để giữ user unit chạy sau khi bạn logout. MemoryHigh= giới hạn process ở 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.