একটি 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-তে উন্নীত করুন। বেশিরভাগ repository-তে এটি প্রথম দিনেই ঘটে। Agent process নিজে ছোট। আপনার হয়ে agent যে toolchain চালায়, সেটিই সার্ভারের অধিকাংশ resource ব্যবহার করে।

[
  {
    "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। এটি API-তে ফাইল ও একটি plan পাঠায়, উত্তরের জন্য অপেক্ষা করে, তারপর স্থানীয়ভাবে ফাইল সম্পাদনা করে এবং command চালায়। অপেক্ষা করার সময় এটি প্রায় কোনো CPU ব্যবহার করে না। এর নিজস্ব memory সাধারণত কয়েকশ megabyte হয়। তাই মাঝারি ক্ষমতার CPU box-ই এর জন্য উপযুক্ত machine।

নিজে model চালানো ভিন্ন hardware-এ ভিন্ন ধরনের product। Server চালু থাকা পর্যন্ত weights memory-তে থাকে। 4 bits-এ quantise করা 7 billion parameter-এর একটি model-এর weights-এর জন্যই আনুমানিক 5 GB দরকার হয়। এর সঙ্গে context-এর দৈর্ঘ্য অনুযায়ী বাড়তে থাকা key/value cache-এর memory-ও যোগ হয়। শুধু CPU ব্যবহার করলে একটি shared vCPU প্রতি second-এ কয়েকটি token তৈরি করে। একটি agent task-এ হাজার হাজার token তৈরি হতে পারে। তাই API ব্যবহার করে 1 মিনিটের কম সময় লাগা কাজ স্থানীয়ভাবে প্রায় 1 ঘণ্টা সময় নিতে পারে। আপনি যদি এটাই চান, তাহলে VRAM-এর (GPU-র video memory) ভিত্তিতে capacity নির্ধারণ করুন এবং এই 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
  }
]

মাঝারি আকারের প্রকল্পের জন্য এগুলো সাধারণত প্রকাশিত পরিসংখ্যান। এগুলোকে একটি ধারণাগত চিত্র হিসেবে নিন, আপনার কোড সম্পর্কে নিশ্চয়তা হিসেবে নয়।

চার্টে 6টি সারি আছে এবং agent-টির খরচ সবচেয়ে কম। এটি নিষ্ক্রিয় অবস্থায় প্রায় 250 MB মেমরি ব্যবহার করে, কারণ এটি একটি conversation এবং ছোট একটি file cache ধরে রাখে; এর বাইরে আর কিছু নয়। একটি TypeScript language server index করার সময় প্রায় 2000 MB-এ পৌঁছায়। কারণ এটি আপনার tsconfig.json থেকে পাওয়া প্রতিটি file-এর জন্য type graph তৈরি করে এবং পরবর্তী অনুরোধ দ্রুত উত্তর দেওয়ার জন্য graph-টি মেমরিতে রেখে দেয়। বড় workspace-এ rust-analyzer একই কারণে সাধারণত 4000 MB ছাড়িয়ে যায়, কারণ workspace-এর প্রতিটি crate এতে অন্তর্ভুক্ত থাকে।

Headless Chrome-এর browser এবং একটি tab-এর জন্য প্রায় 350 MB লাগে। প্রতিটি অতিরিক্ত tab-এর জন্য আরও একটি operating system process তৈরি হয়। চারটি worker-সহ Node test run-এ চারটি Node process থাকে, তাই এর peak প্রায় 3000 MB হয়। Docker image build-এর peak প্রায় 2500 MB হয়। কারণ build container-এর ভিতরে আপনার প্রকল্পের নিজস্ব compiler চালায়, আর daemon layer লিখতে থাকে।

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 ছোট থাকতে পারে এবং এটি কোনো তথ্য দেয় না। available-এর মাধ্যমে একটি নতুন process বাস্তবে কত মেমরি পেতে পারে তা বোঝা যায়।

কার্যকর তিনটি কনফিগারেশন

