איך להשאיר מודל Ollama בזיכרון באופן קבוע

מדוע Ollama פורק את המודל מהזיכרון לאחר מספר דקות?

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

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

קיימים שני מקומות להגדרת keep_alive: בבקשה הפרטנית, או כברירת המחדל של השרת. שימוש ב-systemd drop-in הוא הדרך להבטיח שברירת המחדל של השרת תישמר גם לאחר אתחול. מדריך זה מניח ש-Ollama כבר רץ כשירות. אם לא, התחילו ב-התקנת Ollama על שרת VPS וחזרו לכאן.

FAQ

אילו מודלים טעונים כרגע בזיכרון, ומתי יפוג תוקפם?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

פלט ריק מציין ששום מודל אינו טעון, ולכן הבקשה הבאה תגרור טעינה מלאה. PROCESSOR מציג היכן מאוחסנים המשקולות. 100% GPU ו-100% CPU הם המקרים הברורים. פיצול כגון 25%/75% CPU/GPU מציין שהמודל לא נכנס ל-VRAM, ולכן חלק ממנו רץ על המעבד והפקת התוכן איטית יותר.

UNTIL הוא הספירה לאחור, והוא מציג זמן יחסי כגון 4 minutes from now. הוא מציג Forever כאשר המודל נטען עם keep_alive שלילי. הוא מציג Stopping... במהלך חלון הזמן הקצר שבו השרת מבצע פריקה (unloading).

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

curl -s http://localhost:11434/api/ps

כל רשומה נושאת expires_at, חותמת זמן מוחלטת כגון 2026-08-09T14:38:31.83753Z, ו-size_vram, החלק של אותו מודל שנמצא בזיכרון ה-GPU. ערך size_vram של 0 מציין שהמודל רץ על ה-CPU.

מהו המחיר האמיתי של טעינה מחדש

אל תנחשו. Ollama מדווחת על זמן הטעינה בכל תגובה, תחת load_duration, בננו-שניות.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

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

שמירת מודל Ollama בזיכרון עבור בקשה אחת

שלחו את keep_alive יחד עם הבקשה. ההגדרה תחול על המודל מרגע סיום הבקשה.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

ניתן להשתמש בארבעה פורמטים של ערכים:

• מחרוזת זמן: "30m", "24h", "90s"
• מספר פשוט, המפורש כשניות: 3600
• ערך שלילי, -1 או "-1m", שמשמעותו ביטול מוחלט של ה-timeout להמתנה
• 0, שמשמעותו פריקת המודל מהזיכרון מיד עם סיום הבקשה

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

ניתן גם לטעון מודל מבלי לייצר פלט. שלחו רק את שם המודל. השרת יטען אותו ויחזיר תגובה ריקה עם "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

זהו הפקודה שיש להריץ לאחר reboot, או לאחר משיכת מודל חדש, כדי שהבקשה הראשונה של משתמש אמיתי לא תצטרך להמתין לטעינה. ה-CLI מבצע פעולה זהה באמצעות flag:

ollama run --keepalive 30m qwen3:8b "hello"

שמירה על טעינת המודל כברירת מחדל באמצעות OLLAMA_KEEP_ALIVE

השרת קורא את OLLAMA_KEEP_ALIVE בעת העלייה ומשתמש בו עבור כל מודל שאינו נושא ערך משלו. המשתנה מקבל את אותם הפורמטים כמו שדה הבקשה, כך ש-30m, 3600 ו--1 כולם תקינים.

הקושי הוא להבין באיזו סביבה המשתנה צריך להיות מוגדר. הרצת export OLLAMA_KEEP_ALIVE=30m בתוך סשן ה-SSH שלכם לא תבצע דבר, כיוון שהתקנה ארוזה מריצה את השרת כשירות systemd תחת משתמש ייעודי עם סביבה משלו. ה-shell שלכם והשירות הזה לעולם אינם נפגשים. זוהי הסיבה הנפוצה ביותר לכך שההגדרה נראית כאילו היא מתעלמת מהערך שנקבע.

הבטחת פעילות לאחר אתחול באמצעות systemd drop-in

sudo systemctl edit ollama.service

העורך ייפתח עם שני סימני הערה. הקלידו ביניהם: systemd מתעלם מכל מה שייכתב מתחת לסימן השני.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

