Ollama או vLLM: מה לבחור להרצת מודלי שפה?

Ollama לעומת vLLM, בפסקה אחת

Ollama הוא מנהל מודלים הכולל שרת מובנה: הוא מוריד משקולות שעברו קוונטיזציה (quantized weights), טוען אותן ומשיב בפורט 127.0.0.1:11434, גם על גבי CPU אם זה המשאב היחיד הזמין במכונה. לעומתו, vLLM הוא מנוע להגדלת תפוקה (throughput engine): הוא שומר על ה-GPU עמוס בבקשות רבות המעובדות במקביל, ולכן הוא אינו הכלי המתאים למכונה ללא מאיץ גרפי. זהו כלל ההחלטה המרכזי. עבור משתמש יחיד המשוחח עם עוזר מקומי, Ollama הוא הפתרון הנכון. עבור יישום המשרת צוות שלם, יש להשתמש ב-vLLM.

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

מהו Ollama בפועל

Ollama הוא שכבת נוחות. הוא מספק רישום מודלים (ollama pull llama3.1:8b), אחסון מקומי של משקולות, ממשק צ'אט, שירות systemd ו־HTTP API, והכל בהתקנה אחת. המודלים שהוא מגיש הם קובצי GGUF, בדרך כלל בקוונטיזציה של 4-bit, וזו הסיבה שמודל של 7B או 8B תופס כ־5 GB על הדיסק במקום 16 GB. קוונטיזציה היא מה שמאפשר הסקה (inference) על גבי מעבד (CPU) מלכתחילה.

מנוע ההרצה שלו בנוי על גבי llama.cpp, ספריית ה־C++ להסקה שהפכה קוונטיזציית GGUF למעשית על חומרה סטנדרטית. מאז, Ollama הוסיף מנוע משלו עבור כמה משפחות מודלים חדשות יותר, אך llama.cpp נותר התשתית שמתחת לרוב מה שהוא מגיש. לכן, כאשר אנשים משווים בין Ollama לבין llama.cpp, הם לרוב משווים שכבת הנדסת אנוש לכלי שהיא עוטפת.

יעד התכנון הוא משתמש יחיד. נכון ליולי 2026, ברירת המחדל עבור OLLAMA_NUM_PARALLEL היא 1, מה שאומר שמודל אחד מעבד בקשה אחת בכל פעם וכל השאר ממתינים בתור שמכיל כברירת מחדל 512 כניסות (OLLAMA_MAX_QUEUE). ניתן להעלות את הגדרת המקביליות, והסעיף להלן מסביר מה המחיר של כך. אם לא הרצתם את Ollama בעבר, התחילו ב-אירוח Ollama על שרת VPS ושמירה על פורט 11434 סגור, כיוון של־API אין שום מנגנון אימות.

מהו vLLM בפועל

vLLM הוא שרת הסקה (inference server) ותו לא. הוא אינו מנהל ספריית מודלים, אין לו ממשק צ'אט, והוא לא ימשוך עבורכם מודל בזמן הבקשה. בעת ההפעלה עליכם לציין מאגר (repository) מ־Hugging Face; הוא טוען את המודל הזה ומגיש אותו עד שתעצרו את התהליך.

מה שאתם מקבלים בתמורה למיקוד הזה הוא תפוקה (throughput). שני מנגנונים מבצעים את העבודה. PagedAttention מאחסן את ה-KV cache (מטמון מפתח-ערך, מצב ה-attention לכל טוקן שהמודל שומר עבור כל בקשה פעילה) בבלוקים בגודל קבוע, בדומה לאופן שבו מערכת הפעלה מבצעת paging לזיכרון. בקשה אינה זקוקה עוד להקצאה רציפה וגדולה המותאמת לתרחיש הגרוע ביותר, כך שזיכרון שבעבר נותר שמור ולא בשימוש הופך זמין עבור בקשות מקבילות נוספות. Continuous batching מאפשר לבקשה חדשה להצטרף ל-batch הפעיל בשלב ה-decoding הבא, במקום להמתין לסיום ה-batch הנוכחי. רצף שהסתיים עוזב את ה-batch באופן מיידי והמשבצת שלו מתמלאת מחדש.

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

