coding agent VPS కు ఎంత RAM అవసరం?

కోడింగ్ agent VPS కు ఎంత RAM అవసరం?

రిపోజిటరీలో నిరంతరం పనిచేసే ఒక coding agent కోసం 4 GB RAM మరియు 2 vCPU తో ప్రారంభించండి. language server లేదా Docker build session లో చేరిన వెంటనే 8 GB RAM మరియు 4 vCPU కు పెంచండి. చాలా రిపోజిటరీల్లో ఇది మొదటి రోజే అవసరం అవుతుంది. agent process స్వయంగా చిన్నదే. మీ తరఫున agent నడిపించే toolchain వల్లే సర్వర్‌లో ఎక్కువ వనరులు వినియోగించబడతాయి.

[
  {
    "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 ను పిలుస్తారని భావిస్తుంది. మొత్తం sizing నిర్ణయం ఈ ఆధారంపైనే ఉంటుంది. కాబట్టి ముందుగా దీన్ని నిర్ధారించండి.

మీరు agent ను నడుపుతున్నారా, లేక model ను నడుపుతున్నారా?

Cloud model ను పిలిచే coding agent అనేది shell అనుసంధానించబడిన network client. ఇది files మరియు plan ను APIకి పంపుతుంది, response కోసం వేచి ఉంటుంది, తరువాత files ను సవరించి commands ను స్థానికంగా అమలు చేస్తుంది. వేచి ఉన్న సమయంలో ఇది దాదాపు CPUని ఉపయోగించదు. దీని memory వినియోగం సాధారణంగా కొన్ని వందల megabytes మాత్రమే ఉంటుంది. అందుకే పరిమిత CPU సామర్థ్యం ఉన్న 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 కలిగిన VPS వాస్తవంగా ఏమి అందిస్తుంది చదవండి.

క్రింద ఉన్న మొత్తం సమాచారం cloud-model సందర్భాన్ని ఆధారంగా చేసుకుంది.

మెమరీని వాస్తవంగా ఏది ఉపయోగిస్తుంది

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

ఇవి మధ్యస్థ పరిమాణ ప్రాజెక్ట్‌ల కోసం సాధారణంగా ప్రచురించే గణాంకాలు. వీటిని మీ code గురించి హామీగా కాకుండా, ఒక సాధారణ నమూనాగా పరిగణించండి.

Chart లో 6 rows ఉన్నాయి. agent వాటిలో అతి తక్కువ memory ఉపయోగిస్తుంది. ఇది idle స్థితిలో సుమారు 250 MB వద్ద ఉంటుంది, ఎందుకంటే ఇది ఒక సంభాషణను, చిన్న file cache ను మాత్రమే ఉంచుతుంది. TypeScript language server indexing సమయంలో సుమారు 2000 MB కు చేరుతుంది. కారణం, మీ tsconfig.json నుంచి అందుబాటులో ఉన్న ప్రతి file కోసం ఇది type graph ను నిర్మించి, తదుపరి request కు త్వరగా సమాధానం ఇవ్వడానికి ఆ graph ను memoryలో ఉంచుతుంది. పెద్ద workspaceలో rust-analyzer కూడా ఇదే కారణంతో సాధారణంగా 4000 MB ను దాటుతుంది. ఇది workspaceలోని ప్రతి crate కు వర్తిస్తుంది.

Headless Chrome browser మరియు ఒక tab కోసం సుమారు 350 MB ఉపయోగిస్తుంది. ప్రతి అదనపు tab మరో operating system process ను సృష్టిస్తుంది. నలుగురు workers తో Node test run నాలుగు Node processes ను ఉపయోగిస్తుంది. అందువల్ల ఇది సుమారు 3000 MB వద్ద peak అవుతుంది. Docker image build సుమారు 2500 MB వద్ద peak అవుతుంది. కారణం, 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 అందుబాటులో ఉన్న ప్రతి spare page ను disk cache కోసం ఉపయోగిస్తుంది. అందువల్ల పూర్తిగా ఆరోగ్యంగా ఉన్న machineలో కూడా free చిన్నదిగా ఉంటుంది; దాని ఆధారంగా ఏమీ నిర్ధారించలేరు. కొత్త process వాస్తవంగా పొందగల memory available.

పనిచేసే మూడు కాన్ఫిగరేషన్లు

కనీసంగా ఉపయోగించగల కాన్ఫిగరేషన్: 4 GB RAM, 2 vCPU, 50 GB disk. ఒక agent session, ఒక repository, ఒక language server, అలాగే వేచి ఉండగల builds. ఈ tier పనిచేస్తుంది. అయితే పెద్ద test run మరియు indexing language server ఒకేసారి నడిస్తే, మొదటిసారే out-of-memory killer ను ఎదుర్కొంటారు. Swap జోడించి, build workers సంఖ్యకు పరిమితి విధించండి.

సౌకర్యవంతమైన కాన్ఫిగరేషన్: 8 GB RAM, 4 vCPU, 100 GB disk. ఒక agent, Docker, tests కోసం headless browser, అలాగే ఒక build spike కు తగిన అదనపు వనరులు. చాలా మంది single developers ఎంచుకోవాల్సిన tier ఇదే. vCPU సంఖ్యను రెట్టింపు చేస్తే build కోసం వేచి ఉండే సమయం కూడా సుమారుగా సగానికి తగ్గుతుంది. Memory కొరత కంటే ఈ ప్రయోజనం మీకు చాలా తరచుగా కనిపిస్తుంది.

Team కాన్ఫిగరేషన్: 16 GB RAM, 8 vCPU, 200 GB disk. ఒకేసారి నాలుగు sessions నడుస్తాయి. ప్రతి session కు ప్రత్యేక checkout మరియు ప్రత్యేక toolchain ఉంటుంది. గరిష్ఠ వినియోగాన్ని ఆధారంగా చేసుకుని పరిమాణం నిర్ణయించండి. నాలుగు idle agents కు దాదాపు ఎలాంటి ఖర్చూ ఉండదు. కానీ నాలుగు test runs ఒకేసారి నడిస్తే, పై పట్టికలోని గరిష్ఠ స్థాయి కంటే నాలుగు రెట్లు peak వనరులు అవసరమవుతాయి.

August 2026 నాటికి, మొదటి వరుస నుంచి చివరి వరుసకు వెళ్లినప్పుడు annual VPS billing లో నెలవారీ ధర సుమారుగా నాలుగు రెట్లు పెరుగుతుంది: కనిష్ఠ స్థాయిలో నెలకు 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 అయిపోకముందే disk స్థలం ఎందుకు అయిపోతుంది

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

ఆ వరుసలన్నింటినీ కలిపితే, మీరు ఒక్క code line కూడా రాయకముందే 50 GB disk దాదాపుగా నిండిపోతుంది. ఒకే అంశంగా అత్యధిక స్థలాన్ని Docker ఉపయోగిస్తుంది: సుమారు 20 GB. ఎందుకంటే మీరు ఆపమని చెప్పే వరకు BuildKit ప్రతి build లోని ప్రతి intermediate layer ను ఉంచుతుంది.

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

docker system df ప్రతి category కి reclaim చేయగల స్థలాన్ని చూపిస్తుంది. అందువల్ల దాన్ని ముందు మరియు తరువాత అమలు చేయండి. 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 అయిపోవచ్చు. సగం ఖాళీగా కనిపించే disk పై కూడా write No space left on device తో విఫలమవుతుంది.

df -h /
df -i /

IUse% 100 ను చూపిస్తే, మీరు ప్రస్తుతం ఉపయోగించని branches కు చెందిన node_modules directories ను తొలగించండి. లేదా pnpm కు మారండి. ఇది ప్రతి package version ను ఒక్కసారి నిల్వ చేసి, ప్రతి project లోకి hard-link చేస్తుంది.

Logs నిశ్శబ్దంగా స్థలాన్ని ఆక్రమిస్తాయి. ఎల్లప్పుడూ నడుస్తున్న agent session transcripts ను రాస్తుంది. systemd journal default గా disk లోని గణనీయమైన భాగం వరకు పెరుగుతుంది.

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: what it buys, and what it hides

Swap is worth adding, because it turns a small overshoot into slow work instead of a dead process. Size it at half of RAM, up to about 4 GB. There is little reason to go further on a 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 should now list /swapfile at the size you asked for. Without the /etc/fstab line the swap is gone after the next reboot and the box quietly returns to its old behaviour. If fallocate answers Operation not supported, build the file with sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 and carry on from chmod.

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

A low swappiness tells the kernel to reclaim disk cache before it pushes program memory out to disk, which keeps a language server responsive.

Now the part swap hides. When a job genuinely needs more memory than the box has, the kernel spends its time moving pages between RAM and disk instead of running your build. Nothing crashes. Everything crawls, and load average climbs while the CPU sits idle.

vmstat 1 10

Steady non-zero numbers in the si and so columns mean continuous swapping, so the fix is less concurrency or more RAM, and never more swap. On a small box sudo apt install -y zram-tools gives compressed swap held in RAM, tuned in /etc/default/zramswap. It is much faster than a swap file, and it spends RAM to save RAM, so it helps with cold pages and not with a build that needs real working memory.

మీ coding agent నిలిచిపోయినట్లు ఎందుకు కనిపిస్తుంది

చిన్న agent సర్వర్‌లో తరచుగా తప్పుగా నిర్ధారించబడే సమస్య ఇదే. ఒక command ఎలాంటి output ఇవ్వదు, agent వేచి ఉంటుంది, session నిలిచిపోయినట్లు కనిపిస్తుంది. వాస్తవానికి kernel out-of-memory (OOM) killer ఆ process ను terminate చేసింది. దానికి SIGKILL అందింది. అందువల్ల అది error ను ముద్రించలేకపోయింది, 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

నిజమైన line ఇలా ఉంటుంది:

[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 terminate అయినప్పుడు అది ఉపయోగిస్తున్న memory పరిమాణం. ఏ process ను ఎంచుకున్నదో గమనించండి. Kernel ప్రధానంగా ఉపయోగంలో ఉన్న memory ఆధారంగా score కేటాయిస్తుంది. అందువల్ల box పరిమితిని దాటేలా చేసిన build కంటే language server లేదా agent ను తరచుగా terminate చేస్తుంది. అందుకే ఈ లక్షణం “agent విఫలమైంది” అని కనిపిస్తుంది.

Docker లో ఇదే సంఘటన మరింత స్పష్టమైన గుర్తును వదిలివేస్తుంది. Container code 137 తో exit అవుతుంది. ఇది 128 plus signal 9.

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

"OOMKilled": true ద్వారా container తన memory limit ను తాకిందని, స్వయంగా crash కాలేదని నిర్ధారించవచ్చు.

ఖరీదైన command కు ప్రత్యేక memory ceiling ఇవ్వాలి. అప్పుడు agent కాకుండా build terminate అవుతుంది:

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

ఇప్పుడు build 4 GB వద్ద terminate అవుతుంది, agent కొనసాగుతుంది. అందువల్ల అర్థంకాని hang సాధారణ failed command గా మారుతుంది; readable exit code కూడా లభిస్తుంది. దీనికి systemd user session అవసరం. కాబట్టి SSH ద్వారా మాత్రమే చేరుకునే box లో loginctl enable-linger $USER అమలు చేయండి. MemoryHigh= threshold వద్ద process ను terminate చేయకుండా throttle చేస్తుంది. Build నెమ్మదిగా అయినా పూర్తవడం మీకు ముఖ్యమైతే ఇది సాధారణంగా మరింత అనుకూలమైన setting.

Compose memory limits తో ఒకసారి పరిమితి నిర్ణయించండి

Agent సాధనాలు containers లో నడుస్తే, ప్రతి run సమయంలో ఆ పరిమితి వర్తించేలా Compose file లోనే గరిష్ఠ పరిమితిని ఉంచండి.

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 పై పూర్తి guide reservations మరియు container తన గరిష్ఠ పరిమితిని చేరుకున్నప్పుడు ఏమి జరుగుతుందో వివరిస్తుంది. Server లో Docker ఇంకా లేకపోతే ముందుగా 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తో విఫలమవుతుంది. సంఖ్యలను చేతితో సెట్ చేయండి:

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

--max-old-space-size MBలో ఉంటుంది మరియు V8 heap కు గరిష్ఠ పరిమితిని విధిస్తుంది. దీన్ని container limit కంటే తక్కువగా సెట్ చేయండి. అప్పుడు Node చదవగలిగే error ను విసురుతుంది, process అకస్మాత్తుగా అదృశ్యం కాదు:

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

ఆ message ఉపయోగకరంగా ఉంటుంది. ఎందుకంటే చేరుకున్న limit మరియు దాన్ని చేరుకున్న process పేర్లు అందులో ఉంటాయి. OOM killer ఎప్పుడూ అలా చేయదు.

ఒకే సర్వర్‌పై అనేక agent sessions నడపడం

ప్రతి వ్యక్తి కోసం కాకుండా, ప్రతి session కోసం capacity ప్రణాళిక రూపొందించండి. ఒకే repositoryలో రెండు sessions ఉంటే, రెండు language servers, మెమరీలో build caches యొక్క రెండు సమితులు, రెండు agents ఒకేసారి busyగా ఉంటే రెండు test runs అవసరమవుతాయి. అందుకే team row 16 GBకి పెరుగుతుంది.

ఒక session మొత్తం సర్వర్‌ను నిలిపివేయకుండా ఉండేందుకు ప్రతి userకు hard ceiling ఇవ్వండి:

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ను echo చేయాలి. ఆ user sessionలో మొత్తం వినియోగం 6 GB దాటితే, kernel ఆమె sliceలోని ఒక processను terminate చేస్తుంది. మిగిలిన sessions అన్నీ పని చేస్తూనే ఉంటాయి. terminalకు బదులుగా serviceగా నడిచే agent కోసం, దాని unit fileలో MemoryMax= ఉంచండి. agentను ఎల్లప్పుడూ నడిచే serviceగా self-host చేయడంలో అనుసరించాల్సిన పద్ధతి ఇదే.

FAQ

కోడింగ్ agent కోసం 2 GB RAM సరిపోతుందా?

agent process కోసం సరిపోతుంది. అది చేసే పనికి మాత్రం అరుదుగా సరిపోతుంది. agent సాధారణంగా 250 MB సమీపంలో ఉంటుంది. అయితే మధ్యస్థ పరిమాణం ఉన్న repositoryలో ఒక TypeScript language server 2000 MB వరకు చేరవచ్చు. దాంతో 2 GB serverలోనే swap ఉపయోగించడం ప్రారంభమవుతుంది. Configuration files మరియు చిన్న scriptsను సవరించడానికి 2 GB సరిపోతుంది. Compile చేసే లేదా test suite అమలు చేసే పనులకు కనీసంగా 4 GB ఉపయోగించండి.

VPSలో coding agent నడపడానికి GPU అవసరమా?

agent API ద్వారా cloud modelను ఉపయోగిస్తే GPU అవసరం లేదు. ఆ workload network-boundగా ఉంటుంది. అందువల్ల సాధారణ CPU VPS సరైన యంత్రం. GPU idleగా ఉండి, ఎక్కువ ఖర్చు మాత్రమే అవుతుంది. Model అదే serverలో నడిచినప్పుడు మాత్రమే GPU అవసరం. అప్పుడు ప్రశ్న RAM గురించి కాకుండా VRAM మరియు model పరిమాణం గురించి అవుతుంది.

Agent VPSకు ఎంత swap జోడించాలి?

RAMలో సగం, గరిష్ఠంగా సుమారు 4 GB వరకు జోడించండి. తాత్కాలికంగా memory వినియోగం పెరిగినప్పుడు swap రక్షణ ఇస్తుంది. Kernel, processను terminate చేయడానికి బదులుగా ఉపయోగంలో లేని pagesను diskకు తరలించగలదు. అయితే swap ఉపయోగించగల memoryని పెంచదు. vmstat 1 లోని si మరియు so columnsలో నిరంతర traffic కనిపిస్తే, server thrashingలో ఉంది. Parallel workers సంఖ్యను తగ్గించాలి లేదా పెద్ద planకు మారాలి.

Build మధ్యలో నా coding agent ఎందుకు freeze అవుతుంది?

Kernel OOM killer buildను terminate చేసి ఉండే అవకాశం చాలా ఎక్కువ. అది SIGKILL పంపుతుంది. అందువల్ల ఎటువంటి output కనిపించదు. Agent ఎప్పటికీ data రాని pipe కోసం వేచి ఉంటుంది. sudo dmesg -T | grep -i "killed process" అమలు చేసి process name మరియు దాని anon-rss విలువను చూడండి. systemd-run --user --scope -p MemoryMax=4G ఉపయోగించి buildకు పరిమితి విధించండి, workerల సంఖ్యను తగ్గించండి లేదా తదుపరి RAM tierకు మారండి.