שמירה כותבת את /etc/systemd/system/ollama.service.d/override.conf. זהו קובץ drop-in ולא עריכה של קובץ ה-unit המקורי, לכן שדרוג חבילת Ollama שמחליף את ollama.service לא יפגע בהגדרות שלכם. אם קובצי drop-in וקובצי unit הם מושגים חדשים עבורכם, המדריך לשירותים וטיימרים ב-systemd מסביר את אופן הפעולה שלהם.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

הפקודה האחרונה מציגה את סביבת העבודה שבה השירות ירוץ בפועל. אם OLLAMA_KEEP_ALIVE=30m חסר בשורה זו, ה-drop-in לא נטען, והסיבה לכך היא כמעט תמיד כותרת [Service] חסרה או שורות שהוקלדו מתחת לסימן. האתחול עצמו מוחק כל מודל טעון מהזיכרון, לכן הבקשה הבאה תהיה טעינה קרה. בצעו חימום באמצעות פקודת ה-preload שצוינה לעיל.

העלות של החזקת מודל בזיכרון

העמודה SIZE בתוך ollama ps מייצגת זיכרון שמוחזק לאורך כל חלון ההמתנה (idle window), ולא רק בזמן עיבוד בקשה. מודל 8B בקוונטיזציה של 4-bit תופס סביב 5 עד 6 GB. מודל 27B הוא סיפור אחר, וכדאי לבצע את חישובי הזיכרון להרצה על שרת VPS מבוסס CPU בלבד לפני שמחליטים להשאיר אותו בזיכרון באופן קבוע. הגדרה של keep_alive ל--1 משמעותה שהחלטתם שהמודל קודם לכל תהליך אחר בשרת, לצמיתות. בשרת VPS קטן, מדובר בוויתור ישיר על משאבים עבור מסד הנתונים, יישום ה-web ומשימות ה-build שלכם.

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

free -h

העמודה available מציגה את הזיכרון שה-kernel עדיין יכול להקצות לתהליך חדש. בשרת עם כרטיס מסך NVIDIA, הפקודה nvidia-smi מציגה תמונה דומה עבור ה-VRAM. אם השרת אוזל מזיכרון, ה-kernel יסיים תהליך כדי לפנות מקום:

sudo dmesg -T | grep -i "out of memory"

שורה המציינת את ollama משמעותה ששרת המודל היה הקורבן. שורה המציינת את מסד הנתונים שלכם משמעותה שהמודל "ניצח" ושירות שחשוב לכם "הפסיד". שתי התוצאות נובעות מאותה החלטה: חלון keep-alive ארוך מדי בשרת ללא מרווח נשימה.

ישנן שתי עלויות שקל לפספס. אורך context גדול יותר שומר cache של KV גדול יותר (key value cache, מצב ה-attention לכל token שהמודל שומר בזמן יצירת פלט), ו-cache זה הוא חלק מהזיכרון התפוס. הגודל שלו נגזר מ-num_ctx, לכן הגדלת חלון ה-context מעלה את כמות הזיכרון שהמודל תופס לאורך כל תקופת ההמתנה, ולא רק בזמן מתן תשובה. הגדרה של OLLAMA_NUM_PARALLEL מעל 1 משריינת את ה-cache הזה פעם אחת לכל slot מקבילי. אם אתם מתכננים לשרת כמה משתמשים ממודל אחד, חשבו את הזיכרון לפי כמות ה-slots, ולא רק לפי משקולות המודל.

ברירת מחדל סבירה: מודל בודד בשרת עם מרווח נשימה יכול להשתמש ב--1. בשרת משותף כדאי להשתמש בחלון שמכסה את הפערים בין הבקשות שלכם, כמו 30m, כך שהזיכרון יתפנה כאשר תפסיקו לעבוד.

פריקת מודל באופן מיידי

ollama stop qwen3:8b

הפקודה חוזרת ללא פלט, והמודל נעלם מתוך ollama ps. שם שאינו טעון יחזיר couldn't find model "qwen3:8b" to stop. פורמט ה-API הוא בקשה ללא prompt, כאשר keep_alive מוגדר ל-0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

התגובה מכילה "done_reason": "unload". השתמשו בשיטה זו במקום לבצע הפעלה מחדש לשירות. systemctl restart ollama מפנה גם הוא את הזיכרון, אך הוא מסיר את כל שאר המודלים הטעונים ומפסיק כל בקשה שהייתה בתהליך.

הרצת יותר ממודל אחד על שרת יחיד

