האם באמת צריך שרת VPS עם GPU להרצת מודלים?

האם דרוש שרת VPS עם GPU, או שדי ב-CPU?

שרת VPS עם GPU משנה שני היבטים בהרצת מודל באופן עצמאי: קצב הפקת הטוקנים (tokens) והיכולת להכניס מודל גדול לזיכרון. מעבר לכך, דבר אינו משתנה. אם עומס העבודה שלכם כולל מודל צ'אט מקוונטז (quantized) בגודל 7B עד 27B המשיב למשתמש אחד בכל פעם, משימת embedding בנפח נמוך, או תמלול קולי באמצעות Whisper small, שרת VPS רגיל עם CPU וכמות RAM מספקת יבצע את העבודה. התחילו עם CPU, מדדו את הביצועים שאינם מספקים אתכם, ורק אז שדרגו.

הסיבה לכך היא רוחב פס של הזיכרון. כאשר מודל שפה מפיק טוקן אחד, הוא קורא את כל המשקולות הדרושות לו מהזיכרון. מודל 8B מקוונטז ל-4 ביט תופס כ-4.9 GB על הדיסק ובערך אותו דבר בזיכרון, לכן הפקת טוקן מחייבת העברה של כ-4.9 GB. חלקו את רוחב הפס של הזיכרון במכונה במספר זה, ותקבלו את תקרת הטוקנים לשנייה. חילוק פשוט זה מסביר כמעט כל benchmark שתקראו.

מה באמת מקבלים מ־GPU

רוחב פס. זיכרון DDR5 בשרת מודרני מעביר עשרות גיגה-בייט בשנייה. זיכרון GPU (המכונה VRAM) מעביר מאות ואף יותר מאלף. היחס הזה הוא מהירות העבודה, והוא משמעותי מאוד.

קיבולת לצד מהירות. שרת עם מעבד (CPU) ו־64 GB של RAM יכול לטעון מודל 70B בקוונטיזציה של 4-bit. הוא ירוץ, אך בקצב שקרוב יותר לקריאה מאשר לניהול שיחה. GPU עוזר כאן רק אם המודל נכנס לתוך ה־VRAM, כיוון שברגע ששכבות המודל גולשות לזיכרון המערכת, הנתיב האיטי חוזר לשלוט בביצועים.

תפוקת Batch. זהו החלק שאנשים נוטים להמעיט בערכו. GPU שמייצר טקסט עבור משתמש אחד משאיר את רוב כוח החישוב שלו במצב המתנה, כיוון שהוא ממתין לזיכרון. אם מגישים 20 בקשות בו-זמנית, אותה קריאת משקולות משרתת את כל 20 הבקשות. כמות ה־tokens לשנייה המצטברת עולה פי כמה, בעוד המהירות לכל משתמש בודד יורדת בקושי. מנועי הסקה (inference) מבוססי CPU, כמו llama.cpp, תומכים גם הם ב־batching, עם שיפורים שתלויים בחומרה ובעומס העבודה. אם אתם בונים API שפונים אליו לקוחות רבים, ה־batching הוא הטיעון המרכזי לשימוש ב־GPU, יותר מאשר מהירות גולמית של זרם יחיד.

עיבוד Prompt. קריאת prompt ארוך מוגבלת על ידי כוח חישוב (compute-bound) ולא על ידי זיכרון, וזהו התחום שבו ה־GPU מנצח בפער הגדול ביותר. הקשר (context) של 30,000 tokens שמעבד (CPU) מעבד במשך דקה, ירוץ בתוך שניות ספורות על גבי GPU. מערכות שליפת מידע (retrieval) שמזינות מסמכים לתוך כל בקשה מרגישות את ההבדל הזה ללא הרף.

מספרים גסים, וכיצד לקרוא אותם

קצב התעבורה (throughput) בפועל נמוך מרוחב הפס חלקי גודל המודל, כיוון שמנגנון ה-attention על פני הקשר (context) הולך וגדל מוסיף עבודה שחישוב החילוק הפשוט מתעלם ממנה.

