כמה RAM צריך עבור VPS להרצת סוכן קידוד?

כמה זיכרון RAM נדרש עבור VPS של סוכן קידוד?

התחילו עם 4 GB של RAM ו-2 vCPU עבור סוכן קידוד אחד שפועל תמיד ועובד על מאגר קוד (repository). עברו ל-8 GB ו-4 vCPU ברגע ששרת שפה (language server) או תהליך build של Docker מצטרפים לסשן, מה שקורה ברוב המאגרים כבר ביום הראשון. תהליך הסוכן עצמו קטן, לכן מה שממלא את השרת הוא שרשרת הכלים (toolchain) שהסוכן מפעיל עבורכם.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

כל שורה לעיל מניחה שהמודל רץ במקום אחר, מאחורי API שאתם קוראים לו דרך הרשת. הנחה זו מכריעה את כל שאלת הגודל, לכן החליטו לגביה תחילה.

האם אתם מריצים את הסוכן (agent) או את המודל?

סוכן קידוד שקורא למודל בענן הוא לקוח רשת עם shell מחובר. הוא שולח קבצים ותוכנית עבודה ל-API, ממתין לתשובה, ולאחר מכן עורך קבצים ומריץ פקודות באופן מקומי. בזמן ההמתנה הוא כמעט אינו צורך משאבי CPU. צריכת הזיכרון שלו נמדדת במאות מגה-בייטים, וזו הסיבה שמכונה עם CPU צנוע היא החומרה המתאימה.

הרצת המודל בעצמכם היא מוצר שונה על חומרה שונה. המשקולות (weights) נשארות בזיכרון כל עוד השרת פעיל. מודל של 7 מיליארד פרמטרים שעבר קוונטיזציה ל-4 ביטים דורש כ-5 GB עבור המשקולות בלבד, עוד לפני ה-key/value cache שגדל ככל שאורך ההקשר (context) עולה. בהרצה על CPU בלבד, vCPU משותף מפיק מספר בודד של tokens בשנייה, ומשימת סוכן אחת יכולה להפיק אלפי tokens; לכן, עבודה שלוקחת פחות מדקה מול API תיקח קרוב לשעה בהרצה מקומית. אם זה מה שאתם מחפשים, תכננו את המשאבים לפי VRAM (זיכרון וידאו על ה-GPU) וקראו את מה באמת מקבלים ב-VPS עם GPU במקום את הדף הזה.

כל מה שמופיע להלן מניח את תרחיש השימוש במודל ענן.

מה באמת צורך את הזיכרון

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

אלו הם נתונים טיפוסיים שפורסמו עבור פרויקטים בגודל בינוני. התייחסו אליהם כאל הערכה כללית, ולא כהבטחה לגבי הקוד שלכם.

הטבלה מכילה 6 שורות והסוכן הוא הזול ביותר. הוא צורך כ-250 MB במצב המתנה, כיוון שהוא מנהל שיחה ומחזיק מטמון קבצים קטן ותו לא. שרת שפה של TypeScript מגיע לכ-2000 MB בזמן אינדוקס, כיוון שהוא בונה גרף טיפוסים עבור כל קובץ שנגיש מתוך ה-tsconfig.json שלכם, ואז שומר את הגרף בזיכרון כדי להשיב לבקשה הבאה במהירות. rust-analyzer בסביבת עבודה גדולה עובר בדרך כלל את ה-4000 MB מאותה סיבה, עבור כל crate בסביבת העבודה.

Headless Chrome צורך כ-350 MB עבור הדפדפן בתוספת לשונית אחת, וכל לשונית נוספת היא תהליך מערכת הפעלה נפרד. הרצת בדיקות של Node עם ארבעה עובדים היא ארבעה תהליכי Node, ולכן השיא שלהם קרוב ל-3000 MB. בניית אימג' של Docker מגיעה לשיא של כ-2500 MB, כיוון שהבנייה מריצה את המהדר של הפרויקט שלכם בתוך המכולה בזמן שה-daemon כותב שכבות.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

קראו את עמודת ה-available ב-free -h, ולא את עמודת ה-free. לינוקס מקצה כל דף פנוי למטמון דיסק, לכן ה-free קטן במכונה תקינה לחלוטין ואינו מעיד על דבר. ה-available הוא מה שתהליך חדש יכול לקבל בפועל.

שלוש תצורות עבודה

מינימום נדרש: 4 GB RAM, 2 vCPU, 50 GB disk. סשן סוכן אחד, מאגר קוד אחד, שרת שפה אחד, וזמני בנייה שתצטרכו להמתין להם. תצורה זו עובדת, אך היא תפעיל את ה-out-of-memory killer ברגע שריצת בדיקות גדולה תתנגש עם שרת אינדוקס שפה. הוסיפו swap והגבילו את כמות ה-build workers.

