הרצת Qwen 27B על שרת VPS עם Ollama: מדריך מעשי

האם ניתן להריץ את Qwen 3.8 27B על שרת VPS ללא GPU?

כדי להריץ את Qwen 3.8 27B על שרת VPS, עליכם להשתמש בתג מודל קיים. נכון ל-4 באוגוסט 2026, בספריית Ollama לא קיים ערך qwen3.8 כלל. התג הקרוב ביותר ששוחרר עבור מודל 27B הוא qwen3.6:27b: מודל בעל 27.8 מיליארד פרמטרים, קוונטיזציה מסוג Q4_K_M, ורישיון Apache 2.0. כל פקודה וכל מספר להלן מתייחסים לתג זה בגרסת Ollama v0.32.5, שפורסמה ב-27 ביולי 2026.

התשובה הקצרה היא כן, על שרת VPS עם 32 GB RAM ומעלה, אך הביצועים יהיו איטיים. מודל 27B צפוף בקוונטיזציה Q4 דורש כ-17 GB של RAM עבור המשקולות בלבד, עוד לפני אחסון טוקן אחד של הקשר (context). נתון זה פוסל לחלוטין תוכניות של 8 GB ו-16 GB. בשרת VPS טיפוסי עם DDR4 בעל שני ערוצים, התקרה היא בערך 3 טוקנים לשנייה, מהירות איטית יותר מקצב קריאה ממוצע.

מאיפה מגיע המספר 3.8? ככל הנראה ממספר הפרמטרים. דף ה-Ollama עבור qwen3.6:27b מדווח על 27.8B פרמטרים, וקל לזכור את 27.8 כ-3.8. קיים גם qwen3.5:27b, שהוא אותו מבנה Q4_K_M מהגרסה הקודמת. בדקו את הרשימה העדכנית לפני העתקת פקודה כלשהי ב-דף התגים של Ollama qwen3.6. אם גרסה אמיתית של qwen3.8 תשוחרר בעתיד, החישוב כאן עדיין יהיה תקף, שכן הוא תלוי במספר הפרמטרים ובמספר הביטים לכל משקולת ולא במספר הגרסה.

איזה תג (tag) של Ollama למשוך, וכיצד לבדוק זאת

משיכת תג שאינו קיים מניבה שגיאה ברורה, לכן קל להכריע בעניין ישירות על השרת.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show מדפיס את הארכיטקטורה, מספר הפרמטרים, אורך ההקשר (context length) והקוונטיזציה (quantisation) עבור התג שברשותך בפועל. אם שורת הפרמטרים מציגה 27.8B ושורת הקוונטיזציה מציגה Q4_K_M, סימן שיש בידך את הגרסה שעבורה נכתב מדריך זה. הספרייה כוללת גם את qwen3.6:27b-q8_0 ו-qwen3.6:27b-bf16 עבור אותם משקלים בדיוק ברמת דיוק גבוהה יותר, בתוספת קבוצת תגים מסוג 35b-a3b שהם מודלי MoE (תערובת מומחים) ומתנהגים בצורה שונה מאוד על גבי ה-CPU. פירוט נוסף על כך בהמשך.

חישוב כמות פרמטרים לפי בתים למשקל

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

הנוסחה מורכבת משורה אחת. בתים למשקלים = פרמטרים * סיביות למשקל / 8. בחישוב נקי של 4 סיביות, 27.8 מיליארד פרמטרים יתפסו 13.9 GB. התג Q4_K_M ששוחרר הוא בגודל 17 GB, מה שמתרגם בפועל ל-4.89 סיביות למשקל.

