بیشتر مردم RAM را حدس میزنند. یا «محض احتیاط» خیلی بیشتر از لازم میخرند یا ساعت ۳ بامداد با OOM killer آشنا میشوند. حافظه در واقع یکی از سادهترین چیزها برای اندازهگیری است، چون وقتی اعداد تقریبی را بدانید، کاربردها قابل پیشبینیاند. این هم اعداد، از سرور ۱ گیگابایتی برای بات تا سرورهای ۶۴ گیگابایتی که مردم وقتی میخواهند یک مدل بزرگ را محلی اجرا کنند دنبالش میگردند.
اعداد تقریبی بر اساس کاربرد
اینها ارقام واقعی حالت پایدار در یک راهاندازی معمولی هستند، نه حداقلهای اعلامشده سازندگان.
| کاربرد | RAM واقعی مصرفی | پلن مناسب |
|---|---|---|
| بات Telegram/Discord (Python، Node.js) | ۱۰۰ تا ۳۰۰ مگابایت | Nano ۱ گیگابایت |
| سایت ایستا + Caddy/Nginx | ۵۰ تا ۱۵۰ مگابایت | Nano ۱ گیگابایت |
| WordPress + MariaDB، ترافیک معمولی | ۰٫۸ تا ۱٫۵ گیگابایت | Micro-IP ۲ گیگابایت |
| PostgreSQL برای یک اپلیکیشن کوچک | ۰٫۵ تا ۲ گیگابایت (با shared_buffers خودتان تعیین میکنید) | Micro / Small |
| n8n با چند گردش کار | ۰٫۵ تا ۱٫۵ گیگابایت | Micro ۲ گیگابایت |
| میزبان Docker با ۵ تا ۱۰ سرویس کوچک | ۲ تا ۴ گیگابایت | Small ۴ گیگابایت |
| Coolify + بیلدها + پایگاهداده | ۳ تا ۴ گیگابایت | Small-IP ۴ گیگابایت |
| LLM 7–8B، ۴ بیت، استنتاج روی CPU | ۵ تا ۶ گیگابایت | Medium ۶ گیگابایت |
| LLM 14B، ۴ بیت | حدود ۱۰ گیگابایت | Pro-32 |
| LLM 32B، ۴ بیت | حدود ۲۰ گیگابایت | Pro-32 |
| LLM 70B، ۴ بیت | حدود ۴۰ تا ۴۵ گیگابایت | Pro-48 / Pro-64 |
به دو چیز دقت کنید. اول، فاصله بین کاربردهای «معمولی» و LLMها عظیم است: یک بات و یک مدل 70B دویست برابر با هم فرق دارند. دوم، بیشتر سرویسها با ۱ تا ۴ گیگابایت خوب کار میکنند؛ مردم بیش از حد میخرند چون برای آیندهای اندازه میگیرند که بهندرت میرسد.
فرمول LLM
برای مدلهای زبانی یک تخمین ساده وجود دارد: تعداد پارامترها × بیت برای هر وزن ÷ ۸، به علاوه سربار. یک مدل 8B با حدود ۴٫۵ بیت (یک کوانتیزهسازی معمول Q4) میشود ۸ × ۴٫۵ ÷ ۸ ≈ ۴٫۵ گیگابایت وزن. ۱ تا ۲ گیگابایت برای پنجره context (کش KV با طول context بزرگ میشود) و محیط اجرا اضافه کنید، به ۵ تا ۶ گیگابایت میرسید.
بخش صادقانه: روی سرورهای فقط-CPU، حافظه فقط نیمی از ماجراست. برای مدلهای 7–8B روی چند vCPU انتظار تعداد تکرقمی توکن در ثانیه داشته باشید و برای 70B حدود یک توکن در ثانیه. این برای کارهای دستهای، agentهای پسزمینه و آزمایشهای خصوصی خوب است؛ اما تجربه گفتگو برای کاربران همزمان زیاد نیست. اگر بیشتر APIهای مدلهای میزبانیشده را صدا میزنید، agent شما خیلی کمتر لازم دارد؛ اندازه VPS برای agentهای هوش مصنوعی را ببینید.
به جای حدس زدن، بسنجید
اگر از قبل سرور دارید، اعداد جلوی چشمتان است:
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 در شلوغترین ساعت شما بالای حدود ۲۵٪ بماند، اندازه درست است. اگر مرتب به صفر برسد و swap بزرگ شود، ارتقا دهید.
کشته شدنهای قبلی به خاطر OOM را هم بررسی کنید:
journalctl -k | grep -i "out of memory"
Swap: کمربند ایمنی، نه موتور
یک فایل swap ۱ تا ۲ گیگابایتی روی سرور کوچک بیمهای ارزان است: ارتقای یک بسته یا بیلد Docker که لحظهای حافظه بیشتری میخواهد به جای کشته شدن زنده میماند. اما اگر سرویسی در swap زندگی کند، هر درخواست منتظر دیسک میماند. Swap برای جهشهاست. swap مداوم یعنی به پلن بعدی نیاز دارید.
خب، چقدر بخرید؟
- ۱ گیگابایت: یک بات، یک API کوچک، یک سایت ایستا.
- ۲ گیگابایت: پیشفرض معقول برای هر چیزی که پایگاهداده یا Docker دارد.
- ۴ تا ۶ گیگابایت: چند سرویس روی یک سرور، بیلد روی سرور، یک مدل محلی کوچک.
- ۳۲ تا ۶۴ گیگابایت: فقط وقتی یک چیز بزرگ باید در حافظه زندگی کند: مدل محلی بزرگتر از 14B، ایندکس بزرگ RAG، ناوگان agentها. پلنهای پرحافظه برای همیناند.
یک اندازه کوچکتر از آنچه حستان میگوید شروع کنید، یک هفته free -h را زیر نظر بگیرید و اگر اعداد گفتند ارتقا دهید. در EQVPS ارتقای پلن دادههای شما را نگه میدارد و فقط مابهالتفاوت متناسب را میگیرد (تغییر پلن چطور کار میکند).
نظرات
هنوز نظری نیست. اولین نفر باشید.