زیادہ تر لوگ RAM کا اندازہ لگاتے ہیں۔ یا تو «احتیاطاً» بہت زیادہ خرید لیتے ہیں یا رات 3 بجے 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 |
| 5–10 چھوٹی سروسز والا Docker ہوسٹ | 2–4 GB | Small 4 GB |
| Coolify + بلڈز + ڈیٹا بیس | 3–4 GB | Small-IP 4 GB |
| 7–8B LLM، 4-bit، CPU پر انفرنس | 5–6 GB | Medium 6 GB |
| 14B LLM، 4-bit | ~10 GB | Pro-32 |
| 32B LLM، 4-bit | ~20 GB | Pro-32 |
| 70B LLM، 4-bit | ~40–45 GB | Pro-48 / Pro-64 |
دو باتوں پر غور کریں۔ پہلی، «عام» کاموں اور LLMs کے درمیان چھلانگ بہت بڑی ہے: ایک بوٹ اور 70B ماڈل میں دو سو گنا کا فرق ہے۔ دوسری، زیادہ تر سروسز 1–4 GB پر ٹھیک چلتی ہیں؛ لوگ زیادہ خریدتے ہیں کیونکہ وہ ایسے مستقبل کے لیے سائز کرتے ہیں جو کم ہی آتا ہے۔
LLM کا فارمولا
لینگویج ماڈلز کے لیے ایک سادہ تخمینہ ہے: پیرامیٹرز × فی وزن بٹس ÷ 8، جمع اضافی بوجھ۔ تقریباً 4.5 بٹ (ایک عام Q4 کوانٹائزیشن) پر 8B ماڈل کا مطلب ہے 8 × 4.5 ÷ 8 ≈ 4.5 GB وزن۔ context ونڈو (KV cache، context کی لمبائی کے ساتھ بڑھتا ہے) اور رن ٹائم کے لیے 1–2 GB جوڑیں تو آپ 5–6 GB پر پہنچتے ہیں۔
ایماندارانہ حصہ: صرف CPU والے سرورز پر میموری آدھی کہانی ہے۔ چند vCPU پر 7–8B ماڈلز کے لیے فی سیکنڈ اکائی ہندسوں میں ٹوکنز اور 70B کے لیے تقریباً ایک ٹوکن فی سیکنڈ کی توقع رکھیں۔ یہ بیچ جابز، پس منظر کے agents اور نجی تجربات کے لیے ٹھیک ہے؛ یہ بہت سے ایک ساتھ صارفین کے لیے چیٹ کا تجربہ نہیں۔ اگر آپ زیادہ تر ہوسٹ شدہ ماڈل APIs کال کرتے ہیں تو آپ کے agent کو بہت کم چاہیے؛ دیکھیں AI agents کے لیے 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% سے اوپر رہے تو سائز درست ہے۔ اگر یہ باقاعدگی سے صفر تک پہنچے اور swap بڑھے تو اپ گریڈ کریں۔
پچھلے OOM کِلز بھی چیک کریں:
journalctl -k | grep -i "out of memory"
Swap: سیٹ بیلٹ، انجن نہیں
چھوٹے سرور پر 1–2 GB کی swap فائل سستی انشورنس ہے: کوئی پیکیج اپ گریڈ یا Docker بلڈ جسے لمحے بھر کو زیادہ میموری چاہیے، مارے جانے کے بجائے بچ جاتا ہے۔ لیکن اگر کوئی سروس swap میں رہے تو ہر درخواست ڈسک کا انتظار کرتی ہے۔ swap اچانک اضافوں کے لیے ہے۔ مسلسل swapping کا مطلب ہے کہ آپ کو اگلا پلان چاہیے۔
تو کتنی خریدیں؟
- 1 GB: ایک بوٹ، ایک چھوٹا API، ایک اسٹیٹک سائٹ۔
- 2 GB: ڈیٹا بیس یا Docker والی کسی بھی چیز کے لیے معقول ڈیفالٹ۔
- 4–6 GB: ایک مشین پر کئی سروسز، سرور پر بلڈز، ایک چھوٹا مقامی ماڈل۔
- 32–64 GB: صرف تب جب ایک بڑی چیز کو میموری میں رہنا ہو: 14B سے بڑا مقامی ماڈل، بڑا RAG انڈیکس، agents کا بیڑا۔ زیادہ میموری والے پلانز اسی کے لیے ہیں۔
اپنے اندازے سے ایک سائز چھوٹا شروع کریں، ایک ہفتہ free -h دیکھیں، اور اعداد کہیں تو اپ گریڈ کریں۔ EQVPS پر پلان اپ گریڈ آپ کا ڈیٹا برقرار رکھتا ہے اور صرف متناسب فرق لیتا ہے (پلان کی تبدیلی کیسے کام کرتی ہے)۔
تبصرے
ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