Continuous batching הוא ההבדל המהותי

דמיינו חמש בקשות המגיעות לשרת בו-זמנית על גבי חומרה זהה.

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

vLLM מפענח את כל חמש הבקשות באותו forward pass. יצירת token אחד עבור חמישה רצפים עולה כמעט אותו דבר כמו יצירת token אחד עבור רצף בודד, כיוון שהחלק היקר הוא קריאת משקולות המודל מהזיכרון, וקריאה זו משותפת לכל ה-batch. זוהי אותה עובדה של רוחב פס בזיכרון שהופכת הסקה (inference) ב-CPU לאיטית: אתם משלמים על העברת המשקולות, לא על החישוב האריתמטי.

ניתן להגדיר את OLLAMA_NUM_PARALLEL=4 ולקבל חלק מכך. המחיר הוא זיכרון. כל slot מקבילי זקוק ל-KV cache משלו, ו-Ollama מחלק את ה-context window בין ה-slots; לכן, ארבע בקשות מקבילות מול מודל המוגדר ל-8192 tokens משאירות לכל בקשה 2048 tokens של הקשר. המספר 8192 הוא בחירה ולא נתון קבוע, לכן הגדלת num_ctx והקצאת ה-RAM הנדרשת לכך הוא הצעד הקובע האם ארבעה slots הם בכלל ברי-שימוש. ה-paged cache של vLLM הוא מה שמונע את הפשרה הזו, כיוון שבלוקים מוקצים לבקשה רק ככל שהיא גדלה בפועל. כך או כך, התקרה למספר האנשים ששרת בודד יכול לשרת בו-זמנית נקבעת לפי גודל ה-KV cache, עלות ה-prefill ועומק התור, וזו הסיבה לכך ששרת שהרגיש תקין עבור אדם אחד זוחל תחת עומס של חמישה.

התקנה והגשה באמצעות Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

סקריפט ההתקנה יוצר משתמש מערכת בשם ollama, מתקין את הקובץ הבינארי, ורושם את ollama.service כך שיהיה קשור ל-127.0.0.1:11434. השורה eval rate המודפסת על ידי --verbose מייצגת את קצב הטוקנים האמיתי לשנייה בשרת הספציפי שלכם. הסתמכו עליה יותר מאשר על כל נתון שפורסם. קריאה אחת מתוך הנחיה (prompt) בודדת היא נקודת התחלה בלבד ולא מדד לקיבולת, לכן מדידת טוקנים לשנייה לאורך סריקת עומס מקבילי היא הדרך לקבוע האם השרת עומד בעומס שאתם צופים בפועל, והאם השכרת GPU משתלמת יותר מתשלום לפי טוקן.

כדי להעלות את רמת העבודה המקבילית (concurrency), השתמשו ב-drop-in של systemd כדי ששדרוג לא ידרוס את השינוי:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

הפקודה ollama ps מציגה מה טעון בזיכרון, והעמודה PROCESSOR מציגה את המצב לאשורו. הערך 100% CPU משמעו שאין מעורבות של GPU, וזהו ההסבר הכנה לרוב הדיווחים על כך ש-Ollama איטי. השורה OLLAMA_KEEP_ALIVE=30m בתוך ה-drop-in חשובה לא פחות גם בשרת שאינו עמוס, כיוון שברירת המחדל היא פריקת המודל מהזיכרון לאחר חמש דקות ללא בקשה, ופעולת השארת המודל בזיכרון בין בקשות היא זו שמונעת מהנחיה ראשונה לאחר שעה של חוסר פעילות לשלם שוב את מלוא זמן הטעינה.

התקנה והגשה באמצעות vLLM

vLLM דורש Linux וגרסת Python מ-3.10 עד 3.13. יש להתקין אותו בסביבה וירטואלית נפרדת, כיוון שהוא מושך גרסה ספציפית של PyTorch:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

לאחר מכן, הגישו מודל. השם הוא מזהה המאגר ב-Hugging Face, ולא תגית קצרה:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

