אילו מודלי AI ניתן לארח באופן עצמי על שרת VPS?

מה קובע אילו מודלי AI ניתן לארח באופן עצמי

השאלה אילו מודלי AI ניתן לארח באופן עצמי מוכרעת על ידי נתון אחד: כמות ה-RAM בשרת. משפחת המודל וה-framework פחות חשובים מהשאלה האם ה-weights נכנסים בזיכרון עם מקום פנוי שנותר. פוסט זה מציג את החישובים הנדרשים כדי לקבוע זאת. התקנת סביבת הרצה היא משימה נפרדת, המכוסה ב-מדריך להרצת Ollama על גבי VPS.

שתי עלויות מכריעות את התשובה. ה-weights הם העלות הקבועה, הנקבעת לפי מספר הפרמטרים וה-quantisation. ה-context window הוא העלות המשתנה, וזהו המשתנה שאנשים שוכחים עד שמודל שנטען אתמול מסרב להיטען היום.

חישוב הנפח: ביטים לפרמטר

קובץ מודל מורכב כמעט כולו ממשקולות. כל משקולת נשמרת במספר מסוים של ביטים. קוונטיזציה (Quantisation) משמעותה שמירה של המשקולות במספר ביטים נמוך מהדיוק שבו הן אומנו, מה שגורם לאובדן דיוק קל אך חוסך זיכרון רב. גודל המודל נגזר ישירות מכך:

weights in GB = (parameters in billions x bits per weight) / 8

מודלים משוחררים בדרך כלל בדיוק של 16 ביט, כלומר 2 GB לכל מיליארד פרמטרים. זו הסיבה שכמעט אף אחד לא מריץ מודלים בדיוק המקורי שלהם על שרת VPS. אלו הן רמות הקוונטיזציה שתפגשו בפועל, עם ממוצע הביטים האמיתי לכל משקולת:

• Q8_0 מאחסן כ-8.5 ביטים למשקולת, כלומר בערך 1.1 GB לכל מיליארד פרמטרים.
• Q6_K מאחסן כ-6.6 ביטים, כלומר בערך 0.83 GB לכל מיליארד.
• Q5_K_M מאחסן כ-5.7 ביטים, כלומר בערך 0.71 GB לכל מיליארד.
• Q4_K_M מאחסן כ-4.8 ביטים, כלומר בערך 0.6 GB לכל מיליארד.

השתמשו ב-0.6 GB לכל מיליארד פרמטרים כמספר העבודה שלכם. Q4_K_M הוא ברירת המחדל ההגיונית עבור שרת המוגבל בזיכרון: אובדן האיכות בהשוואה ל-8 ביט הוא קטן ברוב המשימות, והקובץ קטן כמעט בחצי. מתחת ל-4 ביט האובדן גדל במהירות, לכן מודל 70B שנדחס ל-2 ביט בדרך כלל יספק תשובות פחות טובות ממודל 32B ב-4 ביט מאותו דור. כאשר הזיכרון מוגבל, עדיף להקטין את גודל המודל (Size class) לפני שיורדים מתחת ל-4 ביט.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

עמודת המשקולות לעיל מבוססת על כלל ה-0.6 GB למיליארד. קובצי GGUF אמיתיים קרובים מאוד לערך זה, כיוון ששכבות ה-embedding וה-output נשמרות בדיוק גבוה יותר משאר המודל. מודל 3B ב-4 ביט הוא בערך 1.8 GB. מודל 8B הוא 4.8 GB. מודל 32B הוא 19.2 GB, ומודל 70B הוא 42 GB.

מדוע אורך ההקשר צורך יותר זיכרון RAM מאשר המשקולות

ה־KV cache (מטמון מפתחות וערכים, מצב ה־attention שהמודל שומר עבור כל token בשיחה הנוכחית) הוא העלות השנייה בחשיבותה. הוא מוקצה בעת טעינת המודל, גודלו נקבע לפי אורך ההקשר המבוקש, והוא גדל בצורה ליניארית בהתאם לאורך זה.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

באורך ההקשר המוגדר כברירת מחדל ב־Ollama, מודל 8B צורך חצי ג'יגה-בייט עבור המטמון. ב־8192 tokens הוא צורך 1 GB. באורך הקשר של 128k, כפי שמפורסם בדף המודל, הוא צורך 16 GB, שזה יותר מפי שלושה ממשקל המודל עצמו. במודל 70B המצב הפוך: המטמון שלו ב־128k הוא 40 GB, פחות ממשקל המודל, כיוון ששימוש ב־grouped query attention מונע מהעלות לכל token לגדול בקצב שמתקרב למספר הפרמטרים.