לשם השוואה, קריאה דוממת של מבוגרים באנגלית עומדת בממוצע על כ-4.0 עד 4.3 מילים בשנייה: 238 מילים לדקה בספרי עיון ו-260 בספרות יפה. כל קצב של 15 טוקנים לשנייה ומעלה כבר מרגיש לקורא בודד כמו הקלדה רגילה. זו הסיבה לכך שהגדרות רבות המבוססות על CPU בלבד מספקות ביצועים תקינים בהחלט.

תכנון נפח VRAM לפני רכישה

גודל קובץ המודל הוא הרף המינימלי, לא הדרישה הכוללת. יש לתקצב את המשקולות, בתוספת ה-KV cache (זיכרון מפתח-ערך, הזיכרון לכל טוקן ששומר מנגנון ה-attention), ועוד כ-1 GB של תקורה (overhead).

חשבו את ה-cache במדויק במקום להוסיף אחוז קבוע, כיוון שקוונטיזציה (quantization) של המשקולות אינה משפיעה על ה-cache. עבור כל טוקן, מודל full-attention שומר מפתח וערך לכל שכבה ולכל KV head, בנפח של 2 בתים למספר בפורמט FP16, שהוא סוג ה-cache המוגדר כברירת מחדל ב-Ollama. מטא-דאטה של מודלים ב-Ollama, שנבדק ב-2026-10-27, מציין כי ל-Llama 3.1 8B יש 32 שכבות ו-8 KV heads במימדים של 128, מה שמתרגם ל-128 KiB לכל טוקן: כ-1.07 GB בהקשר (context) של 8k וכ-2.15 GB ב-16k. לכן, מודל 8B בגודל 4.9 GB ידרוש כ-7 GB של VRAM עבור 8k וכ-8 GB עבור 16k. מודל 27B ב-4 ביט הוא סביב 17 GB (כמו Gemma 3 27B בספריית Ollama). המטא-דאטה של Gemma 3 מציין sliding window של 1,024 טוקנים, מה שמונע מה-cache לגדול משמעותית, לכן תכננו על 20 GB ומעלה. מודל 70B ב-4 ביט הוא כ-43 GB (כמו Llama 3.3 70B). עם 80 שכבות, ה-cache בפורמט FP16 מוסיף כ-2.7 GB ב-8k וכ-5.4 GB ב-16k, כך שהוא דורש כרטיס של 48 GB עם מעט מאוד מרווח, או שני כרטיסים קטנים יותר. החישוב הזה תקף גם הרבה מעבר לכך, ו-החישוב של נפח ה-VRAM עבור מודל עם 2.8 טריליון פרמטרים כמו Kimi K3 מראה את הנקודה שבה בחירת כרטיס כבר אינה השאלה העיקרית.

הקשרים (contexts) ארוכים הם המקום שבו זה משמעותי ביותר. במודלים של full-attention כמו Llama 3.1, ה-KV cache גדל ליניארית עם אורך ההקשר, וב-128k טוקנים הוא עלול לעלות על גודל המשקולות עצמן. מודלים עם sliding-window או chunked attention מתנהגים אחרת: תיעוד ה-Transformers של Hugging Face מציין את Mistral, Gemma 2 ו-Llama 4 כדוגמאות שבהן ה-cache בשכבות אלו מפסיק לגדול ברגע שהוא מגיע לגודל ה-window או ה-chunk, ולכן סך הזיכרון שלהם גדל לאט יותר. אם אתם מתכננים להשתמש בהקשרים ארוכים, תכננו קודם כל עבור ה-cache ובדקו מה המנוע שלכם מציע עבור קוונטיזציה של ה-cache. ב-Ollama, ה-OLLAMA_KV_CACHE_TYPE=q8_0 משתמש בכמחצית מהזיכרון של ה-f16 המוגדר כברירת מחדל, וקוונטיזציה של ה-cache חלה רק כאשר Flash Attention מופעל. הגדירו את אורך ההקשר במפורש. Ollama בוחרת את ברירת המחדל שלה לפי ה-VRAM: 4k מתחת ל-24 GiB, 32k בין 24 ל-48 GiB, ו-256k ב-48 GiB ומעלה. על כרטיס של 48 GB שמריץ מודל 70B, ברירת מחדל זו מבקשת הרבה יותר cache ממה שהכרטיס יכול להכיל.