העלייה איטית בפעם הראשונה, כיוון שהמערכת מורידה את המשקולות ומבצעת פרופיילינג ל-GPU כדי להחליט כמה בלוקים של KV cache יכנסו בזיכרון. השירות מאזין בפורט 8000. בדקו אותו לפני כתיבת קוד לקוח:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

אם Docker כבר מותקן על השרת, ה-image הרשמי חוסך את הצורך בהתמודדות עם תלויות CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

הדגל --ipc=host הוא הכרחי, ולא לקישוט: PyTorch מעביר טנזורים בין תהליכים דרך זיכרון משותף, והקצאת הזיכרון המשותף המוגדרת כברירת מחדל ב-Docker קטנה מדי עבור הסקה (inference) בטכניקת tensor-parallel.

הדגלים החשובים ביותר בסביבת production הם --max-model-len (חלון ההקשר שאתם מוכנים להקצות), --gpu-memory-utilization (חלק הזיכרון בכרטיס ש-vLLM רשאי לתפוס, 0.92 כברירת מחדל נכון ליולי 2026), --tensor-parallel-size לפיצול מודל בודד על פני כמה כרטיסי GPU, ו---api-key.

אימות הוא דגל אחד ב-vLLM ואינו קיים ב-Ollama

vLLM אוכף שימוש ב-bearer token אם תספק לו אחד כזה:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

ניתן להגדיר את אותו ערך באמצעות משתנה הסביבה VLLM_API_KEY. בקשה ללא טוקן זה תקבל שגיאת HTTP 401. זו עדיין אינה סיבה לחשוף את פורט 8000 לממשק ציבורי, כיוון של-vLLM אין מנגנון rate limiting וטוקן HTTP פשוט ניתן לקריאה במהלך המעבר ברשת, אך המשמעות היא שלשרת יש מושג לגבי זהות הקורא.

ב-Ollama אין מנגנון כזה. אין מפתח, אין התחברות ואין רשימת מורשים. כל תהליך שיכול להגיע לפורט 11434 יכול להריץ, למשוך או למחוק מודלים. שמרו אותו על ה-loopback וגשו אליו דרך רשת WireGuard VPN שאתם מארחים בעצמכם, או דרך reverse proxy מאמת שמבצע TLS (transport layer security) termination.

חומרה: מה כל אחד דורש

Ollama רץ על ה-CPU. מודל בקוונטיזציה של 4-bit צורך בערך חצי ג'יגה-בייט של RAM לכל מיליארד פרמטרים, בתוספת של כג'יגה-בייט אחד עבור תקורה בזמן ריצה ועוד עבור הקשר (context). לכן, מודל 3B דורש כ-4 GB פנויים, ומודל 8B דורש כ-8 GB. המהירות על vCPU משותף נעה בין מספר חד-ספרתי למספר דו-ספרתי נמוך של טוקנים לשנייה. מדובר במגבלת רוחב פס של הזיכרון, לא בתקלה בהגדרות, ושום flag לא יתקן זאת. כדי לראות את החישוב הזה בפעולה על גרסה ספציפית במקום להסתמך על כלל אצבע, הרצת Nemotron 3.5 Lightning על גבי VPS מבהירה בדיוק איזה tag למשוך, כמה RAM המודל תופס לאחר הטעינה, והאם הרצה על CPU בלבד היא מהירה מספיק לשימוש.

vLLM מניח קיומו של GPU. נתיב ברירת המחדל שלו מגיש משקולות ללא קוונטיזציה בדיוק של 16-bit, שזה בערך 2 GB לכל מיליארד פרמטרים: מודל 8B דורש כ-16 GB של זיכרון וידאו עבור המשקולות בלבד, עוד לפני ה-KV cache שמעניק לך את יכולת העבודה במקביל שבשבילה התקנת את vLLM. על כרטיס של 24 GB זה משאיר cache עובד. על כרטיס של 16 GB זה לא מספיק, לכן עליך לבחור מודל קטן יותר או להעביר את --quantization עם checkpoint שעבר קוונטיזציה. קיים backend ל-CPU, אך ה-wheels הסטנדרטיים לא בנויים עבורו, והוא מבטל את הסיבה להריץ את vLLM מלכתחילה.

