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

האם דרוש שרת VPS עם GPU, או שמעבד (CPU) מספיק?

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

הסיבה לכך היא רוחב פס של הזיכרון. כאשר מודל שפה מייצר token אחד, הוא קורא כל משקל נחוץ מהזיכרון. מודל 8B מקוונטט ל־4 ביטים תופס כ־4.7 GB על הדיסק ובערך אותו דבר בזיכרון, לכן הפקת token משמעותה העברת כ־4.7 GB. חלקו את רוחב הפס של הזיכרון במכונה במספר זה, ותקבלו את התקרה ל־tokens לשנייה. חילוק פשוט זה מסביר כמעט כל benchmark שתקראו.

מה באמת מקבלים מרכישת GPU

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

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

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

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

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

הבלוק להלן מציג נתונים טיפוסיים שפורסמו עבור זרם יחיד (single-stream) עבור מודל 8B בקוונטיזציה של 4-bit, נכון ליולי 2026. אלו הם נתוני הערכה מסדר גודל כללי, ולא הבטחה. הקוונטיזציה, אורך ההקשר (context length) ומנוע ההסקה (inference engine) שלכם ישנו את התוצאות.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

השורה עבור GPU עם 24 GB מציגה 50 טוקנים לשנייה לעומת 11 עבור שרת CPU עם זיכרון DDR5. זהו יחס של פי חמישה בערך, התואם את יחס רוחב הפס ולא הבדל בחישוב גולמי. התפוקה בפועל נמוכה מרוחב הפס חלקי גודל המודל, כיוון שמנגנון ה-attention על פני הקשר גדל מוסיף עבודה שחישוב פשוט מתעלם ממנה.

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

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

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

כלל אצבע מעשי נכון ליולי 2026: קחו את גודל קובץ המודל בגיגה-בייט והוסיפו 20 אחוז עבור הקשר (context) סטנדרטי של 8k עד 16k. מודל 8B בגודל 4.7 GB דורש כ-6 GB של VRAM. מודל 27B בקוונטיזציה של 4 ביט הוא כ-16 GB ודורש בערך 20 GB. מודל 70B ב-4 ביט הוא כ-40 GB וזקוק לכרטיס של 48 GB, או לשני כרטיסים קטנים יותר. החישוב הזה ממשיך לעבוד גם הרבה מעבר לכך, ו-המתמטיקה של VRAM עבור מודל עם 2.8 טריליון פרמטרים כמו Kimi K3 מראה את הנקודה שבה בחירת הכרטיס מפסיקה להיות השאלה העיקרית.

הקשרים ארוכים (long contexts) שוברים את הכלל הזה. ה-KV cache גדל ליניארית עם אורך ההקשר, וב-128k טוקנים הוא עלול לעלות בנפחו על המשקולות עצמן. אם אתם מתכננים להשתמש בהקשרים ארוכים, תכננו את הנפח לפי ה-cache תחילה ובדקו אילו אפשרויות קוונטיזציה ל-cache מציע מנוע ההרצה שלכם.

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

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

nvidia-smi

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

עבור מכולות (containers), הדרייבר לבדו אינו מספיק. 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 שלא ניתן לספק, מעידה על כך שה-toolkit מותקן אך Docker לא הוגדר מחדש או לא עבר הפעלה מחדש; לכן, הריצו שוב את הפקודה 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 עולים פי כמה ממופע CPU מקביל, והחיוב עבורם מתבצע לפי כל שעה שבה הם קיימים, לא לפי כמות ה-tokens שהם מייצרים. GPU שפועל ללא הפסקה ומשרת מספר קטן של בקשות ביום הוא הדרך היקרה ביותר להרצת הסקה (inference). נקודת האיזון היא ניצולת: GPU עמוס הוא זול לכל token, בעוד ש-GPU במצב סרק הוא בזבוז טהור.

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

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

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

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

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

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

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

FAQ

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

כ־6 GB עבור מודל 8B בקוונטיזציה של 4-bit עם context רגיל של 8k עד 16k. המשקולות תופסות כ־4.7 GB, והיתרה מוקצית ל-KV cache בתוספת כ־1 GB של overhead. כרטיס עם 12 GB משאיר מרווח נוח ל-contexts ארוכים יותר. אם בכוונתכם להריץ context של 128k, חשבו את גודל ה-cache בנפרד, שכן הוא עלול לגדול מעבר לנפח המשקולות.

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

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

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

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

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

בדרך כלל לא. אדם אחד קורא בקצב של 5 עד 10 מילים לשנייה, ושרת CPU כבר מייצר טוקנים מהר יותר מזה עבור מודלים של עד כ-13B. המקרים המצדיקים את העלות עבור משתמש יחיד הם הנחיות ארוכות, יצירת תמונות ו-fine-tuning. שירות למשתמשים רבים בו-זמנית הוא הטיעון החזק ביותר, כיוון ש-batching מאפשר ל-GPU אחד לענות לעשרים בקשות בעלות הקרובה לעלות של מענה לבקשה אחת.

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

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