בדיקת החומרה הקיימת במכונה

במופע GPU, ודאו תחילה שהדרייבר מזהה את הכרטיס לפני כל פעולה אחרת.

nvidia-smi

עליכם לקבל טבלה המפרטת את שם ה-GPU, גרסת הדרייבר, והזיכרון שבשימוש מתוך סך הזיכרון הכולל. השגיאה NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver מציינת ש-NVIDIA-SMI אינו מצליח לתקשר עם הדרייבר; בדקו שהדרייבר מותקן ושמודול ה-kernel שלו טעון. בתמונת Ubuntu סטנדרטית, הפתרון הוא בדרך כלל sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, ולאחריו ביצוע reboot כדי שהמודול החדש ייטען. עבור מכונות חישוב, התיעוד של Ubuntu Server ממליץ על sudo ubuntu-drivers install --gpgpu, שבוחר בענף הדרייברים לשרתים.

עבור מכולות, הדרייבר לבדו אינו מספיק. Docker זקוק ל-NVIDIA Container Toolkit כדי להעביר את ההתקן פנימה.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

לאחר מכן, ודאו שהעברת ההתקן (passthrough) עובדת מתוך המכולה:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

אותה טבלה אמורה להופיע. שורה המכילה docker: Error response from daemon: could not select device driver, המציינת יכולת GPU שאינה מסופקת, מעידה על כך ש-Docker לא מצא דרייבר התקן התואם לבקשה; בדקו שה-toolkit מותקן, ולאחר מכן הריצו שוב את השורה nvidia-ctk ובצעו הפעלה מחדש. ב-Compose, המקבילה היא רשומה מסוג deploy.resources.reservations.devices שבה ה-driver הוא nvidia ורשימת היכולות כוללת את gpu, אשר משתלבת בהגדרות השירות הרגילות המפורטות ב-Docker Compose on a VPS.

מדידה לפני שדרוג

הריצו את המודל שבו אתם מתכוונים להשתמש בפועל על שרת ה-CPU הקיים שלכם, ותעדו את התוצאות. עם אירוח עצמי של LLM באמצעות Ollama על גבי VPS הפעולה דורשת flag אחד בלבד:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

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

במכונה הכוללת GPU, ודאו שהמודל אכן נטען עליו:

ollama ps

העמודה PROCESSOR מציגה 100% GPU כאשר הכל נכנס לזיכרון, או ערך דוגמת 43%/57% CPU/GPU כאשר זה לא קרה. פיצול חלקי הוא בדרך כלל גרוע מכפי שניתן לצפות, כיוון שכל טוקן עדיין ממתין לחלק האיטי של התהליך.

שאלת העלות

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

קיימים שלושה דפוסי עבודה הגיוניים. שמרו עבודה בהיקף נמוך וקבוע על גבי CPU VPS. שלחו בקשות מורכבות מזדמנות ל-API חיצוני ושלמו לפי טוקן. שכרו GPU לפי שעה עבור משימות אצווה (batch jobs), כוונון עדין (fine-tuning) או הרצת embedding מרוכזת, ולאחר מכן בטלו את המופע. שילוב ביניהם הוא נוהג מקובל, ומשמעת התקציב המתוארת ב-בקרת עלויות של סוכן AI על גבי VPS פעיל תמיד תקפה גם כאן, עם ההבדל שזמן המתנה הוא מקור הדליפה ולא כמות הטוקנים.

מה עדיין פועל היטב ללא GPU

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

מודלי Whisper בגרסאות small ו-base לתמלול. הספרייה Faster-whisper על גבי CPU מתמללת במהירות הקרובה לזמן אמת עבור המודל הקטן, וזה מספיק עבור תהליך עבודה שרץ במהלך הלילה.

מודלי צ'אט מקוונטזים (Quantized) עד סדר גודל של 27B, עבור משתמש אחד או שניים. הביצועים איטיים, אך קריאים ושמישים.