אורך ההקשר המוגדר כברירת מחדל ב־Ollama הוא 4096 tokens בשרת מבוסס CPU בלבד. כאשר קיים GPU, המערכת בוחרת את ברירת המחדל מתוך ה־VRAM: 32k עבור נפח שבין 24 ל-48 GiB, ו-256k עבור 48 GiB ומעלה. ניתן להגדיל ערך זה באמצעות המשתנה OLLAMA_CONTEXT_LENGTH בשרת, ולאחר מכן לבדוק מהו הערך שקיבל המודל בפועל בעמודה CONTEXT בתוך ollama ps. החישובים המתמטיים שמאחורי הגדרה זו מפורטים ב-פוסט בנושא num_ctx ואורך הקשר.

קיימות שתי דרכים לצמצם את צריכת הזיכרון של המטמון. הגדירו את אורך ההקשר הדרוש לכם בפועל במקום להשתמש בערך המקסימלי המפורסם בדף המודל, שכן רוב עבודות הצ'אט והתכנות מסתפקות בטווח שבין 8k ל-32k. לחלופין, ניתן לבצע קוונטיזציה (quantisation) למטמון עצמו ל-8-bit, מה שיקטין את צריכת הזיכרון שלו בחצי, במחיר של ירידה מסוימת ביכולת השליפה מהקשרים ארוכים.

מודל תושב שומר על ה-RAM עד שגורם כלשהו פורק אותו

Ollama שומרת מודל בזיכרון למשך 5 דקות לאחר הבקשה האחרונה, ולאחר מכן פורקת אותו. ברירת מחדל זו מתאימה למחשב נייד אך שגויה עבור שרת, שבו כל בקשה ראשונה לאחר תקופת המתנה גוררת שוב את זמן הטעינה.

ollama ps
ollama stop qwen3:4b

ollama ps מציג אילו מודלים תושבים בזיכרון, כאשר עמודה SIZE מציגה כמה זיכרון הם תופסים ועמודה UNTIL מציגה מתי הם יפוגו. כדי להצמיד מודל לצמיתות, הגדירו את OLLAMA_KEEP_ALIVE=-1 בשירות. ערך של 0 יפרוק את המודל מיד עם סיום כל תגובה.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

שלחו הנחיה אחת, ולאחר מכן הריצו את ollama ps שוב כעבור עשר דקות. המודל עדיין מופיע ברשימה, וזו בדיוק המטרה: הוא תופס את ה-RAM ללא קשר לשאלה אם מישהו משתמש בו. מודל מוצמד אינו נחשב לקיבולת פנויה. בשרת VPS עם 16 GB, מודל 8B עם context של 8k תופס בערך 6 GB כל עוד השירות רץ, לכן יש לתכנן את גודל השרת לפי המודל בתוספת היישום שלכם, ולא לפי המודל בלבד. הצמדת מודל בזיכרון מכסה את השיקולים מול השהיית "התנעה קרה" (cold start).

מה ניתן להריץ על VPS עם 4 GB זיכרון

הקצו כ-1 GB עבור מערכת ההפעלה ושרת המודל, מה שמותיר כ-3 GB פנויים. נפח זה מספיק להרצת מודל בטווח של 1B עד 4B פרמטרים בקוונטיזציה של 4-bit, עם אורך הקשר (context) ברירת מחדל של 4096 טוקנים. נכון לאוגוסט 2026, קטגוריה זו כוללת את Llama 3.2 בגרסת 3B, את Qwen 3 בגרסאות 1.7B ו-4B, ואת המהדורות הקטנות של Gemma ו-Phi. התייחסו לשמות אלו כדוגמאות לגודל בלבד, ולא כהמלצות. השמות מתחלפים מדי כמה חודשים, אך החישוב המתמטי נותר קבוע.

צפו לקצב של כ-6 עד 14 טוקנים לשנייה. מודלים קטנים אלו מתאימים למשימות ממוקדות: סיווג, חילוץ תגיות, סיכומים קצרים, ושכתוב פסקה לפי סגנון כתיבה מוגדר. הם חלשים במשימות הדורשות הסקה רב-שלבית או בכתיבת קוד המשתרע על פני כמה קבצים, ושום טכניקת prompting לא תפתור זאת.

