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. במחשבי Apple Silicon הוא יכול להריץ גם מודלים מבוססי safetensors דרך מנוע MLX, והחל מגרסה v0.40.0 (ספטמבר 2026) ארכיטקטורות נתמכות מורצות שם על MLX באופן אוטומטי.

מנוע ה־GGUF שלו בנוי על גבי llama.cpp, ספריית ההסקה ב־C++ שהפכה קוונטיזציית GGUF למעשית על חומרה רגילה. נכון לאוקטובר 2026, Ollama תומך בשני מנועים, llama.cpp ו־MLX, וגרסאות ה־Linux תומכות גם בהסקה ב־MLX עם CUDA. מדריך הפיתוח מאפשר את ה־backend הזה באמצעות cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, עם דרישות קדם של CUDA 13+ ו־cuDNN 9+. לכן, כאשר אנשים משווים בין Ollama לבין llama.cpp, הם לרוב משווים בין שכבת נוחות לבין הכלי שהיא עוטפת.

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

מהו vLLM בפועל

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

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

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

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

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

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

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

ניתן להגדיר את OLLAMA_NUM_PARALLEL=4 ולקבל חלק מכך. המחיר הוא זיכרון. כל slot מקבילי זקוק ל-KV cache משלו, ו-Ollama מכפיל את הקצאת ההקשר (context) במקום לחלק אותה: ה-FAQ שלו מציין כי ה-RAM הנדרש גדל לפי OLLAMA_NUM_PARALLEL כפול OLLAMA_CONTEXT_LENGTH. לכן, ארבע בקשות מקביליות מול מודל שהוגדר ל-8192 טוקנים שומרות 8192 טוקנים כל אחת, אך השרת חייב להחזיק cache עבור 32768 טוקנים בסך הכל. המספר 8192 הוא בחירה ולא נתון קבוע, לכן הגדלת num_ctx והערכת עלות ה-RAM הוא הצעד הקובע האם ארבעה slots יכנסו בכלל. ה-paged cache של vLLM הוא שמונע שמירה מראש של כל ה-window עבור כל slot, כיוון שבלוקים מוקצים לבקשה רק ככל שהיא גדלה בפועל. כך או כך, התקרה למספר האנשים ששרת בודד יכול לשרת בו-זמנית תלויה בגודל ה-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

גרסאות ה-GPU של vLLM דורשות Linux (ב-macOS על Apple Silicon קיימת תמיכה ב-CPU בלבד באמצעות wheel מוכן מראש בגרסה 0.32.0, והאצת GPU במחשבי Mac אלו מגיעה מ-vLLM-Metal, תוסף נפרד המתוחזק על ידי הקהילה ומבוסס על MLX). ב-Python, הגרסה הנוכחית (0.32.0, אוקטובר 2026) תומכת בגרסאות 3.11 עד 3.14, ומדריך ההתקנה מציין את אותו טווח. התמיכה ב-Python 3.10 הופסקה בגרסה 0.32.0, לכן 3.12, שבה נשתמש להלן, היא הבחירה הבטוחה. יש להתקין את vLLM בתוך סביבה וירטואלית ייעודית, כיוון שהיא מושכת גרסה ספציפית של PyTorch:

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

השורה האחרונה מופיעה במדריך ההתקנה של vLLM עבור NVIDIA נכון לאוקטובר 2026. היא מתקינה את ה-kernels המהודרים מראש של FlashInfer. בלעדיהם, vLLM מוריד ומהדר kernels בזמן העלייה, דבר שלפי המדריך עלול להוסיף מספר דקות על גבי כרטיסי Hopper וכרטיסי GPU חדשים יותר. יש להריץ פקודה זו שוב לאחר כל שדרוג של vLLM, כיוון ש-FlashInfer מסרב להיטען כאשר ה-kernels אינם תואמים.

לאחר מכן, הגישו מודל. השם הוא מזהה מאגר (repository id) מ-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 כבר מותקן על השרת, התמונה הרשמית חוסכת את הצורך בטיפול בתלויות 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 מעניק למכולה גישה לזיכרון משותף של המארח; הגדלת --shm-size היא אפשרות נוספת. PyTorch מעביר טנזורים בין תהליכים באמצעות זיכרון משותף, במיוחד עבור הסקה (inference) בשיטת tensor-parallel.

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

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

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

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