הפער הזה אינו שגיאה. פורמטים מסוג K-quant אינם שומרים כל טנזור ברוחב הנומינלי. הטנזורים שמאבדים הכי הרבה איכות תחת דחיסה נשמרים ב-5 או 6 סיביות, ושכבות ה-token embedding והפלט נשמרות בדרך כלל ב-Q6_K או Q8_0. השם של הפורמט מייצג ממוצע, והממוצע נע סביב 4.9. אותו אפקט מופיע בקצה השני של הסקאלה: 56 GB עבור BF16 הם 16.1 סיביות למשקל ולא 16 עגול, כיוון שהקובץ מכיל גם מטא-דאטה וטבלת embedding בדיוק מלא.

עבור Q5_K_M לא פורסם תג עבור מודל זה, לכן השורה של 19.8 GB מחושבת לפי 5.7 סיביות למשקל המקובלות בפורמט זה, ולא לפי מדידה. Q8_0 כמעט מכפיל את Q4 ל-30 GB. בשרת מבוסס CPU בלבד, הכפלה זו מכפילה את תעבורת הזיכרון לכל token, ולכן היא גם מקצצת בערך בחצי את כמות ה-tokens לשנייה. Q4_K_M הוא ברירת המחדל הנכונה כאן מהסיבה הזו בלבד.

עלות ה-KV cache ככל שההקשר (context) גדל

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

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

הנתונים הללו מניחים את המבנה ש-Qwen השתמשה בו בדגמים הצפופים האחרונים שלה במחלקת גודל זו: 64 שכבות, 8 ראשי מפתח/ערך תחת GQA (grouped-query attention), וממד ראש של 128. זה מסתכם ב-256 KiB לכל token בפורמט f16, כלומר 8 GB ב-32k tokens ו-32 GB ב-128k. אל תסתמכו על החישובים שלי יותר מאשר על המכונה שלכם. טענו את המודל וקראו את עמודת ה-SIZE ב-ollama ps, שמדווחת על משקולות בתוספת מטמון ותקורות כנתון אחד.

זו הסיבה שהקשר של 256K המופיע בכרטיס המודל הוא כותרת ולא תוכנית עבודה. מילוי שלו ב-f16 יעלה 64 GB של מטמון מעבר למשקולות, על מכונה שכבר השקיעה 17 GB במשקולות. Ollama לא מעניקה לכם את מלוא החלון כברירת מחדל. היא טוענת חלון קטן בהרבה, ואתם מגדילים אותו באופן מכוון באמצעות OLLAMA_CONTEXT_LENGTH. הגדילו אותו בשלבים ובדקו את ollama ps לאחר כל שינוי.

שתי הגדרות מקצצות את המטמון בחצי או יותר. OLLAMA_KV_CACHE_TYPE=q8_0 שומר את המטמון ב-8 ביט במקום ב-16, ומוריד 32k tokens מ-8 GB ל-4 GB. זה דורש flash attention, לכן הגדירו גם את OLLAMA_FLASH_ATTENTION=1, וודאו את הירידה ב-ollama ps במקום להניח שהיא התבצעה. OLLAMA_NUM_PARALLEL=1 חשוב באותה מידה. Ollama יכולה לשרת כמה בקשות בו-זמנית, וכל חריץ (slot) מקבל נתח הקשר משלו, כך שהשארת המקביליות בברירת המחדל מכפילה בשקט את המטמון שתקצבתם. אם יותר מאדם אחד ישתמש במכונה הזו, הכפל הזה הוא המקום שבו מתחילות הצרות, ו-מספר המשתמשים בו-זמנית שמודל באירוח עצמי יכול לשרת נקבע על ידי חריצי מטמון ועומק תור הרבה לפני שהוא נקבע על ידי מספר הליבות.

מה נכנס ב-8, 16, 32 ו-64 GB של RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

התייחסו לשני המספרים כאל אלפי טוקנים של הקשר (context) שנכנסים לצד המשקולות, ב-cache מסוג f16, על שרת Linux ללא ממשק גרפי (headless) עם כ-1.5 GB פנויים עבור מערכת ההפעלה ומרווח ביטחון קטן מעבר לכך. אפס משמעו שהמשקולות עצמן אינן נכנסות, ולכן דבר אינו נכנס.

