איך להריץ Ollama על שרת VPS בצורה מאובטחת

מה אתם בונים

מודל שפה בעל משקולות פתוחות הרץ על שרת בבעלותכם, הנגיש דרך API מסוג HTTP, ואם תרצו, גם דרך דף צ'אט בדפדפן. Ollama הוא הרכיב שמוריד את המודל, טוען אותו לזיכרון ומגיש בקשות ב-http://127.0.0.1:11434. ההתקנה מתבצעת באמצעות פקודה אחת. החלקים המורכבים נמצאים במקומות אחרים: בחירת מודל שה-VPS שלכם מסוגל להחזיק ב-RAM, והימנעות מחשיפה לא מכוונת של שרת הסקה (inference) ללא אימות לכל רחבי האינטרנט.

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

בדיקת המציאות של דרישות הזיכרון, במספרים פשוטים

טביעת הרגל בזיכרון של מודל היא בערך גודל הקובץ שלו, בתוספת גיגה-בייט אחד בערך עבור תקורה בזמן ריצה, ועוד קצת עבור חלון ההקשר (context window). התגיות (tags) המוגדרות כברירת מחדל ברוב המודלים הפופולריים של Ollama, ביניהם llama3.2:3b, llama3.1:8b ו-mistral:7b, הן בקוונטיזציה של 4-bit (מסומנות כ-Q4_K_M), מה שדורש כחצי גיגה-בייט של RAM על כל מיליארד פרמטרים. לא כל ברירת מחדל היא Q4: מודלים זעירים כמו smollm2:135m מופצים ב-16-bit, לכן בדקו את שורת הקוונטיזציה בדף הספרייה של המודל לפני ביצוע החישובים. החשבון פשוט, והוא קובע הכול. את המשתנה האחרון אתם קובעים בעצמכם: העלאת num_ctx מעבר לברירת המחדל הקטנה של Ollama מפנה מקום להנחיות (prompts) ארוכות יותר, אך מגדילה את ה-KV cache ב-RAM, לכן החליטו על אורך ההקשר לפני שתקבעו אם מודל מסוים מתאים.

מודל 3B כמו llama3.2:3b הוא הורדה של כ-2 GB ודורש כ-4 GB של RAM פנוי כדי לרוץ. מודל 7B או 8B כמו mistral:7b או llama3.1:8b הוא כ-5 GB על הדיסק ודורש כ-8 GB של RAM, כאשר 16 GB יספקו עבודה נוחה. מודל 13B או 14B דורש בערך 16 GB. כל מודל בטווח שבין 30B ל-70B דורש שרת עם כמות גדולה של RAM או, באופן מציאותי, GPU; על שרת VPS מבוסס CPU הוא או לא ייכנס לזיכרון, או יענה לאט כל כך עד שלא יהיה בו שימוש.

כעת לגבי המהירות, שכן זהו החלק שאנשים נוטים להמעיט בערכו. הסקת מסקנות (inference) על גבי CPU מוגבלת על ידי רוחב הפס של הזיכרון, לא על ידי מהירות השעון, ולשרת VPS עם vCPU משותף יש רוחב פס צנוע. צפו לקצב של ספרה אחת עד שתי ספרות נמוכות של טוקנים לשנייה: מודל 7-8B בקוונטיזציית Q4 עשוי להגיע ל-4 עד 10 טוקנים לשנייה, ומודל 3B ל-10 עד 25. GPU מהיר בערך בסדר גודל אחד. אלו מספרים גסים במכוון; הצעד הכנה הוא למדוד את השרת שלכם, כפי שמודגם בשלב ההרצה להלן. סמכו על ה-eval rate שלכם, לא על מספר במאמר כלשהו, כולל זה.