ניתן להגדיר את אותו הערך באמצעות משתנה הסביבה VLLM_API_KEY. בקשה לנתיבי /v1 ללא הטוקן תניב שגיאת HTTP 401. עם זאת, המפתח אינו מכסה את כל השרת. מדריך האבטחה של vLLM, וקוד האימות בגרסת המקור 0.32.0, מחילים אותו רק על נקודות קצה תחת קידומות הנתיב /v1, /v2, /inference ו-/cohere. טקסט העזרה של --api-key בדף vllm serve מפרט רק את השלוש הראשונות, אך הקוד בודק את כל הארבע. גם המדריך וגם טקסט העזרה מציינים שנקודות קצה אחרות, ובראשן /invocations, החושפת את אותה הסקה (inference) כמו /v1, אינן מאומתות. זו סיבה מספקת שלא לחשוף את פורט 8000 לממשק ציבורי. מדריך האבטחה של vLLM גם מותיר את הגבלת הקצב (rate limiting) ל-reverse proxy שיוצב לפניו, וטוקן שנשלח ב-HTTP גלוי ניתן לקריאה במעבר, אך הדגל אכן מעיד על כך שלשרת יש מושג של קורא (caller).

ה-API המקומי של Ollama אינו דורש אימות. מודלים בענן, פרסום מודלים והורדת מודלים פרטיים דורשים התחברות; גישת API ישירה ל-ollama.com דורשת מפתח API. כל תהליך שיכול להגיע ל-11434 יכול להריץ, למשוך (pull) או למחוק מודלים. שמרו אותו על ה-loopback וגשו אליו דרך רשת WireGuard VPN שאתם מארחים בעצמכם, או דרך reverse proxy מאמת שמבצע TLS termination (אבטחת שכבת תעבורה).

חומרה: מה כל רכיב דורש

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

vLLM מניח קיום של GPU. נתיב ברירת המחדל שלו מגיש משקולות ללא קוונטיזציה בדיוק של 16-bit, מה ששווה בערך ל-2 GB לכל מיליארד פרמטרים: מודל 8B דורש כ-16 GB של זיכרון וידאו עבור המשקולות בלבד, עוד לפני ה-KV cache שמעניק את יכולת ה-concurrency שבשבילה התקנתם את vLLM. בכרטיס של 24 GB זה משאיר cache עובד. בכרטיס של 16 GB זה לא מספיק, לכן עליכם לבחור מודל קטן יותר, להעביר את --quantization (עם checkpoint שעבר קוונטיזציה, או כדי לבצע קוונטיזציה למשקולות בדיוק מלא בזמן הטעינה), או לדחוף חלק מהמשקולות ל-RAM של המערכת בעזרת --cpu-offload-gb. פעולה זו שומרת על הדיוק שלהן אך היא איטית יותר, כיוון שהמשקולות עוברות ל-GPU בכל forward pass. קיים 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: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

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

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

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

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

vLLM מדווח שהמודל לא נמצא. Ollama מושך מודלים לפי דרישה, vLLM לא. השדה model בגוף הבקשה חייב להתאים למזהה המאגר (repository id) שאיתו הפעלת את השירות, או לערך של --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 בלבד, לשניהם יש נתיבי הסקה (inference) נתמכים, כאשר vLLM משתמש ב-wheels נפרדים עבור CPU.

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

כן, באמצעות ה-backend ל-CPU שלו. ה-wheels הסטנדרטיים מיועדים ל-GPUs של NVIDIA או AMD, והסיבה לקיומו של vLLM – שמירה על מאיץ רווי בבקשות ב-batch – מתבטלת ב-CPU. קיים backend ל-CPU, עם wheels נפרדים עבור x86 ו-Arm. להסקה אמיתית על CPU, השתמשו ב-Ollama או ב-llama.cpp ישירות.

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

llama.cpp היא ספריית ההסקה, ו-GGUF הוא פורמט המשקולות המקומץ שלה. Ollama משתמשת בה עבור הסקת GGUF ומוסיפה רישום מודלים, הורדות מתויגות, ניהול מודלים ו-systemd unit. בנוסף, Ollama כוללת מנוע MLX שמריץ מודלים מבוססי safetensors על Apple Silicon ותומכת ב-builds של CUDA על Linux, כך שהשתיים אינן תמיד זהות מתחת למכסה המנוע.

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

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

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

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