ন্যূনতম কার্যকর: 4 GB RAM, 2 vCPU, 50 GB disk। একটি agent session, একটি repository, একটি language server এবং যেসব build শেষ হওয়ার জন্য অপেক্ষা করতে আপনার আপত্তি নেই। এই tier কাজ করবে, তবে বড় test run এবং indexing language server একই সময়ে চললে প্রথমবারই out-of-memory killer-এর মুখোমুখি হবে। swap যোগ করুন এবং build worker-এর সংখ্যা সীমিত করুন।

স্বাচ্ছন্দ্যপূর্ণ: 8 GB RAM, 4 vCPU, 100 GB disk। একটি agent, Docker, tests-এর জন্য একটি headless browser এবং একটি build spike সামলানোর মতো অতিরিক্ত capacity। অধিকাংশ একক developer-এর এই tier বেছে নেওয়া উচিত। vCPU-এর সংখ্যা দ্বিগুণ করলে build-এর অপেক্ষার সময়ও প্রায় অর্ধেক হয়। memory-এর ঘাটতির তুলনায় এই সুবিধা আপনি অনেক বেশি ঘন ঘন অনুভব করবেন।

Team: 16 GB RAM, 8 vCPU, 200 GB disk। চারটি concurrent session, প্রতিটির জন্য আলাদা checkout এবং আলাদা toolchain। সর্বোচ্চ ব্যবহারের জন্য capacity নির্ধারণ করুন। চারটি idle agent-এর খরচ প্রায় নেই, কিন্তু একই সময়ে চারটি test run চললে উপরের সর্বোচ্চ সারির তুলনায় খরচ চার গুণ হয়।

August 2026 অনুযায়ী, annual VPS billing-এ প্রথম সারি থেকে শেষ সারিতে যেতে মাসিক দাম আনুমানিক চার গুণ হয়: সর্বনিম্ন tier-এ মাসে এক অঙ্কের dollar, আর সর্বোচ্চ tier-এ দশকের অঙ্কের dollar। পরিকল্পনা করার আগে বর্তমান listing দেখুন, কারণ এই দাম পরিবর্তিত হয়। server সাধারণত সবচেয়ে ব্যয়বহুল অংশ নয়। প্রতিদিন agent ব্যবহার করলে model API-এর bill দ্রুত server bill-কে ছাড়িয়ে যায়। তাই server ছোট করার আগে 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
  }
]

এই সারিগুলোর মোট যোগ করলে দেখা যাবে, এক লাইন code লেখার আগেই 50 GB disk প্রায় পূর্ণ হয়ে গেছে। এককভাবে সবচেয়ে বড় item হলো Docker, প্রায় 20 GB, কারণ BuildKit আপনি বন্ধ করতে না বলা পর্যন্ত প্রতিটি build-এর প্রতিটি intermediate layer রেখে দেয়।

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

docker system df প্রতিটি category অনুযায়ী reclaim করা সম্ভব এমন space দেখায়, তাই এটি আগে ও পরে চালান। until=168h filter এক সপ্তাহের বেশি পুরোনো build cache সরিয়ে দেয় এবং চলতি সপ্তাহের cache রেখে দেয়; এই cache-ই এখনও আপনার সময় বাঁচায়। docker image prune -a আরও এগিয়ে এমন প্রতিটি image সরিয়ে দেয় যা কোনো container ব্যবহার করছে না। তাই পরবর্তী build-এ আবার pull করতে হবে।

Node project-এ সমস্যা আরও অস্বাভাবিকভাবে দেখা দেয়। npm install কয়েক লক্ষ ছোট file তৈরি করে। ফলে df -h এখনও কয়েক GB free দেখালেও filesystem-এর inode শেষ হয়ে যেতে পারে। তখন অর্ধেক খালি দেখানো disk-এও write ব্যর্থ হয়ে No space left on device দেখায়।

df -h /
df -i /

যদি IUse% 100 পড়ে, আপনি বর্তমানে যে branch-এ নেই তার node_modules directory মুছে দিন। অথবা pnpm ব্যবহার করুন। এটি প্রতিটি package version একবার সংরক্ষণ করে এবং প্রতিটি project-এ hard-link তৈরি করে।

