
Trả lời nhanh: Ba nguyên nhân theo thứ tự hay gặp. Một là ổ đĩa chậm: mỗi lượt agent phải đọc hàng trăm file để hiểu ngữ cảnh rồi ghi lại thay đổi, chạy test và ghi log. Hai là thiếu RAM: công cụ build và trình phân tích mã chiếm nhiều bộ nhớ, thiếu là máy chuyển sang swap và chậm thảm hại. Ba là độ trễ mạng khi gọi API. Đo bằng iostat và free trong lúc agent đang chạy, cột I/O wait cao mà CPU còn dư nghĩa là ổ đĩa đang là nút thắt.
Bạn giao một tác vụ cho agent rồi ngồi nhìn con trỏ nhấp nháy. Bốn phút sau nó mới trả lời. Cảm giác chờ đợi đó không phải do mô hình chậm mà thường do máy chủ của bạn.
- Agent đọc ghi ổ đĩa nhiều hơn bạn tưởng: đọc mã nguồn, ghi file, chạy test, ghi log từng bước.
- Thiếu RAM khiến máy dùng swap trên ổ cứng, đây là kiểu chậm khó chịu nhất.
- Độ trễ gọi API chỉ chiếm phần nhỏ, đừng đổ lỗi cho mạng trước khi đo.
- Đo trước khi nâng cấp: iostat và free cho biết chính xác nút thắt nằm đâu.
Một phiên làm việc của agent chạm ổ đĩa bao nhiêu lần
Nhìn bề ngoài, agent chỉ gõ vài dòng mã. Nhưng bên dưới mỗi vòng lặp là chuỗi thao tác:
- Đọc cấu trúc thư mục và hàng trăm file để dựng ngữ cảnh.
- Ghi lại file đã sửa, thường nhiều file một lúc.
- Chạy cài thư viện nếu có thay đổi phụ thuộc.
- Chạy build và chạy test, cả hai đều sinh ra rất nhiều file trung gian.
- Ghi log từng bước để bạn xem lại được.
Nhân với vài chục vòng cho một tính năng, tổng lượng đọc ghi rất lớn và toàn file nhỏ nằm rải rác. Đây đúng là kiểu truy cập mà ổ NVMe bỏ xa ổ thường, và cũng là lý do nhiều người mua gói nhiều nhân mà vẫn thấy ì.
Cách đo trong lúc agent đang chạy
Mở phiên thứ hai vào máy chủ rồi chạy song song:
iostat -x 2 # xem cột %util và await
free -h # xem RAM còn lại và swap
top # xem chỉ số wa và mức dùng từng nhânCách đọc:
- %util gần 100 trong khi CPU còn dư: ổ đĩa là nút thắt.
- Swap đang được dùng: thiếu RAM, đây là thứ phải sửa trước tiên.
- Một nhân chạm trần còn các nhân khác rảnh: bị giới hạn bởi xung nhịp, thêm nhân vô ích.
- Cả ba đều thấp mà vẫn chậm: khi đó mới là chuyện độ trễ mạng hoặc phía nhà cung cấp mô hình.
Thứ tự xử lý
- Đủ RAM trước. Máy đang dùng swap thì mọi thứ khác đều vô nghĩa.
- Ổ nhanh. Chuyển sang NVMe cải thiện rõ nhất ở khâu cài thư viện và chạy test.
- Xung nhịp cao. Nhiều bước trong chuỗi build chạy tuần tự.
- Số nhân. Chỉ tăng khi bạn chạy nhiều phiên song song.
Có một cách rẻ hơn mọi khoản nâng cấp: dọn bớt thư mục làm việc. Kho bộ nhớ đệm phình to hàng chục GB làm chậm chính nó, vì mỗi lần kiểm tra thay đổi là một lần quét ổ.
Ngưỡng cụ thể để đọc kết quả đo
Chạy iostat -x 2 và free -h trong lúc agent làm việc, rồi so với bảng này:
| Chỉ số | Ngưỡng đáng lo | Kết luận và việc cần làm |
|---|---|---|
%iowait trong top hoặc cột wa | trên 20% kéo dài | Ổ đĩa là nút thắt. Chuyển sang NVMe hoặc giảm số lần đọc ghi |
await trong iostat -x | trên 10 ms với SSD, trên 1 ms với NVMe | Ổ chậm hơn mức bình thường của loại ổ đó, hoặc đang bị hàng xóm chung máy chủ chiếm |
%util | gần 100 trong khi CPU còn dư | Ổ chạm trần |
Swap đang dùng trong free -h | bất kỳ giá trị nào lớn hơn 0 và đang tăng | Thiếu RAM. Sửa trước mọi thứ khác |
si và so trong vmstat 2 | liên tục khác 0 | Máy đang tráo trang liên tục, đây là kiểu chậm nặng nhất |
Một nhân 100% còn lại rảnh trong top (bấm phím 1) | kéo dài | Nghẽn đơn luồng, thêm nhân vô ích, cần xung nhịp cao hơn |
Đo tổng lượng đọc ghi của cả phiên: cat /proc/PID/io với PID của tiến trình agent, hai dòng read_bytes và write_bytes. Con số này thường làm người ta bất ngờ.
Bốn việc chỉnh được ngay, không tốn tiền
- Giảm swappiness.
sysctl vm.swappiness=10, và ghi vào/etc/sysctl.d/99-swap.confđể giữ sau khi khởi động lại. Máy còn RAM sẽ ít tráo trang hơn. Đây không thay cho việc thêm RAM khi thật sự thiếu. - Dọn bộ nhớ đệm gói. Với dự án Node:
npm cache verify, và xóa các thư mụcnode_modulescủa dự án cũ không còn dùng. Với Python:pip cache purge. Với Docker:docker system prune -a, thường lấy lại vài chục GB. - Loại thư mục nặng khỏi phạm vi agent. Thêm
node_modules,.venv,dist,.next, thư mục dữ liệu mẫu vào tệp bỏ qua của công cụ. Agent quét ít tệp thì mỗi vòng nhanh hơn rõ rệt. - Kiểm tra ổ có bị giới hạn IOPS không.
fiođọc ngẫu nhiên 4k trong 30 giây cho biết trần thật của ổ. Nhà cung cấp giá rẻ thường đặt trần IOPS thấp mà không ghi trong bảng giá, và đó là lý do ổ ghi là NVMe nhưng chạy như SATA.
Cấu hình đề xuất theo quy mô dự án
| Dùng vào việc gì | RAM | Ổ đĩa | CPU |
|---|---|---|---|
| Một phiên, dự án web vừa | 8 GB | NVMe 80 GB | 4 nhân xung cao |
| Hai tới ba phiên song song, có chạy test | 16 GB | NVMe 160 GB | 6 tới 8 nhân |
| Dự án lớn, monorepo, build nặng | 32 GB | NVMe 320 GB | 8 nhân trở lên |
Thứ tự ưu tiên khi ngân sách có hạn: đủ RAM trước, rồi tới ổ NVMe thật, rồi mới tới số nhân. Thêm nhân là khoản đầu tư kém hiệu quả nhất với loại việc này vì phần lớn các bước chạy tuần tự.
Câu hỏi thường gặp
Claude Code cần bao nhiêu RAM trên VPS?
Dự án web vừa chạy tốt với 4GB. Dự án lớn hoặc chạy nhiều phiên song song nên 8GB trở lên. Thiếu RAM là nguyên nhân gây chậm nặng nhất vì máy phải dùng swap trên ổ cứng.
Vì sao agent chậm dù mạng nhanh?
Vì phần lớn thời gian không nằm ở gọi API mà nằm ở đọc mã nguồn, chạy build và chạy test trên máy của bạn. Đó là công việc của ổ đĩa và CPU.
Ổ NVMe giúp Claude Code nhanh hơn bao nhiêu?
Rõ nhất ở khâu cài thư viện và chạy test, hai khâu đọc ghi hàng chục nghìn file nhỏ. Phần gọi mô hình không đổi vì nó chạy trên hạ tầng của nhà cung cấp.
Có nên chạy agent trên máy cá nhân không?
Được cho việc ngắn, nhưng tác vụ dài thì bất tiện vì phải để máy bật và mạng nhà hay chập chờn. VPS giải quyết đúng hai điểm đó.
Bài viết liên quan
- Tailscale trên macOS: App Store, standalone hay brew?
- Hermes Agent cron + scheduled tasks: chạy automation hằng đêm trên VPS
- Host Claude AI agent trên Business Hosting TND
- Giải Pháp Proxy Cao Cấp Cho Người Kinh Doanh Online và Quản Lý Tài Khoản Seller
- Whitelist IP cho VPS, API và database bằng ip.tnd.vn
- CI/CD pipeline GitLab CE self-host trên VPS đầy đủ



