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

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

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

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

מהו כל פרויקט בפועל

llama.cpp הוא מימוש ב-C וב-C++ של הסקת (inference) מודלי transformer, הבנוי על גבי ספריית ggml. הוא קורא קובצי GGUF. פורמט GGUF (ראשי תיבות של GGML universal file format) הוא מכולה (container) בקובץ יחיד המכילה את המשקולות, את ה-tokeniser ואת המטא-דאטה שהמנוע צריך כדי להריץ את המודל. הפרויקט מפיץ קובצי binary נפרדים למשימות שונות. llama-server הוא שרת HTTP, llama-cli הוא ממשק אינטראקטיבי, ו-llama-bench מודד את קצב העיבוד (throughput). הגרסאות (releases) מתויגות לפי מספר 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 בלינוקס. קבצים אלו יושבים על כונן ה-root ומגיעים לנפח של כמה ג'יגה-בייט כל אחד, לכן בשרת VPS עם נפח root של 25 GB כדאי לדעת מה הפקודה pull משאירה מאחור וכיצד להעביר את ספריית המודלים למקום אחר לפני שהורדה שלישית תמלא את הדיסק.

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

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

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

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

ב-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) בטוקנים, -t הוא מספר ה-threads, ו--ngl קובע כמה שכבות יועברו ל-GPU (ערך 0 בשרת מבוסס CPU בלבד). שום דבר לא מנוחש עבורך.

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

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

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

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

אורך ההקשר הוא ההגדרה שמכשילה משתמשים. Ollama בוחרת את ברירת המחדל שלה לפי ה-VRAM הזמין, ושרת ללא GPU נופל לקטגוריה הקטנה ביותר: 4096 טוקנים. אם תשלח מסמך של 20,000 טוקנים, הטוקנים העודפים יימחקו לפני שהמודל יראה אותם, והתשובה תהיה שגויה בביטחון לגבי קובץ שנקרא רק בחציו. הגדל זאת באמצעות OLLAMA_CONTEXT_LENGTH ב-daemon, או באמצעות PARAMETER num_ctx ב-Modelfile. אם רק משימה אחת זקוקה לחלון גדול יותר, ניתן להגדיר num_ctx לכל בקשה בנפרד במקום ברמת השרת, מה שמונע מה-cache הנוסף להשפיע על כל שאר הפעולות שה-daemon מבצע. גם ל-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 בזמן שהמודל נטען, ואל תסמכו על הערכה שלא מדדתם בעצמכם. אם אתם מתכננים משאבים עבור מודל הגדול מ-8B, אותו חישוב אריתמטי שבוצע עבור מודל 27B על שרת VPS מבוסס CPU בלבד מראה מה כל רמת זיכרון מ-8 עד 64 GB מסוגלת להחזיק בפועל.

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

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

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 לניטור פעילות של כל חריץ בקשה (request slot), ו-/metrics בפורמט Prometheus. אם אתם מתכננים לנטר את השירות, סביר להניח שזהו ההבדל שיכריע את הבחירה.

אף אחד מהשרתים אינו מפעיל אימות (authentication) כברירת מחדל. שניהם מוגדרים כברירת מחדל ל-loopback מסיבות טובות. גשו אליהם דרך SSH tunnel או מתוך 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 מערכת ארוך מוסיף זמן המתנה לכל בקשה. אורך התשובה הוא חצי מהחשבון שניתן לשלוט בו, כיוון שבקצב של שלושה tokens לשנייה, מודל שפולט 600 tokens תופס את השרת למשך שלוש דקות, לכן הגבלת הפלט באמצעות num_predict היא הדרך הזולה ביותר למנוע מתשובה ארוכה מדי להפוך ל-timeout.

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

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

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

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

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

כדי לקבע גרסה ספציפית, השתמשו ב-tarball המוכן להורדה מדף ה-releases. גרסה b10224 היא ה-tag העדכני נכון ל-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'

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

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-mapping לקובץ ה-GGUF, כך שקובץ הגדול מה-RAM עדיין יתחיל לעבוד. ה-kernel מבצע החלפת דפים (paging) של משקולות מהדיסק בכל טוקן, וקצב היצירה צונח לשניות לכל טוקן בזמן שהדיסק נמצא ב-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?

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

מה מהיר יותר ב-VPS ללא GPU?

הם חולקים את אותו מנוע, לכן באותו קובץ מודל, quantisation, גודל context ומספר threads, הביצועים יהיו דומים מאוד. הבדלים שמדווחים משתמשים נובעים בדרך כלל מהגדרות ברירת מחדל שונות, לרוב אורך ה-context ומספר ה-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. כך משתמשים ב-quantisation שאינו קיים ב-registry.

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

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