8 GB ו-16 GB אינם גבוליים. 17 GB של משקולות לא ייכנסו ל-16 GB של RAM, ושום שינוי בהגדרות ההקשר לא ישנה זאת. גם הוספת swap לא תפתור את הבעיה. Ollama מבצעת מיפוי זיכרון (memory-map) לקובץ ה-GGUF, כך שברגע שדפי הזיכרון הפעילים חורגים מה-RAM, ה-kernel מתחיל לפנות אותם ולקרוא אותם שוב מהדיסק; כל טוקן גורר קריאה של גיגה-בייטים מהדיסק. השרת יציג iowait גבוה וייצר פחות מטוקן אחד לשנייה.

32 GB הם נקודת הכניסה. המשקולות תופסות 17 GB ונותרים לכם בערך 13 GB פנויים, המכסים כ-32k טוקנים של הקשר f16 עם מרווח ביטחון. משקולות Q8_0 בנפח 30 GB אינן נכנסות בשכבה זו כלל.

64 GB הם נפח נוח. Q4 מותיר מקום לכ-128k טוקנים של הקשר, ומשקולות Q8_0 נכנסות עם כ-64k טוקנים פנויים אחריהן. לפני שמשלמים על 64 GB כדי לקבל Q8, ודאו שאתם מבינים מה אתם קונים: פלט מעט טוב יותר בחצי מהמהירות, על מכונה שהייתה איטית ממילא. עבור כמעט כולם, Q4 עם הקשר ארוך יותר הוא עסקה משתלמת יותר.

מהי מהירות ה-inference של מעבד (CPU) ב-VPS?

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

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

אלו הם תקרות תיאורטיות, לא מדידות בפועל. הפלט האמיתי מגיע בערך ל-50 עד 70 אחוז מהנתון המוצג, כיוון שזמן השהיה (latency) של הזיכרון ו-prefetching לא מושלם מונעים הגעה לשיא התיאורטי. שרת VPS עם ערוץ כפול של DDR4-3200 מוגבל ל-3 טוקנים לשנייה, לכן צפו ל-2 בערך. שרת עם ערוץ כפול של DDR5-4800 מוגבל ל-4.5, לכן צפו ל-3 בערך.

שרתים גדולים מגיעים עם אזהרה. פלטפורמת EPYC עם 12 ערוצים מציעה 460.8 GB/s ותקרה של 27.1 טוקנים לשנייה, אך אתם לא שוכרים שרת EPYC שלם. רוחב פס של זיכרון הוא משאב שרת משותף לכל הדיירים על אותה מכונה, לכן פרוסת 8 vCPU לא מקבלת 12 ערוצים של רוחב פס בלעדי. מדריכים המתמקדים ב-GPU מתעלמים מכך לחלוטין, וזו הסיבה ששתי תוכניות VPS עם מספר vCPU זהה יכולות להציג הבדל של פי 3 במהירות על אותו מודל.

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

עיבוד ה-prompt מתנהג אחרת. שלב ה-prefill, המעבר על הקלט שלכם לפני הופעת הטוקן הראשון, מוגבל על ידי כוח חישוב ולא על ידי רוחב פס, לכן הוא כן משתפר עם יותר ליבות. ההשפעה המעשית היא השהיה ארוכה לפני שהפלט מתחיל ב-prompt גדול, ולאחריה קצב יציב ואיטי כפי שצוין לעיל. מדדו את שני החלקים בנפרד בעזרת --verbose, שמדפיס prompt eval rate ו-eval rate עבור כל בקשה.

אם מודל 27B דחוס הוא איטי מדי, בדקו את תגיות ה-qwen3.6:35b-a3b לפני שתוותרו על ה-CPU. אלו מפעילות בערך 3 מיליארד פרמטרים לכל טוקן במקום את כל 27.8 המיליארדים, כך שתעבורת הזיכרון לכל טוקן יורדת בסדר גודל, למרות שהקובץ על הדיסק גדול יותר. אתם מקריבים נפח RAM עבור מהירות. הבחירה בסביבת הריצה חשובה גם כאן, ו-Ollama ו-llama.cpp חושפים בקרות כוונון CPU שונות עבור אותו קוד inference בסיסי.