המסקנה המעשית: מודלים קטנים ומקוונטטים על גבי CPU הם שימושיים באמת לטיוטות, סיכומים וסיווג, אם אתם יכולים להשלים עם הקצב. לכל דבר גדול או מהיר יותר, תקצבו מופע (instance) עם GPU. אם אתם מעדיפים לראות את החישוב הזה מבוצע מתחילתו ועד סופו על מודל ספציפי, הרצת Nemotron 3.5 Lightning על שרת VPS מכסה איזו תגית למשוך, ה-RAM שהוא באמת צריך, והאם הרצה על CPU בלבד עומדת בקצב.

כדי לשקול מודל ספציפי מול שרת ספציפי, העריכו את טביעת הרגל שלו בזיכרון כאן:

התקנת Ollama

קיימות שתי דרכים נקיות לביצוע הפעולה. הסקריפט הרשמי הוא הדרך הפשוטה ביותר בשרת VPS חשוף:

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

פעולה זו יוצרת משתמש מערכת בשם ollama, מתקינה את הקובץ הבינארי ב-/usr/local/bin/ollama, ורושמת שירות systemd בשם ollama.service שמופעל בעת עליית המערכת ומאזין ב-127.0.0.1:11434. ודאו שהשירות פעיל:

systemctl status ollama
ollama --version

אם אתם כבר מריצים Docker, השתמשו במכולה במקום זאת:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

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

משיכה והרצה של המודל הראשון שלכם

ollama pull llama3.2:3b
ollama run llama3.2:3b

הפקודה pull מורידה את שכבות המודל לדיסק (כ-2 GB עבור מודל זה). הפקודה run טוענת אותן לזיכרון ומעבירה אתכם לממשק שורת פקודה מסוג >>>. הקלידו שאלה. יצירת ה-token הראשון עשויה להימשך מספר שניות בזמן שהמשקלים נטענים מהדיסק ל-RAM, ולאחר מכן התשובה תוזרם למסך. הקלידו /bye כדי לצאת מהצ'אט; Ollama ימשיך לרוץ ברקע.

בדקו מה טעון וכיצד המודל משתלב במשאבי המערכת:

ollama ps

העמודה PROCESSOR מציגה את המצב לאשורו. הערך 100% CPU מציין שלא נעשה שימוש ב-GPU, וזהו המקור לאיטיות. מדדו את המהירות בפועל באמצעות דגל הפירוט:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

השורה eval rate שנדפסת בסיום מציגה את כמות ה-tokens לשנייה בחומרה זו. זהו הנתון לפיו יש לתכנן את העבודה.

היכן מודלים מאוחסנים, וכמה שטח דיסק לרכוש

לאחר התקנה באמצעות הסקריפט והרצה כשירות, המודלים נשמרים בתיקיית הבית של המשתמש ollama:

sudo du -sh /usr/share/ollama/.ollama/models

בהרצה אינטראקטיבית כמשתמש שלכם, הם נמצאים ב-~/.ollama/models. בתוך ה-container הם מאוחסנים ב-volume ששמו ollama. זה משמעותי מכיוון שמשקלים קוונטיים (quantized weights) מצטברים במהירות: מודל 3B תופס כ-2 GB, מודל 7-8B תופס כ-5 GB, ומודל 14B תופס כ-9 GB. אם תורידו ארבעה מודלים לצורך השוואה, תנצלו 20 GB מבלי להרגיש. תכננו את נפח הדיסק בהתאם למודלים שאתם מתכוונים לשמור, ומחקו את השאר באמצעות ollama rm <model>. אם אותו שרת VPS מריץ כבר שירות בעל צריכת משאבים גבוהה, כגון PhotoPrism או Immich המאחסנים ספריית תמונות, הפחיתו זאת מהשטח הפנוי תחילה והתייחסו למה שנותר כאל תקציב המודלים האמיתי שלכם.

הרצת השירות תחת שליטתך

סקריפט ההתקנה כבר רשם את ollama.service, לכן הוא יופעל מחדש בעת עליית המערכת ללא צורך בפעולה נוספת. ההגדרה שכדאי לשנות היא משך הזמן שבו מודל נשאר בזיכרון, ובחלק מההגדרות גם את כתובת ה-bind; את שניהם יש להגדיר ב-systemd drop-in כדי ששדרוג של Ollama לא ידרוס אותם:

sudo systemctl edit ollama.service

הוסיפו זאת תחת הכותרת [Service] שמוצגת בעורך:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE קובע כמה זמן מודל נשאר בזיכרון לאחר הבקשה האחרונה (ברירת המחדל היא 5 דקות). העלו ערך זה בשרת שבו אתם מבצעים שאילתות לאורך כל היום כדי להימנע מטענת המשקלים מחדש בכל פעם; הגדירו אותו ל-0 בשרת עם משאבים מוגבלים כדי לפנות RAM ברגע שהבקשה מסתיימת. אם ברצונכם להשאיר מודל בזיכרון ללא הגבלת זמן במקום לפרק זמן קצוב, המדריך שמירת מודל Ollama טעון באופן קבוע מסביר על השדה keep_alive בכל בקשה וכיצד לוודא שהמשקלים נטענים מחדש לאחר אתחול במקום להמתין לבקשה הראשונה האיטית. systemctl edit טוען מחדש את קובצי ה-unit עבורכם, לכן בצעו restart כדי להחיל את השינוי:

sudo systemctl restart ollama

נקודת האבטחה החשובה ביותר

כברירת מחדל, Ollama מאזין ל-127.0.0.1:11434, כך שרק תהליכים על ה-VPS עצמו יכולים לגשת אליו. ברירת מחדל זו היא הנכונה. שמרו עליה.

ל-API אין מנגנון אימות. אין לו מפתח API, אין כניסה למערכת ואין הגבלת קצב (rate limit). רשימת המורשים היחידה שקיימת, OLLAMA_ORIGINS, שולטת רק על מקורות דפדפן שיכולים לקרוא לו (CORS); היא אינה מונעת מ-curl או מסקריפט במכונה אחרת לבצע פעולות. כל מי שיכול להגיע לפורט 11434 יכול להריץ כל מודל שהורדתם, להוריד מודלים חדשים, למחוק אותם, ולהעמיס את ה-CPU או ה-GPU שלכם ללא הגבלה. סורקים כמו Shodan מאנדקסים אלפי מופעי Ollama פתוחים, ומופע חשוף מתגלה ומנוצל בתוך שעות.

לכן, זו הטעות היחידה שאסור לעשות: אל תגדירו את OLLAMA_HOST=0.0.0.0 ואל תפתחו את 11434 ב-firewall שלכם. פעולה זו חושפת שרת הסקה (inference) ללא אימות לכל רחבי האינטרנט. שום כמות של הגדרות לא תהפוך את 11434 הגולמי ב-0.0.0.0 למאובטח, כיוון שאף אחת מהגדרות Ollama המתועדות אינה מוסיפה אימות ל-API המקומי, ורשימת מקורות מורשים אינה מהווה כניסה למערכת. זהו כלל הנוגע לשירות ספציפי זה, ולא איסור גורף על פתיחת פורטים: ממסר RustDesk לאירוח עצמי עבור שולחן עבודה מרוחק חייב לקבל תעבורה ציבורית כדי לבצע את עבודתו, והוא מאובטח בזכות מנגנון אימות מבוסס מפתח ורשימה קצרה ומתועדת של פורטים – דברים שחסרים ב-Ollama לחלוטין.

ישנן שלוש דרכים בטוחות לגשת למודל ממקום שאינו השרת עצמו:

• שמרו על גישה מקומית. אם הקורא היחיד הוא תוכנית אחרת על אותו ה-VPS, סקריפט cron, בוט, או שרת MCP המגשר בין הכלים שלכם למודל, השאירו את ה-bind על 127.0.0.1 ותנו לתוכנית ההיא לקרוא ל-http://127.0.0.1:11434. שום דבר לא נחשף ושום דבר נוסף אינו נדרש.
• גשו דרך מנהרה פרטית. הציבו את ה-VPS על רשת WireGuard VPN שאתם מארחים בעצמכם, הגדירו את OLLAMA_HOST לכתובת המנהרה (למשל 10.8.0.1, ולא 0.0.0.0), ורק עמיתי ה-VPN יוכלו להתחבר. האינטרנט הציבורי לא יראה דבר בפורט 11434.
• הציבו reverse proxy עם אימות לפני השירות. בצעו TLS termination ודרשו סיסמה או אסימון ב-nginx, ב-Traefik או ב-Caddy, ולאחר מכן בצעו proxy ל-127.0.0.1:11434. Ollama שומר על ה-bind ל-localhost; ה-proxy הוא הדבר היחיד שמאזין בפורט הציבורי. זהו אותו מבנה כמו הצבת תעודת Let's Encrypt על nginx לפני כל שירות מקומי.

