ניתוח עלויות חדש מראה שאירוח עצמי (self-hosting) של מודל שפה גדול (LLM) משתלם יותר משימוש ב-APIs מסחריים רק כאשר עסק מעבד בערך 5 מיליון עד 10 מיליון טוקנים של קלט בכל חודש. עבור כל מי שמתקצב שירותי AI, נקודת האיזון קובעת האם הפיתוי של משקולות פתוחות (open weights) "חינמיות" יהפוך לחיסכון אמיתי.

מודל ה-API

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

  • Claude Sonnet 5 – $2 למיליון טוקנים של קלט
  • GPT-5.6 – כ-$1 למיליון טוקנים של קלט
  • Meta Muse Spark – $1.25 למיליון טוקנים נכנסים (inbound), $4.25 למיליון טוקנים יוצאים (outbound)

המודל הוא בתשלום לפי שימוש (pay-as-you-go). כאשר התעבורה יורדת לאפס, החשבון יורד לאפס. המשתמשים גם נמנעים מכאב הראש של כשלים ב-GPU, עדכוני קושחה (firmware) ותכנון קיבולת.

מודל האירוח העצמי

הרצת מודל בעל משקולות פתוחות (open-weight) על החומרה שלכם פירושה שאתם נושאים בעלות המחשוב ללא קשר לניצול. NVIDIA H100 בודד – בחירה נפוצה להסקה (inference) של LLM – עולה:

  • $2 – $3 לשעה בשירותי ענן GPU גנריים
  • $7 – $12 לשעה בפלטפורמות ענן מרכזיות (AWS, Azure)

זה מתרגם לכ-1,800$ עד 2,000$ לחודש עבור הפעלה רציפה של H100 אחד. מחיר החומרה הוא רק החלק הגלוי בחשבון.

איפה שהמספרים נפגשים

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

הוצאות תפעוליות נסתרות

השכרת GPU מהווה רק כ-30% מהעלות האמיתית של הרצת מודל בסביבת ייצור (production). השאר מגיע מ:

  • Networking and storage – קישורי רוחב פס גבוה ודיסקים מהירים שומרים על שיהוי (latency) נמוך.
  • Redundancy and monitoring – מופעים (instances) מרובים, בדיקות תקינות (health checks) וצינורות התראות מוסיפים הן להוצאות התוכנה והן לחומרה.
  • Engineering talent – שמירה על מודל מחובר באופן אמין דורשת בדרך כלל 1.5 עד 2 מהנדסים במשרה מלאה. לפי תעריפי השוק, זה מוסיף 270,000$ עד 550,000$ להוצאות השנתיות.

כשמוסיפים את השכבות הללו, החיסכון לכאורה מהחומרה לבדה מתנדף במהירות.

מי צריך לשקול אירוח עצמי

אירוח עצמי הגיוני רק בתנאים ספציפיים:

  • נפח עצום ועקבי – על הארגון לעבור באופן קבוע את סף ה-5 מיליון טוקנים, אחרת מחיר ה-API לכל טוקן נשאר נמוך יותר.
  • מגבלות רגולטוריות או פרטיות נתונים – מגזרים מסוימים אוסרים על שליחת נתונים קנייניים או אישיים לנקודות קצה (endpoints) של צד שלישי.
  • התאמה אישית מיוחדת או הבטחות שיהוי (latency) – כאשר יש צורך בכוונון עדין (fine-tuning) של מודל על נתונים פנימיים או אספקת תגובות מתחת לשנייה, בעלות על ה-stack יכולה להצדיק זאת.

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

אסטרטגיית היברידית

רוב הצוותים שמגיעים לקנה מידה שבו אירוח עצמי הוא בר-קיימא עדיין שומרים על גישה מעורבת:

  1. התחילו עם APIs – הם זולים, מהירים להטמעה ומושלמים לניסויים או לעומסי עבודה נמוכים.
  2. העבירו זרמי נתונים בנפח גבוה – ברגע שמספר הטוקנים עובר באופן עקבי את נקודת האיזון, העבירו את צינורות הנתונים (pipelines) הללו לצבר (cluster) פנימי.
  3. שמרו על רשת ביטחון – השאירו בקשות מזדמנות או בעלות "שיאי עומס" (bursty) ב-API כדי להימנע מיתור יתר (over-provisioning) של משאבים מקומיים (on-prem).

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

שורה תחתונה

אם מוצר ה-AI שלכם מעבד פחות מכמה מיליוני טוקנים בכל חודש, המסלול הפשוט והזול ביותר הוא עדיין לקרוא ל-API. רק כאשר עולה דרישה מתמשכת לנפח גבוה, ציות (compliance) מחמיר או צרכי שיהוי (latency) מותאמים אישית, אירוח עצמי הופך לכדאי מבחינה כלכלית – וגם אז, יש לקחת בחשבון את העלות הנסתרת של כוח אדם ותשתית לפני שמכריזים על ניצחון על הענן.