coding agent VPS کے لیے کتنی RAM درکار ہے؟

ایک coding agent VPS کے لیے کتنی RAM درکار ہے؟

ایک repository میں مسلسل چلنے والے ایک coding agent کے لیے 4 GB RAM اور 2 vCPU سے آغاز کریں۔ جیسے ہی session میں language server یا Docker build شامل ہو، 8 GB RAM اور 4 vCPU پر منتقل ہو جائیں۔ زیادہ تر repositories میں یہ ضرورت پہلے ہی دن پیش آ جاتی ہے۔ خود agent process چھوٹا ہوتا ہے، اس لیے VPS کی زیادہ تر resources وہ 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
  }
]

اوپر دی گئی ہر row یہ فرض کرتی ہے کہ model کہیں اور چل رہا ہے اور آپ اسے network کے ذریعے API call کرتے ہیں۔ sizing کے پورے فیصلے کا انحصار اسی مفروضے پر ہے، اس لیے پہلے اسے واضح کریں۔

کیا آپ agent چلا رہے ہیں یا model؟

ایسا coding agent جو cloud model کو call کرتا ہے، دراصل shell کے ساتھ network client ہوتا ہے۔ یہ files اور plan کو API پر بھیجتا ہے، جواب کا انتظار کرتا ہے، پھر مقامی طور پر files میں ترمیم اور commands چلاتا ہے۔ انتظار کے دوران یہ تقریباً کوئی CPU استعمال نہیں کرتا۔ اس کی اپنی memory سینکڑوں megabytes میں ہوتی ہے، اسی لیے modest CPU box موزوں machine ہے۔

خود model چلانا مختلف hardware پر مختلف product ہے۔ جب تک server چل رہا ہو، weights memory میں موجود رہتے ہیں۔ 7 billion parameters والے model کو 4 bits پر quantise کرنے کے لیے صرف weights کے لیے تقریباً 5 GB درکار ہوتے ہیں۔ اس کے علاوہ key/value cache بھی ہوتا ہے، جو context کی لمبائی کے ساتھ بڑھتا ہے۔ صرف CPU پر shared vCPU چند tokens فی second پیدا کرتا ہے، جبکہ ایک agent task ہزاروں tokens خارج کر سکتا ہے۔ اس لیے API کے ذریعے ایک minute سے کم وقت لینے والا کام مقامی طور پر تقریباً ایک گھنٹہ لے سکتا ہے۔ اگر آپ یہی چاہتے ہیں تو VRAM یعنی GPU کی video memory کے مطابق sizing کریں، اور اس page کے بجائے 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 کے بارے میں ضمانت نہ سمجھیں۔

جدول میں 6 قطاریں ہیں، اور 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 تک پہنچ جاتا ہے۔ Docker image build تقریباً 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 کے لیے استعمال کرتا ہے، اس لیے مکمل طور پر صحت مند system پر بھی free کم ہو سکتا ہے اور اس سے کوئی مفید نتیجہ نہیں نکلتا۔ available بتاتا ہے کہ نیا process حقیقت میں کتنی memory حاصل کر سکتا ہے۔

تین کارآمد configurations

کم از کم قابلِ عمل: 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 کے مقابلے میں اس کا فائدہ آپ کو کہیں زیادہ بار محسوس ہوتا ہے۔

ٹیم: 16 GB RAM، 8 vCPU، 200 GB disk۔ بیک وقت چار sessions، ہر session کے لیے اپنی checkout اور اپنا toolchain۔ peak کے مطابق sizing کریں، کیونکہ چار idle agents کی لاگت تقریباً کچھ نہیں ہوتی، جبکہ ایک ہی وقت میں چلنے والے چار test runs کی لاگت اوپر دیے گئے peak column سے چار گنا ہوتی ہے۔

August 2026 تک، پہلے row سے آخری row تک جانے پر 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 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
  }
]

ان قطاروں کو جمع کریں تو 50 GB disk، code کی ایک لائن لکھنے سے پہلے ہی تقریباً بھر جاتی ہے۔ سب سے بڑی واحد شے 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 ایک ہفتے سے پرانے build cache کو حذف کرتا ہے اور اس ہفتے کا cache برقرار رکھتا ہے، جو اب بھی وقت بچاتا ہے۔ docker image prune -a مزید آگے جا کر ہر وہ image حذف کرتا ہے جسے کوئی container استعمال نہیں کر رہا، اس لیے اگلی build کے دوران image دوبارہ pull ہونے کی توقع رکھیں۔