אפשרות ה-reverse proxy היא בדיוק מה שממשק הצ'אט יציע לכם בהמשך, עם מנגנון כניסה אמיתי מצורף.

הוספת ממשק צ'אט עם Open WebUI, מאחורי TLS

Open WebUI הוא ממשק צ'אט לאירוח עצמי. הריצו אותו בתוך Docker והפנו אותו ל-Ollama המקומי:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

הדגל --network=host הוא הפרט החשוב בשרת VPS מבוסס Linux. הוא מציב את ה-container בתוך ה-network namespace של המארח, כך ש-127.0.0.1 בתוך ה-container הוא ה-loopback של המארח עצמו, וה-container מגיע ל-Ollama בכתובת 127.0.0.1:11434 מבלי ש-Ollama יצטרך להאזין בממשק אחר כלשהו. המתכון של bridge-network שתראו במקומות אחרים, --add-host=host.docker.internal:host-gateway עם OLLAMA_BASE_URL=http://host.docker.internal:11434, לא עובד כאן: שם זה מתרגם ל-gateway של ה-bridge ב-Docker, ושירות שמאוגד ל-127.0.0.1 במארח אינו נגיש דרך ה-bridge, לכן Open WebUI פשוט נשאר במצב המתנה ומדווח שהוא לא מצליח להתחבר ל-Ollama.

החיסרון בשימוש ב-host networking הוא ש-Open WebUI מאזין כעת בפורט 8080 של המארח בכל הממשקים; כל מיפוי -p מתבטל, ו-Docker מציג אזהרה על כך. לכן, סגרו את 8080 גם ברמת המארח וגם ב-firewall של ספק הענן, ותנו ל-reverse proxy עם TLS להיות הדלת הציבורית היחידה. בביקור הראשון, Open WebUI יבקש מכם ליצור חשבון מנהל; חשבון זה הוא שכבת האימות שלכם, לכן בחרו סיסמה חזקה.

כדי לפתוח את הצ'אט מהמחשב הנייד שלכם דרך HTTPS, הציבו reverse proxy עם TLS לפני 127.0.0.1:8080. אם אתם כבר מנתבים כמה יישומי Docker על השרת, Traefik עם TLS אוטומטי עבור יישומים רבים הוא הפתרון הנקי ביותר: בלוק labels אחד מנפיק את התעודה ומנתב את chat.example.com אל Open WebUI. אותו ניתוב מבוסס labels לכל יישום הוא מה שכל ממשק דפדפן אחר על השרת ישתמש בו, בין אם מדובר בלוח מחוונים (dashboard) או במשהו משחקי יותר כמו Halcyon, המציג ספריית Jellyfin כחנות השכרת סרטים משנות ה-90, כאשר כל אחד מהם נמצא תחת שם מתחם משלו ומאחורי מנגנון התחברות נפרד. הכלל מסעיף האבטחה עדיין תקף: ה-proxy מחזיק בפורט הציבורי ובמנגנון ההתחברות, בעוד Ollama נשאר ב-localhost והפורט 8080 של Open WebUI נשאר חסום ב-firewall.

שימוש בנקודת קצה תואמת OpenAI מהקוד שלכם

Ollama תומכת בתת-קבוצה של ה-API לצ'אט של OpenAI בכתובת /v1, לכן רוב ספריות הלקוח של OpenAI יעבדו לאחר שינוי של שני דברים: כתובת ה-base URL ומפתח זמני.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

