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 के पूरे प्रश्न का निर्णय करती है, इसलिए सबसे पहले इसे स्पष्ट करें।

क्या आप एजेंट चला रहे हैं, या मॉडल चला रहे हैं?

एक कोडिंग एजेंट जो क्लाउड मॉडल को कॉल करता है, वह एक नेटवर्क क्लाइंट है जिसके साथ एक शेल जुड़ा होता है। यह फाइलों और एक प्लान को API पर भेजता है, उत्तर की प्रतीक्षा करता है, फिर फाइलों को एडिट करता है और स्थानीय रूप से कमांड चलाता है। प्रतीक्षा के दौरान यह लगभग शून्य CPU का उपयोग करता है। इसकी अपनी मेमोरी सैकड़ों मेगाबाइट में मापी जाती है, इसीलिए एक साधारण CPU बॉक्स इसके लिए सही मशीन है।

मॉडल को स्वयं चलाना अलग हार्डवेयर पर एक अलग उत्पाद है। जब तक सर्वर चालू रहता है, वेट्स (weights) मेमोरी में बने रहते हैं। 4 बिट्स पर क्वांटाइज्ड (quantised) 7 बिलियन पैरामीटर वाले मॉडल को केवल वेट्स के लिए लगभग 5 GB की आवश्यकता होती है, और यह उस की/वैल्यू (key/value) कैश से पहले है जो कॉन्टेक्स्ट की लंबाई के साथ बढ़ती है। केवल CPU पर, एक साझा vCPU प्रति सेकंड कुछ ही टोकन उत्पन्न करता है, और एक एजेंट टास्क हजारों टोकन उत्सर्जित कर सकता है। इसलिए, जो काम API के साथ एक मिनट से कम समय में होता है, वह स्थानीय रूप से करने में लगभग एक घंटा लग सकता है। यदि आप यही चाहते हैं, तो 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 पंक्तियों को धारण करता है और एजेंट सबसे सस्ता है। यह 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 खत्म होने से पहले डिस्क खत्म होने के कारण

