বেশিরভাগ মানুষ RAM আন্দাজে কেনেন। হয় “যদি লাগে” ভেবে অনেক বেশি কেনেন, নয়তো রাত ৩টায় OOM killer-এর সঙ্গে পরিচয় হয়। আসলে মেমরি হলো আকার ঠিক করার সবচেয়ে সহজ জিনিসগুলোর একটি, কারণ মোটামুটি সংখ্যা জানা থাকলে কাজের চাহিদা আগে থেকে বলা যায়। এই রইল সেই সংখ্যাগুলো, বটের জন্য 1 GB মেশিন থেকে শুরু করে সেই 64 GB সার্ভার পর্যন্ত, যা মানুষ বড় মডেল লোকালি চালাতে চাইলে খোঁজেন।
কাজ অনুযায়ী মোটামুটি সংখ্যা
এগুলো একটি সাধারণ সেটআপের স্থির অবস্থার বাস্তব মান, বিক্রেতার ন্যূনতম প্রয়োজনীয়তা নয়।
| কাজ | আসলে যত RAM নেয় | মানানসই প্ল্যান |
|---|---|---|
| Telegram/Discord বট (Python, Node.js) | 100–300 MB | Nano 1 GB |
| স্ট্যাটিক সাইট + Caddy/Nginx | 50–150 MB | Nano 1 GB |
| WordPress + MariaDB, সাধারণ ট্রাফিক | 0.8–1.5 GB | Micro-IP 2 GB |
| ছোট অ্যাপের জন্য PostgreSQL | 0.5–2 GB (আপনি shared_buffers দিয়ে ঠিক করেন) | Micro / Small |
| কয়েকটি ওয়ার্কফ্লোসহ n8n | 0.5–1.5 GB | Micro 2 GB |
| ৫–১০টি ছোট পরিষেবাসহ Docker হোস্ট | 2–4 GB | Small 4 GB |
| Coolify + বিল্ড + একটি ডেটাবেস | 3–4 GB | Small-IP 4 GB |
| 7–8B LLM, 4-বিট, CPU ইনফারেন্স | 5–6 GB | Medium 6 GB |
| 14B LLM, 4-বিট | ~10 GB | Pro-32 |
| 32B LLM, 4-বিট | ~20 GB | Pro-32 |
| 70B LLM, 4-বিট | ~40–45 GB | Pro-48 / Pro-64 |
দুটি বিষয় লক্ষণীয়। প্রথমত, “সাধারণ” কাজ আর LLM-এর মধ্যে ব্যবধান বিশাল: একটি বট আর একটি 70B মডেলের পার্থক্য দুশো গুণ। দ্বিতীয়ত, বেশিরভাগ পরিষেবা 1–4 GB-তেই ভালো চলে; মানুষ বেশি কেনেন কারণ তারা এমন ভবিষ্যতের কথা ভেবে আকার বাছেন যা খুব কমই আসে।
LLM-এর সূত্র
ভাষা মডেলের জন্য একটি সহজ হিসাব আছে: প্যারামিটার × প্রতি ওজনে বিট ÷ 8, সঙ্গে বাড়তি খরচ। প্রায় 4.5 বিটের (একটি সাধারণ Q4 কোয়ান্টাইজেশন) একটি 8B মডেলের ওজন 8 × 4.5 ÷ 8 ≈ 4.5 GB। কনটেক্সট উইন্ডো (KV ক্যাশ কনটেক্সটের দৈর্ঘ্যের সঙ্গে বাড়ে) আর রানটাইমের জন্য 1–2 GB যোগ করুন, হয়ে যায় 5–6 GB।
সৎ কথাটি হলো: শুধু CPU-র সার্ভারে মেমরি গল্পের অর্ধেক মাত্র। কয়েকটি vCPU-তে 7–8B মডেলে প্রতি সেকেন্ডে কয়েকটি টোকেন আর 70B-তে প্রায় এক টোকেন প্রতি সেকেন্ড আশা করুন। ব্যাচ কাজ, পটভূমির এজেন্ট আর ব্যক্তিগত পরীক্ষার জন্য এটি ঠিক আছে; একসঙ্গে অনেক ব্যবহারকারীর চ্যাটের অভিজ্ঞতা এটি নয়। আপনি যদি মূলত হোস্ট করা মডেলের API ডাকেন, তাহলে আপনার এজেন্টের অনেক কম লাগবে: দেখুন AI এজেন্টের জন্য VPS-এর আকার।
আন্দাজ নয়, মাপুন
আপনার যদি আগে থেকেই সার্ভার থাকে, তাহলে সংখ্যাগুলো সেখানেই আছে:
free -h # look at "available", not "free"
ps aux --sort=-rss | head -n 8 # the biggest processes, by resident memory
docker stats --no-stream # per-container usage
Linux অলস RAM-কে ডিস্ক ক্যাশ হিসেবে ব্যবহার করে, তাই “free” সবসময় ছোট থাকে, আর এটাই স্বাভাবিক। আসল গুরুত্ব available-এর: কার্নেল এখনই প্রোগ্রামকে যে মেমরি দিতে পারে। সবচেয়ে ব্যস্ত সময়ে available যদি ~25%-এর ওপরে থাকে, তাহলে আকার ঠিক আছে। যদি এটি প্রায়ই শূন্যে নামে আর সোয়াপ বাড়তে থাকে, তাহলে প্ল্যান বাড়ান।
আগে কখনো OOM-এ প্রসেস মারা গেছে কি না, সেটিও দেখে নিন:
journalctl -k | grep -i "out of memory"
সোয়াপ: সিটবেল্ট, ইঞ্জিন নয়
ছোট সার্ভারে 1–2 GB-র একটি সোয়াপ ফাইল সস্তা বিমা: যে প্যাকেজ আপগ্রেড বা Docker বিল্ডের অল্প সময়ের জন্য বেশি মেমরি লাগে, সেটি মেরে ফেলার বদলে টিকে যায়। কিন্তু কোনো পরিষেবা যদি সোয়াপে বাস করে, তাহলে প্রতিটি অনুরোধ ডিস্কের অপেক্ষায় থাকে। সোয়াপ উল্লম্ফনের জন্য। সারাক্ষণ সোয়াপিং মানে আপনার পরের প্ল্যান দরকার।
তাহলে কত কিনবেন?
- 1 GB: একটি বট, একটি ছোট API, একটি স্ট্যাটিক সাইট।
- 2 GB: ডেটাবেস বা Docker থাকা যেকোনো কিছুর জন্য যুক্তিসঙ্গত ডিফল্ট।
- 4–6 GB: এক মেশিনে কয়েকটি পরিষেবা, সার্ভারে বিল্ড, একটি ছোট লোকাল মডেল।
- 32–64 GB: শুধু তখনই, যখন একটি বড় জিনিসকে মেমরিতে থাকতেই হয়: 14B-এর চেয়ে বড় লোকাল মডেল, বড় RAG ইনডেক্স, এজেন্টের দল। বেশি মেমরির প্ল্যান এর জন্যই।
আপনার অনুমানের চেয়ে এক আকার ছোট দিয়ে শুরু করুন, এক সপ্তাহ free -h দেখুন, আর সংখ্যা বললে আপগ্রেড করুন। EQVPS-এ প্ল্যান আপগ্রেড করলে আপনার ডেটা থেকে যায় এবং শুধু আনুপাতিক পার্থক্য নেওয়া হয় (প্ল্যান বদল কীভাবে কাজ করে)।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।