הערך api_key נדרש על ידי ספריית הלקוח אך Ollama מתעלמת ממנו, לכן כל מחרוזת תעבוד. model חייב להיות שם של מודל שכבר הורדתם; שם לא מוכר יחזיר שגיאת 404 עם model 'x' not found. קריאת curl פשוטה פועלת על אותו עיקרון:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

זו גם הדרך לחבר את המודל לכלי סוכנים (agents) ועורכי קוד. אם אתם כבר מפתחים על השרת, מודל מקומי יכול להריץ סקריפטים ותוספים לצד הרצת Claude Code על ה-VPS בתוך tmux, ובכך לשמור עבודת טיוטה זולה ופרטית מחוץ ל-API בתשלום, בעוד משימות הסקה כבדות נשארות עם מודל מאוחסן.

מצבי כשל, עם המחרוזות המדויקות שתראו

התהליך נסגר ("Killed") באמצע יצירת התוכן. אתם מפעילים מודל גדול והטרמינל מדפיס Killed, או שלוג השרת (journalctl -u ollama) מציג שורה שמתחילה ב-llama-server process has terminated. זהו הניסוח ב-Ollama 0.40.7, נכון ל-21 באוקטובר 2026; גרסאות ישנות יותר הציגו llama runner process has terminated: signal: killed. ה-OOM killer של לינוקס עצר את התהליך כיוון שהמודל דרש יותר RAM ממה שיש למכונה. אשרו את הסיבה באמצעות sudo dmesg | grep -i oom, שם תראו שורה כמו Out of memory: Killed process .... הפתרון הוא מודל קטן יותר או מודל שעבר קוונטיזציה (quantization) אגרסיבית יותר, למשל llama3.2:3b במקום 13B, או הוספת swap כך שעומס שחורג במעט מה-RAM הפיזי ימשיך לעבוד לאט במקום לקרוס. ה-swap הופך קריסה מיידית לתשובה איטית; הוא לא הופך מודל 70B למעשי על 4 GB. הסגירה מתבצעת בשקט אלא אם אתם צופים בטרמינל, לכן במכונה שאתם ניגשים אליה מרחוק, צירוף יחידת OnFailure= ל-ollama.service ששולחת הודעה ל-שרת ntfy שאתם מארחים עבור התראות push תודיע לכם ברגע שהתהליך קורס במקום שתגלו זאת רק בבקשה הבאה.

Ollama מסרב לטעון את המודל. הבקשה נכשלת מיד עם שגיאה במקום לקרוס, ולוג השרת מתעד model is too large for system memory (Ollama 0.40.7, נכון ל-21 באוקטובר 2026). גרסאות ישנות יותר הדפיסו Error: model requires more system memory (X GiB) than is available (Y GiB) ישירות בשורת הפקודה. זו הגרסה המנומסת לקריסה שתוארה לעיל: Ollama ביצע את החישוב ועצר במקום לתת ל-OOM killer לעשות זאת. בחרו מודל שדרישות הזיכרון שלו נמוכות מה-RAM הפנוי שלכם (בדקו עם free -h), קצרו את אורך ה-context, או עברו ל-VPS גדול יותר. אין flag שיגרום למודל להיכנס לזיכרון, הזיכרון הוא פיזי.

הטוקן הראשון לוקח נצח, ואז הכל תקין. מודל "קר" לא מדפיס דבר במשך חמש עד שלושים שניות, ואז מזרים טקסט כרגיל. ההשהיה הזו היא טעינת המשקולות מהדיסק ל-RAM בפעם הראשונה, ואחסון איטי מחמיר זאת. לאחר הטעינה, המודל נשאר בזיכרון למשך הזמן של OLLAMA_KEEP_ALIVE, כך שהבקשה השנייה נענית מיידית. אם הטעינה הראשונה חורגת מ-timeout כלשהו בנתיב הקריאה, תקבלו שגיאה במקום תשובה איטית, ו-בדיקה איזה layer דיווח על context deadline exceeded תגלה לכם אם הלקוח, ה-proxy או הטעינה עצמה איבדו סבלנות. העלו את הערך הזה אם ההשהיות מפריעות לכם, והשתמשו ב-ollama ps כדי לראות אם מודל טעון כרגע.

