Coding agent VPS साठी किती RAM आवश्यक आहे?

कोडिंग agent VPS साठी किती RAM आवश्यक आहे?

एका repository मध्ये सतत चालणाऱ्या एका coding agent साठी 4 GB RAM आणि 2 vCPU पासून सुरुवात करा. Session मध्ये language server किंवा Docker build जोडताच 8 GB RAM आणि 4 vCPU वर जा. बहुतेक repositories मध्ये हे पहिल्याच दिवशी घडते. Agent process स्वतः लहान असतो. त्यामुळे agent तुमच्या वतीने चालवतो तो toolchain 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
  }
]

वरील प्रत्येक पर्यायात model अन्यत्र चालतो आणि तुम्ही network वरून API call करता, असे गृहीत धरले आहे. Sizing चा संपूर्ण निर्णय या गृहीतकावर अवलंबून असतो. त्यामुळे आधी हे निश्चित करा.

तुम्ही agent चालवत आहात की model?

Cloud model ला कॉल करणारा coding agent हा shell जोडलेला network client असतो. तो files आणि plan API कडे पाठवतो, reply ची प्रतीक्षा करतो, त्यानंतर files संपादित करतो आणि commands स्थानिक पातळीवर चालवतो. प्रतीक्षा करत असताना तो जवळजवळ CPU वापरत नाही. त्याची memory वापराची गरज शेकडो megabytes इतकी असते. त्यामुळे मध्यम क्षमतेचा CPU box हे योग्य machine ठरते.

स्वतः model चालवणे हे वेगळ्या hardware वरचे वेगळे product आहे. Server सुरू असेपर्यंत weights memory मध्ये राहतात. 4 bits वर quantise केलेल्या 7 billion parameter model ला फक्त weights साठी अंदाजे 5 GB आवश्यक असतात. याशिवाय context च्या लांबीसोबत वाढणारा key/value cache आवश्यक असतो. केवळ CPU वर shared vCPU दर सेकंदाला काही tokens तयार करतो. एका agent task मध्ये हजारो tokens तयार होऊ शकतात. त्यामुळे API वापरून एका मिनिटापेक्षा कमी वेळात पूर्ण होणारे काम स्थानिक पातळीवर जवळजवळ एक तास घेऊ शकते. तुम्हाला हेच करायचे असल्यास VRAM (GPU वरील video memory) नुसार क्षमता ठरवा आणि या पानाऐवजी GPU असलेला VPS प्रत्यक्षात काय देतो ते वाचा.

खालील सर्व माहिती cloud-model प्रकरणावर आधारित आहे.

प्रत्यक्षात 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
  }
]

ही mid-size प्रोजेक्ट्ससाठी प्रकाशित केलेली सामान्य आकडेवारी आहे. ती तुमच्या code बाबतची हमी समजू नका; फक्त एक सामान्य आकारमान म्हणून पहा.

या chart मध्ये 6 rows आहेत आणि agent सर्वात कमी memory वापरतो. तो idle असताना जवळपास 250 MB memory वापरतो, कारण त्याच्याकडे conversation आणि छोटा file cache असतो; त्याशिवाय काही नसते. TypeScript language server indexing करताना सुमारे 2000 MB पर्यंत पोहोचतो, कारण तो तुमच्या tsconfig.json पासून उपलब्ध असलेल्या प्रत्येक file साठी type graph तयार करतो आणि पुढील request ला जलद उत्तर देता यावे म्हणून तो graph memory मध्ये ठेवतो. मोठ्या workspace मध्ये rust-analyzer याच कारणामुळे सामान्यतः 4000 MB पेक्षा जास्त memory वापरतो; workspace मधील प्रत्येक crate साठी हे लागू होते.

Headless Chrome browser आणि एका tab साठी सुमारे 350 MB memory वापरतो. प्रत्येक अतिरिक्त tab साठी आणखी एक operating system process तयार होतो. चार workers सह Node test run म्हणजे चार Node processes. त्यामुळे ते जवळपास 3000 MB memory वापरते. Docker image build करताना memory वापर जवळपास 2500 MB पर्यंत पोहोचतो, कारण build container मध्ये तुमच्या project चा 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 column वाचा, free column नाही. Linux उरलेली प्रत्येक page disk cache साठी वापरते. त्यामुळे पूर्णपणे निरोगी box वर free लहान असतो आणि त्यातून काहीही कळत नाही. नवीन process ला प्रत्यक्षात किती memory मिळू शकते हे available दाखवतो.

काम करणारी तीन कॉन्फिगरेशन

