Ollama או llama.cpp: מה מתאים להרצה על VPS?

Ollama לעומת llama.cpp: באיזו שכבה כדאי להשתמש?

Ollama ו-llama.cpp אינם מתחרים במובן שהשאלה מרמזת עליו. llama.cpp הוא מנוע ההסקה (inference engine): הוא טוען קובץ מודל והופך הנחיה (prompt) לטוקנים. Ollama הוא מנהל מודלים, daemon שרץ ברקע ו-API מסוג HTTP שיושב מעל המנוע הזה. ה-README של Ollama עדיין מציין את llama.cpp כ-backend ההסקה שלו (נכון ל-2 באוגוסט 2026). לכן, השאלה האמיתית היא באיזו שכבה ברצונכם להשתמש ב-VPS שלכם, ולא איזו מהן מהירה יותר.

הריצו את Ollama כאשר אתם זקוקים לשירות שמושך מודלים לפי שם וממשיך לעבוד ללא צורך בתחזוקה. הריצו את llama.cpp ישירות כאשר השרת קטן ואתם צריכים לבחור במדויק את קובץ המודל, את גודל ההקשר (context size) ואת מספר התהליכונים (thread count), כיוון שב-VPS קטן כל אחת מההגדרות הללו צורכת זיכרון שאינו זמין לכם.

מהות הפרויקטים

llama.cpp היא מימוש של הסקת (inference) מודלי Transformer בשפות C ו-C++, הבנוי על גבי ספריית ggml. הפרויקט קורא קובצי GGUF. פורמט GGUF (ראשי תיבות של GGML universal file format) הוא מכולה (container) בקובץ יחיד המכילה את המשקולות, ה-tokeniser והמטא-דאטה שהמנוע דורש כדי להריץ את המודל. הפרויקט מפיץ קובצי binary נפרדים למשימות שונות. llama-server הוא שרת HTTP, llama-cli הוא ממשק אינטראקטיבי, ו-llama-bench מודד את קצב העיבוד (throughput). הגרסאות מסומנות לפי מספר build ולא לפי גרסאות סמנטיות. התגית הנוכחית היא b10224, שפורסמה ב-2 באוגוסט 2026, ותגית חדשה יוצאת ברוב ימי העבודה.

Ollama היא תוכנית שנכתבה ב-Go. דמון (daemon) ברקע, המופעל באמצעות ollama serve, טוען מודלים ומשיב לבקשות HTTP, ולקוח שורת פקודה מתקשר עם דמון זה. מאחורי שניהם עומד מאגר (registry) בכתובת ollama.com המכיל מודלים ארוזים מראש. Ollama משתמשת בגרסאות סמנטיות, וגרסה v0.32.5 שוחררה ב-27 ביולי 2026. הפקודה ollama pull מורידה קובץ GGUF יחד עם תבנית prompt וקבוצת פרמטרים כברירת מחדל, ואז שומרת אותו תחת /usr/share/ollama/.ollama/models במערכות Linux.

האריזה היא ההבדל המהותי. Ollama מחליטה עבורכם על הקוונטיזציה (quantisation), התבנית ואורך ההקשר (context length), ומספקת שם אחד לזכירה. llama.cpp אינה מחליטה דבר ומספקת לכם דגלים (flags).

ציר 1: בקרת מודל וקוונטיזציה

קוונטיזציה מצמצמת כל משקל מ-16 או 32 ביט ל-4, 5 או 8 ביט. זה מה שמאפשר למודל עם 8 מיליארד פרמטרים להיכנס לזיכרון ה-RAM של שרת VPS רגיל. שמות הקבצים בפורמט GGUF הופכים לקריאים ברגע שמכירים את התבנית: Q4_K_M פירושו קוונטיזציה מסוג K-quant של 4 ביט, בגודל בינוני. מספר גבוה יותר שומר על דיוק רב יותר אך דורש יותר זיכרון.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