לכן, שאלת החומרה עונה על שאלת התוכנה ברוב המקרים. היעדר GPU משמעו Ollama. GPU מושכר שנמצא ב-5 אחוז ניצולת כי הבקשות עוברות סריאליזציה משמעו vLLM.

מה מתאים לעומס העבודה שלך

• אדם אחד, שרת VPS עם מעבד בודד, לכתיבת טיוטות וסיכומים: Ollama. הקצב סביר ואין פתרון פשוט יותר.
• עוזר תכנות, או שרת MCP המקשר בין הכלים שלך למודל מקומי, שרק אתה ניגש אליו: Ollama. עומס עבודה של משתמש יחיד הוא התרחיש המתאים.
• השוואה בין חמישה מודלים השבוע: Ollama. משיכה ומחיקה של מודלים מתויגים היא בדיוק מה שהכלי הזה עושה היטב, בעוד ש־vLLM דורש הפעלה מחדש של התהליך עבור כל מודל.
• יישום פנימי, מוצר צ'אט, או צינור שליפת נתונים (retrieval pipeline) עם משתמשים אמיתיים: vLLM. כאן יכולות ה־batching מצדיקות את עלות ה־GPU.
• משימת batch לעיבוד מאה אלף מסמכים במהלך הלילה: vLLM, עם --max-num-seqs גבוה. קצב העבודה (throughput) הוא המדד היחיד שקובע, בעוד שהשהיה (latency) לכל מסמך אינה רלוונטית.
• פלטפורמת סוכנים שבה כמה סוכני AI באירוח עצמי פונים למודל בו-זמנית: vLLM, כיוון שתעבורת סוכנים היא מטבעה מתפרצת ומקבילית.

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

vLLM מסרב לעלות עקב שגיאת KV cache. ההודעה מציינת את שני המספרים:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

המודל מצהיר על חלון הקשר (context window) הגדול מהזיכרון שנותר לאחר טעינת המשקולות. יש להקטין אותו באמצעות --max-model-len 8192, או להגדיל את --gpu-memory-utilization אם אין תהליכים אחרים המשתמשים בכרטיס. דחיפת הניצול מעבר ל-0.95 בערך נוטה להחליף את שגיאת העלייה הזו בקריסת CUDA out-of-memory מאוחרת יותר תחת עומס, מצב שהוא גרוע יותר.

Ollama מדפיס Killed באמצע יצירת התוכן. מנגנון ה-out-of-memory killer של Linux עצר את התהליך כיוון שהמודל דרש יותר RAM ממה שזמין במכונה. ניתן לאמת זאת באמצעות sudo dmesg | grep -i oom. הפתרון הוא שימוש במודל קטן יותר או במודל שעבר קוונטיזציה (quantization) אגרסיבית יותר, ולא שינוי הגדרות.

Ollama עונה היטב כשהוא לבד, אך נתקע תחת עומס. לא מופיעה שגיאה בשום מקום. הבקשות פשוט לוקחות זמן רב יותר ככל שיש יותר פונים, כיוון ש-OLLAMA_NUM_PARALLEL=1 מבצע להן סריאליזציה. תשובות ארוכות מחמירות את התור, שכן פונה יחיד שמחזיק בחריץ (slot) היחיד עד שהמודל מסיים, חוסם את כל מי שמאחוריו. לכן, הגבלת התשובה באמצעות num_predict מציבה תקרה למשך הזמן שבו פנייה בודדת יכולה להחזיק את השרת. יש להגדיל את הגדרת המקביליות ולהשלים עם הקשר (context) קטן יותר לכל בקשה, או להעביר את העומס ל-vLLM.

vLLM מחזיר 401 בכל קריאה. הפעלת את השירות עם --api-key והלקוח אינו שולח כותרת Authorization. רוב ספריות הלקוח של OpenAI שולחות את מה שתגדיר כמפתח, לכן יש להגדיר אותו שם במקום להסיר את ה-flag.