किमान व्यवहार्य: 4 GB RAM, 2 vCPU, 50 GB डिस्क. एक agent session, एक repository, एक language server आणि ज्यांच्यासाठी प्रतीक्षा करणे स्वीकार्य आहे असे builds. हा स्तर कार्य करतो; परंतु मोठ्या test run ची वेळ indexing language server सोबत जुळली की पहिल्याच वेळी out-of-memory killer सक्रिय होईल. Swap जोडा आणि build workers ची कमाल संख्या मर्यादित करा.

आरामदायी: 8 GB RAM, 4 vCPU, 100 GB डिस्क. एक agent, त्यासोबत Docker आणि tests साठी headless browser, तसेच एका build spike साठी अतिरिक्त क्षमता. बहुतेक single developers नी हा स्तर निवडावा. vCPU ची संख्या दुप्पट केल्यास build साठीची प्रतीक्षा साधारण निम्मी होते. मेमरीपेक्षा हा फरक अधिक वेळा जाणवतो.

Team: 16 GB RAM, 8 vCPU, 200 GB डिस्क. चार concurrent sessions, प्रत्येकासाठी स्वतंत्र checkout आणि स्वतंत्र toolchain. Peak load नुसार आकार ठरवा. चार idle agents साठी जवळजवळ कोणताही खर्च होत नाही. परंतु चार test runs एकाच वेळी चालल्यास वरील peak column मधील खर्चाच्या चारपट संसाधने लागतात.

August 2026 पर्यंत, annual VPS billing मध्ये पहिल्या row पासून शेवटच्या row पर्यंत जाण्यासाठी monthly price साधारण चारपट वाढते: खालच्या स्तरासाठी दरमहा single digit dollars आणि वरच्या स्तरासाठी tens of dollars. योजना करण्यापूर्वी सध्याची listing तपासा, कारण हे आकडे बदलतात. Server क्वचितच सर्वात महाग घटक असतो. दररोज agent वापरणाऱ्या व्यक्तींसाठी model API bill लवकरच server bill पेक्षा जास्त होतो. त्यामुळे box लहान करण्यापूर्वी agent ला किती खर्च करण्याची परवानगी आहे ते मर्यादित करा. Build साठी VPS वर coding agent चालवण्याचे walkthrough account setup आणि disconnect केल्यानंतर session सुरू ठेवण्याची पद्धत स्पष्ट करते.

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 प्रत्येक build चे प्रत्येक intermediate layer जतन करते.

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

docker system df प्रत्येक category नुसार पुन्हा मिळवता येणारी जागा दाखवते, त्यामुळे ती आधी आणि नंतर चालवा. until=168h filter एक आठवड्यापेक्षा जुना build cache काढून टाकते आणि या आठवड्यातील cache ठेवते. हा cache अजूनही तुमचा वेळ वाचवतो. docker image prune -a आणखी पुढे जाऊन कोणताही container वापरत नसलेली प्रत्येक image काढून टाकते. त्यामुळे पुढील build वेळी पुन्हा pull होण्याची अपेक्षा ठेवा.

Node projects अधिक विचित्र पद्धतीने अयशस्वी होतात. npm install शेकडो हजारो लहान files लिहिते. त्यामुळे df -h अजूनही अनेक gigabytes मोकळ्या असल्याचे दाखवत असताना filesystem मधील inodes संपुष्टात येऊ शकतात. अर्धी डिस्क रिकामी दिसत असतानाही write No space left on device सह अयशस्वी होते.

df -h /
df -i /

IUse% चे मूल्य 100 असल्यास, तुम्ही सध्या वापरत नसलेल्या branch च्या node_modules directories हटवा. किंवा pnpm वापरा. ते प्रत्येक package version एकदाच साठवते आणि प्रत्येक project मध्ये hard-links तयार करते.

Logs ही शांतपणे जागा घेणारी बाब आहे. नेहमी सुरू असलेला agent session transcripts लिहितो आणि systemd journal default नुसार डिस्कचा मोठा भाग व्यापत जातो.

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 जोडणे उपयुक्त ठरते, कारण त्यामुळे लहान memory overshoot मुळे process बंद पडण्याऐवजी कामाचा वेग कमी होतो. त्याचा आकार RAM च्या निम्मा, कमाल सुमारे 4 GB, ठेवा. Build box साठी यापेक्षा अधिक swap देण्याचे कारण सहसा नसते.

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 ही line नसल्यास पुढील reboot नंतर swap नाहीसा होईल आणि box पुन्हा जुन्या वर्तनाकडे शांतपणे परतेल. fallocate चे उत्तर Operation not supported असल्यास, sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 ने file तयार करा आणि chmod पासून पुढे सुरू ठेवा.

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