כל משימה שניתן להגדיר כ-batch job. אם אף אחד לא צופה במסך, זמן הביצוע הוא פרט טכני של תזמון ולא דרישה תפעולית.

מה דורש GPU באופן מובהק: אימון או fine-tuning מעבר ל-adapter קטן, הגשת שירות למספר רב של משתמשים בו-זמנית, יצירת תמונות ווידאו, ודיבור בזמן אמת שבו השיהוי (latency) הוא חלק מהמוצר.

FAQ

כמה VRAM נדרש עבור מודל 7B או 8B?

כ־7 GB עבור מודל 8B בקוונטיזציה של 4-bit עם context של 8k, וכ־8 GB עבור 16k, בהתבסס על ה־cache המוגדר כברירת מחדל ב-Ollama מסוג FP16. המשקולות תופסות כ-4.9 GB, ה-KV cache מוסיף כ-1.07 GB ב-8k או 2.15 GB ב-16k, והיתרה היא כ-1 GB של תקורה (overhead). כרטיס עם 8 GB יריץ את המודל ב-8k ויהיה גבולי ב-16k, בעוד כרטיס עם 12 GB משאיר מרווח נוח ל-context ארוך יותר. מעבר של ה-cache ל-q8_0 מקטין את חלקו בערך בחצי. אם אתם מתכננים להריץ context של 128k, חשבו את גודל ה-cache בנפרד, שכן הוא עלול לגדול מעבר למשקל המודל עצמו.

האם ניתן להריץ את Ollama ללא GPU?

כן. Ollama עוברת אוטומטית לשימוש ב-CPU וזקוקה רק למספיק RAM כדי להחזיק את המודל. צפו לקצב של כ-5 עד 12 טוקנים לשנייה עבור מודל 8B ב-4-bit, תלוי במהירות הזיכרון, מה שקרוב לקצב קריאה של משתמש בודד. prompt ארוכים הם נקודת התורפה האמיתית ב-CPU, כיוון שקריאת 30,000 טוקנים של context מוגבלת על ידי כוח העיבוד ולוקחת זמן רב בהרבה מאשר יצירת התשובה.

מדוע ה-GPU שלי בקושי מהיר יותר מה-CPU?

הסיבה הנפוצה היא שהמודל לא נכנס במלואו ל-VRAM, ולכן חלק מהשכבות רצות על ה-CPU וכל טוקן ממתין לחלק האיטי. הריצו את ollama ps ובדקו אם העמודה PROCESSOR מציגה 100% GPU. אם מופיע פיצול, השתמשו בקוונטיזציה נמוכה יותר או במודל קטן יותר. סיבה נפוצה נוספת היא benchmark קצר שבו זמן טעינת המודל משפיע על המדידה יותר מהביצועים עצמם.

האם משתלם לשכור GPU VPS עבור משתמש בודד?

בדרך כלל לא. קריאה שקטה של מבוגר באנגלית היא בממוצע כ-4.0 עד 4.3 מילים לשנייה, ויש להמיר טוקנים לשנייה למילים לשנייה לפני שמשווים שרת CPU לקצב הזה. המקרים שמצדיקים את העלות עבור משתמש בודד הם prompt ארוכים, יצירת תמונות, ו-fine-tuning. שירות למשתמשים רבים בו-זמנית הוא הטיעון החזק ביותר, כיוון ש-batching מאפשר ל-GPU אחד לשתף קריאות משקולות בין בקשות שונות.

האם כדאי לשכור GPU לפי שעה או להריץ שרת קבוע?

שכרו לפי שעה כאשר העבודה היא מרוכזת (bursty): ביצוע fine-tuning, הרצה מאסיבית של embeddings, או עבודת תמלול אצווה. הריצו שרת קבוע רק כאשר הכרטיס נשאר עמוס, כיוון שמשאבי GPU מוקצים מחויבים לפי זמן ולא לפי כמות טוקנים שנוצרו. עוזר אישי עם תעבורה נמוכה זול יותר על שרת CPU, או באמצעות API בתשלום לפי טוקן, מאשר על GPU שעומד ללא שימוש.