אופן הכשל הנפוץ ברמת משאבים זו הוא שימוש ב-swap. אם המודל אינו נכנס בזיכרון ה-RAM, מערכת Linux לא תסרב לטעון אותו. במקום זאת, היא תבצע paging של הזיכרון לדיסק. מכיוון שיצירת טוקן בודד דורשת קריאה של כל משקולות המודל פעם אחת, מהירות היצירה תצנח לשניות לכל טוקן. נטרו את free -h ואת העמודות si ו-so בתוך vmstat 1 בזמן שהמודל משיב. ערכים שאינם אפס ב-swap in וב-swap out במהלך היצירה מעידים על כך שהמודל גדול מדי עבור התוכנית שנבחרה.

מה מריצים על VPS עם 8 עד 16 GB זיכרון

כאן מודל באירוח עצמי הופך לשימושי באמת. על 8 GB ניתן להריץ מודל 7B או 8B בקוונטיזציה של 4 bits, שזה בערך 4.8 GB של משקולות, עם context של 8k. על 16 GB ניתן להריץ מודל 13B או 14B בקוונטיזציה של 4 bits, שזה בערך 8.4 GB, או להשאיר מודל 8B בקוונטיזציה של 8 bits אם אתם מעדיפים להשקיע את הזיכרון בדיוק (precision) ולא במספר הפרמטרים.

המהירות היא המכשול. מודל 8B על CPU מייצר בערך 3 עד 7 טוקנים לשנייה, ומודל 14B בערך 1.5 עד 3.5. אדם קורא בקצב של בערך 5 עד 10 טוקנים לשנייה, לכן מודל 8B על VPS מבוסס CPU מרגיש כמו צפייה בקלדן איטי. זה תקין עבור משימות רקע, אך מעייף עבור צ'אט אינטראקטיבי. הרצות מדודות של Qwen 3 בגרסת 8B ומעלה על VPS מראות איך זה נראה בפועל.

מה מריצים על VPS עם 32 עד 64 GB זיכרון

מודל 32B בקוונטיזציה של 4-bit תופס כ-19.2 GB, לכן הוא נכנס בתוכנית של 32 GB עם הקשר (context) קצר, ופועל בנוחות על 48 GB או 64 GB. מודל 70B ב-4-bit תופס כ-42 GB, ולכן הוא דורש 64 GB עוד לפני הוספת זיכרון מטמון (cache) כלשהו.

לאחר מכן, יש לבחון את המהירות באופן ריאלי. מודל 32B על גבי CPU פועל במהירות של 0.6 עד 1.5 טוקנים לשנייה, ומודל 70B במהירות של 0.2 עד 0.5. תשובה של 500 טוקנים ממודל 70B תיקח כעשרים דקות. אלו כלים לעיבוד אצוות (batch). הזינו להם תור של מסמכים במהלך הלילה, והמהירות לא תהיה קריטית. אם תציבו אותם מאחורי ממשק צ'אט, המהירות תהיה משמעותית מאוד.

ניתוב בשיטת Mixture of Experts משנה את החישוב הזה, וזהו פרט הארכיטקטורה היחיד ששווה ללמוד. מודל MoE מעביר כל טוקן דרך חלק קטן בלבד מהמשקולות שלו. מודל עם 30B פרמטרים בסך הכל ו-3B פרמטרים פעילים לכל טוקן דורש זיכרון של מודל 30B, אך מייצר טקסט במהירות הקרובה למודל 3B דחוס, כיוון שכל טוקן קורא רק את המומחים הפעילים. על שרת של 32 GB, מודל MoE במבנה כזה הוא שימושי הרבה יותר ממודל 30B דחוס. הכלל שיש לזכור: סך הפרמטרים קובע את דרישת הזיכרון, והפרמטרים הפעילים קובעים את המהירות.

מהי המהירות הריאלית של הסקת CPU?

יצירת טוקן אחד מחייבת קריאה של כל משקולת פעילה מהזיכרון פעם אחת. אין דרך לעקוף זאת, לכן מהירות היצירה ב-CPU נקבעת על ידי רוחב הפס של הזיכרון ולא על ידי מספר הליבות. התקרה היא תוצאה של חילוק: רוחב הפס הזמין של הזיכרון חלקי גודל המשקולות בבתים. שרת VPS שיתופי קטן מספק באופן ריאלי בין 10 ל-25 GB לשנייה לכל ה-vCPUs שלו, לכן מודל בגודל 4.8 GB יגיע לשיא של כ-2 עד 5 טוקנים לשנייה.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

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

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

