Coding agent VPS के लिए कितनी RAM चाहिए?

Coding agent VPS के लिए कितनी RAM की आवश्यकता होती है?

एक repository पर काम करने वाले हमेशा active रहने वाले एक coding agent के लिए 4 GB RAM और 2 vCPU से शुरुआत करें। जैसे ही कोई language server या Docker build session में जुड़ता है, तो 8 GB RAM और 4 vCPU पर आ जाएं; अधिकांश repositories के लिए यह पहले दिन ही आवश्यक हो जाता है। Agent process स्वयं छोटी होती है, इसलिए server पर load उस toolchain के कारण बढ़ता है जिसे agent आपकी ओर से चलाता है।

[
  {
    "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 कहीं और चल रहा है, एक ऐसे API के पीछे जिसे आप network के माध्यम से call करते हैं। यह धारणा ही sizing के पूरे प्रश्न का निर्णय करती है, इसलिए सबसे पहले इसे स्पष्ट करें।

क्या आप agent चला रहे हैं, या model चला रहे हैं?

Cloud model को call करने वाला coding agent, shell से जुड़ा network client होता है। यह files और plan को API पर भेजता है, reply की प्रतीक्षा करता है, फिर locally files edit करता है और commands चलाता है। प्रतीक्षा के दौरान यह लगभग कोई CPU उपयोग नहीं करता। इसकी memory खपत सैकड़ों megabytes में होती है। इसी कारण modest CPU box इसके लिए सही machine है।

Model को स्वयं चलाना अलग hardware पर अलग product चलाने जैसा है। Server के up रहने तक weights memory में रहते हैं। 4 bits पर quantise किया गया 7 billion parameter model लगभग 4 GB weights लेता है (Llama 2 7B, Q4_0 में 3.83 GB और Q4_K_M में 4.08 GB के रूप में ship होता है), और runtime overhead जोड़ने के बाद इसका publisher GPU के बिना इसे चलाने के लिए 6.3 से 6.6 GB RAM सूचीबद्ध करता है। लंबे contexts के लिए अधिक memory चाहिए, क्योंकि context की लंबाई बढ़ने के साथ key/value cache भी बढ़ता है। केवल CPU पर shared vCPU कुछ tokens प्रति second generate करता है, और एक agent task हजारों tokens generate कर सकता है। इसलिए API के विरुद्ध under a minute लेने वाला काम locally most of an hour ले सकता है। यदि आप यही करना चाहते हैं, तो VRAM (GPU की video memory) के अनुसार sizing करें और इस page के बजाय GPU वाले VPS से वास्तव में आपको क्या मिलता है पढ़ें।

नीचे की पूरी जानकारी cloud-model case मानकर दी गई है।

मेमोरी का उपयोग वास्तव में क्या करता है

[
  {
    "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 पंक्तियों को धारण करता है और एजेंट सबसे सस्ता है। यह idle होने पर लगभग 250 MB के आसपास रहता है, क्योंकि यह केवल एक conversation और एक छोटी file cache को बनाए रखता है। एक TypeScript language server इंडेक्सिंग के दौरान लगभग 2000 MB तक पहुँच जाता है, क्योंकि यह आपके tsconfig.json से पहुँच योग्य प्रत्येक फ़ाइल के लिए एक type graph बनाता है और फिर अगली request का तुरंत उत्तर देने के लिए उस graph को मेमोरी में रखता है। rust-analyzer एक बड़े workspace पर इसी कारण से, workspace की प्रत्येक crate के लिए, आमतौर पर 4000 MB से ऊपर चला जाता है।

Headless Chrome की लागत ब्राउज़र और एक tab के लिए लगभग 350 MB है, और प्रत्येक अतिरिक्त tab एक अलग operating system process है। चार workers के साथ Node test run का मतलब चार Node processes है, इसलिए यह 3000 MB के आसपास peak पर पहुँचता है। एक Docker image build 2500 MB के आसपास peak पर पहुँचती है, क्योंकि 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 हर खाली page को disk cache पर खर्च कर देता है, इसलिए एक पूरी तरह से स्वस्थ box पर free छोटा होता है और यह आपको कुछ नहीं बताता। available वह है जो एक नई process वास्तव में प्राप्त कर सकती है।

तीन कार्यशील कॉन्फ़िगरेशन

न्यूनतम व्यवहार्य (Minimum viable): 4 GB RAM, 2 vCPU, 50 GB disk. एक एजेंट सत्र, एक रिपॉजिटरी, एक लैंग्वेज सर्वर और ऐसे बिल्ड जिनके लिए आप प्रतीक्षा करने को तैयार हैं। यह टियर काम करता है, लेकिन जब कोई बड़ा टेस्ट रन किसी इंडेक्सिंग लैंग्वेज सर्वर के साथ ओवरलैप होगा, तो यह out-of-memory killer का सामना करेगा। Swap जोड़ें और अपने बिल्ड वर्कर्स की संख्या सीमित करें।

आरामदायक (Comfortable): 8 GB RAM, 4 vCPU, 100 GB disk. एक एजेंट, साथ में Docker, टेस्ट के लिए एक headless ब्राउज़र, और एक बिल्ड स्पाइक के लिए अतिरिक्त क्षमता। यह वह टियर है जिसे अधिकांश एकल डेवलपर्स को चुनना चाहिए। vCPU की संख्या दोगुनी करने से बिल्ड का प्रतीक्षा समय लगभग आधा हो जाता है, और आप इसे मेमोरी की कमी महसूस करने की तुलना में कहीं अधिक बार अनुभव करेंगे।

टीम (Team): 16 GB RAM, 8 vCPU, 200 GB disk. चार समवर्ती सत्र, प्रत्येक का अपना चेकआउट और अपना टूलचेन। पीक लोड के अनुसार आकार निर्धारित करें, क्योंकि चार निष्क्रिय एजेंटों की लागत लगभग शून्य होती है, जबकि एक ही समय पर चार टेस्ट रन चलने की लागत ऊपर दिए गए पीक कॉलम से चार गुना अधिक होती है।

अगस्त 2026 तक, पहली पंक्ति से अंतिम पंक्ति तक का अंतर वार्षिक VPS बिलिंग पर मासिक मूल्य का लगभग चार गुना है: निचले स्तर पर कुछ डॉलर प्रति माह, और शीर्ष स्तर पर दसियों डॉलर। योजना बनाने से पहले वर्तमान लिस्टिंग देखें, क्योंकि ये आंकड़े बदलते रहते हैं। सर्वर शायद ही कभी महंगा हिस्सा होता है। जो कोई भी प्रतिदिन एजेंट का उपयोग कर रहा है, उसके लिए मॉडल API का बिल सर्वर बिल से जल्दी बढ़ जाता है, इसलिए बॉक्स का आकार छोटा करने से पहले एजेंट के खर्च की सीमा निर्धारित करें। बिल्ड के लिए, VPS पर कोडिंग एजेंट चलाने का वॉकथ्रू अकाउंट सेटअप और डिस्कनेक्ट करने के बाद सत्र को सक्रिय रखने की प्रक्रिया को कवर करता है।

RAM खत्म होने से पहले disk space क्यों खत्म हो जाती है

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

इन rows को जोड़ने पर 50 GB disk में code की एक line लिखने से पहले ही लगभग पूरी space भर जाती है। सबसे बड़ा single item Docker होता है, जो लगभग 20 GB लेता है। ऐसा इसलिए होता है क्योंकि BuildKit, जब तक आप उसे रोकने के लिए न कहें, हर build की हर intermediate layer रखता है।

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

docker system df हर category में reclaimable space दिखाता है, इसलिए इसे पहले और बाद में चलाएँ। until=168h filter उन cache records को रखता है जिन्हें build ने पिछले week में उपयोग किया है और बाकी delete कर देता है। यह age के आधार पर नहीं, last use के आधार पर काम करता है। इसलिए 1 month पहले बनाई गई लेकिन कल reuse की गई layer बची रहती है। यही वह cache है जो आपका समय बचाती है। docker image prune -a इससे आगे जाकर वे सभी images हटा देता है जिनका कोई container उपयोग नहीं कर रहा है। इसलिए अगला build फिर से pull करेगा।

Node projects अलग तरह से fail होते हैं। npm install सैकड़ों हजारों छोटी files लिखता है। इसलिए filesystem में inodes खत्म हो सकते हैं, जबकि df -h अभी भी free gigabytes दिखाता है। तब आधी खाली दिखने वाली disk पर write, No space left on device के साथ fail हो जाता है।

df -h /
df -i /

यदि IUse% का output 100 है, तो उन branches की node_modules directories delete करें जिन पर आप अब नहीं हैं। या pnpm पर switch करें। यह हर package version को एक बार store करता है और उसे हर project में hard-link करता है।

Logs शांत तरीके से space लेते हैं। हमेशा चलने वाला 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 set करें और sudo systemctl restart systemd-journald चलाएँ, ताकि यह limit स्थायी हो जाए। केवल एक बार किया गया vacuum आज की space वापस दिलाता है, लेकिन आगे disk भरने से नहीं रोकता।

Swap: यह क्या लाभ देता है और क्या छिपाता है

Swap जोड़ना फायदेमंद है, क्योंकि यह किसी प्रक्रिया के अचानक बंद होने (crash) के बजाय उसे धीमा कर देता है। इसका आकार 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 लाइन के बिना, अगले reboot के बाद 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 को यह निर्देश देती है कि वह program memory को disk पर भेजने से पहले disk cache को खाली करे, जिससे language server की responsiveness बनी रहती है।

अब वह हिस्सा जिसे swap छिपा देता है। जब किसी job को वास्तव में box की उपलब्ध memory से अधिक की आवश्यकता होती है, तो kernel आपका build चलाने के बजाय RAM और disk के बीच pages को स्थानांतरित करने में अपना समय व्यतीत करता है। कुछ भी crash नहीं होता। सब कुछ बहुत धीमा हो जाता है और CPU के idle रहने के बावजूद load average बढ़ जाता है।

vmstat 1 10

si और so columns में लगातार गैर-शून्य (non-zero) संख्याएँ निरंतर swapping का संकेत देती हैं। इसका समाधान concurrency कम करना या अधिक RAM जोड़ना है, न कि और अधिक swap बढ़ाना। एक छोटे box पर sudo apt install -y zram-tools RAM में compressed swap प्रदान करता है, जिसे /etc/default/zramswap में ट्यून किया जा सकता है। यह swap file की तुलना में बहुत तेज़ है, और यह RAM को बचाने के लिए RAM का ही उपयोग करता है। इसलिए, यह cold pages के लिए तो सहायक है, लेकिन ऐसे build के लिए नहीं जिसे वास्तविक working memory की आवश्यकता हो।

आपका coding agent hang जैसा क्यों दिखता है

छोटे agent box पर यह सबसे अधिक गलत समझी जाने वाली failure है। कोई command कुछ return नहीं करती, agent प्रतीक्षा करता रहता है और session frozen जैसा दिखता है। Kernel के out-of-memory (OOM) killer ने process को kill कर दिया होता है। इसे SIGKILL मिला, इसलिए यह error print नहीं कर सका, log flush नहीं कर सका और agent को बता नहीं सका कि क्या हुआ। Agent को empty result और कोई exit message दिखाई नहीं देता।

Kernel इसका record रखता है:

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 ने कितनी memory रखी थी। ध्यान दें कि कौन-सा process चुना गया। Kernel मुख्यतः उपयोग में आ रही memory के आधार पर score करता है। इसलिए यह अक्सर उस build को kill करने के बजाय language server या agent को kill कर देता है जिसने box को limit से आगे पहुँचा दिया था। इसी कारण symptom ऐसा लगता है कि "agent टूट गया"।

Docker के अंदर यही event अधिक स्पष्ट fingerprint छोड़ता है। 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 को अपनी अलग limit दें, ताकि build समाप्त हो और agent चलता रहे:

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

अब build 4 GB पर kill होगा और agent बचा रहेगा। इससे रहस्यमय hang एक सामान्य failed command में बदल जाता है, जिसमें पढ़ने योग्य exit code होगा। इसके लिए systemd user manager आवश्यक है। सामान्य SSH login आपके लिए इसे start कर देता है, इसलिए यह command SSH पर सीधे काम करती है। loginctl enable-linger $USER केवल logout करने के बाद user units को चलते रहने के लिए है। MemoryHigh= threshold पर process को kill करने के बजाय throttle करता है। जिस build को आप धीमे चलाकर पूरा होने देना चाहते हैं, उसके लिए यह अक्सर अधिक उपयुक्त setting होती है।

Compose memory limits के साथ सीमा निर्धारित करें

यदि agent के tools 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 के अपनी सीमा तक पहुँचने पर क्या होता है, इस बारे में जानकारी देती है। यदि सर्वर पर Docker अभी तक नहीं है, तो पहले VPS पर Docker इंस्टॉल करें।

एक गलती लोगों का काफी समय बर्बाद करती है। 2 GB तक सीमित container अभी भी host की /proc/meminfo और host की CPU count को पढ़ता है, क्योंकि इनमें से कोई भी namespaced नहीं है। एक test runner जो CPU count से worker count चुनता है, वह आठ vCPU वाले host पर 2 GB container के अंदर आठ workers शुरू कर देगा और फिर 137 error के साथ बंद हो जाएगा। इन संख्याओं को मैन्युअल रूप से सेट करें:

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

--max-old-space-size MB में होता है और V8 heap को सीमित करता है। इसे container की सीमा से कम सेट करें ताकि Node गायब होने के बजाय एक error दे जिसे आप पढ़ सकें:

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

वह संदेश एक उपयोगी संकेत है, क्योंकि यह उस सीमा का नाम बताता है जो पार हो गई थी और उस process का नाम भी बताता है जिसने इसे पार किया। OOM killer कभी ऐसा नहीं करता।

एक ही बॉक्स पर कई एजेंट सत्र चलाना

प्रति व्यक्ति के बजाय प्रति सत्र योजना बनाएँ। एक ही रिपॉजिटरी पर दो सत्रों का मतलब है दो लैंग्वेज सर्वर, मेमोरी में बिल्ड कैश के दो सेट, और यदि दोनों एजेंट एक ही समय पर व्यस्त हो जाते हैं तो दो टेस्ट रन। यही कारण है कि टीम रो 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 को उस UID से बदलें जिसे id -u ने प्रिंट किया था। उपयोगकर्ता के लॉग इन करने के बाद systemctl show को MemoryMax=6442450944 इको करना चाहिए। जब उस उपयोगकर्ता के सत्र में सब कुछ 6 GB से अधिक हो जाता है, तो कर्नेल उसके स्लाइस के भीतर एक प्रोसेस को समाप्त कर देता है और बाकी सभी सत्र काम करते रहते हैं। ऐसे एजेंट के लिए जो टर्मिनल के बजाय सर्विस के रूप में चलता है, उसके यूनिट फ़ाइल में MemoryMax= डालें, जो कि एजेंट को हमेशा चालू रहने वाली सर्विस के रूप में सेल्फ-होस्ट करते समय पालन करने का पैटर्न है।

FAQ

क्या coding agent के लिए 2 GB RAM पर्याप्त है?

Agent process के लिए हाँ। उसके किए जाने वाले काम के लिए, आम तौर पर नहीं। Agent लगभग 250 MB पर रहता है, लेकिन एक TypeScript language server mid-size repository पर 2000 MB तक पहुँच सकता है। यह अकेले 2 GB box को swap में भेजने के लिए पर्याप्त है। Configuration files और small scripts edit करने के लिए 2 GB ठीक है। ऐसी किसी भी चीज़ के लिए जो compile होती है या test suite चलाती है, 4 GB को minimum मानें।

क्या VPS पर coding agent चलाने के लिए GPU चाहिए?

यदि agent API के माध्यम से cloud model को call करता है, तो नहीं। यह workload network-bound है। इसलिए plain CPU VPS सही machine है, जबकि GPU बहुत अधिक price पर idle रहता है। GPU की आवश्यकता तभी होती है जब model उसी box पर चलता है। तब सवाल RAM से बदलकर VRAM और model size का हो जाता है।

Agent VPS में कितना swap जोड़ना चाहिए?

RAM का आधा, अधिकतम लगभग 4 GB तक। Swap short overshoot से बचाता है, क्योंकि kernel किसी process को kill करने के बजाय cold pages को disk पर move कर सकता है। इससे usable memory नहीं बढ़ती। यदि vmstat 1 में si और so columns में steady traffic दिखाई दे, तो box thrashing कर रहा है। ऐसी स्थिति में parallel workers कम करें या बड़ा plan चुनें।

Build के बीच में मेरा coding agent freeze क्यों हो जाता है?

Build को kernel OOM killer ने almost certainly kill किया है। यह SIGKILL भेजता है, इसलिए कुछ भी print नहीं होता और agent ऐसी pipe पर wait करता रहता है जो कभी fill नहीं होती। sudo dmesg -T | grep -i "killed process" चलाएँ और process name तथा उसका anon-rss value देखें। Build को systemd-run --user --scope -p MemoryMax=4G से cap करके और worker count घटाकर इसे ठीक करें, या एक RAM tier ऊपर जाएँ।