Ollama: השוואת קוונטיזציה q4, q8 ו-fp16

המשמעות של קוונטיזציה ב-Ollama

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

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

אם Ollama עדיין לא רץ, התחילו ב-התקנת Ollama על שרת VPS. דף זה מניח ש-ollama ls כבר עובד.

כיצד לקרוא תגית קוונטיזציה של Ollama כגון q4_K_M

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

המספר מייצג את רוחב היעד. q4 מציין שרוב טנזורי המשקולות דחוסים לארבעה ביטים כל אחד. q8 מציין שמונה ביטים. fp16 אינו עובר קוונטיזציה כלל: זהו המודל בפורמט 16-bit floating point, רמת הדיוק שבה רוב המודלים מתפרסמים.

K מסמן K-quant. המשקולות מקובצות לבלוקים קטנים, וכל בלוק מאחסן קנה מידה (scale) משלו לצד הערכים הדחוסים. בלוק שכל משקולותיו קרובות ל-0.01 מקבל קנה מידה עדין. בלוק המכיל חריג אחד גדול מקבל קנה מידה גס. קני מידה אלו לכל בלוק הם ששומרים על קובץ ארבעה ביטים שמיש, והם גם הסיבה לכך שקובץ ארבעה ביטים לעולם אינו בדיוק ארבעה ביטים לכל משקולת.

האות האחרונה היא התערובת (mixture). S, M ו-L קובעים כמה טנזורים יועלו לרמת דיוק גבוהה מרוחב היעד. ב-q4_K_M, הטנזורים שהעיגול שלהם גורם לנזק הרב ביותר נשמרים ברוחב גדול יותר, בעוד הרוב נשאר בארבעה ביטים. זו הסיבה ש-q4_K_M מפיק פלט טוב יותר מה-q4_0 הישן יותר, באותו גודל קובץ כמעט.

שאלו את Ollama מה קיים על הדיסק במקום לנחש לפי השם שהקלדתם:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show מדפיס את architecture, parameters, quantization, context length ו-embedding length. השורה quantization היא האמת המוחלטת עבור מודל שהורדתם לפני חודשים ואינכם זוכרים מה בחרתם.

מספר הביטים לכל משקל הוא המקור לנפח הקובץ

כל הערכת נפח מתחילה ממספר אחד: כמה ביטים הפורמט מקצה לכל משקל, בממוצע על פני כל הקובץ. llama.cpp מפרסמת נתונים מדודים עבור Llama 3.1 8B בתיעוד ה-quantize שלה, והם תקפים לכל מודל צפוף בעל מבנה דומה.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

ההפתעה בטבלה זו נמצאת בעמודה השנייה. Q4_K_M אינו ארבעה ביטים לכל משקל. הוא נמדד כ-4.89 ביטים, כיוון שקני המידה של הבלוקים והטנזורים המקודמים צורכים נפח אחסון בפועל. Q8_0 נמדד כ-8.5 ביטים במקום שמונה, מאותה סיבה. השתמשו במספר המדוד והחישוב יניב תוצאה הקרובה בתוך אחוזים בודדים לנפח הקובץ האמיתי:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

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

מה Ollama מפיצה בפועל עבור כל גודל מודל

הספרייה מפרסמת תגית q4_K_M, תגית q8_0 ותגית fp16 עבור רוב המשפחות. כמה משפחות חדשות יותר חורגות מהתבנית הזו ומופיעות בספרייה כתגיות ענן בלבד ללא אפשרות משיכה (pull) בכל רוחב שהוא; זהו המחסום שבו נתקלים בעת ניסיון להריץ את GLM 5.2 על שרת VPS. אלו הם הגדלים של Qwen3 נכון לאוגוסט 2026, כפי שהם מופיעים ברשימת התגיות בדף המודל. כל נתון להלן מתייחס לנפח הדיסק לפני השימוש ב-RAM, ושילוב של שניים או שלושה מהם ימלא נפח אחסון של שרת VPS קטן, לכן כדאי לדעת היכן Ollama מאחסנת את המודלים שהיא מורידה לפני שמתחילים לאסוף תגיות.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

