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

নিজে model চালানো ভিন্ন hardware-এ ভিন্ন ধরনের product। Server চালু থাকা পর্যন্ত weights memory-তে থাকে। 4 bits-এ quantise করা 7 billion parameter-এর একটি model-এর weights প্রায় 4 GB (Llama 2 7B-এর Q4_0 সংস্করণ 3.83 GB এবং Q4_K_M সংস্করণ 4.08 GB হিসেবে release হয়)। Runtime overhead ধরলে GPU ছাড়া চালানোর জন্য publisher 6.3 থেকে 6.6 GB RAM উল্লেখ করে। Context দীর্ঘ হলে আরও memory দরকার হয়, কারণ context-এর দৈর্ঘ্যের সঙ্গে key/value cache বড় হয়। শুধু CPU ব্যবহার করলে shared vCPU প্রতি সেকেন্ডে কয়েকটি token তৈরি করে। একটি agent task-এ হাজার হাজার token তৈরি হতে পারে। তাই API-তে এক মিনিটের কম সময় লাগা কাজ স্থানীয়ভাবে প্রায় এক ঘণ্টা নিতে পারে। আপনি যদি সেটিই চান, তাহলে VRAM-এর জন্য 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টি সারি আছে এবং 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 শেষ হয়ে যায়

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

ওই row-গুলো যোগ করলে 50 GB disk-এ এক লাইন code লেখার আগেই প্রায় পুরো 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 record রেখে বাকিগুলো মুছে দেয়। এটি age নয়, last use দেখে কাজ করে। তাই এক মাস আগে তৈরি হলেও গতকাল পুনরায় ব্যবহার করা layer থেকে যায়। এই 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 তৈরি করে।

Log হলো নীরব সমস্যা। সব সময় চালু থাকা agent session transcript লেখে। 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 শুধু আজকের 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-এ এটিই সবচেয়ে বেশি ভুলভাবে শনাক্ত করা failure। কোনো command কিছু return করে না, agent অপেক্ষা করতে থাকে, এবং session frozen মনে হয়। kernel-এর out-of-memory (OOM) killer process-টিকে kill করেছে। Process-টি 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

Process মারা যাওয়ার সময় সেটি কত memory ধরে রেখেছিল, তা anon-rss দেখায়। কোন process নির্বাচন করা হয়েছে তা লক্ষ্য করুন। Kernel মূলত ব্যবহৃত memory-এর ভিত্তিতে score করে। তাই box-এর সীমা অতিক্রম করানো build-কে না মেরে প্রায়ই language server বা agent-কে kill করে। এই কারণেই লক্ষণটি “agent নষ্ট হয়েছে” বলে মনে হয়।

Docker-এর ভেতরে একই ঘটনা আরও স্পষ্টভাবে দেখা যায়। Container 137 exit code নিয়ে বন্ধ হয়। এটি 128-এর সঙ্গে signal 9 যোগ করলে পাওয়া যায়।

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

"OOMKilled": true নিশ্চিত করে যে container নিজে crash করেনি; বরং তার memory limit-এ পৌঁছেছিল।

সমাধান হলো ব্যয়বহুল command-এর জন্য আলাদা ceiling দেওয়া। এতে agent-এর বদলে build বন্ধ হবে:

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

এখন build 4 GB-এ kill হবে এবং agent চালু থাকবে। ফলে রহস্যময় hang-এর পরিবর্তে readable exit code-সহ সাধারণ failed command দেখা যাবে। এর জন্য systemd user manager দরকার। সাধারণ SSH login এটি নিজে চালু করে, তাই SSH-এর মাধ্যমে command-টি সরাসরি কাজ করে। Log out করার পর user unit চালু রাখার জন্যই শুধু loginctl enable-linger $USER দরকার। MemoryHigh= threshold-এ পৌঁছালে process kill না করে throttle করে। ধীরে শেষ হওয়া গ্রহণযোগ্য এমন 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 করুন।