הסיכום המודפס לאחר סיום התשובה מסתיים בשורה המכילה את eval rate: ... tokens/s. זוהי מהירות היצירה שלכם. התעלמו מההרצה הראשונה של הסשן, כיוון ש-load duration באותו סיכום כולל את קריאת המשקולות מהדיסק. מדידה נכונה של טוקנים לשנייה מסבירה כיצד לקבל נתון שראוי להשוואה.

שתי תוצאות מפתיעות אנשים בהקשר זה. הוספת vCPUs מפסיקה להועיל מהר מאוד, כיוון שאחרי כ-8 ליבות, הליבות הנוספות ממתינות לזיכרון במקום לבצע חישובים. ובתוכנית אירוח שיתופית, אותה פקודה תחזיר מספרים שונים משעה לשעה; זהו זמן גניבת CPU משכן רועש ולא משהו שהגדרתם בצורה שגויה.

קריאת ה-prompt שלכם היא משימה שונה מיצירת התשובה. עיבוד ה-prompt מוגבל על ידי כוח חישוב (compute bound), לכן הוא אכן משתפר עם הוספת ליבות, וזהו השלב שבו GPU משיג את היתרון המשמעותי ביותר. מסמך ארוך ידרוש מ-CPU דקות של קריאה, בעוד ש-GPU יסיים זאת בשניות.

מה משתנה כשמוסיפים GPU

החישוב האריתמטי אינו משתנה, רק המשאב שעליו הוא חל. נפח ה-VRAM הוא מגבלה קשיחה, לכן יש לחשב מה נכנס לפני השכירה:

• 8 GB של VRAM מכילים מודל 7B או 8B בקוונטיזציה של 4-bit עם הקשר (context) קצר.
• 16 GB מכילים מודל 14B ב-4-bit עם הקשר ממשי, או מודל 8B ב-8-bit.
• 24 GB מכילים מודל 32B ב-4-bit עם הקשר קצר.
• 48 GB ומעלה מכילים מודל 70B ב-4-bit עם מקום ל-cache ולעבודה במקביל.

כאשר מודל אינו נכנס בזיכרון, Ollama מפצל אותו: חלק מהשכבות ב-GPU, והשאר ב-CPU. ה-ollama ps מדווח על הפיצול בעמודת ה-PROCESSOR, בפורמט כגון 78%/22% CPU/GPU. יש להתייחס לכך כאזהרה ולא כתכונה. החלק שרץ על ה-CPU קובע את הקצב, שכן כל טוקן ממתין לשכבות הללו; לכן, מודל שרבע מהשכבות שלו ב-CPU ירוץ במהירות קרובה הרבה יותר למהירות CPU מאשר למהירות GPU. אם אתם רואים פיצול שלא תכננתם, צמצמו תחילה את אורך ההקשר. ה-cache הוא בדרך כלל הגורם שחורג מהמכסה.

עבודה במקביל (concurrency) היא סיבה נוספת להגדלת המשאבים. המשקולות משותפות בין בקשות בו-זמנית, אך כל בקשה פעילה זקוקה ל-KV cache משלה. לכן, עשרה משתמשים בו-זמנית על מודל 8B עם הקשר של 8k זקוקים לפי עשרה מ-1 GB של cache מעבר למשקולות המודל. הגשת שירות למשתמשים במקביל ממודל אחד באירוח עצמי מפרט היכן עובר הגבול הזה.

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

מה לא ניתן לארח באופן עצמי

קיימים שני מחסומים שונים בתחום זה, וכדאי להבין באיזה מהם נתקלתם.

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

המחסום השני הוא משקולות פתוחות שהן פשוט גדולות מדי. המודלים הפתוחים הגדולים ביותר מבוססים על ארכיטקטורת Mixture of Experts עם מאות מיליארדי פרמטרים בסך הכל. אותו כלל חל גם עליהם: מודל של 400B פרמטרים בקוונטיזציה של 4-bit דורש כ-240 GB עבור המשקולות בלבד, עוד לפני חישוב ה-cache. מדובר בחומרה ייעודית, ועלות השכרתה החודשית גבוהה משמעותית ממה שרוב האנשים מוציאים על אסימוני API בשנה שלמה. המאמר מה נדרש כדי לארח באופן עצמי מודל מסוג Kimi סוקר את הדרישות בפועל.

הקו המנחה הכנה בין השניים הוא: ארחו באופן עצמי כאשר העומס קבוע והמידע אינו אמור לעזוב את השרת שלכם. רכשו אסימונים כאשר העומס משתנה בפתאומיות, או כאשר איכות התשובה של מודלים מתקדמים היא הדבר שאתם באמת צריכים.