אלו גדלי הקבצים שפורסמו במאגר bartowski/Meta-Llama-3.1-8B-Instruct-GGUF ב-Hugging Face, כפי שנקראו ב-2 באוגוסט 2026 ותורגמו מבתים ל-GiB. ישנן 6 גרסאות של מודל אחד, כאשר הקטנה ביותר היא 2.96 GiB לעומת 7.95 GiB לגדולה ביותר. ברירת המחדל הנפוצה, Q4_K_M, היא 4.58 GiB. בשרת VPS עם 4 GiB, בחירה בודדת זו קובעת האם המודל ייטען בכלל.

ב-llama.cpp אתם מציינים את שם הקובץ, לכן אתם בוחרים את השורה בעצמכם.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c הוא גודל ההקשר (context size) בטוקנים, -t הוא מספר ה-threads, ו--ngl קובע כמה שכבות יועברו ל-GPU (ערך 0 בשרת מבוסס CPU בלבד). שום דבר לא מנוחש עבורכם.

ב-Ollama הקוונטיזציה נגזרת מהתגית שאתם מושכים, ו-ollama ls מציג מה יש לכם בפועל על הדיסק. כאשר ה-registry לא מכיל את הגרסה הרצויה לכם, ייבאו קובץ GGUF בעצמכם. כתבו Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

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

ollama create llama31-q4 -f ./Modelfile
ollama ls

אורך ההקשר הוא ההגדרה שמכשילה משתמשים רבים. Ollama בוחרת את ברירת המחדל שלה לפי ה-VRAM הזמין, ושרת ללא GPU נופל לקטגוריה הקטנה ביותר: 4096 טוקנים. אם תשלחו מסמך של 20,000 טוקנים, הטוקנים העודפים יימחקו לפני שהמודל יראה אותם, ולכן התשובה תהיה שגויה בביטחון מלא לגבי קובץ שנקרא רק בחציו. הגדילו את הערך באמצעות OLLAMA_CONTEXT_LENGTH ב-daemon, או באמצעות PARAMETER num_ctx בתוך Modelfile. גם ל-llama.cpp אין ברירת מחדל שאפשר לסמוך עליה. הגדירו -c במפורש ודעו מה הגדרתם.

החשבון האמיתי של צריכת הזיכרון

קובץ המודל אינו העלות היחידה. ה-KV cache (מטמון מפתחות/ערכים) מחזיק רשומה אחת לכל שכבה עבור כל טוקן בהקשר, והוא גדל ככל שהשיחה מתארכת.

נבצע את החישוב עבור Llama 3.1 8B. למודל יש 32 שכבות, 8 ראשי מפתח/ערך ומימד ראש של 128. כל טוקן מאחסן מפתח וערך ב-2 בתים כל אחד בפורמט f16, כלומר 2 x 8 x 128 x 2 = 4096 בתים לכל שכבה. על פני 32 שכבות מדובר ב-128 KiB לכל טוקן. לכן, הקשר של 4096 טוקנים עולה 512 MiB, והקשר של 32,768 טוקנים עולה 4 GiB.

לפיכך, מודל Q4_K_M 8B עם הקשר של 4k דורש בערך 4.58 GiB עבור המשקולות, בתוספת כ-0.5 GiB עבור המטמון, ועוד צריכת הזיכרון של סביבת ההרצה עצמה. הוא לא ייכנס ב-4 GiB של RAM. הוא יתאים ל-8 GiB עם מרווח עבודה. אם תעלו את ההקשר ל-32k על אותה מכונה של 8 GiB, המטמון לבדו יבלע את כל יתרת הזיכרון. עקבו אחר הנתונים בזמן אמת עם free -h בזמן שהמודל נטען, ואל תסתמכו על הערכה שלא מדדתם בעצמכם.

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

