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

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

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

הטיימר נקרא 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 מבצע את אותה פעולה באמצעות דגל:

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 ולא עריכה של יחידת השירות המקורית, לכן שדרוג חבילת Ollama שמחליף את ollama.service לא יפגע בהגדרה שלכם. אם קובצי drop-in וקובצי יחידה הם מושגים חדשים עבורכם, המדריך לשירותים וטיימרים ב-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 גדול יותר שומר לעצמו KV cache (זיכרון מטמון של key-value, מצב ה-attention לכל token שהמודל שומר בזמן יצירת טקסט), וזיכרון מטמון זה הוא חלק מהזיכרון התפוס (resident size). הגדרה של 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, או שלושה במכונה מבוססת CPU בלבד. המגבלה סופרת מודלים, אך הזיכרון הוא המגבלה האמיתית; לכן, מודל גדול שני עלול להידחות הרבה לפני שתגיעו למכסה של שלושה.

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