איך להריץ Ollama ב-VPS בצורה בטוחה

מה אתם בונים

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

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

בדיקת תקינות גודל המודל, במספרים פשוטים

צריכת הזיכרון של מודל היא בערך גודל הקובץ שלו, בתוספת כ-1 GB של overhead בזמן ריצה, ועוד מעט עבור ה-context window. המודלים الافتراضيים של Ollama הם ב-quantization של 4-bit (מסומנים כ-Q4), מה שצורך כחצי ג'יגה 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 — ב-CPU VPS המודל לא ייכנס בזיכרון או שיתן תשובות לאט כל כך עד שלא ניתן יהיה להשתמש בו.

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

המסקנה המעשית: מודלים קטנים ו-quantized על CPU מועילים באמת לכתיבת טיוטות, סיכום וסיווג, אם ניתן להשלים עם המהירות. לכל דבר גדול או מהיר יותר, יש להקצות תקציב עבור instance עם GPU.

כדי להשוות מודל ספציפי מול מכשיר ספציפי, אמידו את צריכת הזיכרון שלו כאן:

Install Ollama

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

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

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

systemctl status ollama
ollama --version

אם אתם כבר משתמשים ב-Docker, השתמשו ב-container:

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

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

Pull and run your first model

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

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

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

ollama ps

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

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

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

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

המודלים מותקנים על ידי ה-script ורצים כשירות (service). הם נמצאים בתיקיית הבית של המשתמש ollama:

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

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

הרץ אותו כשירות (service) בשליטתך

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

sudo systemctl edit ollama.service

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

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

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

sudo systemctl restart ollama

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

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

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

לכן, זו הטעות היחידה שאסור לעשות: אל תגדירו את OLLAMA_HOST=0.0.0.0 ואל תפתחו את פורט 11434 ב-firewall שלכם. פעולה זו מפרסמת שרת הסקה (inference server) ללא אימות לכל האינטרנט. שום רמת הגדרה לא תהפוך את פורט 11434 גלוי ב-0.0.0.0 לבטוח, מכיוון שאין ב-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), ורק צמתים (peers) ב-VPN יוכלו להתחבר. האינטרנט הציבורי עדיין לא יראה דבר בפורט 11434.
• הציבו Reverse Proxy עם אימות לפניו. בצעו TLS termination ודרשו סיסמה או טוקן ב-nginx, Traefik, או Caddy, ולאחר מכן בצעו proxy ל-127.0.0.1:11434. Ollama ישמור על ה-localhost bind שלו; ה-proxy הוא היחיד שמאזין לפורט הציבורי. זהו אותו מבנה כמו הוספת תעודת Let's Encrypt ל-nginx לפני שירות מקומי כלשהו.

אופציית ה-reverse-proxy היא בדיוק מה שממשק ה-chat UI יספק לכם בשלב הבא, עם התחברות אמיתית.

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

Open WebUI הוא ממשק צ'אט המופעל באופן עצמאי (self-hosted). ניתן להריץ אותו בתוך 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 הוא פרט קריטי ב-Linux VPS. הוא מכניס את ה-container ל-network namespace של ה-host. כתוצאה מכך, 127.0.0.1 בתוך ה-container הוא ה-loopback של ה-host, וה-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 של ה-Docker bridge, ושירות שמוגדר ב-127.0.0.1 ב-host אינו נגיש דרך ה-bridge. לכן Open WebUI פשוט יציג שגיאה על חוסר יכולת להתחבר ל-Ollama.

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

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

שימוש ב-endpoint תואם OpenAI מהקוד שלך

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

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 נדרש על ידי ספריית ה-client אך נIgnore על ידי Ollama, לכן ניתן להשתמש בכל מחרוזת. ה-model חייב להיות שם של מודל שכבר הורדת (pulled); שם לא מוכר יחזיר את השגיאה model "x" not found, try pulling it first. גם קריאת 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"}]}'

זוהי גם הדרך לחבר את המודל לכלי agent ו-editor. אם אתה מפתח כבר על השרת, מודל מקומי יכול לתמוך בסקריפטים ובתוספים לצד Claude Code running on the VPS inside tmux. כך ניתן לבצע עבודת טיוטה זולה ופרטית ללא שימוש ב-API בתשלום, בעוד שהחשיבה המורכבת נשארת עם מודל מארח.

Failure modes, with the exact strings you will see

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

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

ה-token הראשון לוקח זמן רב, ואז הכל תקין. מודל ב-cold state לא מדפיס דבר במשך חמש עד שלושים שניות, ואז מתחיל לזרום (stream) כרגיל. ההשהיה הזו היא טעינת ה-weights מהדיסק לתוך ה-RAM בפעם הראשונה, ואחסון איטי מחמיר את המצב. לאחר הטעינה, המודל נשאר בזיכרון למשך OLLAMA_KEEP_ALIVE, ולכן הפרומפט השני מקבל תשובה מיידית. הגדל ערך זה אם ההשהיות מפריעות לך, והשתמש ב-ollama ps כדי לראות אם מודל טעון כעת.

הכל פשוט איטי. עשרה tokens בשנייה או פחות, ללא שום שגיאה. זהו inference על ה-CPU הפועל כפי ש-CPU inference אמור לפעול. ollama ps מראה 100% CPU, מה שאומר שאין GPU. זו אינה תקלה ואין הגדרה שתתקן זאת, כיוון שהמגבלה היא רוחב פס הזיכרון (memory bandwidth) ולא הגדרה שגויה. השתמש במודל קטן יותר, קבל את המהירות, או עבור ל-instance עם GPU — ומדוד את המהירות האמיתית שלך באמצעות --verbose לפני שתחליט שמשהו שבור.

Connection refused from another machine. מהלפטופ שלך תקבל curl: (7) Failed to connect to <ip> port 11434: Connection refused. זהו מצב תקין: Ollama קשורה (binds) ל-localhost בלבד. אל תנסה "לתקן" זאת על ידי קשירה ל-0.0.0.0, שזו בדיוק טעות החשיפה המתוארת לעיל. נסה לגשת למודל דרך ה-VPN או דרך proxy עם אימות (authentication).

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

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

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

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

שדרגו את Ollama על ידי הרצה מחדש של script ההתקנה; שדרגו את Open WebUI באמצעות docker pull ghcr.io/open-webui/open-webui:main ולאחר מכן צרו מחדש את ה-container. אל תתקעו גרסאות לטווח ארוך: גם איכות המודלים וגם סביבת ההרצה משתנות במהירות, לכן יש לקרוא את ה-release notes ולבצע benchmark מחדש על המכשיר שלכם במקום להסתמך על נתונים מהרבעון הקודם.

FAQ

האם ניתן באמת להריץ LLM על VPS המבוסס על CPU בלבד?

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

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

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

האם ה-Ollama API מאומת?

לא. ל-Ollama אין אימות מובנה, API key או הגבלת קצב (rate limit) — לכל מי שיכול להגיע ל-port 11434 יש שליטה מלאה עליו. זו בדיוק הסיבה שהוא קושר (binds) את 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 לפני ה-port 8080 שלו לצורך גישה מהלפטופ. יש להשאיר את 8080 סגור ב-firewall כך שה-proxy יהיה הפתח הציבורי היחיד. חשבון ה-admin של Open WebUI מספק את ההתחברות, ואת הסיסמה שלו קובעים בהפעלה הראשונה.

איך קוראים לו מתוך אפליקציה משלי?

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