編碼代理 VPS 需要多少 RAM？

編碼代理 VPS 需要多少 RAM？

對於在儲存庫中持續運作的單一編碼代理，請從 4 GB RAM 和 2 vCPU 開始。只要工作階段加入語言伺服器或 Docker build，就應立即升級至 8 GB RAM 和 4 vCPU；對大多數儲存庫而言，這通常在第一天就會發生。代理程式本身占用的資源很少，真正填滿 VPS 的是代理代表你操作的工具鏈。

[
  {
    "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
  }
]

以上每一列都假設模型在其他位置執行，而你透過網路呼叫其 API。這項假設會決定整個規模配置問題，因此應先確認。

您是在執行 agent，還是執行模型？

會呼叫雲端模型的 coding agent，本質上是附帶 shell 的網路用戶端。它會將檔案與執行計畫傳送至 API，等待回應，然後在本機編輯檔案並執行命令。等待回應時，幾乎不會使用 CPU。agent 本身只需要數百 MB 的記憶體，因此配備一般 CPU 的主機即可滿足需求。

自行執行模型則是不同的產品，需要不同的硬體。只要伺服器持續執行，模型權重就會一直留在記憶體中。量化為 4 bits 的 7 billion parameter 模型，光是權重就約需 5 GB，還未計入會隨 context 長度增加的 key/value cache。僅使用 CPU 時，共用的 vCPU 每秒只能產生幾個 token；單一 agent 工作可能產生數千個 token，因此原本透過 API 在不到 1 分鐘內完成的工作，在本機執行可能需要將近 1 小時。如果這才是您的需求，請依 VRAM（GPU 的視訊記憶體）規劃硬體，並閱讀GPU VPS 實際能提供什麼，不要參考本頁。

以下內容皆以雲端模型情境為前提。

實際使用記憶體的項目

[
  {
    "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
  }
]

這些是中型專案常見的公開數據。請將它們視為大致輪廓，不要視為對您程式碼的承諾。

圖表包含 6 列，其中 agent 的記憶體用量最低。閒置時約為 250 MB，因為它只維持一段對話和小型檔案快取，沒有其他工作。TypeScript language server 在建立索引時約使用 2000 MB，因為它會為從您的 tsconfig.json 可到達的每個檔案建立型別圖，並將該圖保留在記憶體中，以快速回應下一個請求。rust-analyzer 在大型 workspace 中通常會超過 4000 MB，原因相同，而且涵蓋 workspace 中的每個 crate。

Headless Chrome 包含瀏覽器與一個分頁時約使用 350 MB，每增加一個分頁，就會多出一個 operating system process。使用 4 個 worker 的 Node 測試執行會產生 4 個 Node process，因此峰值接近 3000 MB。Docker image build 的峰值接近 2500 MB，因為 build 會在 container 內執行專案本身的 compiler，同時 daemon 會寫入 layers。

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

請讀取 free -h 的 available 欄，而不是 free 欄。Linux 會將所有剩餘頁面用於磁碟快取，因此在完全正常的主機上，free 可能很小，無法提供有用資訊。available 才是新 process 實際可以取得的記憶體。

可行的3種配置

最低可行配置：4 GB RAM、2 vCPU、50 GB 磁碟。 執行1個 agent 工作階段、1個儲存庫、1個 language server，以及可以接受等待時間的建置工作。此配置可以運作，但大型測試執行作業與 indexing language server 同時執行時，第一次就可能觸發 out-of-memory killer。請加入 swap，並限制建置 worker 數量。

舒適配置：8 GB RAM、4 vCPU、100 GB 磁碟。 可同時執行1個 agent、Docker 及用於測試的 headless browser，並為1次建置尖峰保留餘裕。大多數單人開發者都應選擇此配置。將 vCPU 數量加倍，大致也能將建置等待時間減半；這種改善的感受通常比增加記憶體更明顯。

團隊配置：16 GB RAM、8 vCPU、200 GB 磁碟。 可同時執行4個工作階段，每個工作階段都有自己的 checkout 與 toolchain。請依尖峰負載規劃，因為4個閒置的 agent 幾乎不會產生成本，但4個測試執行作業同時進行時，成本會是上方最高配置欄位的4倍。

