VPS עם GPU: מתי באמת צריך אותו?

האם אתם זקוקים ל-VPS עם GPU, או ש-CPU מספיק?

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

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

מה GPU באמת נותן לך

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

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

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

עיבוד פרומפט. קריאת פרומפט ארוך תלויה בכוח החישוב, ולא ברוחב הפס של הזיכרון, ובתחום הזה GPUs משיגים את היתרון הגדול ביותר. הקשר של 30,000 טוקנים, ש-CPU מעבד בתוך דקה, מעובד בתוך כמה שניות ב-GPU. במערכות אחזור שמכניסות מסמכים לכל בקשה, ההבדל הזה מורגש כל הזמן.

מספרים משוערים וכיצד לקרוא אותם

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

[
  {
    "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 לפני הרכישה

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

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

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

בדקו מה קיים בפועל במחשב

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

nvidia-smi

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

עבור קונטיינרים, המנהל לבדו אינו מספיק. 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

לאחר מכן ודאו שהעברת ההתקן פועלת מתוך קונטיינר:

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

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

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

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

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

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

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

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

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

מודלי צ'אט מכומתים עד בערך 27B, עבור משתמש אחד או שניים. איטיים, קריאים ושימושיים.

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

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

FAQ

כמה זיכרון VRAM נדרש למודל 7B או 8B?

כ-6 GB עבור מודל 8B שעבר quantization ל-4 ביט, בהקשר רגיל של 8k עד 16k. המשקלים תופסים בערך 4.7 GB, והיתרה משמשת ל-KV cache ולתקורה של כ-1 GB. כרטיס בנפח 12 GB משאיר מקום נוח להקשרים ארוכים יותר. אם בכוונתכם להפעיל הקשר של 128k, יש להקצות מקום ל-cache בנפרד, משום שהוא עלול לגדול מעבר לנפח המשקלים.

האם ניתן להפעיל את Ollama ללא GPU?

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

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

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

האם VPS עם GPU משתלם למשתמש יחיד?

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

האם כדאי לשכור GPU לפי שעה או להפעיל אותו תמיד?

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