कमी swappiness असल्यास kernel program memory disk वर पाठवण्यापूर्वी disk cache reclaim करतो. त्यामुळे language server प्रतिसादक्षम राहतो.

आता swap काय लपवतो ते पाहू. Box कडे उपलब्ध असलेल्या memory पेक्षा एखाद्या job ला खरोखरच अधिक memory लागल्यास, kernel तुमचा build चालवण्याऐवजी pages RAM आणि disk दरम्यान हलवण्यात वेळ घालवतो. काहीही crash होत नाही. मात्र सर्व काम अत्यंत मंद होते आणि CPU idle असतानाही load average वाढतो.

vmstat 1 10

si आणि so columns मध्ये सातत्याने दिसणारे non-zero numbers सतत swapping होत असल्याचे दर्शवतात. त्यामुळे योग्य उपाय म्हणजे concurrency कमी करणे किंवा RAM वाढवणे; अधिक swap देणे हा उपाय नाही. छोट्या box वर sudo apt install -y zram-tools RAM मध्ये ठेवलेला compressed swap उपलब्ध करून देते आणि /etc/default/zramswap मध्ये त्याचे tuning केले जाते. हे swap file पेक्षा बरेच जलद असते. RAM वाचवण्यासाठी ते RAM वापरते. त्यामुळे cold pages साठी त्याचा उपयोग होतो; प्रत्यक्ष working memory आवश्यक असलेल्या build साठी नाही.

तुमचा coding agent थांबल्यासारखा का दिसतो

लहान agent box वरील सर्वाधिक चुकीने निदान केली जाणारी समस्या ही आहे. एखादी command कोणतेही output परत करत नाही, agent प्रतीक्षा करत राहतो आणि session गोठल्यासारखे दिसते. Kernel च्या out-of-memory (OOM) killer ने process बंद केलेला असतो. त्याला SIGKILL मिळाल्यामुळे तो error print करू शकत नाही, log flush करू शकत नाही किंवा काय झाले ते agent ला सांगू शकत नाही. Agent ला रिकामा result आणि exit message मिळत नाही.

Kernel मात्र याची नोंद करतो:

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 म्हणजे process बंद झाला तेव्हा त्याने वापरलेली memory. कोणता process निवडला गेला हे लक्षात घ्या: kernel मुख्यतः वापरात असलेल्या memory वरून गुणांकन करतो. त्यामुळे box ची मर्यादा ओलांडणाऱ्या build ऐवजी तो अनेकदा language server किंवा agent बंद करतो. म्हणूनच हा प्रकार "agent बिघडला" असा दिसतो.

Docker मध्ये याच घटनेचा अधिक स्पष्ट पुरावा मिळतो. Container code 137 सह बंद होतो. हा code 128 अधिक signal 9 इतका असतो.

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

"OOMKilled": true यावरून container स्वतः crash न होता त्याची memory limit गाठल्याचे निश्चित होते.

महागड्या command साठी स्वतंत्र कमाल मर्यादा निश्चित करा. त्यामुळे agent ऐवजी build बंद होईल:

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

आता build 4 GB वर बंद होतो आणि agent सुरू राहतो. त्यामुळे गूढ hang ऐवजी वाचता येणाऱ्या exit code सह सामान्य failed command मिळते. यासाठी systemd user session आवश्यक आहे. त्यामुळे फक्त SSH द्वारे पोहोचता येणाऱ्या box वर loginctl enable-linger $USER चालवा. MemoryHigh= process बंद करण्याऐवजी threshold वर त्याचा वेग कमी करते. Build हळू चालला तरी पूर्ण व्हावा असे वाटत असल्यास ही अनेकदा अधिक योग्य setting असते.

Compose memory limits वापरून एकदाच मर्यादा निश्चित करा

Agent ची साधने containers मध्ये चालत असल्यास, Compose file मध्ये कमाल मर्यादा निश्चित करा. त्यामुळे ती प्रत्येक run वेळी लागू राहते.

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 memory limits साठी संपूर्ण मार्गदर्शक मध्ये reservations आणि container कमाल मर्यादेपर्यंत पोहोचल्यावर काय होते, हे स्पष्ट केले आहे. Server वर Docker अद्याप installed नसल्यास, प्रथम VPS वर Docker install करा.

एका चुकीमुळे लोकांचा अर्धा दिवस वाया जातो. 2 GB मर्यादा असलेला container host चा /proc/meminfo आणि host वरील CPU count अजूनही वाचतो, कारण यापैकी कोणतीही गोष्ट namespace केलेली नसते. CPU count वरून worker count निवडणारा test runner, आठ vCPU असलेल्या host वरील 2 GB container मध्ये आठ workers सुरू करेल आणि नंतर 137 status ने बंद होईल. संख्या स्वतः निश्चित करा:

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

