Gaano Karaming RAM ang Kailangan ng Coding Agent VPS?

Gaano karaming RAM ang kailangan ng coding agent VPS?

Magsimula sa 4 GB na RAM at 2 vCPU para sa isang coding agent na laging tumatakbo at gumagana sa isang repository. Lumipat sa 8 GB at 4 vCPU sa sandaling may language server o Docker build nang kasali sa session. Sa karamihan ng repository, nangyayari ito sa unang araw. Maliit mismo ang agent process, kaya ang kumokonsumo ng resources sa server ay ang toolchain na pinapatakbo nito para sa iyo.

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

Ipinapalagay ng bawat row sa itaas na tumatakbo ang model sa ibang lugar, sa likod ng isang API na tinatawagan mo sa network. Ang palagay na ito ang nagtatakda sa buong usapin ng sizing, kaya ayusin muna ito.

Agent ba ang pinapatakbo mo, o ang model?

Ang coding agent na tumatawag sa cloud model ay isang network client na may kalakip na shell. Nagpapadala ito ng mga file at plano sa isang API, naghihintay ng tugon, pagkatapos ay nag-e-edit ng mga file at nagpapatakbo ng mga command nang lokal. Habang naghihintay ito, halos walang CPU ang ginagamit nito. Nasusukat sa daan-daang megabytes ang memory na ginagamit nito, kaya ang tamang machine ay isang katamtamang CPU box.

Ibang produkto ang pagpapatakbo ng model mismo, at ibang hardware ang kailangan dito. Nananatili sa memory ang weights habang tumatakbo ang server. Ang model na may 7 billion parameters at naka-quantise sa 4 bits ay nangangailangan ng humigit-kumulang 5 GB para sa weights lamang, bago idagdag ang key/value cache na lumalaki batay sa haba ng context. Kung CPU lamang ang gamit, ilang token bawat segundo lang ang nalilikha ng isang shared vCPU. Maaaring maglabas ng libo-libong token ang isang agent task, kaya ang gawaing wala pang isang minuto kapag API ang gamit ay maaaring umabot ng halos isang oras kapag lokal. Kung ito ang kailangan mo, maglaan ng sapat na VRAM (video memory sa GPU) at basahin ang kung ano talaga ang ibinibigay ng VPS na may GPU sa halip na ang page na ito.

Ipinapalagay ng lahat ng sumusunod ang paggamit ng cloud model.

Ano talaga ang gumagamit ng memory

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

Karaniwang published figures ang mga ito para sa mga mid-size project. Gamitin ang mga ito bilang pangkalahatang pattern, hindi bilang garantiya para sa code mo.

May 6 row ang chart, at ang agent ang may pinakamababang paggamit. Nasa humigit-kumulang 250 MB ito kapag idle, dahil may hawak itong conversation at maliit na file cache lamang. Umaabot ang TypeScript language server sa humigit-kumulang 2000 MB habang nag-i-index ito, dahil bumubuo ito ng type graph para sa bawat file na naaabot mula sa tsconfig.json at pinananatili ang graph na iyon sa memory upang mas mabilis nitong masagot ang susunod na request. Karaniwang lumalagpas ang rust-analyzer sa 4000 MB sa malaking workspace sa parehong dahilan, para sa bawat crate sa workspace.

Umaabot ang headless Chrome sa humigit-kumulang 350 MB para sa browser at isang tab, at ang bawat karagdagang tab ay nagdadagdag ng isa pang operating system process. Ang Node test run na may apat na worker ay binubuo ng apat na Node process, kaya umaabot ang peak nito sa malapit sa 3000 MB. Umaabot ang Docker image build sa humigit-kumulang 2500 MB, dahil pinapatakbo ng build ang sariling compiler ng project sa loob ng container habang nagsusulat ng layers ang daemon.

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

Basahin ang column na available ng free -h, hindi ang column na free. Ginagamit ng Linux ang bawat ekstrang page para sa disk cache, kaya maliit ang free sa isang ganap na maayos na machine at wala itong kapaki-pakinabang na ipinapahiwatig. Ang available ang nagsasabi kung gaano karaming memory ang aktuwal na maaaring makuha ng bagong process.

Tatlong configuration na gumagana