ציר 2: ה-daemon שעליך להפעיל

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

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE חשוב יותר בשרת VPS מבוסס CPU מאשר בכל מקום אחר. מודלים נשמרים בזיכרון למשך 5 דקות כברירת מחדל ולאחר מכן מוסרים ממנו. הבקשה הבאה מחייבת קריאה חוזרת של כל הקובץ מהדיסק לפני שניתן להשיב, כך שרענון של 4.58 GiB הופך תגובה של שתי שניות לתגובה של שלושים שניות באחסון איטי. הגדרת keep-alive ארוך פותרת את השיהוי אך תופסת את ה-RAM לצמיתות. לשתי האפשרויות יש עלות ממשית. בחר את זו שפוגעת בך פחות.

llama.cpp אינו מספק daemon, לכן עליך לכתוב את היחידה בעצמך כ-/etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

הפעל אותה באמצעות sudo systemctl enable --now llama-server. התהליך מחזיק את המודל לאורך כל זמן פעולתו. דבר אינו מתפנה בזמן המתנה, מה שאומר שאין הפתעות של טעינה מחדש ואין דרך לשחרר את הזיכרון מלבד עצירת השירות. אם כתיבת יחידות היא תחום חדש עבורך, מדובר באותו דפוס כמו ב-הרצת שירותים עצמאיים תחת systemd ב-VPS.

ציר 3: ה-API שאליו היישום שלך יתקשר

ציר זה הצטמצם משמעותית. שני הפרויקטים תומכים כעת בפורמט ה-chat של OpenAI, כך שרוב ספריות הלקוח עובדות מול שניהם לאחר שינוי של כתובת ה-base URL בלבד.

Ollama מאזין ב-127.0.0.1:11434. הנתיב התואם ל-OpenAI שלו הוא http://localhost:11434/v1/chat/completions, והוא ממשיך להחזיק API מקורי ב-/api/chat במקביל. כמו כן, מתועד נתיב תואם ל-Anthropic.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server מאזין ב-127.0.0.1:8080 ומגיש את /v1/chat/completions, /v1/completions ו-/v1/embeddings, בנוסף ל-endpoint מקורי משלו ב-/completion וממשק אינטרנט מובנה. הוא גם חושף נתיבים תפעוליים ש-Ollama אינו מציע: /health לבדיקת מוכנות (readiness probe), /props להגדרות המודל הטעון, /slots לניטור פעילות של כל slot בקשה, ו-/metrics בפורמט Prometheus. אם בכוונתך לנטר שירות זה, ייתכן שהבדל זה הוא שיכריע את הבחירה.

אף אחד מהשרתים אינו מפעיל אימות (authentication) כברירת מחדל. שניהם מוגדרים כברירת מחדל ל-loopback מסיבות טובות. יש לגשת אליהם דרך מנהרת SSH או מאחורי reverse proxy, ולעולם אין לפתוח את 11434 או 8080 לאינטרנט.

מה שרת VPS מבוסס CPU בלבד יכול לעשות בפועל

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

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

העמודה pp מייצגת את מהירות עיבוד ה-prompt, והעמודה tg מייצגת את מהירות יצירת ה-tokens, שתיהן ב-tokens לשנייה. בתוכנית vCPU משותפת, מודל 8B בפורמט Q4_K_M מגיע בדרך כלל לערכים חד-ספרתיים נמוכים ב-tg. עיבוד ה-prompt הוא החלק הבעייתי: כל ה-prompt מעובד לפני שמופיע ה-token הראשון, לכן prompt מערכת ארוך מוסיף זמן המתנה לכל בקשה.

שימושי על CPU: מודל בגודל 1B עד 4B לביצוע סיווג, חילוץ נתונים, סיכומים קצרים או ניתוב. התשובות מגיעות תוך שניות והזיכרון מתאים לתוכנית סטנדרטית. לא שימושי על CPU: צ'אט אינטראקטיבי במהירות קריאה, עוזרי כתיבת קוד, עבודה על מסמכים ארוכים, או כל דבר הכולל לולאת סוכן (agent loop) המבצעת קריאות רבות ברצף. לולאה שמבצעת שתים-עשרה קריאות של ארבע שניות כל אחת, תיקח דקה לפני שתפיק תוצאה כלשהי.

