Ollama או vLLM: איזה שרת LLM לבחור?

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

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

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

מה Ollama באמת

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

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

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

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

נניח שחמש בקשות מגיעות לכל שרת באותו רגע, בחומרה זהה.

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

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

אפשר להגדיר את OLLAMA_NUM_PARALLEL=4 ולקבל חלק מההתנהגות הזו. המחיר הוא בזיכרון. כל משבצת מקבילית זקוקה למטמון KV משלה, ו-Ollama מחלק את חלון ההקשר בין המשבצות. לכן ארבע בקשות מקביליות מול מודל שהוגדר עבור 8192 אסימונים משאירות לכל בקשה חלון הקשר של 2048 אסימונים. המטמון המחולק לעמודים של vLLM מונע את הפשרה הזו, מכיוון שהבלוקים מוקצים לבקשה בהתאם לגידול בפועל של הבקשה.

התקנה והגשה באמצעות 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 מציגה את מספר האסימונים לשנייה בפועל במערכת זו. יש להסתמך עליה ולא על נתון שפורסם.

כדי להגדיל את המקביליות, השתמשו בקובץ override של 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.

התקנה והפעלת שירות באמצעות 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 מתאימים. השירות מאזין ביציאה 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 כבר מותקן במחשב, התמונה הרשמית חוסכת את הטיפול בתלות ב-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 קטנה מדי להסקה מקבילית-טנזורים.

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

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

vLLM אוכף שימוש באסימון bearer אם תספקו לו אסימון:

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

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

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

חומרה: מה כל אחד מהם צריך

Ollama פועל על המעבד. מודל שעבר קוונטיזציה ל-4 ביטים צורך בערך חצי גיגה-בייט של RAM לכל מיליארד פרמטרים, נוסף על תקורת זמן ריצה של כגיגה-בייט ועל זיכרון נוסף להקשר. לכן מודל 3B דורש כ-4 GB פנויים, ומודל 8B דורש כ-8 GB. המהירות ב-vCPU משותף היא מספר חד-ספרתי עד מספר דו-ספרתי נמוך של טוקנים בשנייה. זו מגבלה של רוחב הפס של הזיכרון, ולא שגיאת תצורה. שום דגל לא יתקן אותה.

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

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

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

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

מצבי כשל, והמיתרים שיופיעו

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

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.

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

Ollama מדפיס Killed באמצע יצירת הטקסט. מנגנון סיום התהליכים עקב מחסור בזיכרון ב־Linux עצר את התהליך, מכיוון שהמודל נזקק ליותר RAM מכמות הזיכרון הזמינה במערכת. אשרו זאת באמצעות sudo dmesg | grep -i oom. הפתרון הוא שימוש במודל קטן יותר או במודל שעבר קוונטיזציה אגרסיבית יותר, ולא שינוי הגדרה.

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

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

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

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

הם אינם חלופות בלעדיות. תצורה נפוצה היא vLLM על מופע GPU שמספק את השירות ליישום, ובמקביל Ollama על VPS רגיל עבור סקריפטים מקומיים, משימות cron וניסוי של גרסאות חדשות של מודלים. שתי נקודות הקצה תואמות ל-OpenAI, ולכן ספריית לקוח אחת והחלפת כתובת בסיס מספיקות כדי לעבור ביניהן. בקרת עלויות חשובה כאן יותר מבחירת מנוע זה או אחר, משום ש-GPU שאינו פעיל מחויב באותו תעריף כמו GPU עמוס, ו-שמירה על עלויות צפויות של סוכנים והסקה היא תחום נפרד מבחירת שרת.

FAQ

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

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

האם vLLM יכול לפעול ללא GPU?

לא באופן שימושי. חבילות ה-wheel הסטנדרטיות מיועדות ל-GPU של NVIDIA או AMD, והסיבה לקיומו של vLLM — שמירה על accelerator רווי בבקשות מקובצות — אינה מתקיימת במעבד CPU. קיים backend עבור CPU לצורכי פיתוח. להסקה אמיתית על CPU, השתמשו ישירות ב-Ollama או ב-llama.cpp.

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

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

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

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

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

בדרך כלל יש לשנות רק את כתובת הבסיס, את מפתח ה-API ואת שם המודל. 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.