[
  {
    "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 प्रति श्रेणी पुनः प्राप्त करने योग्य स्थान (reclaimable space) को प्रिंट करता है, इसलिए इसे पहले और बाद में चलाएं। until=168h फ़िल्टर एक सप्ताह से पुराने बिल्ड कैश को हटा देता है और इस सप्ताह का कैश रखता है, जो वह कैश है जो अभी भी आपका समय बचाता है। docker image prune -a और आगे जाता है और हर उस इमेज को हटा देता है जिसका कोई कंटेनर उपयोग नहीं कर रहा है, इसलिए उम्मीद रखें कि अगला बिल्ड फिर से पुल (pull) करेगा।

Node प्रोजेक्ट्स एक अजीब तरीके से विफल होते हैं। npm install लाखों छोटी फाइलें लिखता है, इसलिए फाइलसिस्टम के inodes खत्म हो सकते हैं जबकि df -h अभी भी खाली गीगाबाइट दिखाता है। फिर राइट ऑपरेशन No space left on device के साथ विफल हो जाता है, जबकि डिस्क आधी खाली दिखती है।

df -h /
df -i /

यदि IUse% 100 पढ़ता है, तो उन शाखाओं की node_modules निर्देशिकाओं को हटा दें जिन पर आप अब नहीं हैं, या pnpm पर स्विच करें, जो प्रत्येक पैकेज संस्करण को एक बार संग्रहीत करता है और इसे प्रत्येक प्रोजेक्ट में हार्ड-लिंक करता है।

लॉग्स चुपचाप जगह घेरते हैं। एक हमेशा चालू रहने वाला एजेंट सत्र प्रतिलेख (session transcripts) लिखता है, और 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 चलाएं, क्योंकि एक बार का वैक्यूम केवल आज की जगह वापस दिलाता है।

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 की आवश्यकता हो।

आपका कोडिंग एजेंट हैंग क्यों होता हुआ दिखता है

यह एक छोटे एजेंट बॉक्स पर सबसे गलत तरीके से डायग्नोस की जाने वाली विफलता है। एक कमांड कोई परिणाम नहीं देती, एजेंट प्रतीक्षा करता है, और सत्र जमा हुआ (frozen) दिखता है। प्रक्रिया को kernel के out-of-memory (OOM) killer द्वारा समाप्त कर दिया गया था। इसे SIGKILL प्राप्त हुआ, इसलिए यह कोई त्रुटि प्रिंट नहीं कर सका, लॉग फ्लश नहीं कर सका, या एजेंट को यह नहीं बता सका कि क्या हुआ। एजेंट को एक खाली परिणाम और कोई एग्जिट संदेश नहीं मिलता है।

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 यह दर्शाता है कि मरने के समय उस प्रक्रिया ने कितनी मेमोरी ले रखी थी। ध्यान दें कि कौन सी प्रक्रिया चुनी गई: kernel मुख्य रूप से उपयोग में मौजूद मेमोरी के आधार पर स्कोर करता है, इसलिए यह अक्सर build के बजाय language server या एजेंट को मार देता है जिसने बॉक्स को सीमा के पार धकेला था। यही कारण है कि लक्षण "एजेंट खराब हो गया" के रूप में दिखाई देता है।

Docker के अंदर यही घटना एक स्पष्ट फिंगरप्रिंट छोड़ती है। कंटेनर कोड 137 के साथ बाहर निकलता है, जो 128 प्लस सिग्नल 9 है।

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

"OOMKilled": true पुष्टि करता है कि कंटेनर अपने आप क्रैश होने के बजाय अपनी मेमोरी सीमा तक पहुँच गया था।

इसका उपाय यह है कि महंगी कमांड को उसकी अपनी सीमा (ceiling) दी जाए, ताकि एजेंट के बजाय build समाप्त हो जाए:

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

build अब 4 GB पर समाप्त हो जाती है और एजेंट जीवित रहता है, जो एक रहस्यमयी हैंग को एक पठनीय एग्जिट कोड के साथ एक सामान्य विफल कमांड में बदल देता है। इसके लिए एक systemd user session की आवश्यकता होती है, इसलिए उस बॉक्स पर loginctl enable-linger $USER चलाएं जिसे आप केवल SSH के माध्यम से एक्सेस करते हैं। MemoryHigh= प्रक्रिया को मारने के बजाय सीमा पर थ्रॉटल (throttle) कर देता है, जो अक्सर उस build के लिए बेहतर सेटिंग है जिसे आप धीरे-धीरे पूरा होते देखना पसंद करेंगे।

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

क्या 2 GB RAM एक कोडिंग एजेंट के लिए पर्याप्त है?

एजेंट प्रोसेस के लिए, हाँ। लेकिन जो काम यह करता है, उसके लिए शायद ही। एजेंट लगभग 250 MB RAM का उपयोग करता है, लेकिन एक TypeScript language server मध्यम आकार की रिपॉजिटरी पर 2000 MB तक पहुँच सकता है, और केवल इतना ही 2 GB वाले बॉक्स को swap में धकेल देता है। 2 GB RAM config files और छोटी scripts को एडिट करने के लिए ठीक है। किसी भी ऐसे काम के लिए जो compile होता हो या test suite चलाता हो, 4 GB को न्यूनतम मानकर चलें।

क्या VPS पर कोडिंग एजेंट चलाने के लिए मुझे GPU की आवश्यकता है?

नहीं, यदि एजेंट API के माध्यम से cloud model को कॉल करता है। वह वर्कलोड network-bound होता है, इसलिए एक सामान्य CPU VPS ही सही मशीन है और GPU बहुत अधिक कीमत पर बेकार पड़ा रहेगा। आपको GPU की आवश्यकता केवल तब होती है जब model स्वयं उसी बॉक्स पर चलता है, और तब प्रश्न RAM से बदलकर VRAM और model के आकार पर आ जाता है।

मुझे एजेंट VPS में कितनी swap जोड़नी चाहिए?

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

मेरा कोडिंग एजेंट build के बीच में ही क्यों फ्रीज हो जाता है?

Build निश्चित रूप से kernel OOM killer द्वारा kill कर दिया गया है, जो SIGKILL भेजता है, इसलिए कुछ भी print नहीं होता और एजेंट एक ऐसे pipe पर प्रतीक्षा करता है जो कभी भरता ही नहीं। sudo dmesg -T | grep -i "killed process" चलाएँ और process का नाम तथा उसका anon-rss मान देखें। इसे ठीक करने के लिए build को systemd-run --user --scope -p MemoryMax=4G के साथ सीमित करें और worker count कम करें, या फिर उच्च RAM tier पर अपग्रेड करें।