Logs নীরবে space দখল করে। সবসময় চালু থাকা একটি agent session transcript লেখে, আর systemd journal ডিফল্টভাবে 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 কেবল আজকের space-ই ফিরিয়ে দেয়।

Swap: এটি কী সুবিধা দেয় এবং কী আড়াল করে

Swap যোগ করা উপযোগী, কারণ সামান্য অতিরিক্ত memory প্রয়োজন হলে process বন্ধ না হয়ে ধীরগতিতে কাজ চালিয়ে যেতে পারে। RAM-এর অর্ধেক পরিমাণ Swap নির্ধারণ করুন, তবে সর্বোচ্চ প্রায় 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 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 কী আড়াল করে তা দেখা যাক। কোনো job-এর সত্যিই box-এ থাকা memory-এর চেয়ে বেশি memory প্রয়োজন হলে kernel build চালানোর বদলে RAM ও disk-এর মধ্যে page সরাতেই সময় ব্যয় করে। কিছু crash করে না। সবকিছু ধীর হয়ে যায়, এবং CPU idle থাকা অবস্থায় load average বেড়ে যায়।

vmstat 1 10

si এবং so column-এ ধারাবাহিক non-zero সংখ্যা থাকলে continuous swapping হচ্ছে। তাই সমাধান হলো concurrency কমানো বা RAM বাড়ানো; কখনোই বেশি Swap যোগ করা নয়। ছোট box-এ sudo apt install -y zram-tools RAM-এর মধ্যে রাখা compressed Swap সরবরাহ করে, যা /etc/default/zramswap-এ নির্ধারিত থাকে। এটি Swap file-এর চেয়ে অনেক দ্রুত। তবে RAM বাঁচাতে RAM ব্যবহার করে। তাই এটি cold page-এর ক্ষেত্রে সহায়ক, কিন্তু প্রকৃত 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 ঘটনাটি 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 নির্ধারণ করে। তাই box-এর সীমা অতিক্রম করানো build-এর বদলে এটি প্রায়ই language server বা agent-কে বন্ধ করে। এই কারণেই লক্ষণটি দেখে মনে হয়, "agent নষ্ট হয়ে গেছে"।

Docker-এর ভিতরে একই ঘটনা আরও স্পষ্ট চিহ্ন রেখে যায়। container code 137 দিয়ে exit করে, যা 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-এর বদলে readable exit code-সহ একটি সাধারণ failed command পাওয়া যাবে। এর জন্য systemd user session প্রয়োজন। তাই SSH-এর মাধ্যমে যেই box-এ শুধু remote access করেন, সেখানে loginctl enable-linger $USER চালান। MemoryHigh= threshold-এ পৌঁছালে process-টিকে বন্ধ না করে ধীর করে দেয়। ধীরে শেষ হওয়া মেনে নিতে পারলে build-এর জন্য এটি প্রায়ই বেশি উপযোগী setting।

Compose-এ একবার সীমা নির্ধারণ করুন

Agent-এর সরঞ্জামগুলো যদি container-এ চলে, তাহলে 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-এর সম্পূর্ণ নির্দেশিকা-তে reservation এবং container তার সর্বোচ্চ সীমায় পৌঁছালে কী ঘটে, তা ব্যাখ্যা করা হয়েছে। সার্ভারে Docker এখনও ইনস্টল করা না থাকলে আগে VPS-এ Docker ইনস্টল করুন।

একটি সমস্যার কারণে অনেকে পুরো একটি বিকেল হারান। 2 GB সীমাবদ্ধ একটি container এখনও host-এর /proc/meminfo এবং host-এর CPU count পড়তে পারে, কারণ কোনোটিই namespace-এর মাধ্যমে আলাদা করা হয় না। CPU count থেকে worker count নির্ধারণ করা test runner আট vCPU-র host-এ 2 GB container-এর ভেতরে আটটি worker চালু করবে। এরপর এটি 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 সেই limit-এ পৌঁছেছে, তা জানায়। OOM killer কখনও তা জানায় না।