נוח: 8 GB RAM, 4 vCPU, 100 GB disk. סוכן אחד, בתוספת Docker, ודפדפן headless להרצת בדיקות, עם מרווח נשימה לעומס בנייה אחד. זו התצורה שרוב המפתחים העצמאיים צריכים לרכוש. הכפלת כמות ה-vCPU מקצרת בערך בחצי את זמן ההמתנה לבנייה, וזה מורגש הרבה יותר מאשר זיכרון.

צוות: 16 GB RAM, 8 vCPU, 200 GB disk. ארבעה סשנים בו-זמנית, כל אחד עם ה-checkout ושרשרת הכלים (toolchain) שלו. תכננו לפי שיא העומס, כיוון שארבעה סוכנים במצב המתנה כמעט אינם עולים דבר, בעוד שארבע ריצות בדיקה בו-זמנית יעלו פי ארבעה מהעמודה הקודמת.

נכון לאוגוסט 2026, המעבר מהשורה הראשונה לאחרונה עולה בערך פי ארבעה מהמחיר החודשי בחיוב שנתי של VPS: ספרה בודדת של דולרים בחודש בתחתית, ועשרות דולרים בראש. בדקו את המחירון העדכני לפני התכנון, כיוון שהמספרים משתנים. השרת הוא לעיתים רחוקות החלק היקר. עבור כל מי שמפעיל סוכן מדי יום, חשבון ה-model API יעבור את עלות השרת במהירות, לכן הגבילו את ההוצאה המותרת לסוכן לפני שאתם מקטינים את השרת. עבור הבנייה עצמה, המדריך להרצת סוכן תכנות על VPS מכסה את הגדרת החשבון ושמירה על הסשן פעיל לאחר הניתוק.

מדוע הדיסק מתמלא לפני ה-RAM

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

סיכום השורות הללו מראה שדיסק בנפח 50 GB כמעט מלא עוד לפני שכתבת שורת קוד אחת. הפריט הבודד הגדול ביותר הוא Docker, שתופס סביב 20 GB, כיוון ש-BuildKit שומר כל שכבת ביניים של כל build עד שתורה לו להפסיק.

docker system df
docker builder prune --filter until=168h

הפקודה docker system df מציגה את השטח שניתן לפינוי לפי קטגוריות, לכן כדאי להריץ אותה לפני ואחרי. המסנן until=168h מוחק cache של build ישן משבוע, ושומר על ה-cache של השבוע הנוכחי – זה שעדיין חוסך לך זמן. הפקודה docker image prune -a מרחיקת לכת יותר ומסירה כל image שאינו בשימוש על ידי container, לכן צפה לכך שה-build הבא יבצע משיכה (pull) מחדש.

פרויקטי Node נכשלים בדרך מוזרה יותר. הפקודה npm install כותבת מאות אלפי קבצים זעירים, כך שמערכת הקבצים עלולה להישאר ללא inodes פנויים, בעוד ש-df -h עדיין מדווח על גיגה-בייטים פנויים. הכתיבה נכשלת אז עם השגיאה No space left on device על דיסק שנראה חצי ריק.

df -h /
df -i /

אם IUse% מציג 100, מחק את ספריות ה-node_modules של ענפים (branches) שאינך עובד עליהם יותר, או עבור ל-pnpm, ששומר כל גרסת חבילה פעם אחת ומבצע hard-link שלה לתוך כל פרויקט.

קבצי לוג הם הגורם השקט. סוכן שרץ תמיד כותב תעתיקי סשנים, וה-journal של systemd גדל כברירת מחדל ותופס נתח מהדיסק.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

הגדר את SystemMaxUse=200M בתוך /etc/systemd/journald.conf והרצ את sudo systemctl restart systemd-journald כדי להפוך את תקרת הנפח הזו לקבועה, שכן פעולת vacuum חד-פעמית רק מפנה שטח לזמן הנוכחי.

Swap: מה הוא מעניק ומה הוא מסתיר

כדאי להוסיף Swap, כיוון שהוא הופך חריגה קלה בזיכרון לעבודה איטית במקום לקריסת תהליך. הגדירו את גודלו למחצית מנפח ה-RAM, עד תקרה של כ-4 GB. אין סיבה ממשית לחרוג מכך בשרת המיועד ל-build.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