מתי כדאי לשכור זמן GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

אותה נוסחה המיושמת על רוחב הפס של זיכרון ה-GPU מניבה קטגוריה שונה של תשובות. כרטיס צרכני עם 24 GB מוגבל לתקרה של 59 טוקנים לשנייה עבור משקלים אלו. כרטיס מרכז נתונים (data centre) מודרני מגיע ל-197. זהו אינו פער שניתן לגשר עליו באמצעות כוונון מספר ה-threads. הכרטיס מריץ את הזיכרון שלו ב-1008 GB/s, בעוד ה-VPS שלכם פועל בעשרות בודדות.

לכן, הגדירו את הגבול לפי עומס העבודה ולא לפי העדפה אישית. הסקה (inference) על גבי CPU היא הפתרון הנכון כאשר העבודה היא אסינכרונית ואף אחד אינו ממתין לה: סיכום לילי של ערימת מסמכים, או משימת סיווג לילית שרצה בזמן שאתם ישנים. שכרו GPU ברגע שאדם ממתין לפלט, או ברגע שבקשות מגיעות בקצב מהיר יותר מאחת ל-30 שניות, כיוון שלשרת מבוסס CPU בלבד אין מרווח תמרון לביצוע עיבוד אצוות (batching) והתור פשוט ילך ויגדל.

השוואת העלויות פחות מובנת מאליה מכפי שהיא נראית. שרת VPS עם 64 GB מחויב בכל שעה בחודש, בין אם המודל טעון ובין אם לא, בעוד שמופע GPU מחויב רק עבור השעות שבהן הוא פעיל. אם השימוש בפועל הוא שעתיים ביום, ה-GPU השכור יכול להיות גם מהיר יותר וגם זול יותר. חשבו תחילה את מחזור העבודה שלכם, ורק אז תמחרו אותו. בחירת VPS עם GPU מכסה את מה שיש לבדוק במופע עצמו, ו-vLLM עוקף את Ollama ברגע שמגישים בקשות במקביל על גבי GPU כיוון שהוא מבצע להן batching בצורה תקינה.

קיימת אפשרות שלישית שאנשים נוטים לשכוח. השאירו את המודל מסוג 27B על ה-CPU עבור עבודות אצווה, והציבו מודל API מאוחסן (hosted) עבור המסלול האינטראקטיבי. שום דבר לא מחייב מודל אחד לשרת את שני הצרכים.

התקנת Ollama ומדידת ביצועי השרת שלכם

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

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

הפקודה ollama --version אמורה להציג 0.32.5 או גרסה מאוחרת יותר. בדקו את free -g לפני שאתם מושכים מודל כלשהו. אם העמודה total בשורת ה-Mem מציגה ערך נמוך מ-32, עצרו כאן ובחרו מודל קטן יותר, כיוון שמשיכת מודל של 17 GB שאינכם יכולים להריץ תבזבז שעה של זמן והרבה שטח דיסק.

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

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

הפלט של --verbose הוא המדידה שלשמה התכנסנו. eval rate מייצג את כמות ה-tokens לשנייה שלכם בזמן יצירת הטקסט. prompt eval rate הוא מהירות ה-prefill שלכם. load duration הוא הזמן שלקח לקרוא את המשקולות (weights) מהדיסק, וזו הסיבה לכך ש-OLLAMA_KEEP_ALIVE=60m מוגדר: בהרצה על גבי CPU, טעינה מחדש של 17 GB מהדיסק בכל בקשה עולה יותר מהבקשה עצמה.

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

ollama ps