একটি মেশিনে একাধিক agent session চালানো

প্রতি ব্যক্তির ভিত্তিতে নয়, প্রতি session-এর ভিত্তিতে পরিকল্পনা করুন। একই repository-তে দুটি session চললে দুটি language server, মেমরিতে build cache-এর দুটি সেট এবং উভয় agent একই সময়ে ব্যস্ত হলে দুটি test run দরকার হয়। এ কারণেই team row-এর মান 16 GB-এ বেড়ে যায়।

প্রতিটি user-এর জন্য একটি hard ceiling নির্ধারণ করুন, যাতে কোনো runaway 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-এর পরিবর্তে id -u যে UID দেখিয়েছে, সেটি বসান। user লগ ইন করার পরে systemctl show-এর আউটপুটে MemoryMax=6442450944 একবার দেখা উচিত। ওই user-এর session-এ মোট ব্যবহার 6 GB অতিক্রম করলে kernel তার slice-এর একটি process বন্ধ করে দেয়, আর অন্য সব session কাজ চালিয়ে যায়। কোনো agent terminal-এর পরিবর্তে service হিসেবে চললে তার unit file-এ MemoryMax= যোগ করুন। agent-কে সবসময় চালু থাকা service হিসেবে নিজে host করার ক্ষেত্রে এই পদ্ধতিই অনুসরণ করুন।

FAQ

একটি coding agent-এর জন্য 2 GB RAM কি যথেষ্ট?

Agent process-এর জন্য যথেষ্ট। কিন্তু এটি যে কাজ করে, তার জন্য সাধারণত যথেষ্ট নয়। Agent প্রায় 250 MB মেমরি ব্যবহার করে, কিন্তু একটি TypeScript language server মাঝারি আকারের repository-তে 2000 MB পর্যন্ত ব্যবহার করতে পারে। এটিই 2 GB-এর server-কে swap ব্যবহারে ঠেলে দিতে পারে। Configuration file এবং ছোট script সম্পাদনার জন্য 2 GB যথেষ্ট। Compile হয় বা test suite চালায়—এমন যেকোনো কাজের জন্য 4 GB-কে ন্যূনতম সীমা ধরুন।

VPS-এ coding agent চালাতে কি GPU দরকার?

Agent যদি API-এর মাধ্যমে cloud model ব্যবহার করে, তাহলে GPU দরকার নেই। এই workload network-bound। তাই সাধারণ CPU VPS-ই উপযুক্ত, আর অনেক বেশি দামের GPU অব্যবহৃত থাকে। Model একই server-এ চললে তবেই GPU দরকার। সে ক্ষেত্রে প্রশ্নটি RAM থেকে VRAM এবং model-এর আকারে পরিবর্তিত হয়।

Agent VPS-এ কতটা swap যোগ করা উচিত?

RAM-এর অর্ধেক, তবে সর্বোচ্চ প্রায় 4 GB। Swap স্বল্প সময়ের অতিরিক্ত memory usage সামলাতে সাহায্য করে। Kernel process বন্ধ না করে cold page disk-এ সরিয়ে নিতে পারে। তবে swap ব্যবহারযোগ্য memory বাড়ায় না। vmstat 1-এ si এবং so column-এ যদি নিয়মিত traffic দেখা যায়, তাহলে server thrashing করছে। এ ক্ষেত্রে parallel worker কমান অথবা বড় plan নিন।

Build-এর মাঝখানে আমার coding agent freeze করে কেন?

সম্ভবত kernel OOM killer build-টি বন্ধ করে দিয়েছে। এটি SIGKILL পাঠায়। তাই কোনো output দেখা যায় না এবং agent এমন একটি pipe-এর জন্য অপেক্ষা করে, যা আর data পায় না। sudo dmesg -T | grep -i "killed process" চালিয়ে process name এবং তার anon-rss value দেখুন। systemd-run --user --scope -p MemoryMax=4G দিয়ে build-এর সীমা নির্ধারণ করুন এবং worker-এর সংখ্যা কমান। অথবা এক ধাপ বেশি RAM tier-এ upgrade করুন।