ज़्यादातर लोग 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-बिट, 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 पर प्लान अपग्रेड करने से आपका डेटा बना रहता है और सिर्फ़ आनुपातिक अंतर लिया जाता है (प्लान बदलना कैसे काम करता है)।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।