Minimum viable: 4 GB RAM, 2 vCPU, 50 GB disk. Isang agent session, isang repository, isang language server, at mga build na handa mong hintayin. Gumagana ang tier na ito, ngunit tatamaan ito ng out-of-memory killer kapag nagsabay ang isang malaking test run at isang language server na nag-i-index. Magdagdag ng swap at limitahan ang mga build worker.

Komportable: 8 GB RAM, 4 vCPU, 100 GB disk. Isang agent, kasama ang Docker at isang headless browser para sa mga test, na may sapat na headroom para sa isang build spike. Ito ang tier na dapat piliin ng karamihan sa mga solo developer. Kapag dinoble ang bilang ng vCPU, humigit-kumulang kalahati ang build wait, at mas madalas mo itong mapapansin kaysa sa epekto ng memory.

Team: 16 GB RAM, 8 vCPU, 200 GB disk. Apat na concurrent session, bawat isa ay may sariling checkout at sariling toolchain. Mag-size ayon sa peak usage, dahil halos walang gastos ang apat na idle agent, samantalang ang apat na sabay-sabay na test run ay nagkakahalaga ng apat na beses ng peak column sa itaas.

Noong August 2026, humigit-kumulang apat na beses ang buwanang presyo ng unang row kumpara sa huling row kapag annual VPS billing: single-digit dollars bawat buwan sa pinakamababa, at tens of dollars sa pinakamataas. Suriin ang kasalukuyang listing bago magplano, dahil nagbabago ang mga halagang ito. Bihirang ang server ang pinakamahal na bahagi. Para sa sinumang gumagamit ng agent araw-araw, mabilis na lalampas sa server bill ang model API bill, kaya limitahan kung magkano ang maaaring gastusin ng agent bago ka pumili ng mas maliit na server. Para sa mismong build, saklaw ng walkthrough para sa pagpapatakbo ng coding agent sa VPS ang pag-set up ng account at pagpapanatiling aktibo ng session pagkatapos mong mag-disconnect.

Bakit nauubusan ka ng disk bago maubusan ng 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
  }
]

Kapag pinagsama ang mga row na iyon, halos puno na ang 50 GB disk bago ka pa makasulat ng isang linya ng code. Ang pinakamalaking item ay Docker, na nasa humigit-kumulang 20 GB, dahil iniingatan ng BuildKit ang bawat intermediate layer ng bawat build hanggang sabihin mong itigil ito.

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

Ipinapakita ng docker system df ang reclaimable space ayon sa kategorya, kaya patakbuhin ito bago at pagkatapos ng cleanup. Inaalis ng until=168h filter ang build cache na mas luma sa isang linggo at pinananatili ang cache ng kasalukuyang linggo, dahil ito pa ang nakakatipid ng oras. Mas malawak ang paglilinis ng docker image prune -a at inaalis nito ang bawat image na hindi ginagamit ng anumang container, kaya asahan mong magda-download muli ang susunod na build.

Mas kakaiba ang failure sa mga Node project. Lumilikha ang npm install ng daan-daang libong maliliit na file, kaya maaaring maubusan ng inodes ang filesystem kahit nag-uulat pa ang df -h ng mga libreng gigabyte. Nabibigo ang pagsusulat at lumalabas ang No space left on device kahit mukhang kalahating puno lamang ang disk.

df -h /
df -i /

Kung nagbabasa ang IUse% ng 100, tanggalin ang node_modules directories ng mga branch na hindi mo na ginagamit, o lumipat sa pnpm. Iniimbak nito ang bawat package version nang isang beses at gumagamit ng hard links para maisama ito sa bawat project.

Tahimik na kumokonsumo ng space ang logs. Nagsusulat ng session transcripts ang isang always-on agent, at karaniwang lumalaki ang systemd journal hanggang kumain ito ng malaking bahagi ng disk.

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

Itakda ang SystemMaxUse=200M sa /etc/systemd/journald.conf at patakbuhin ang sudo systemctl restart systemd-journald upang maging permanente ang limit na iyon, dahil pansamantalang space lamang ang nababawi ng one-off vacuum.

Swap: ano ang naitutulong nito at ano ang tinatago nito

Makabubuting magdagdag ng swap dahil ginagawa nitong mabagal na trabaho ang maliit na paglagpas sa memory limit sa halip na maging dead process. Itakda ang laki nito sa kalahati ng RAM, hanggang humigit-kumulang 4 GB. Kaunti ang dahilan para lumampas pa rito sa isang 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