ישנן שתי דרכים לצאת מהמצב כאשר המספרים אינם מספקים. אם הבעיה היא במקביליות (concurrency) – משתמשים רבים הפונים למודל אחד בו-זמנית – בחירת המנוע משתנה, ו-השוואה בין Ollama ל-vLLM עבור הגשה מקבילית מכסה נושא זה. אם הבעיה היא במהירות גולמית, הפתרון הוא שרת VPS עם GPU מחובר, שם ה--ngl מתחיל להיות משמעותי. לפני כל אחד מהם, קבעו נקודת ייחוס (baseline) לחומרה עצמה, כיוון שרוחב הפס של הדיסק והזיכרון משפיעים על זמן הטעינה לא פחות מה-CPU. ביצוע benchmark חוזר ל-VPS שווה את השעה שתשקיעו בכך.

התקנת llama.cpp, בגרסה מקובעת

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

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

כדי לקבע גרסה ספציפית, הורידו את קובץ ה-tarball המוכן מראש מדף ה-releases. גרסה b10224 היא התג העדכני נכון ל-2 באוגוסט 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

לחלופין, ניתן לבנות את אותו התג מתוך קוד המקור:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev הוא התלות המתועדת עבור תכונות HTTPS. תהליך ההידור (compile) אורך מספר דקות ודורש יותר זיכרון RAM ממה שזמין בתוכניות האירוח הקטנות ביותר; אם השרת הקטן קורס, בצעו את הבנייה על שרת חזק יותר והעתיקו את הקבצים הבינאריים.

התקנת Ollama, בגרסה מקובעת

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

הסקריפט קורא את OLLAMA_VERSION, כך שניתן לקבע גרסה יציבה ומוכרת במקום להשתמש בכל מה ששוחרר הבוקר. הגרסה v0.32.5 פורסמה ב־27 ביולי 2026. קיימת גם דרך ידנית אם אינכם מעוניינים להריץ סקריפט ישירות לתוך ה-shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

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

מצבי כשל והודעות שגיאה נפוצות

Ollama מסרב לטעון את המודל. ollama run מחזיר שורה במבנה הבא:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

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

llama.cpp לא נכשל, אלא עובד באיטיות קיצונית. כברירת מחדל, llama.cpp מבצע memory-map לקובץ ה-GGUF, כך שקובץ הגדול מה-RAM עדיין יתחיל לעבוד. ה-kernel יבצע החלפת דפים (paging) של המשקולות מהדיסק בכל token, ומהירות היצירה תרד לשניות לכל token, כאשר הדיסק יהיה ב-100 אחוז ניצול. העבירו את הדגל --no-mmap כדי לכפות הקצאה ממשית, כך שהתהליך ייכשל מיד במקום להאט את המערכת. כאשר ה-kernel מתערב, dmesg יציג את הסיבה:

Out of memory: Killed process 1234 (llama-server)

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

error loading model architecture: unknown model architecture: 'qwen3next'

הפתרון הוא שדרוג המנוע, לא החלפת הקובץ. זהו המחיר של קיבוע גרסאות (pinning), וזו הסיבה שעליכם לתעד את מספר ה-build. עליכם לדעת מאיזו גרסה אתם משדרגים.

ה-API מגיב מקומית אך לא מהיישום שלכם. Ollama מאזין ל-127.0.0.1:11434, לכן מארח אחר יקבל שגיאת connection refused. הגדירו את OLLAMA_HOST=0.0.0.0:11434 דרך systemctl edit ollama רק כאשר הפורט נמצא מאחורי firewall או רשת פרטית, כיוון של-API אין מנגנון אימות מובנה.

התגובה הראשונה לאחר הפסקה איטית מאוד. התרחש תהליך ה-unload עקב חוסר פעילות של 5 דקות, והמודל נקרא שוב מהדיסק. הרצת ollama ps רגע לפני הבקשה תראה ששום דבר אינו טעון, מה שמאשר זאת. הגדילו את הערך של OLLAMA_KEEP_ALIVE.