--max-old-space-size हे MB मध्ये असते आणि V8 heap ची कमाल मर्यादा निश्चित करते. ते container limit पेक्षा कमी ठेवा. त्यामुळे Node न दिसता बंद होण्याऐवजी वाचता येईल अशी error दाखवेल:

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

हा message उपयुक्त असतो, कारण कोणती limit गाठली आणि कोणत्या process ने ती गाठली, हे त्यात स्पष्ट असते. OOM killer असे कधीच सांगत नाही.

एका मशीनवर अनेक agent sessions चालवणे

नियोजन प्रत्येक व्यक्तीनुसार नव्हे, तर प्रत्येक session नुसार करा. एकाच repository वर चालणाऱ्या दोन sessions म्हणजे दोन language servers, memory मध्ये build caches चे दोन संच आणि दोन्ही agents एकाच वेळी व्यस्त झाल्यास दोन test runs. म्हणूनच team row मधील आकडा 16 GB पर्यंत वाढतो.

एका runaway session मुळे संपूर्ण मशीन बंद पडू नये यासाठी प्रत्येक user साठी कठोर कमाल मर्यादा ठेवा:

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 लिहा. User ने login केल्यानंतर systemctl show ने MemoryMax=6442450944 दाखवले पाहिजे. त्या user च्या session मधील एकूण वापर 6 GB पेक्षा जास्त झाल्यावर kernel तिच्या slice मधील एखादी process बंद करतो आणि इतर सर्व sessions सुरू राहतात. एखादा agent terminal ऐवजी service म्हणून चालत असल्यास, त्याच्या unit file मध्ये MemoryMax= लिहा. agent ला नेहमी सुरू असलेल्या service म्हणून self-host करणे यासाठी हीच पद्धत वापरा.

FAQ

कोडिंग agent साठी 2 GB RAM पुरेशी आहे का?

Agent process साठी होय. मात्र तो करत असलेल्या कामासाठी बहुतेक वेळा पुरेशी नसते. Agent सुमारे 250 MB RAM वापरतो; परंतु मध्यम आकाराच्या repository वर एक TypeScript language server 2000 MB पर्यंत RAM वापरू शकतो. त्यामुळे 2 GB RAM असलेला सर्व्हर swap वापरू लागतो. Configuration files आणि लहान scripts संपादित करण्यासाठी 2 GB पुरेशी आहे. Compile होणाऱ्या किंवा test suite चालवणाऱ्या कोणत्याही कामासाठी 4 GB ही किमान क्षमता ठेवा.

VPS वर coding agent चालवण्यासाठी GPU आवश्यक आहे का?

Agent API द्वारे cloud model ला call करत असेल, तर GPU आवश्यक नाही. हे workload network-bound असते. त्यामुळे साधा CPU VPS योग्य असतो आणि GPU जास्त किंमतीत निष्क्रिय राहतो. Model त्याच सर्व्हरवर चालवायचा असल्यासच GPU आवश्यक आहे. त्या वेळी प्रश्न RAM चा नसून VRAM आणि model size चा असतो.

Agent VPS साठी किती swap जोडावे?

RAM च्या निम्मे, मात्र साधारण 4 GB पर्यंत. अल्पकाळासाठी memory usage अपेक्षेपेक्षा वाढल्यास swap संरक्षण देते. Kernel process बंद करण्याऐवजी वापरात नसलेले pages disk वर हलवू शकतो. Swap मुळे वापरण्यायोग्य memory वाढत नाही. vmstat 1 च्या si आणि so columns मध्ये सतत traffic दिसत असल्यास सर्व्हर thrashing करत आहे. अशा वेळी parallel workers ची संख्या कमी करा किंवा मोठा plan निवडा.

Build च्या मध्यभागी माझा coding agent freeze का होतो?

Kernel OOM killer ने build process बंद केलेला असण्याची शक्यता सर्वाधिक आहे. तो SIGKILL पाठवतो. त्यामुळे कोणताही output दिसत नाही आणि कधीही भरू न शकणाऱ्या pipe वर agent प्रतीक्षा करत राहतो. sudo dmesg -T | grep -i "killed process" चालवा आणि process name तसेच त्याचे anon-rss value तपासा. systemd-run --user --scope -p MemoryMax=4G वापरून build वर मर्यादा घाला आणि worker count कमी करा. किंवा RAM च्या पुढील tier वर जा.