הכל פשוט איטי. עשרה טוקנים לשנייה או פחות, ללא שגיאה כלל. זהו הסקה (inference) על גבי ה-CPU שעושה בדיוק את מה שהסקה על CPU עושה. ollama ps מציג 100% CPU, מה שאומר שאין GPU. זו אינה תקלה, ושום הגדרה לא תהפוך CPU ל-GPU, כיוון שהמגבלה העיקרית היא רוחב פס של הזיכרון. הגדרה אחת שווה בדיקה ב-VM: Ollama בוחר את מספר ה-threads לפי ליבות פיזיות שהוא מזהה, ו-hypervisor עלול לדווח עליהן בצורה שגויה. בסשן ollama run --verbose, נסו את /set parameter num_thread 4 (או את מספר ה-vCPU שלכם), הריצו שוב את אותה בקשה, ושמרו על הערך שנותן את ה-eval rate הטוב ביותר. מעבר לכך, השתמשו במודל קטן יותר, קבלו את המהירות, או עברו ל-instance עם GPU, ומדדו את הקצב האמיתי שלכם עם --verbose לפני שתחליטו שמשהו שבור. כאשר ההמתנה נובעת מאורך התשובה ולא מהקצב, הגבלת התשובה עם num_predict תמנע ממודל שאוהב להאריך בדברים לבזבז דקות על טוקנים שמעולם לא התכוונתם לקרוא.

חיבור נדחה (Connection refused) ממכונה אחרת. מהמחשב הנייד שלכם, פקודת curl עדכנית (8.23.0, נכון ל-21 באוקטובר 2026) מדפיסה curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server, וה-curl 8.5.0 שמגיע עם Ubuntu 24.04 מדפיס curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server. המילים "Connection refused" יופיעו רק אם תוסיפו -v, בשורה שקוראת connect to <ip> port 11434 from ... failed: Connection refused. זה עובד כמתוכנן: Ollama מאזין ל-localhost בלבד. אל "תתקנו" זאת על ידי האזנה ל-0.0.0.0, שזו בדיוק טעות החשיפה שתוארה לעיל. גשו למודל דרך ה-VPN או דרך ה-proxy המאמת.

חשפתם את 11434 לאינטרנט. אם הגדרתם OLLAMA_HOST=0.0.0.0, פתחתם את ה-firewall, וכעת אתם רואים משיכות מודלים שלא התחלתם או שה-CPU ב-100% בגלל לקוחות לא מוכרים, מצאו אתכם והשתמשו בכם. זו טעות חמורה, לא מקרה קצה. החזירו את ההאזנה ל-127.0.0.1 או לכתובת ה-VPN, סגרו את 11434 ב-firewall, והוסיפו אימות גישה. הניחו שכל מה שהיה נגיש בכתובת הזו בזמן שהייתה פתוחה נסרק על ידי זרים.

גיבויים ושדרוגים

יש מעט מאוד מידע שעלול ללכת לאיבוד. ניתן להוריד את המודלים מחדש, לכן הדברים היחידים שראוי לגבות הם נפח הנתונים (volume) של Open WebUI, חשבונות משתמשים, היסטוריית צ'אטים, הגדרות, וכל קובץ drop-in של systemd שיצרתם. בצעו גיבוי לנפח הנתונים באמצעות מכולה זמנית:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