אז באיזו אפשרות כדאי לבחור?

הריצו את Ollama כאשר אתם מעוניינים בניהול מודלים אוטומטי ובנקודת קצה (endpoint) בתבנית OpenAI ללא מאמץ נוסף. זוהי ברירת המחדל המומלצת עבור פריסה ראשונית, ועבור כל תרחיש שבו בחירת המודל עשויה להשתנות.

הריצו את llama.cpp ישירות כאשר זיכרון המערכת מוגבל במידה שמחייבת אתכם לבחור ידנית את רמת ה-quantisation, כאשר אתם זקוקים ל-/health, /slots ו-/metrics לצורכי ניטור, או כאשר נדרש flag ש-Ollama אינה חושפת. זוהי הבחירה המקצועית עבור שרת VPS שבו המודל בקושי נכנס בזיכרון, שכן ההגדרות המאפשרות את הרצתו הן בדיוק אלו ש-Ollama בוחרת עבורכם באופן אוטומטי.

הרצה של שניהם במקביל היא תקינה. השתמשו ב-Ollama לניסויים, וב-llama.cpp עבור המודל היחיד שאתם מעלים לסביבת production ושאינכם מתכננים לשנות.

FAQ

האם Ollama הוא רק מעטפת (wrapper) סביב llama.cpp?

קרוב לכך, אך המעטפת מבצעת עבודה ממשית. ה-README של Ollama מציין את llama.cpp כמנוע ה-inference שלו (נכון ל-2 באוגוסט 2026). מעליו, Ollama מוסיף רישום מודלים (model registry), תבנית prompt שהופכת הודעות צ'אט ל-prompt, קבוצת פרמטרי דגימה (sampling parameters) כברירת מחדל, daemon שמבצע פריקה (unloading) בזמן המתנה, ו-HTTP API. כאשר משווים את מספר ה-tokens לשנייה בהגדרות זהות, משווים למעשה את אותו מנוע לעצמו. הבחירה האמיתית היא בין שכבות הניהול.

מה מהיר יותר על שרת VPS ללא GPU?

הם חולקים את אותו מנוע, לכן באותו קובץ מודל, רמת קוונטיזציה (quantisation), גודל הקשר (context size) ומספר threads, הביצועים יהיו דומים מאוד. הבדלים שמדווחים על ידי משתמשים נובעים בדרך כלל מהגדרות ברירת מחדל שונות, לרוב אורך ההקשר ומספר ה-threads, ולא מהמנוע עצמו. מדדו זאת בעזרת llama-bench -m <file> -p 512 -n 128 והשוו את עמודת tg על השרת שלכם לפני שאתם מסתמכים על נתונים שפורסמו.

האם ניתן להשתמש בקובץ GGUF משלי עם Ollama?

כן. הניחו את הקובץ על השרת, כתבו Modelfile שהשורה הראשונה בו היא FROM ./your-model.gguf, הוסיפו כל שורת PARAMETER שנדרשת לכם, כגון num_ctx, ולאחר מכן הריצו את ollama create your-name -f ./Modelfile. הפקודה ollama ls תציג את המודל לצד כל מודל שהורדתם מה-registry. כך ניתן להשתמש ברמת קוונטיזציה שאינה קיימת ב-registry.

כמה זיכרון RAM דרוש עבור מודל 8B?

חשבו את גודל הקובץ, בתוספת ה-KV cache, בתוספת זמן הריצה. גרסת Q4_K_M של Llama 3.1 8B תופסת כ-4.58 GiB על הדיסק, והקשר (context) של 4096 tokens מוסיף בערך 512 MiB של cache, לכן 8 GiB של RAM הם כמות נוחה ו-4 GiB אינם מספיקים. ה-cache גדל בהתאם להקשר: אותו מודל עם הקשר של 32,768 tokens דורש כ-4 GiB של cache בפני עצמו. ב-Ollama, זכרו שהדרישות גדלות גם בהתאם ל-OLLAMA_NUM_PARALLEL.