הפקודה swapon --show אמורה כעת להציג את /swapfile בגודל שהגדרתם. ללא השורה /etc/fstab, ה-Swap ייעלם לאחר ה-reboot הבא והשרת יחזור בשקט להתנהגותו הקודמת. אם fallocate משיב Operation not supported, צרו את הקובץ באמצעות sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 והמשיכו מ-chmod.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

ערך swappiness נמוך מורה ל-kernel לפנות את ה-disk cache לפני שהוא דוחף זיכרון של תוכניות לדיסק, מה ששומר על תגובתיות של language server.

כעת, החלק ש-Swap מסתיר: כאשר משימה זקוקה באמת ליותר זיכרון ממה שיש בשרת, ה-kernel מבלה את זמנו בהעברת דפי זיכרון בין ה-RAM לדיסק במקום להריץ את ה-build שלכם. שום דבר לא קורס. הכל זוחל, וה-load average מטפס בזמן שה-CPU נותר בטלה.

vmstat 1 10

מספרים קבועים שאינם אפס בעמודות si ו-so מעידים על ביצוע Swap מתמשך. הפתרון הוא הפחתת ה-concurrency או הוספת RAM, ולעולם לא הוספת Swap נוסף. בשרת קטן, sudo apt install -y zram-tools מספק Swap דחוס השמור בתוך ה-RAM, המוגדר ב-/etc/default/zramswap. הוא מהיר משמעותית מקובץ Swap, והוא משתמש ב-RAM כדי לחסוך RAM; לכן הוא מסייע בניהול דפים קרים, אך לא ב-build שזקוק לזיכרון עבודה אמיתי.

מדוע סוכן הקידוד שלכם נראה כאילו הוא קפוא

זוהי התקלה שמאובחנת באופן השגוי ביותר בשרתי סוכנים קטנים. פקודה אינה מחזירה דבר, הסוכן ממתין, והסשן נראה קפוא. התהליך חוסל על ידי מנגנון ה-OOM (Out-Of-Memory) killer של ה-kernel. הוא קיבל SIGKILL, ולכן לא יכול היה להדפיס שגיאה, לרוקן לוג, או להודיע לסוכן מה קרה. הסוכן רואה תוצאה ריקה ללא הודעת יציאה.

ה-kernel אכן מתעד זאת:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

שורה אמיתית נראית כך:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss מייצג את כמות הזיכרון שהתהליך תפס ברגע מותו. שימו לב איזה תהליך נבחר: ה-kernel מדרג תהליכים בעיקר לפי צריכת הזיכרון שלהם, ולכן הוא לרוב יחסל את ה-language server או את הסוכן במקום את תהליך ה-build שגרם לחריגה. זו בדיוק הסיבה שהתסמין נראה כאילו "הסוכן קרס".

בתוך Docker, אותו אירוע מותיר עקבות ברורים יותר. המכולה יוצאת עם קוד 137, שהוא 128 ועוד סיגנל 9.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true מאשר שהמכולה הגיעה למגבלת הזיכרון שלה במקום לקרוס מעצמה.

הפתרון הוא להציב תקרה לפקודה התובענית, כך שה-build ימות במקום הסוכן:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

ה-build יחוסל כעת ב-4 GB והסוכן ישרוד, מה שהופך קפיאה מסתורית לפקודה שנכשלה באופן רגיל עם קוד יציאה קריא. פעולה זו דורשת systemd user session, לכן הריצו את loginctl enable-linger $USER בשרת שאליו אתם ניגשים רק דרך SSH. הפקודה MemoryHigh= תבצע throttling לתהליך בסף המוגדר במקום לחסל אותו, מה שלעיתים קרובות הוא הגדרה עדיפה עבור build שאתם מעדיפים שיסתיים לאט מאשר שלא יסתיים כלל.

הגבלת זיכרון באמצעות Compose

אם כלי העבודה של ה-agent רצים בתוך מכולות, הגדירו את התקרה בקובץ ה-Compose כדי שתחול בכל הרצה.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

גרסה v2 של Docker Compose מחילה את deploy.resources.limits על docker compose up רגיל, ללא צורך ב-swarm mode. המפתח הישן mem_limit: 2g עדיין עובד. המדריך המלא להגבלות זיכרון ב-Compose מפרט לגבי הקצאות (reservations) ומה קורה כאשר מכולה מגיעה לתקרת הזיכרון שלה. אם Docker עדיין לא מותקן על השרת, התקינו Docker על ה-VPS תחילה.