Node projects زیادہ غیر واضح انداز میں fail ہوتے ہیں۔ npm install لاکھوں چھوٹی files لکھتا ہے، اس لیے filesystem میں inodes ختم ہو سکتے ہیں، جبکہ df -h اب بھی کئی خالی gigabytes دکھاتا ہے۔ اس کے بعد writing، آدھی خالی نظر آنے والی disk پر No space left on device کے ساتھ fail ہو جاتی ہے۔

df -h /
df -i /

اگر IUse% کی output 100 ہو تو ان branches کی node_modules directories حذف کریں جن پر آپ اب کام نہیں کر رہے، یا pnpm پر منتقل ہو جائیں۔ یہ ہر package version کو صرف ایک بار محفوظ کرتا ہے اور اسے ہر project میں hard-link کرتا ہے۔

Logs خاموشی سے disk بھرتے ہیں۔ ہمیشہ چلنے والا 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: اس سے کیا فائدہ ہوتا ہے، اور یہ کیا چھپاتا ہے

Swap شامل کرنا مفید ہے، کیونکہ یہ معمولی اضافی memory استعمال کو process ختم ہونے کے بجائے سست کام میں بدل دیتا ہے۔ اسے 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 کو آپ کی مطلوبہ size کے ساتھ دکھانا چاہیے۔ /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 responsive رہتا ہے۔

اب دیکھیں کہ swap کیا چھپاتا ہے۔ جب کسی job کو واقعی box میں موجود memory سے زیادہ 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 میں configure کیا جاتا ہے۔ یہ swap file سے بہت تیز ہے، اور RAM بچانے کے لیے RAM استعمال کرتا ہے۔ اس لیے یہ cold pages کے لیے مددگار ہے، لیکن ایسے build کے لیے نہیں جسے واقعی زیادہ working memory درکار ہو۔

آپ کا coding agent ہینگ ہوتا ہوا کیوں دکھائی دیتا ہے

یہ ایک چھوٹے agent box پر سب سے زیادہ غلط تشخیص کی جانے والی خرابی ہے۔ کوئی command کچھ واپس نہیں کرتی، agent انتظار کرتا رہتا ہے، اور session منجمد دکھائی دیتا ہے۔ process کو kernel کے out-of-memory (OOM) killer نے ختم کیا ہوتا ہے۔ اسے SIGKILL موصول ہوتا ہے، اس لیے یہ error پرنٹ، log flush، یا agent کو واقعہ بتا نہیں سکتا۔ agent کو خالی 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 اس مقدار کو ظاہر کرتا ہے جتنی memory اس process کے پاس ختم کیے جانے کے وقت تھی۔ یہ بھی دیکھیں کہ کون سا process منتخب ہوا: kernel عموماً استعمال ہونے والی memory کی بنیاد پر score بناتا ہے، اس لیے اکثر وہ language server یا agent کو ختم کرتا ہے، نہ کہ اس build کو جس نے system کو حد سے آگے پہنچایا۔ اسی وجہ سے علامت یہ محسوس ہوتی ہے کہ "agent خراب ہو گیا"۔

Docker کے اندر یہی واقعہ زیادہ واضح نشان چھوڑتا ہے۔ container code 137 کے ساتھ exit کرتا ہے، جو 128 جمع signal 9 کے برابر ہے۔

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

"OOMKilled": true تصدیق کرتا ہے کہ container اپنی memory limit تک پہنچا تھا، نہ کہ خود سے crash ہوا تھا۔

حل یہ ہے کہ مہنگی command کے لیے الگ maximum limit مقرر کی جائے، تاکہ build ختم ہو اور agent چلتا رہے:

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

اب build کو 4 GB پر ختم کر دیا جاتا ہے اور agent محفوظ رہتا ہے۔ یوں پراسرار hang ایک عام failed command میں بدل جاتا ہے، جس کا exit code پڑھا جا سکتا ہے۔ اس کے لیے systemd user session درکار ہے، اس لیے loginctl enable-linger $USER ایسے box پر چلائیں جس تک آپ صرف SSH کے ذریعے پہنچتے ہوں۔ MemoryHigh= threshold پر process ختم کرنے کے بجائے اس کی رفتار محدود کرتا ہے۔ اس build کے لیے یہ عموماً زیادہ مناسب setting ہوتی ہے جسے آپ آہستہ سہی، مکمل ہونے دینا چاہتے ہیں۔

Compose کے ساتھ ایک بار memory limit مقرر کریں