לתגית ברירת המחדל יש חשיבות כאן. ollama pull qwen3:8b מורידה בדיוק את אותם 5.2 GB כמו ollama pull qwen3:8b-q4_K_M, כיוון שהתגית ללא סיומת היא גרסת ה-q4_K_M. הגרסה q4_K_M אינה פשרה שהספרייה מציעה בחוסר רצון. זוהי ברירת המחדל שבחר היצרן (upstream), ולכן התאמה אליה היא הצעד הראשון ההגיוני עבור כל מודל שטרם בדקת בעצמך. אותו היגיון מנחה את בחירת התגיות ב-הרצת Qwen 3 על שרת VPS.

היחסים נשמרים בכל שורה. מעבר מ-q4_K_M ל-q8_0 עולה כשבעים אחוז יותר ולא בדיוק פי שניים, כיוון שה-embedding וה-output tensors אינם גדלים באותו אופן כמו שאר המודל. גרסת fp16 גדולה בערך פי שלושה מ-q4_K_M. מודל 32B בגרסת q4_K_M תופס 20 GB של משקולות, מה שכבר חורג מהיכולת של שרת עם 16 GB RAM להכיל אותו עם כל חלון הקשר (context window) שהוא. למבט רחב יותר על מה מתאים לאיזו מכונה, ראו אילו מודלים ניתן לארח באופן עצמי.

מדוע ה-KV cache הוא עלות שנייה התלויה בהקשר

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

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

מספרי המודל הללו מגיעים מהגדרות המודל עצמו: 36 שכבות, 8 ראשי מפתח/ערך, ומימד ראש של 128. ollama show מספק לכם את הארכיטקטורה ואת מספר הפרמטרים, וה-config.json של המודל ב-Hugging Face מספק את השאר. הכפילו את העלות לכל אסימון בגודל החלון, והמטמון יפסיק להיות שגיאת עיגול.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

בחלון ברירת המחדל של Ollama, העומד על 4096 אסימונים, המטמון מוסיף 0.6 GB מעבר למשקולות. העלו את החלון ל-32k והמטמון לבדו יגיע ל-4.83 GB, כמות זיכרון שכמעט משתווה למשקולות המקודדות (quantized), והרף התחתון עבור המודל כולו יהיה 10 GB. אנו קוראים לזה רף תחתון מכיוון שמאגרי חישוב ומערכת ההפעלה מתווספים מעליו. קראו את הנתון האמיתי מעמודת SIZE ב-ollama ps לאחר שהמודל נטען.

החלון מוגדר בשרת, ולא לכל בקשה, כאשר מריצים את Ollama כשירות:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

עבור התקנת systemd, הציבו זאת בקובץ drop-in במקום:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

בצעו הפעלה מחדש עם sudo systemctl restart ollama, ולאחר מכן בדקו את עמודת CONTEXT ב-ollama ps כדי לוודא את החלון שבו נטען המודל בפועל. OLLAMA_KV_CACHE_TYPE מבצע קידוד (quantization) למטמון עצמו: f16 הוא ברירת המחדל, q8_0 משתמש בכמחצית מהזיכרון של f16, ו-q4_0 ברבע. זוהי אפשרות גלובלית, לכן כל מודל בשרת זה מקבל את אותו הטיפול. במכונה קטנה עם חלון ארוך, צמצום המטמון בחצי מפנה יותר זיכרון מכל שינוי בודד אחר. הגדרת num_ctx והעלות הכרוכה בכך מכסה את החלון עצמו בפירוט. המטמון גם מקבל גודל פעם אחת לכל חריץ בקשה בו-זמנית (concurrent request slot) ולא פעם אחת לכל שרת, לכן מתן אפשרות ל-Ollama לענות לשתי הנחיות בו-זמנית מכפיל את הנתון שחישבתם זה עתה; זהו החישוב העומד מאחורי בחירת מספר חריצים מקבילים ומגבלת תור.

מה מתאים לשרת VPS עם 8, 16 או 32 GB זיכרון