vLLM מדווח שהמודל לא נמצא. Ollama מושך מודלים לפי דרישה, vLLM לא. השדה model בגוף הבקשה חייב להתאים למזהה ה-repository שאיתו הפעלת את השירות, או לערך של --served-model-name אם הגדרת כזה. יש לוודא את המחרוזת המדויקת באמצעות curl http://localhost:8000/v1/models.

הרצה של שניהם היא פתרון סביר

הם אינם מוציאים זה את זה. תצורה נפוצה היא vLLM על גבי instance עם GPU שמשרת את היישום, לצד Ollama על גבי VPS רגיל עבור סקריפטים מקומיים, משימות cron, ובדיקת גרסאות מודלים חדשות. שני ה־endpoints תואמים ל־OpenAI, כך שספריית לקוח אחת והחלפת base-URL מכסות את שניהם. בקרת עלויות חשובה כאן יותר מכל מנוע ספציפי, כיוון ש־GPU במצב המתנה מחויב באותו תעריף כמו GPU בעומס, ו-שמירה על עלויות סוכנים והסקה (inference) צפויות היא תחום נפרד מבחירת השרת.

FAQ

האם vLLM מהיר יותר מ־Ollama?

עבור בקשה בודדת על אותו GPU, הפער צנוע, כיוון ששניהם מבצעים את אותן פעולות חשבוניות. עבור בקשות רבות בו-זמנית, vLLM מקדים משמעותית, כיוון ש־continuous batching מפענח כל רצף פעיל במעבר forward יחיד, בעוד ש־Ollama מריץ אותם כברירת מחדל בזה אחר זה. במכונה מבוססת CPU בלבד, השאלה אינה רלוונטית: Ollama פועל שם, בעוד vLLM למעשה אינו פועל.

האם vLLM יכול לרוץ ללא GPU?

לא באופן שימושי. ה־wheels הסטנדרטיים מיועדים ל־GPU של NVIDIA או AMD, והסיבה לקיומו של vLLM – שמירה על מאיץ רווי בבקשות ב־batch – מתבטלת ב־CPU. קיים backend עבור CPU לצורכי פיתוח. עבור הסקה (inference) אמיתית ב־CPU, השתמשו ב־Ollama או ב־llama.cpp ישירות.

מה ההבדל בין Ollama לבין llama.cpp?

llama.cpp היא ספריית ההסקה, ו־GGUF הוא פורמט המשקולות המקוונטות שלה. ה־runner של Ollama בנוי עליה ומוסיף את החלקים ש־llama.cpp מותירה למשתמש: רישום מודלים, הורדה אוטומטית, שרת תושב, יחידת systemd, ונקודת קצה תואמת OpenAI. Ollama הוסיפה מנוע משלה עבור כמה משפחות מודלים חדשות, כך שהשניים אינם זהים עוד מתחת למכסה המנוע.

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

בדיוק של 16-bit, המשקולות לבדן תופסות כ־16 GB, בערך 2 GB לכל מיליארד פרמטרים, וה־KV cache זקוק למקום מעבר לכך. כרטיס של 24 GB מספק נוחות עבודה. כרטיס של 16 GB דורש checkpoint מקוונטט או מודל קטן יותר. vLLM תופס חלק מהכרטיס שנקבע על ידי --gpu-memory-utilization, שערכו כברירת מחדל הוא 0.92 נכון ליולי 2026.

האם עליי לשנות את קוד היישום שלי כדי לעבור ביניהם?

בדרך כלל רק את ה־base URL, את ה־API key ואת שם המודל. Ollama מגיש את הממשק תואם ה־OpenAI שלו בכתובת http://127.0.0.1:11434/v1 ומתעלם מהמפתח, בעוד vLLM מגיש בכתובת http://localhost:8000/v1 ואוכף את המפתח אם הגדרת כזה. שמות המודלים נבדלים בצורתם: llama3.1:8b עבור Ollama, לעומת מזהה מאגר מלא כגון Qwen/Qwen2.5-1.5B-Instruct עבור vLLM.