בדקו מה עומד לרשותכם לפני הבחירה

free -h
nproc
lscpu | grep 'Model name'

תכננו לפי עמודת ה-available ב-free -h, ולא לפי עמודת ה-total, כיוון ש-total כוללת זיכרון שהמערכת כבר מנצלת. החסירו כ-1 GB עבור מערכת ההפעלה ושרת המודלים. חלקו את היתרה ב-0.6 כדי לקבל את מספר הפרמטרים המקסימלי במיליארדים שניתן להחזיק ב-4 bits. לאחר מכן, החסירו את ה-KV cache עבור ההקשר (context) שבו אתם באמת מעוניינים. מה שנותר הוא התשובה שלכם, ובניגוד לרשימת שמות מודלים, היא אינה מתיישנת.

FAQ

כמה זיכרון RAM דרוש להרצת מודל 8B?

כ-4.8 GB עבור המשקולות בקוונטיזציה של 4 bit, בתוספת ה-KV cache עבור אורך ההקשר (context length) שלכם, ועוד כ-1 GB עבור מערכת ההפעלה ושרת המודל. בהקשר של 8192 טוקנים, ה-cache מוסיף כ-1 GB, לכן תוכנית של 8 GB תספיק, בעוד תוכנית של 4 GB לא תספיק. אם ברצונכם להשתמש במלוא ה-128k context שמצוין בדף המודל, ה-cache לבדו יצרוך 16 GB, ותזדקקו לתוכנית של 32 GB.

מדוע המודל איטי למרות של-VPS יש הרבה vCPUs?

מכיוון שיצירת טוקנים מוגבלת על ידי רוחב הפס של הזיכרון, ולא על ידי מספר הליבות. כל טוקן דורש שליפה של כל סט המשקולות הפעיל מה-RAM, כך שברגע שמספר ליבות מנצלות את ערוצי הזיכרון, הליבות הנותרות פשוט ממתינות. סיבה נפוצה נוספת היא swap. אם vmstat 1 מציג ערכים שאינם אפס ב-si וב-so בזמן שהמודל משיב, המשקולות אינן נכנסות ב-RAM וחלק מכל טוקן מוגש מהדיסק, מה שגורם לעיכוב משמעותי הרבה יותר ממה שנראה לעין.

האם חלון הקשר (context window) ארוך יותר באמת דורש יותר זיכרון?

כן, והגידול הוא ליניארי ביחס למספר הטוקנים. מודל 8B טיפוסי צורך כ-128 KiB של KV cache לכל טוקן, כך ש-8192 טוקנים עולים 1 GB ו-131072 טוקנים עולים 16 GB. ה-cache מוקצה בעת טעינת המודל ולא ככל שהשיחה מתארכת, לכן הגדרת 128k context משריינת את הזיכרון הזה באופן מיידי, גם אם כל prompt שתשלחו יהיה באורך 200 טוקנים בלבד.

האם כדאי להריץ מודל גדול ב-2 bits או מודל קטן יותר ב-4 bits?

בחרו במודל הקטן יותר ב-4 bits. האיכות יורדת באיטיות מ-8 bits ל-4, אך צונחת במהירות מתחת ל-4. לכן, מודל 70B שנדחס ל-2 bits בדרך כלל יספק תשובות פחות טובות ממודל 32B ב-4 bits מאותו דור מודלים. קוונטיזציה כבדה מתבטאת בחזרתיות ובאי-ביצוע הוראות במקום בהודעת שגיאה, מה שמקשה על זיהוי הבעיה ומטעה לחשוב שהבעיה ב-prompt. התייחסו ל-4 bits כאל רף מינימלי ושנו את מספר הפרמטרים במקום זאת.

האם ניתן לארח עצמאית מודל חזק כמו המודלים המסחריים הגדולים?

לא ב-VPS רגיל. המודלים הפתוחים החזקים ביותר מגיעים למאות מיליארדי פרמטרים, מה שדורש ב-4 bits מעל 200 GB של RAM עוד לפני ה-KV cache, והמודלים המסחריים החזקים ביותר כלל אינם מופצים. חומרה רגילה מתאימה להרצת מודל 8B עד 32B למשימה ספציפית, שבה מודל קטן וממוקד עם prompt מדויק לרוב משתווה למודל כללי. אם אתם זקוקים לאיכות קצה, השוו את עלות ה-API לעלות החומרה לפני הרכישה.