מלכודת אחת גוזלת מאנשים זמן רב. מכולה שמוגבלת ל-2 GB עדיין קוראת את ה-/proc/meminfo של המארח ואת מספר ה-CPU שלו, כיוון שאף אחד מהם אינו נמצא ב-namespace נפרד. מריץ בדיקות (test runner) שבוחר את מספר ה-workers לפי מספר ה-CPU יפעיל שמונה workers בתוך מכולה של 2 GB על שרת עם שמונה vCPU, ואז יקרוס עם שגיאה 137. הגדירו את המספרים ידנית:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

הערך --max-old-space-size מצוין ב-MB ומגביל את ה-V8 heap. הגדירו אותו נמוך מהמגבלה של המכולה כדי ש-Node תזרוק שגיאה קריאה במקום להיעלם:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

הודעה זו היא יתרון, כיוון שהיא מציינת את המגבלה שנחצתה ואת התהליך שחצה אותה. ה-OOM killer לעולם לא עושה זאת.

הרצת מספר סשנים של סוכן על שרת יחיד

תכננו לפי סשן, לא לפי משתמש. שני סשנים על אותו מאגר משמעותם שני שרתי שפה, שני סטים של מטמוני בנייה (build caches) בזיכרון, ושתי הרצות בדיקה אם שני הסוכנים הופכים לפעילים בו-זמנית. זו הסיבה שהשורה של הצוות קופצת ל-16 GB.

הגדירו לכל משתמש תקרה קשיחה כדי שסשן אחד שיוצא משליטה לא יפיל את כל השרת:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

החליפו את 1001 ב-UID שהודפס על ידי id -u. הפקודה systemctl show אמורה להדפיס MemoryMax=6442450944 ברגע שהמשתמש התחבר. כאשר כל התהליכים בסשן של אותו משתמש עוברים את ה-6 GB, ה-kernel מסיים תהליך בתוך ה-slice שלו, ושאר הסשנים ממשיכים לעבוד כסדרם. עבור סוכן שרץ כשירות ולא בתוך טרמינל, הציבו את MemoryMax= בקובץ ה-unit שלו במקום זאת; זהו הדפוס שיש לעקוב אחריו כאשר אתם מארחים סוכן כשירות קבוע.

FAQ

האם 2 GB של RAM מספיקים עבור סוכן פיתוח (coding agent)?

עבור תהליך הסוכן עצמו, כן. עבור העבודה שהוא מבצע, לרוב לא. הסוכן צורך בקירוב 250 MB, אך שרת שפה (language server) עבור TypeScript יכול להגיע ל-2000 MB במאגר קוד בינוני, וזה לבדו דוחף שרת של 2 GB לשימוש ב-swap. נפח של 2 GB מתאים לעריכת קובצי הגדרה וסקריפטים קטנים. השתמשו ב-4 GB כרף מינימלי לכל פעולה הכוללת הידור (compilation) או הרצת חבילת בדיקות.

האם אני זקוק ל-GPU כדי להריץ סוכן פיתוח על VPS?

לא אם הסוכן פונה למודל ענן דרך API. עומס עבודה כזה מוגבל על ידי רוחב פס של רשת, לכן VPS מבוסס CPU הוא המכונה המתאימה, בעוד ש-GPU יישאר לא פעיל במחיר גבוה בהרבה. אתם זקוקים ל-GPU רק כאשר המודל עצמו רץ על אותה מכונה, ואז השאלה משתנה מ-RAM ל-VRAM ולגודל המודל.

כמה swap עלי להוסיף ל-VPS של סוכן?

מחצית מנפח ה-RAM, עד כ-4 GB. ה-swap מגן עליכם מפני חריגה קצרה, כיוון שה-kernel יכול להעביר דפים (pages) לא פעילים לדיסק במקום להרוג תהליך. הוא אינו מוסיף זיכרון עבודה זמין. אם vmstat 1 מציג תעבורה קבועה בעמודות si ו-so, המכונה מבצעת thrashing, והפתרון הוא הפחתת מספר העובדים המקבילים או שדרוג לתוכנית גדולה יותר.

מדוע סוכן הפיתוח שלי קופא באמצע תהליך build?

תהליך ה-build נהרג כמעט בוודאות על ידי ה-OOM killer של ה-kernel, ששולח SIGKILL; לכן לא מודפס דבר והסוכן ממתין ל-pipe שלעולם לא יתמלא. הריצו את sudo dmesg -T | grep -i "killed process" ובדקו את שם התהליך ואת ערך ה-anon-rss שלו. פתרו זאת על ידי הגבלת ה-build בעזרת systemd-run --user --scope -p MemoryMax=4G והפחתת מספר העובדים (workers), או על ידי מעבר לשכבת RAM גבוהה יותר.