עמודת ה-SIZE מייצגת את טביעת הרגל האמיתית בזיכרון, כולל ה-KV cache, והיא צריכה להיות קרובה למשקל המודל בתוספת השורה עבור אורך ה-context שלכם בטבלת ה-KV. ב-8192 tokens עם cache של 8-bit, צפו לתוספת של כ-gigabyte אחד מעבר למשקולות, לעומת 2 GB אם ה-cache היה נשאר בפורמט f16. עמודת ה-PROCESSOR צריכה להציג 100% CPU. אם היא מציגה משהו אחר, סימן שמשהו אחר תפס את ה-GPU ומספרי המהירות במדריך זה אינם מתארים את השרת שלכם.

מצבי כשל והודעות השגיאה המדויקות

המודל מסרב להיטען. Ollama מדפיס שורה המציינת את שני הערכים, במבנה model requires more system memory (18.6 GiB) than is available (15.2 GiB). זהו כשל תקין, כיוון ש-Ollama ביצע בדיקה לפני הקצאת הזיכרון במקום להניח ל-kernel לטפל בכך. הקטינו את אורך ה-context, עברו ל-tag קטן יותר, או שדרגו לתוכנית גדולה יותר.

התהליך נעלם באמצע יצירת תשובה. ה-client אינו מציג מידע מועיל, ו-journalctl -u ollama -n 50 מראה שהשירות מבצע הפעלה מחדש. הריצו את dmesg -T | tail; שורה המכילה את Out of memory: Killed process ... (ollama) מעידה על כך שה-OOM killer של ה-kernel סיים את התהליך. מצב זה קורה כאשר בדיקת הטעינה המוקדמת עברה, אך ה-cache גדל מעבר להערכה במהלך שיחה ארוכה. הקטינו את אורך ה-context.

פעולת ה-pull נכשלת מיד. Error: pull model manifest: file does not exist מציין שה-tag אינו קיים ב-library. הקלדת qwen3.8:27b תפיק בדיוק שגיאה זו, וכך גם כל שגיאת הקלדה במספר הגרסה. ודאו את ה-tag בדף ה-library לפני שאתם מאשימים את הרשת שלכם.

הכל עובד אך המהירות איטית באופן בלתי נסבל. קצב של פחות מ-token אחד לשנייה על שרת עם מספיק RAM מצביע על paging ולא על בעיית חישוב. הריצו את vmstat 1 בזמן יצירת התוכן. עמודת si או so שאינה אפס מעידה על כך שה-kernel מבצע swapping; הפתרון הוא הקטנת ה-context או הפחתת מספר המודלים הטעונים. ערך wa גבוה וקבוע ללא פעילות swap מעיד על כך שמשקולות המודל (weights) הממופות לזיכרון נקראות שוב ושוב מהדיסק, מה שאומר שהן אינן נכנסות בזיכרון בפועל.

ה-token הראשון לוקח 30 שניות ואז המהירות עולה. זהו שלב ה-prefill, וזהו מצב תקין. על system prompt ארוך משלמים בכל בקשה שאינה נמצאת ב-cache, לכן קצרו את ה-system prompt לפני שתבצעו כיוונונים אחרים.

למה באמת מתאים מודל 27B שרץ על ה-CPU בלבד

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

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

אם זו ההתקנה הראשונה שלכם ב-Ollama, המדריך המלא להרצת Ollama על גבי VPS מכסה את הגדרת השירות, ה-HTTP API וחוקי ה-firewall שמדריך זה מניח שכבר קיימים אצלכם. אל תחשפו את פורט 11434 לאינטרנט. Ollama מגיע ללא מנגנון אימות מובנה, לכן כל מי שיגיע לפורט יוכל להשתמש במודל שלכם ולקרוא את ה-prompts שלכם.

FAQ

האם קיים מודל Qwen 3.8 27B ב-Ollama?

