רוב האנשים מנחשים את ה-RAM. הם או קונים הרבה יותר מדי «ליתר ביטחון» או מגלים את ה-OOM killer ב-3 לפנות בוקר. זיכרון הוא בעצם מהדברים הקלים ביותר לתכנון, כי עומסי עבודה צפויים ברגע שיודעים את המספרים בקירוב. הנה הם, משרת בוט של 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 עם 5–10 שירותים קטנים | 2–4 GB | Small 4 GB |
| Coolify + בילדים + מסד נתונים | 3–4 GB | Small-IP 4 GB |
| LLM 7–8B, 4 ביט, הסקה על CPU | 5–6 GB | Medium 6 GB |
| LLM 14B, 4 ביט | ~10 GB | Pro-32 |
| LLM 32B, 4 ביט | ~20 GB | Pro-32 |
| LLM 70B, 4 ביט | ~40–45 GB | Pro-48 / Pro-64 |
שני דברים לשים לב אליהם. ראשית, הקפיצה בין עומסים «רגילים» ל-LLMs עצומה: בוט ומודל 70B שונים בפקטור של מאתיים. שנית, רוב השירותים מסתדרים עם 1–4 GB; אנשים קונים יותר מדי כי הם מתכננים לעתיד שכמעט לא מגיע.
הנוסחה ל-LLM
למודלי שפה יש הערכה פשוטה: פרמטרים × ביטים למשקל ÷ 8, ועוד תקורה. מודל 8B בכ-4.5 ביט (כימות Q4 טיפוסי) הוא 8 × 4.5 ÷ 8 ≈ 4.5 GB של משקלים. הוסיפו 1–2 GB לחלון ה-context (מטמון ה-KV גדל עם אורך ה-context) ולסביבת הריצה, ומגיעים ל-5–6 GB.
החלק הכן: בשרתים עם CPU בלבד, זיכרון הוא רק חצי מהסיפור. צפו למספר חד-ספרתי של טוקנים בשנייה למודלי 7–8B על כמה vCPU, ובערך לטוקן אחד בשנייה ל-70B. זה בסדר לעבודות אצווה, לסוכנים ברקע ולניסויים פרטיים; זו לא חוויית צ'אט להרבה משתמשים בו-זמנית. אם אתם בעיקר קוראים ל-APIs של מודלים מתארחים, הסוכן שלכם צריך הרבה פחות; ראו גודל VPS לסוכני AI.
למדוד במקום לנחש
אם כבר יש לכם שרת, המספרים ממש שם:
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: חגורת בטיחות, לא מנוע
קובץ swap של 1–2 GB בשרת קטן הוא ביטוח זול: שדרוג חבילה או בילד של Docker שצריך לרגע יותר זיכרון שורד במקום להיהרג. אבל אם שירות חי ב-swap, כל בקשה מחכה לדיסק. swap זה לקפיצות. החלפה מתמדת אומרת שצריך את התוכנית הבאה.
אז כמה לקנות?
- 1 GB: בוט אחד, API קטן אחד, אתר סטטי.
- 2 GB: ברירת המחדל הסבירה לכל דבר עם מסד נתונים או Docker.
- 4–6 GB: כמה שירותים על מכונה אחת, בילדים על השרת, מודל מקומי קטן.
- 32–64 GB: רק כשדבר גדול אחד חייב לחיות בזיכרון: מודל מקומי מעל 14B, אינדקס RAG גדול, צי סוכנים. בשביל זה קיימות התוכניות עתירות הזיכרון.
התחילו מידה אחת קטן ממה שהבטן אומרת, עקבו אחרי free -h שבוע, ושדרגו אם המספרים אומרים. ב-EQVPS שדרוג תוכנית שומר את הנתונים שלכם וגובה רק את ההפרש היחסי (איך שינוי תוכנית עובד).
תגובות
אין עדיין תגובות. היו הראשונים.