יש לשקלל את משקלי המודל, את ה-KV cache, ומרווח ביטחון עבור מערכת ההפעלה וכל תהליך אחר שרץ. מרווח ביטחון של 2 GB הוא נוח בשרת VPS קטן.

8 GB. מודל 4B בקוונטיזציה q4_K_M תופס 2.6 GB ומותיר מקום לחלון הקשר ארוך. מודל 8B בקוונטיזציה q4_K_M נכנס עם חלון ברירת המחדל של 4k, אך עם מעט מאוד מרווח תמרון. אל תבנו על הרצת 8B עם חלון של 32k כאן, כיוון שהרף המינימלי של 10 GB כבר חורג מיכולות השרת.

16 GB. מודל 8B בקוונטיזציה q4_K_M עם חלון של 16k או 32k ירוץ בנוחות. מודל 14B בקוונטיזציה q4_K_M דורש 9.3 GB עבור המשקלים וייכנס עם חלון הקשר צנוע. מודל 8B בקוונטיזציה q8_0 דורש 8.9 GB, לכן גם הוא יתאים; השוואה בין שני אלו באמצעות ה-prompts שלכם היא השעה המועילה ביותר שתוכלו להקדיש לנושא זה.

32 GB. מודל 14B בקוונטיזציה q8_0 (16 GB) ומודל 32B בקוונטיזציה q4_K_M (20 GB) ייטענו שניהם. הרצת מודל 32B עם חלון גדול תדחוף את צריכת הזיכרון אל הקצה, לכן יש לנטר את ollama ps במקום להניח הנחות.

מה נפגע ראשון בקוונטיזציה (Quantization)

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

הנקודה האחרונה היא המבחן המעשי. כאשר מודל נדרש להחזיר JSON שהקוד שלכם מנתח, נזקי הקוונטיזציה מופיעים כשגיאת ניתוח (parse error) ולא כפרוזה גרועה במעט, כך שתבחינו בכך עוד באותו יום. סוכן תכנות (coding agent) הוא הגרסה המחמירה ביותר של מבחן זה, כיוון שהוא מפעיל את המודל בקריאה אחר קריאה לפונקציות, לכן הפניית סוכן לשרת ה-Ollama שלכם תחשוף קוונטיזציה אגרסיבית מדי בתוך אחר צהריים אחד.

מתחת לארבעה ביטים, הירידה באיכות הופכת לתלולה. הסוגים q3 ושני ביטים קיימים עבור אנשים שדוחסים מודל גדול לחומרה קטנה, והם מהווים אפשרות ממשית כאשר החלופה היא אי-הרצת המודל כלל. הם מהווים ברירת מחדל גרועה. בין q4_K_M לבין q8_0 הפער קטן מספיק כדי שטבלת perplexity מפורסמת לא תכריע עבור עומס העבודה שלכם, לכן אל תנסו להכריע בדרך זו. הריצו את שניהם מול שלושים מהפרומפטים שלכם וקראו את הפלט.

מתי כדאי להשתמש ב-q8_0 או ב-fp16

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

משכו את fp16 משתי סיבות בלבד. או שאתם מבצעים קוונטיזציה (quantization) למודל בעצמכם וזקוקים לקובץ המקור, או שאתם מודדים נקודת ייחוס כדי להבין כמה ביצועים איבדתם במעבר לגרסת 4-bit. הרצה מ-fp16 צורכת פי שלושה זיכרון בהשוואה ל-q4_K_M עבור הבדל שרוב האנשים לא יבחינו בו במבחן עיוור, ובמכונה המבוססת על CPU בלבד, היא גם חותכת את קצב יצירת ה-tokens לשליש.

הכלל החזק יותר, תחת תקציב זיכרון קבוע: מודל גדול יותר ב-q4_K_M בדרך כלל עדיף על מודל קטן יותר ב-q8_0. 9.3 GB של משקולות מודל 14B לעומת 8.9 GB של משקולות מודל 8B דורשים כמעט את אותה כמות RAM (זיכרון גישה אקראית), והמודל הגדול יותר "יודע" יותר. בדקו זאת על ה-prompts שלכם במקום להסתמך על הנחות.