לא. נכון ל-4 באוגוסט 2026, בספריית Ollama אין namespace בשם qwen3.8. התגיות 27B הקיימות הן qwen3.5:27b ו-qwen3.6:27b, שתיהן גרסאות Q4_K_M של מודל צפוף (dense) בעל 27.8 מיליארד פרמטרים. המספר 3.8 במונח החיפוש הוא כמעט בוודאות בלבול עם מספר הפרמטרים 27.8B שנתפס בטעות כמספר גרסה. בדקו את https://ollama.com/library/qwen3.6/tags לקבלת הרשימה העדכנית, ובצעו pull ל-qwen3.6:27b אם ברצונכם בגרסה החדשה ביותר של 27B. תגית שאינה קיימת תגרום לשגיאה Error: pull model manifest: file does not exist.

כמה זיכרון RAM דרוש להרצת מודל Qwen 27B על שרת VPS?

32 GB הוא המינימום המעשי עבור Q4_K_M. המשקולות תופסות 17 GB, מערכת ההפעלה זקוקה לכ-1.5 GB, וזיכרון ה-KV cache מוסיף בערך 1 GB לכל 4000 טוקנים של הקשר (context) בפורמט f16. תוכנית של 16 GB לא יכולה להכיל את המשקולות כלל, ושימוש ב-swap לא יעזור כיוון שהקובץ ממופה לזיכרון (memory-mapped) וה-kernel פשוט קורא אותו שוב מהדיסק עבור כל טוקן. 64 GB יאפשרו לכם מרווח להקשר ארוך או למשקולות Q8_0 בנפח 30 GB.

כמה טוקנים לשנייה יספק מודל 27B על גבי CPU?

חלקו את רוחב הפס של הזיכרון שלכם בגודל המשקולות, וקחו 50 עד 70 אחוזים מהתוצאה. שרת VPS עם ערוץ כפול של DDR4-3200 מוגבל לתקרה של כ-3 טוקנים לשנייה ומספק כ-2. שרת עם ערוץ כפול של DDR5-4800 מוגבל לתקרה של כ-4.5 ומספק כ-3. פלטפורמות שרתים עם ריבוי ערוצים נראות טוב יותר על הנייר, אך רוחב הפס של הזיכרון משותף לכל הדיירים בשרת המארח, לכן מדדו את הביצועים שלכם עם ollama run qwen3.6:27b --verbose וקראו את השורה eval rate.

האם כדאי להשתמש ב-Q4 או ב-Q8 בשרת VPS מבוסס CPU בלבד?

ברוב המוחלט של המקרים, השתמשו ב-Q4_K_M. גרסת Q8_0 תופסת 30 GB לעומת 17 GB, לכן היא דורשת תוכנית של 64 GB ומעבירה כמעט פי שניים נתונים מהזיכרון עבור כל טוקן, מה שמקצץ את קצב הטוקנים לשנייה שלכם בערך בחצי. הבדל האיכות בין Q4_K_M ל-Q8_0 במודל 27B הוא זניח עבור רוב המשימות. השקיעו את ה-RAM בהקשר (context) ארוך יותר, שכן זה משנה את יכולות המודל ולא רק את אופן הניסוח שלו.

מתי השכרת GPU זולה יותר משרת VPS עם הרבה RAM?

כאשר מחזור העבודה שלכם נמוך או כאשר יש אדם שממתין לתוצאות. כרטיס GPU עם 24 GB זיכרון מגיע לכ-59 טוקנים לשנייה עם משקולות אלו, לעומת 2 או 3 ב-VPS טיפוסי, והוא מחויב רק עבור השעות שבהן הוא פועל. שרת VPS של 64 GB מחויב לכל אורך החודש, בין אם המודל טעון ובין אם לא. חשבו כמה שעות ביום אתם באמת מייצרים טוקנים. מתחת לשעתיים או שלוש ביום, השכרת GPU לפי שעה לרוב משתלמת יותר גם מבחינת מהירות וגם מבחינת עלות. עבודה רציפה בעדיפות נמוכה היא המקרה שבו שרת VPS פעיל תמיד מנצח.