截至2026年8月，從第1列到最後1列的配置，在按年計費的 VPS 方案中，月費大約增加4倍：最低配置每月為個位數美元，最高配置則為數十美元。規劃前請查看目前的方案清單，因為這些數字會變動。伺服器通常不是昂貴的部分。對每天使用 agent 的人來說，模型 API 費用很快就會超過伺服器費用，因此請先限制 agent 可支出的金額，再縮減伺服器規模。至於建置本身，在 VPS 上執行 coding agent 的操作指南涵蓋帳號設定，以及中斷連線後維持工作階段運作的方法。

磁碟空間耗盡的速度比 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
  }
]

將這些項目加總後，50 GB 磁碟在你寫下第一行程式碼前就幾乎已滿。最大單一項目是 Docker，約占 20 GB，因為 BuildKit 會保留每次建置的所有中間層，直到你要求它清除為止。

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

docker system df 會列出各類別可回收的空間，因此請在清除前後各執行一次。until=168h 會刪除超過一週的建置快取，保留本週的快取；這些快取仍能節省建置時間。docker image prune -a 會進一步刪除所有沒有任何容器使用的映像，因此下次建置時預期需要重新下載。

Node 專案會以更難察覺的方式失敗。npm install 會建立數十萬個小檔案，因此檔案系統可能先耗盡 inode，即使 df -h 仍顯示有數 GB 的可用空間。此時寫入會因 No space left on device 而失敗，但磁碟看起來仍只使用了一半。

df -h /
df -i /

如果 IUse% 讀值為 100，請刪除不再使用的分支之 node_modules 目錄，或改用 pnpm；它只會儲存每個套件版本一次，再透過 hard link 將套件連結到每個專案。

日誌則是較不易察覺的項目。持續執行的 agent 會寫入工作階段記錄，而 systemd journal 預設會逐漸占用部分磁碟空間。

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

在 /etc/systemd/journald.conf 中設定 SystemMaxUse=200M，再執行 sudo systemctl restart systemd-journald，讓此上限永久生效，因為只執行一次 vacuum 只能暫時釋放當下的空間。

Swap 能解決什麼問題，也會掩蓋什麼問題

應該加入 swap，因為它能把小幅度的記憶體超用，轉變成速度緩慢的工作，而不是讓程序直接終止。將 swap 大小設為 RAM 的一半，最多約 4 GB。對 build box 而言，通常沒有必要再增加。

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 現在應列出大小符合要求的 /swapfile。如果沒有 /etc/fstab 這一行，swap 會在下次重新開機後消失，主機也會無聲地恢復原本的行為。如果 fallocate 回應 Operation not supported，請使用 sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 建立檔案，然後從 chmod 繼續。

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

較低的 swappiness 會告訴 kernel 先回收磁碟快取，再將程序記憶體移出到磁碟，讓 language server 維持回應。

接下來是 swap 會掩蓋的問題。當工作確實需要超過主機現有容量的記憶體時，kernel 會把時間花在 RAM 與磁碟之間搬移頁面，而不是執行 build。系統不會當機，但所有工作都會變得極慢；CPU 閒置時，load average 卻會上升。

vmstat 1 10

si 和 so 欄位持續出現非零數值，表示系統正在持續進行 swapping。因此，解決方式是降低並行度或增加 RAM，絕不是增加 swap。在小型主機上，sudo apt install -y zram-tools 會提供儲存在 RAM 中的壓縮 swap，並在 /etc/default/zramswap 中進行設定。它比 swap file 快得多，但會用 RAM 來節省 RAM，因此適合處理冷頁面，不適合處理需要實際工作記憶體的 build。

為什麼你的 coding agent 看起來像是卡住

這是小型 agent 主機上最容易被誤判的故障。命令沒有傳回任何內容，agent 持續等待，工作階段看起來像是凍結。實際上，程序遭到核心的 out-of-memory (OOM) killer 終止。它收到 SIGKILL，因此無法輸出錯誤、寫入剩餘日誌，或告知 agent 發生了什麼事。agent 只會看到空白結果，且沒有結束訊息。

核心確實會記錄這個事件：

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

實際的日誌行如下：