הסקה (Inference) מבוססת CPU בלבד מוגבלת על ידי רוחב פס של זיכרון

רוב תוכניות ה-VPS אינן כוללות GPU, לכן המודל רץ בזיכרון המערכת על גבי ה-CPU של המארח. יצירת הטקסט (Generation) מוגבלת במקרה זה על ידי רוחב הפס של הזיכרון ולא על ידי כוח חישוב אריתמטי, כיוון שהפקת טוקן אחד דורשת קריאה של כל משקולות המודל פעם אחת. מצב זה יוצר תקרה שאינה קשורה למספר הליבות שרכשתם.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

חמישים GB/s הוא בערך הנתון התאורטי עבור מארח עם ערוץ כפול (dual channel) של DDR4-3200. החלק שלכם ברוחב הפס קטן יותר, כיוון ש-VPS חולק את ה-bus הזה עם כל שאר הדיירים על השרת; לכן, התייחסו למספרים אלו כתקרה שאף אחד לא מגיע אליה. המגמה היא החלק השימושי: ב-CPU, הפחתת מספר הביטים לכל משקולת מכפילה בערך את קצב הטוקנים. קוונטיזציה (Quantization) היא מנוף המהירות המשמעותי ביותר הזמין במכונה ללא GPU. האם הקצב שנותר לכם הוא נסבל, זה תלוי במודל, והמאמר Nemotron 3.5 Lightning on a VPS מבצע את החישוב הזה עבור build, תג ונתוני RAM ספציפיים. החצי השני של זמן ההמתנה תלוי בכמות הטקסט שהמודל מחליט לכתוב; בקצב של עשרה טוקנים לשנייה, תשובה של שש מאות טוקנים תעלה דקה שלמה, לכן הגבלת התשובה באמצעות num_predict לרוב חוסכת זמן המתנה רב יותר מאשר צעד נוסף בהפחתת הדיוק.

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

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

ביצוע קוונטיזציה למודל באופן עצמאי

Ollama מסוגלת לבנות מודל שעבר קוונטיזציה מתוך מקור בפורמט fp16 או fp32. יכולת זו חיונית כאשר ביצעתם fine-tuning למודל ואין עבורו תגית זמינה בספריות. יש להפנות את ה-Modelfile למשקולות (weights) שטרם עברו קוונטיזציה:

FROM /path/to/my/model/f16

לאחר מכן, בצעו את הבנייה וודאו את תקינותה:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

הפקודה --quantize מקבלת את q8_0, q4_K_S ו-q4_K_M. לא קיימת כאן אפשרות ל-q6_K או q5_K_M, ולכן עבור אלו יש לבצע קוונטיזציה באמצעות הכלי הייעודי של llama.cpp ולייבא את קובץ ה-GGUF המוכן. לנתיב ייבוא זה יש מכשול פוטנציאלי: אי-התאמה ב-chat template שגורמת למודל להשיב בתוכן משובש, נושא שמוסבר במדריך ייבוא קובץ GGUF לתוך Ollama. השורה quantization מתוך ollama show היא הדרך שלכם לוודא שהבנייה בוצעה בהתאם להגדרות שביקשתם.

מה תראה כאשר משהו משתבש

הכל רץ על ה-CPU למרות שציפית ל-GPU. קרא את העמודה PROCESSOR:

ollama ps

היא מדפיסה 100% GPU, 100% CPU, או פיצול כגון 48%/52% CPU/GPU. פיצול אומר שהמשקולות (weights) יחד עם ה-KV cache לא נכנסו ל-VRAM (זיכרון וידאו, הזיכרון שעל כרטיס המסך), ולכן חלק מהמודל הועבר לזיכרון המערכת. המהירות צונחת אז לרמה הקרובה למהירות של CPU בלבד, כיוון שכל token ממתין לחצי האיטי. הקטן את חלון ההקשר (context window), בצע קוונטיזציה (quantization) ל-cache, או משוך גרסה קטנה יותר של המודל. הוספת ליבות לא תעזור.

המודל נסגר (killed) בזמן הטעינה. בדוק את ה-kernel ואת לוג השירות:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