اگر 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 کے مقررہ maximum تک پہنچنے پر ہونے والے عمل کی وضاحت ہے۔ اگر server پر Docker ابھی موجود نہیں ہے تو پہلے VPS پر Docker install کریں۔

ایک غلطی لوگوں کا پورا دوپہر کا وقت ضائع کر دیتی ہے۔ 2 GB تک محدود container اب بھی host کا /proc/meminfo اور host کی CPU count پڑھتا ہے، کیونکہ ان دونوں کے لیے namespaces استعمال نہیں ہوتے۔ آٹھ vCPU والے host پر CPU count سے worker count منتخب کرنے والا test runner، 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 دے جسے آپ پڑھ سکیں، بجائے اس کے کہ process اچانک غائب ہو جائے:

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 تک پہنچ جاتی ہے۔

ہر user کے لیے سخت حد مقرر کریں تاکہ کوئی بے قابو session پورے سرور کو بند نہ کر دے:

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 نے دکھایا تھا۔ User کے login کرنے کے بعد systemctl show کو MemoryMax=6442450944 دکھانا چاہیے۔ جب اس user کے session میں مجموعی استعمال 6 GB سے تجاوز کرے گا تو kernel اس کے slice کے اندر موجود ایک process کو ختم کر دے گا، جبکہ باقی تمام sessions کام کرتے رہیں گے۔ اگر کوئی agent terminal کے بجائے service کے طور پر چلتا ہے تو اس کی unit file میں MemoryMax= شامل کریں۔ یہی طریقہ اس وقت اختیار کریں جب آپ agent کو ہمیشہ فعال service کے طور پر خود host کریں۔

FAQ

کیا coding agent کے لیے 2 GB RAM کافی ہے؟

agent process کے لیے ہاں۔ اس کے انجام دیے جانے والے کام کے لیے عموماً نہیں۔ agent تقریباً 250 MB RAM استعمال کرتا ہے، لیکن درمیانے درجے کی repository پر ایک TypeScript language server 2000 MB تک پہنچ سکتا ہے، اور صرف یہی 2 GB والے server کو swap استعمال کرنے پر مجبور کر دیتا ہے۔ configuration files اور چھوٹے scripts میں ترمیم کے لیے 2 GB کافی ہے۔ ایسی ہر چیز کے لیے جو compile ہوتی ہو یا test suite چلاتی ہو، کم از کم 4 GB RAM رکھیں۔

کیا VPS پر coding agent چلانے کے لیے GPU ضروری ہے؟

اگر agent API کے ذریعے cloud model کو call کرتا ہے تو نہیں۔ یہ workload network-bound ہوتا ہے، اس لیے سادہ CPU VPS مناسب machine ہے، جبکہ GPU کہیں زیادہ قیمت پر idle رہتا ہے۔ GPU صرف اس وقت درکار ہوتا ہے جب model خود اسی server پر چل رہا ہو۔ ایسی صورت میں سوال RAM سے بدل کر VRAM اور model size کا ہو جاتا ہے۔

agent VPS میں کتنی swap شامل کرنی چاہیے؟

RAM کے نصف کے برابر، اور زیادہ سے زیادہ تقریباً 4 GB۔ swap مختصر مدت کے اضافی memory استعمال سے تحفظ دیتی ہے، کیونکہ kernel کسی process کو ختم کرنے کے بجائے cold pages کو disk پر منتقل کر سکتا ہے۔ یہ قابل استعمال memory میں اضافہ نہیں کرتی۔ اگر vmstat 1 میں si اور so columns کے تحت مسلسل traffic نظر آئے تو server thrashing کر رہا ہے۔ اس کا حل کم parallel workers استعمال کرنا یا بڑا plan لینا ہے۔

build کے دوران coding agent کیوں freeze ہو جاتا ہے؟

تقریباً یقینی طور پر build کو kernel کے OOM killer نے ختم کیا ہے۔ OOM killer SIGKILL بھیجتا ہے، اس لیے کچھ output ظاہر نہیں ہوتا اور agent ایسی pipe پر انتظار کرتا رہتا ہے جو کبھی بھر نہیں سکتی۔ sudo dmesg -T | grep -i "killed process" چلائیں اور process name اور اس کی anon-rss value دیکھیں۔ build کو systemd-run --user --scope -p MemoryMax=4G کے ذریعے محدود کریں اور workers کی تعداد کم کریں، یا RAM کے اگلے tier پر منتقل ہو جائیں۔