שדרגו את Ollama על ידי הרצה חוזרת של סקריפט ההתקנה; שדרגו את Open WebUI באמצעות docker pull ghcr.io/open-webui/open-webui:main ולאחריו יצירה מחדש של המכולה. הערה בנוגע לדיסק עבור סדרת הגרסאות 0.40: החל מגרסה 0.40.2, Ollama החלה לשדרג ברקע מודלים שהורדו בגרסאות קודמות ושומרת את העותקים המקוריים כגיבוי, לכן הם תופסים שטח דיסק נוסף עד למחיקתם. גרסה 0.40.3 (11 באוקטובר 2026) השהתה את שדרוג הרקע הזה. בדקו את df -h לאחר שדרוג, וקראו את הערות השחרור (release notes) כדי למצוא את הפקודה המוחקת את הגיבויים הללו. אל תקבעו גרסאות (pin) לטווח ארוך: גם איכות המודלים וגם סביבת הריצה מתקדמים במהירות, לכן קראו את הערות השחרור ובצעו בדיקות ביצועים (benchmarking) על השרת שלכם במקום להסתמך על נתונים מהרבעון הקודם.

FAQ

האם באמת ניתן להריץ LLM על שרת VPS ללא GPU?

כן, תחת מגבלות מסוימות. מודלים קטנים ומקוונטטים (quantized) בטווח של 3B עד 8B רצים על CPU ושימושיים למדי לטיוטות, סיכומים וסיווג, אם כי באיטיות – בקצב של ספרה אחת או שתיים של tokens לשנייה על vCPU משותף. כל מודל מ-13B ומעלה יהיה איטי בצורה קיצונית או שלא ייכנס כלל ל-RAM. למהירות עבודה אמיתית או עבור מודלים גדולים יותר, יש צורך במופע (instance) עם GPU.

כמה RAM דורש כל מודל?

כלל אצבע עבור תגיות 4-bit (Q4), הנפוצות ביותר בשימוש במודלים פופולריים: כ-0.5 GB של RAM לכל מיליארד פרמטרים עבור המשקולות (weights), בתוספת של כ-1 GB עבור תקורה (overhead) ועוד מעט עבור ה-context. לכן, מודל 3B דורש כ-4 GB פנויים, מודל 7-8B דורש כ-8 GB, ומודל 14B דורש כ-16 GB. בדקו את המרווח הפנוי שלכם באמצעות free -h והשאירו מקום למערכת ההפעלה ולכל תהליך אחר על השרת.

האם ה-API של Ollama מאובטח באמצעות אימות?

לא. ל-Ollama אין מנגנון אימות מובנה, מפתח API או הגבלת קצב (rate limit); לכל מי שיכול להגיע לפורט 11434 יש שליטה מלאה עליו. הגדרת ה-OLLAMA_ORIGINS שלו מגבילה רק אילו מקורות דפדפן (origins) רשאים לקרוא לו, ולא מי יכול להתחבר. זו בדיוק הסיבה שהוא מאזין ל-127.0.0.1 כברירת מחדל, וזו הסיבה שאסור לכם לחשוף את 11434 ב-0.0.0.0 לאינטרנט. גשו אליו מקומית, דרך VPN פרטי, או דרך reverse proxy שמוסיף שכבת התחברות.

איך מוסיפים ממשק צ'אט מבוסס דפדפן?

הריצו את Open WebUI בתוך Docker עם --network=host כדי שישתף את ה-loopback של המארח ויגיע ל-Ollama המקומי ב-http://127.0.0.1:11434, לאחר מכן הציבו TLS reverse proxy לפני פורט 8080 שלו לצורך גישה מהמחשב האישי. השאירו את 8080 סגור ב-firewall כך שה-proxy יהיה השער הציבורי היחיד. חשבון ה-admin של Open WebUI מספק את ההתחברות, ואת הסיסמה מגדירים בהפעלה הראשונה.

איך קוראים למודל מהיישום שלי?

השתמשו ב-endpoint התואם ל-OpenAI בכתובת http://127.0.0.1:11434/v1. כוונו כל OpenAI SDK לכתובת ה-base URL הזו, העבירו כל מחרוזת שהיא בתור מפתח ה-API (מכיוון שהוא מתעלם ממנו), והגדירו את model לשם של מודל שכבר הורדתם. קוד קיים של OpenAI רץ בדרך כלל ללא שינויים, מלבד ה-base URL והמפתח.