agent হোস্টিং নিয়ে যে ভুলটা আমি সবচেয়ে বেশি দেখি তা হলো ভুল জিনিসের জন্য size করা। কেউ একটি agent চালায়, এটি 400 MB ব্যবহার করে, আর তারা সিদ্ধান্তে আসে agent হোস্ট করা সস্তা। তারপর তারা একটি আসল দলে scale করে আর বক্সটি ভোর 3টায় swap করতে শুরু করে।
একটি agent ই সস্তা। ওটা মজার কেসটা নয়।
memory আসলে কোথায় যায়
যে agent শুধু একটি মডেলে API call ছোড়ে সে হালকা — সে বেশিরভাগ সময় নেটওয়ার্কের অপেক্ষায়। আপনি এমন এক ডজন একটি ছোট প্ল্যানে চালাতে পারেন ও কখনও টের পাবেন না।
RAM উধাও হয় যখন agent state ধরতে শুরু করে। কথোপকথনের history যা প্রতি turn-এ বাড়ে। একটি working set যা কয়েকটি agent পড়ে ও লেখে। একই process-এ বসা দীর্ঘমেয়াদি memory-র জন্য একটি vector store। যে মুহূর্তে আপনার আর্কিটেকচার "call API, ভুলে যাও" হওয়া থামিয়ে "মনে রাখো, সমন্বয় করো, hand off করো" হয়, তখন memory বাধা হয়ে ওঠে, CPU নয়।
CrewAI, LangGraph, AutoGPT-ধাঁচের loop — এরা সবই গুরুতর হতে হতে এদিকেই ঝোঁকে। ফ্রেমওয়ার্ক RAM খায় না; state খায়।
মোটামুটি sizing, সৎভাবে
আমি ভান করব না যে একটি সূত্র আছে, কারণ নেই — এটি পুরোপুরি নির্ভর করে প্রতিটি agent কতটা রাখে তার ওপর। কিন্তু এগুলো চালানো থেকে একটি ব্যবহারিক অনুভূতি:
- হালকা, API-নির্ভর agent — এখানে আপনার Pro আদৌ লাগে না; একটি NAT বা dedicated-IP প্ল্যান ($3–20) এটি সামলায়। shared state আপনাকে ~32 GB-র বাইরে ঠেললেই Pro নিজের জায়গা অর্জন করে।
- 32 GB — একটি আসল multi-agent সিস্টেমের sweet spot: shared memory সহ 5–10টি agent plus একটি vector database যা আসলে দরকারি। বেশিরভাগ মানুষ এখানে দাঁড়ায়।
- 64 GB — বড় fleet, দীর্ঘ history, মিলিয়ন-মিলিয়ন vector-এর একটি memory index, বা কয়েকটি co-located সার্ভিস। এখানেই একটি বক্স সেই তিনটি ছোট বক্সের জায়গা নেয় যা আপনি নইলে সামলাতেন।
- 80 GB — ভারী, memory-bound কাজ: বড় in-memory dataset, অনেক concurrent agent, বা একই হোস্টে agent plus local মডেল ইনফারেন্স।
যেখানে দরকার মনে করেন তার নিচে শুরু করুন। একদিন htop দেখুন। swap দেখলে ওপরে resize করুন, তার আগে নয় — বেশি অনুমান শুধু টাকা নষ্ট করে।
যে অংশটা কেনা কঠিন
এই যে জিনিসটা এটিকে অস্বস্তিকর করে: 64 GB RAM ভাড়া নেওয়া সহজ। ক্রিপ্টো ও কোনো পরিচয়-চেক ছাড়া 64 GB ভাড়া নেওয়া নয়। যেসব হোস্ট গুরুতর memory সস্তায় বেচে তার বেশিরভাগ তা করে একটি কার্ড ও একটি KYC ফর্মের আড়ালে।
আপনার agent নিজের সার্ভার provision করলে, বা workload এমন ডেটা ছুঁলে যা আপনি একটি নামের সাথে বাঁধতে চান না, সেই সংমিশ্রণ — high memory, ক্রিপ্টো, no KYC, ও agent নিজে MCP-র মাধ্যমে অর্ডারযোগ্য — সেটাই আসল প্রোডাক্ট। এটি প্রতি গিগাবাইটে সস্তা নয়, আর আমি সেই তুলনা কেন বিভ্রান্ত করে সে নিয়ে আলাদাভাবে লিখেছি। এটি এমন শর্তে উপলব্ধ যা প্রায় কেউ দেয় না।
তাহলে আপনি কী করবেন
আপনার agent হালকা ও API-নির্ভর হলে, বেশি ভাববেন না — একটি ছোট NAT বা dedicated-IP প্ল্যান যথেষ্ট, পুরো high-memory প্রশ্ন এড়িয়ে যান। আপনি state ধরে রাখা একটি আসল fleet চালালে, memory-তে আসলে যা আছে তা দিয়ে size করুন, 32 GB-তে শুরু করুন, ও গ্রাফ বললে ওপরে যান।
সেখানে পৌঁছলে, Pro লাইন একটি dedicated IP ও রাত্রিকালীন backup সহ 32 থেকে 80 GB কভার করে। আপনার উচ্চাকাঙ্ক্ষা নয়, আপনার working set-এর সাথে মেলে এমন tier বাছুন।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।