OLLAMA_MAX_LOADED_MODELS מגביל את מספר המודלים שנטענים בו-זמנית לזיכרון. נכון לאוגוסט 2026, ברירת המחדל היא שלושה מודלים לכל GPU, או שלושה בשרת ללא GPU. המגבלה סופרת מודלים, אך הזיכרון הוא המגבלה המעשית; לכן, ייתכן שמודל גדול שני יידחה הרבה לפני שתגיעו למכסה של שלושה.

כאשר מתבקש מודל חדש ואין מספיק זיכרון פנוי, ה-scheduler מסיר מהזיכרון אחד מהמודלים הקיימים כדי לפנות מקום. המערכת מעדיפה להסיר מודל שאין עבורו בקשות פעילות, והיא תפנה גם מודל שהטיימר שלו טרם פג, כולל מודל שנטען באמצעות -1. לכן, ערך שלילי ב-keep_alive משמעותו ביטול ה-idle timeout. הגדרה זו אינה נועלת את ה-weights מפני בקשות של מודלים אחרים.

החלטה זו מתועדת ברמת debug. הוסיפו שורת Environment="OLLAMA_DEBUG=1" שנייה לאותו קובץ drop-in, בצעו restart, ועקבו אחר הלוגים:

sudo journalctl -u ollama -f

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

הנחיות שרלוונטיות גם לאחר הגרסה הבאה

Ollama משחררת גרסאות בתדירות גבוהה וערכי ברירת המחדל משתנים, לכן מומלץ לבדוק את ה-build הנוכחי שברשותכם במקום לשנן מספרים:

ollama --version
ollama serve --help

ollama serve --help מציג את משתני הסביבה שה-build הספציפי הזה קורא בפועל, וביניהם OLLAMA_KEEP_ALIVE. שני כללים נותרו יציבים לאורך הגרסאות וניתן להסתמך עליהם. ערך שנשלח בבקשה (request) גובר על ברירת המחדל של השרת. בנוסף, ollama ps הוא המקור האמין ביותר למה שנטען בפועל, ללא קשר למה שמוגדר בקובץ התצורה.

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

FAQ

מדוע Ollama פורק את המודל שלי לאחר 5 דקות?

חמש דקות הן ערך ברירת המחדל של keep_alive, טיימר המתנה ש־Ollama מפעיל עם סיום בקשה. כאשר הטיימר פג, השרת משחרר את המשקולות (weights) מהזיכרון, כך שהבקשה הבאה מחייבת טעינה מחדש מהדיסק, והשהיה זו היא ההמתנה שאתם חווים. ניתן להגדיל את הזמן עבור בקשה בודדת על ידי שליחת "keep_alive": "30m" בגוף ה-JSON, או עבור השרת כולו באמצעות משתנה הסביבה OLLAMA_KEEP_ALIVE.

כיצד אוכל להשאיר מודל של Ollama טעון בזיכרון באופן קבוע?

השתמשו בערך שלילי: "keep_alive": -1 בבקשה, או OLLAMA_KEEP_ALIVE=-1 עבור השרת. לאחר מכן, ollama ps יציג Forever בעמודה UNTIL. פעולה זו מסירה את טיימר ההמתנה בלבד. אם יתבקש מודל אחר והזיכרון יהיה חסר, מתזמן המשימות עדיין יפרוק מודל זה כדי לפנות מקום.

מדוע OLLAMA_KEEP_ALIVE לא מקבל התייחסות?

בדקו היכן הגדרתם אותו. הריצו את systemctl show ollama --property=Environment; אם המשתנה אינו מופיע בפלט, השרת לא זיהה אותו, כיוון שמשתנה שיוצא (exported) ב-shell שלכם אינו מגיע לשירות systemd. הגדירו אותו באמצעות sudo systemctl edit ollama.service, ולאחר מכן הריצו את sudo systemctl daemon-reload ו-sudo systemctl restart ollama. סיבה נוספת היא לקוח ששולח keep_alive משלו בבקשה, מה שדורס את ברירת המחדל של השרת.

כיצד אוכל לשחרר את הזיכרון מבלי להפעיל מחדש את Ollama?

הפקודה ollama stop qwen3:8b פורקת את המודל הספציפי באופן מיידי ומותירה את השרת ואת כל שאר המודלים הטעונים פעילים. דרך ה-API, שלחו בקשה ללא prompt עם "keep_alive": 0, והתשובה שתתקבל תכלול "done_reason": "unload". אשרו את הפעולה עם ollama ps, שאמור להפסיק להציג את המודל ברשימה.