הרצת 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, שהוא אותו build מסוג Q4_K_M מהגרסה הקודמת. בדקו את הרשימה העדכנית לפני העתקת פקודה כלשהי ב-דף התגים של Ollama qwen3.6. אם בעתיד ישוחרר qwen3.8 אמיתי, החישוב כאן עדיין יהיה תקף, כיוון שהוא תלוי במספר הפרמטרים ובמספר הביטים לכל משקולת ולא במספר הגרסה.

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

משיכת תג שאינו קיים מניבה שגיאה ברורה, לכן קל מאוד לוודא זאת ישירות על השרת. תג שקיים במאגר עדיין עלול להיות בלתי ניתן להרצה מקומית, וזהו המכשול העיקרי עבור משתמשים עם GLM 5.2, שמופיע בספרייה אך מוגש רק מהענן של 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 הוא ברירת המחדל הנכונה כאן מהסיבה הזו בלבד. אם אתם מעדיפים את שיקול האיכות על פני שיקול הזיכרון, השוואה מעמיקה יותר בין Q4, Q8 ו-fp16 מציגה היכן הפלט מתחיל להידרדר בפועל.

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

המשקולות הן עלות קבועה. ה-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. משתנה ברמת השרת הזה אינו המנוף היחיד, ו-הגדרת num_ctx בבקשה בודדת מאפשרת לכם לשמור על ברירת מחדל חסכונית לכל השאר, בעוד משימה אחת ארוכה מקבלת את החלון הגדול יותר. העלו אותו בשלבים ובדקו את 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) מקבל נתח הקשר משלו, כך שהשארת המקביליות בברירת המחדל מכפילה בשקט את המטמון שתקצבתם. אם יותר מאדם אחד ישתמש במכונה הזו, הכפלה זו היא המקום שבו מתחילות הבעיות, ו-מספר המשתמשים בו-זמנית שמודל באירוח עצמי יכול לשרת נקבע על ידי חריצי מטמון ועומק תור הרבה לפני שהוא נקבע על ידי מספר הליבות.

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

[
  {
    "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) שנכנסים לצד המשקולות (weights), בפורמט מטמון f16, על שרת Linux VPS ללא ממשק גרפי, עם כ-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?

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

[
  {
    "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 tokens לשנייה, לכן צפו לערך של כ-2. שרת עם ערוץ כפול של DDR5-4800 הוא בעל תקרה של 4.5, לכן צפו לערך של כ-3.

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

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

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

אם מודל 27B צפוף הוא איטי מדי, בדקו את התגיות qwen3.6:35b-a3b לפני שאתם מוותרים על ה-CPU. הן מפעילות בערך 3 מיליארד פרמטרים לכל token במקום את כל 27.8 המיליארדים, כך שתעבורת הזיכרון לכל token יורדת בסדר גודל שלם, למרות שהקובץ על הדיסק גדול יותר. אתם מקריבים נפח RAM עבור מהירות. הבחירה ב-runtime חשובה גם כאן, ו-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 השכור יכול להיות גם מהיר יותר וגם זול יותר. חשבו תחילה את מחזור העבודה (duty cycle) שלכם, ורק אז תמחרו אותו. בחירת VPS עם GPU מכסה את הבדיקות שיש לבצע על המופע עצמו, ו-vLLM עוקף את Ollama ברגע שמגישים בקשות במקביל על גבי GPU כיוון שהוא מבצע להן batching בצורה יעילה.

קיימת אפשרות שלישית שאנשים נוטים לשכוח. השאירו את המודל מסוג 27B על ה-CPU עבור עבודות batch, והשתמשו במודל 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 הוא מספר הטוקנים לשנייה שלכם במהלך יצירת הטקסט. prompt eval rate הוא מהירות ה-prefill שלכם. load duration הוא הזמן שלקח לקרוא את המשקולות מהדיסק, וזו הסיבה ש-OLLAMA_KEEP_ALIVE=60m מוגדר: על גבי CPU, טעינה מחדש של 17 GB מהדיסק בכל בקשה עולה יותר מהבקשה עצמה. זמן ההמתנה המוגדר כברירת מחדל לחוסר פעילות הוא חמש דקות, זמן קצר מספיק כדי שתור עיבוד עם מרווחים בין פריטים ישלם את עלות הטעינה הזו שוב ושוב, והמאמר אפשרויות להשארת מודל בזיכרון מכסה גם את השדה keep_alive לכל בקשה וגם את הפיכת ההגדרה לעמידה לאחר אתחול (reboot).

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

ollama ps

עמודת ה-SIZE היא צריכת הזיכרון האמיתית הכוללת את ה-KV cache, והיא אמורה להיות קרובה למשקולות בתוספת השורה עבור אורך ההקשר (context length) שלכם בטבלת ה-KV. ב-8192 טוקנים עם cache של 8-bit, צפו לתוספת של כגיגה-בייט מעבר למשקולות, לעומת 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 הוא הנקודה הזולה ביותר בעקומה שבה הפלט עדיין ראוי לקריאה.

כדי לבצע benchmark לכל זה, אתם זקוקים לקלט מובנה אמיתי, ורוב ממשקי ה-API הציבוריים דורשים חשבון עוד לפני שניתן למדוד throughput. נקודת הקצה להדגמה של Strasmore (שאנחנו מפעילים) עונה בשאילתות SQL לקריאה בלבד על פני 22 שנים של נתוני שוק בארה"ב, ללא מפתח וללא הרשמה: בקשת GET ל-https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 מחזירה JSON שניתן להעביר ישירות ללולאת prompt, יחד עם ה-SQL המדויק שיצר אותו, כך שלמודל יש מה לסכם שאתם יכולים לבדוק באופן עצמאי. המגבלות הן 500 שורות ו-20 שניות לכל קריאה, שזה בבירור יותר ממה ששרת של שני טוקנים לשנייה יצרוך. רשימת העמודות המלאה נמצאת ב-https://api.strasmore.com/v1/schema.

אם זו ההתקנה הראשונה שלכם של 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 של מודל צפוף בעל 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 מוסיף בערך 1 GB לכל 4000 טוקנים של הקשר ב-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 לפי שעה לרוב משתלמת יותר גם במהירות וגם בעלות. עבודה באצוות (batch) בעדיפות נמוכה שרצה ברציפות היא המקרה שבו ה-VPS שתמיד פעיל מנצח.