Dapat ilista ngayon ng swapon --show ang /swapfile sa laki na itinakda mo. Kung wala ang linyang /etc/fstab, mawawala ang swap pagkatapos ng susunod na reboot at tahimik na babalik ang box sa dati nitong behavior. Kung fallocate ay sumagot ng Operation not supported, gawin ang file gamit ang sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 at magpatuloy mula sa chmod.

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

Kapag mababa ang swappiness, inuuna ng kernel na i-reclaim ang disk cache bago ilipat sa disk ang memory ng program. Dahil dito, nananatiling responsive ang language server.

Ngayon, ang bahagi na tinatago ng swap. Kapag tunay na nangangailangan ang isang job ng mas maraming memory kaysa sa mayroon ang box, ginugugol ng kernel ang oras nito sa paglilipat ng pages sa pagitan ng RAM at disk sa halip na patakbuhin ang build. Walang nagka-crash. Bumagal ang lahat, at tumataas ang load average habang idle ang CPU.

vmstat 1 10

Ang tuloy-tuloy na mga numerong hindi zero sa mga column na si at so ay nangangahulugang tuloy-tuloy ang swapping. Kaya ang solusyon ay bawasan ang concurrency o dagdagan ang RAM, at hindi kailanman dagdagan ang swap. Sa maliit na box, nagbibigay ang sudo apt install -y zram-tools ng compressed swap na nananatili sa RAM at naka-tune sa /etc/default/zramswap. Mas mabilis ito kaysa sa swap file. Gumagamit ito ng RAM para makatipid ng RAM, kaya nakatutulong ito sa cold pages ngunit hindi sa build na talagang nangangailangan ng working memory.

Bakit mukhang nagha-hang ang coding agent mo

Ito ang pinakamadalas na maling natutukoy na failure sa isang maliit na agent box. Walang ibinabalik na output ang command, naghihintay ang agent, at mukhang nag-freeze ang session. Pinatay ng kernel ang process dahil sa out-of-memory (OOM). Nakatanggap ito ng SIGKILL, kaya hindi ito nakapag-print ng error, nakapag-flush ng log, o nakapagsabi sa agent kung ano ang nangyari. Nakakita ang agent ng walang laman na resulta at walang exit message.

Nire-record pa rin ito ng kernel:

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

Ganito ang hitsura ng isang aktuwal na linya:

[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

Ipinapakita ng anon-rss kung gaano karaming memory ang hawak ng process nang mamatay ito. Pansinin kung aling process ang pinili: pangunahing binabase ng kernel ang score sa memory na ginagamit, kaya madalas nitong pinapatay ang language server o ang agent sa halip na ang build na nagtulak sa box lampas sa limitasyon. Ito mismo ang dahilan kung bakit mukhang “nasira ang agent” ang sintomas.

Sa loob ng Docker, nag-iiwan ang parehong event ng mas malinaw na palatandaan. Lumalabas ang container na may code 137, na 128 dagdag sa signal 9.

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

Kinukumpirma ng "OOMKilled": true na naabot ng container ang memory limit nito, sa halip na kusang mag-crash.

Ang solusyon ay bigyan ng sariling ceiling ang command na malaki ang konsumo, upang ang build ang mamatay sa halip na ang agent:

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

Pinapatay na ngayon ang build kapag umabot sa 4 GB, habang nananatiling gumagana ang agent. Dahil dito, nagiging ordinaryong failed command na may malinaw na exit code ang dating misteryosong hang. Kailangan nito ng systemd user session, kaya patakbuhin ang loginctl enable-linger $USER sa box na naaabot mo lamang sa SSH. Ina-throttle ng MemoryHigh= ang process kapag nasa threshold ito sa halip na patayin, na kadalasang mas angkop para sa build na mas gugustuhin mong matapos nang mabagal.

Itakda ang memory limit gamit ang Compose

Kung tumatakbo sa containers ang tools ng agent, ilagay ang limit sa Compose file para mailapat ito sa bawat run.

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

Inilalapat ng Docker Compose v2 ang deploy.resources.limits sa isang plain na docker compose up, kaya hindi kasali ang swarm mode. Gumagana pa rin ang lumang mem_limit: 2g key. Sinasaklaw ng Buong guide sa memory limits ng Compose ang reservations at ipinapaliwanag kung ano ang nangyayari kapag naabot ng container ang limit nito. Kung wala pa ang Docker sa server, i-install muna ang Docker sa isang VPS.

May isang karaniwang pagkakamali na maaaring kumain ng isang hapon. Kahit limitado sa 2 GB ang isang container, nababasa pa rin nito ang /proc/meminfo ng host at ang bilang ng CPU ng host dahil hindi naka-namespace ang mga ito. Ang test runner na kumukuha ng bilang ng worker mula sa bilang ng CPU ay magsisimula ng walong worker sa loob ng 2 GB container sa host na may walong vCPU, at pagkatapos ay mamamatay na may exit code 137. Itakda nang manu-mano ang mga value:

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

Ang --max-old-space-size ay nasa MB at nililimitahan nito ang V8 heap. Itakda ito nang mas mababa kaysa sa limit ng container para maglabas si Node ng error na mababasa mo sa halip na biglang mawala:

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

Mahalaga ang mensaheng iyon dahil tinutukoy nito ang limit na naabot at ang process na nakarating dito. Hindi iyon ginagawa ng OOM killer.

Pagpapatakbo ng maraming agent session sa isang box

Magplano batay sa bawat session, hindi sa bawat tao. Ang 2 session sa iisang repository ay nangangahulugang 2 language server, 2 set ng build cache sa memory, at 2 test run kung parehong magiging abala ang mga agent sa parehong oras. Kaya umaabot sa 16 GB ang value sa row ng team.

Magtakda ng hard ceiling para sa bawat user upang hindi mapabagsak ng isang runaway session ang buong box:

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

Palitan ang 1001 ng UID na ipinakita ng id -u. Dapat i-echo ng systemctl show ang MemoryMax=6442450944 kapag naka-login na ang user. Kapag lumampas sa 6 GB ang kabuuang session ng user na iyon, papatayin ng kernel ang isang process sa loob ng slice niya, habang patuloy na gagana ang lahat ng iba pang session. Para sa agent na tumatakbo bilang service sa halip na nasa terminal, ilagay ang MemoryMax= sa unit file nito. Ito ang pattern na dapat gamitin kapag nagho-host ng agent bilang palaging naka-on na service.

FAQ

Sapat ba ang 2 GB RAM para sa isang coding agent?

Para sa proseso ng agent, oo. Para sa mga gawaing isinasagawa nito, bihira. Karaniwang nasa 250 MB ang agent, pero maaaring umabot sa 2000 MB ang isang TypeScript language server sa isang katamtamang laki ng repository, at sapat na iyon para mapunta sa swap ang isang 2 GB na server. Sapat ang 2 GB para sa pag-edit ng configuration file at maliliit na script. Gamitin ang 4 GB bilang minimum para sa anumang nagko-compile o nagpapatakbo ng test suite.

Kailangan ko ba ng GPU para magpatakbo ng coding agent sa isang VPS?

Hindi kung tumatawag ang agent sa isang cloud model sa pamamagitan ng API. Network-bound ang workload na iyon, kaya plain CPU VPS ang tamang machine at mananatiling idle ang GPU sa mas mataas na halaga. Kailangan mo lang ng GPU kapag tumatakbo mismo ang model sa parehong server. Sa ganitong sitwasyon, nagbabago ang tanong mula RAM tungo sa VRAM at laki ng model.

Gaano karaming swap ang dapat kong idagdag sa isang agent VPS?

Kalahati ng RAM, hanggang humigit-kumulang 4 GB. Pinoprotektahan ka ng swap laban sa panandaliang pagtaas ng memory usage, dahil maaaring ilipat ng kernel sa disk ang mga cold page sa halip na mag-kill ng proseso. Hindi ito nagdaragdag ng usable memory. Kung nagpapakita ang vmstat 1 ng tuloy-tuloy na traffic sa mga column na si at so, nagta-thrash ang server. Ang solusyon ay bawasan ang mga parallel worker o gumamit ng mas malaking plan.

Bakit nag-freeze ang coding agent ko sa kalagitnaan ng build?

Halos tiyak na na-kill ng kernel OOM killer ang build. Nagpapadala ito ng SIGKILL, kaya walang napi-print at naghihintay ang agent sa isang pipe na hindi na mapupuno. Patakbuhin ang sudo dmesg -T | grep -i "killed process" at tingnan ang process name at ang value nito sa anon-rss. Ayusin ito sa pamamagitan ng pag-limit sa build gamit ang systemd-run --user --scope -p MemoryMax=4G at pagbawas sa bilang ng worker, o paglipat sa susunod na RAM tier.