[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 表示該程序終止時占用的記憶體量。請注意核心選擇終止的程序：核心主要依據記憶體使用量評分，因此經常終止 language server 或 agent，而不是讓主機超出記憶體上限的 build 程序。這正是為什麼症狀看起來像是「agent 出問題」。

在 Docker 內發生相同事件時，會留下更明確的跡象。容器會以代碼 137 結束，也就是 128 加上 signal 9。

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

"OOMKilled": true 可確認容器是觸及記憶體上限，而不是自行當機。

解決方式是為耗用大量資源的命令設定獨立上限，讓 build 終止，而不是讓 agent 終止：

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

現在 build 會在 4 GB 時遭到終止，而 agent 仍可繼續運作。原本難以判斷的卡住現象，會變成具有可讀結束代碼的一般命令失敗。這需要 systemd user session，因此如果主機只能透過 SSH 存取，請在該主機上執行 loginctl enable-linger $USER。MemoryHigh= 會在達到門檻時限制程序，而不是終止程序。對於希望完成、即使需要較長時間的 build，這通常是較合適的設定。

使用 Compose 一次設定記憶體上限

如果 agent 的工具在容器中執行，請將上限寫入 Compose 檔案，讓每次執行都套用相同限制。

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

Docker Compose v2 會在一般的 docker compose up 上套用 deploy.resources.limits，因此不涉及 swarm mode。較舊的 mem_limit: 2g key 仍可使用。Compose 記憶體限制完整指南說明 reservations，以及容器達到上限時的行為。如果伺服器尚未安裝 Docker，請先在 VPS 上安裝 Docker。

有一個陷阱會讓人耗上一個下午。即使容器限制為 2 GB，仍會讀取主機的 /proc/meminfo 和 CPU 數量，因為這兩者都未納入 namespace。測試 runner 若依 CPU 數量決定 worker 數量，就會在 2 GB 容器中於 8 vCPU 主機上啟動 8 個 worker，最後以 137 結束。請手動設定這些數值：

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

--max-old-space-size 的單位是 MB，並會限制 V8 heap。請將它設在容器限制以下，讓 Node 回報可讀取的錯誤，而不是直接消失：

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

這則訊息很有用，因為它會指出觸發的限制，以及觸發該限制的程序。OOM killer 從不提供這些資訊。

每個主動工作階段分別規劃，而不是依使用者人數規劃

同一個 repository 上執行 2 個工作階段，仍代表需要 2 個 language server、記憶體中 2 組 build cache，以及在 2 個 agent 同時忙碌時執行 2 次測試。因此，團隊列的需求會增加至 16 GB。

為每位使用者設定硬性上限，避免單一失控的工作階段耗盡整台伺服器的資源：

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

將 1001 替換為 id -u 輸出的 UID。使用者登入後，systemctl show 應輸出 MemoryMax=6442450944。當該使用者工作階段中的所有程序總計超過 6 GB 時，kernel 會終止其 slice 內的一個程序，其他工作階段仍可繼續運作。若 agent 是以 service 而非 terminal 執行，請改在其 unit file 中加入 MemoryMax=。當您 將 agent 自行架設為常駐 service 時，應採用這種方式。

FAQ

coding agent 需要 2 GB RAM 嗎？

對 agent 程序而言，足夠。對它執行的工作而言，通常不夠。agent 程序本身約使用 250 MB，但單一 TypeScript language server 在中型 repository 中可能達到 2000 MB，光是這項負載就可能讓 2 GB 伺服器開始使用 swap。2 GB 適合編輯設定檔與小型 script。凡是需要編譯或執行 test suite 的工作，請至少使用 4 GB。

在 VPS 上執行 coding agent 需要 GPU 嗎？

如果 agent 透過 API 呼叫 cloud model，就不需要。這類工作受 network 限制，因此一般 CPU VPS 才是合適的機器；GPU 會閒置，但價格高得多。只有在 model 本身於同一台伺服器上執行時才需要 GPU。此時需要考量的是 VRAM 與 model size，而不是 RAM。

應為 agent VPS 增加多少 swap？

設定為 RAM 的一半，最多約 4 GB。swap 可在記憶體短暫超量時提供緩衝，因為 kernel 能將不常使用的 pages 移至 disk，而不是直接終止 process。swap 不會增加可用記憶體。如果 vmstat 1 在 si 與 so 欄位中顯示持續流量，表示伺服器正在 thrashing。此時應減少平行 worker，或升級至更大的方案。

為什麼 coding agent 會在 build 中途凍結？

build 幾乎確定是遭 kernel 的 OOM killer 終止。OOM killer 會送出 SIGKILL，因此不會輸出任何訊息，而 agent 會等待一個永遠不會填滿的 pipe。執行 sudo dmesg -T | grep -i "killed process"，查看 process name 及其 anon-rss 值。可使用 systemd-run --user --scope -p MemoryMax=4G 限制 build、降低 worker 數量，或升級至上一級 RAM 方案。