שורה המכילה Out of memory: Killed process מציינת שסך המשקולות, ה-KV cache והמאגרים (buffers) חרגו מזיכרון המערכת הזמין. בשרת VPS ללא הגדרת swap, המכונה כולה עלולה לקפוא למשך מספר שניות לפני ששורה זו תופיע.

התשובות הפכו לפחות טובות למרות שלא שינית דבר. שתי גרסאות של אותו מודל יכולות להתקיים זו לצד זו ב-ollama ls תחת תגיות שונות, וסקריפט שמושך את השם ללא סיומת יצביע על מה שהספרייה מגדירה כעת כברירת מחדל. הרץ את ollama show מול התגית המדויקת שהלקוח שלך מבקש וקרא את השורה quantization, במקום להסתמך על השם בקובץ התצורה שלך.

FAQ

באיזו קוונטיזציה (quantization) של Ollama כדאי לבחור?

התחילו עם q4_K_M. זוהי ברירת המחדל שמספקת ספריית Ollama עבור רוב המודלים, ולכן ollama pull qwen3:8b ו־ollama pull qwen3:8b-q4_K_M יורידו את אותו הקובץ בדיוק. עברו ל־q8_0 רק כאשר יש לכם זיכרון פנוי והמשימה רגישה לשגיאות קטנות, כמו קריאה לכלים (tool calling) או פלט JSON מובנה. כאשר תקציב הזיכרון מוגבל, מודל גדול יותר בקוונטיזציה q4_K_M בדרך כלל ייתן תוצאות טובות יותר ממודל קטן יותר ב־q8_0; לכן, בדקו שילוב זה לפני שתקצו RAM נוסף עבור דיוק גבוה יותר.

האם q4_K_M באמת אומר ארבעה ביטים לכל משקל?

לא. במדידה על Llama 3.1 8B התוצאה היא 4.89 ביטים למשקל, כיוון שכל בלוק משקולות שומר קנה מידה (scale) משלו, והטנזורים הרגישים ביותר מקודדים בפורמט רחב יותר. Q8_0 מודד 8.5 ביטים במקום שמונה מאותה סיבה. השתמשו בנתון המדוד בעת הערכת צריכת הזיכרון: מספר הפרמטרים כפול מספר הביטים למשקל, חלקי שמונה, ייתן את גודל הקובץ בבתים.

כמה RAM צריך מודל 8B בשרת VPS מבוסס CPU בלבד?

יש לחשב משקולות, זיכרון מטמון (KV cache) ומרווח ביטחון. Qwen3 8B בקוונטיזציה q4_K_M תופס 5.2 GB עבור המשקולות. בחלון ברירת המחדל של 4096 טוקנים, ה־cache מוסיף 0.6 GB, מה שמביא את הרף התחתון לאזור ה-5.8 GB, עוד לפני חישוב מאגרי הזיכרון של תהליכי העיבוד ומערכת ההפעלה. בחלון של 32k, ה־cache לבדו תופס 4.83 GB. תכננו על 8 GB עבור חלון קצר ועל 16 GB אם אתם זקוקים לחלון ארוך.

מדוע המודל רץ ב-100% CPU למרות שיש לשרת GPU?

הריצו את ollama ps ובדקו את העמודה PROCESSOR. הערך 100% CPU, או פיצול כמו 48%/52% CPU/GPU, מעידים על כך שהמשקולות יחד עם ה־KV cache לא נכנסו לתוך ה-VRAM, ולכן Ollama העבירה חלק מהמודל או את כולו לזיכרון המערכת. הסיבה הנפוצה לכך היא חלון הקשר (context window) גדול יותר ממה שהכרטיס מסוגל להכיל, כיוון שה־cache מוקצה עבור כל גודל החלון ברגע טעינת המודל. הקטינו את החלון באמצעות OLLAMA_CONTEXT_LENGTH, הגדירו את OLLAMA_KV_CACHE_TYPE=q8_0 כדי לצמצם את ה־cache בחצי, או הורידו קוונטיזציה קטנה יותר.