עלות הטוקנים היא שורה אחת מתוך שבע בעלות הבעלות של פיצ׳ר LLM. חשבון מלא כולל טוקני קלט ופלט, ניסיונות חוזרים, אחזור והטמעות, שכבת הערכה, ניטור, בקרה אנושית ותשתית. מחיר ה-API המוצהר מסביר לרוב פחות ממחצית מהעלות בפרודקשן, ולכן מרווחים גולמיים של 80%-90% ב-SaaS מסורתי נשחקים ל-50%-60% ברגע שמוסיפים קריאות מודל למוצר. השאלה הנכונה אינה כמה עולה מיליון טוקנים, אלא כמה עולה יחידת עבודה אחת שהלקוח מוכן לשלם עליה.
שבע שורות העלות של פיצ׳ר שנשען על מודל
רוב הצוותים מתמחרים פיצ׳ר AI לפי מחירון הספק: כך וכך דולרים למיליון טוקני קלט, כך וכך לפלט. זו שורה אחת. כשמגיעים לפרודקשן מתגלות שש שורות נוספות, וחלקן קבועות ולא משתנות עם הנפח, כלומר הן כבדות יותר דווקא בהתחלה.
| שורת עלות | מה נכלל | התנהגות |
|---|---|---|
| טוקני קלט ופלט | הפרומפט, ההקשר שנשלף, ותשובת המודל | משתנה, לינארי בנפח |
| ניסיונות חוזרים וכשלים | timeout, rate limit, פלט שנפסל בוולידציה ונשלח שוב | משתנה, קופץ בעומס |
| אחזור והטמעות | יצירת embeddings, אחסון וקטורי, שאילתות אחזור, אינדוקס מחדש | מעורב: אינדוקס קבוע, שאילתה משתנה |
| שכבת הערכה | מערכי בדיקה, הרצות eval לפני כל שינוי פרומפט או מודל | קבוע לכל מחזור פיתוח |
| ניטור ולוגים | שמירת קלט ופלט, מדדי איכות, התראות, אחסון לאורך זמן | קבוע עם רכיב נפח |
| בקרה אנושית | סקירת מדגם, טיפול בהסלמות, תיוג מקרי קצה | משתנה בשעות אדם |
| תשתית ואינטגרציה | שכבת הפשטה לספקים, תורים, קאשינג, אבטחה והרשאות | קבוע, פוחת יחסית עם הצמיחה |
למה מחיר הטוקן המוצהר מטעה
שלושה פערים שיטתיים מפרידים בין המחירון לחשבונית בפועל.
פלט יקר בהרבה מקלט. אצל רוב הספקים טוקן פלט מתומחר בפי חמישה עד פי שמונה מטוקן קלט. פיצ׳ר שמייצר תשובות ארוכות משלם על האורך הזה בכפל, ולכן הגבלת אורך הפלט היא לרוב מנוף החיסכון הזול ביותר שאפשר להפעיל ביום אחד.
ההקשר גדל בשקט. ברגע שמוסיפים אחזור, כל קריאה נושאת איתה קטעי מסמכים, היסטוריית שיחה והוראות מערכת. הפרומפט שנראה כמו שלוש שורות בקוד הוא בפועל כמה אלפי טוקנים, וההפרש הזה מוכפל בכל קריאה.
ניסיונות חוזרים לא מופיעים בתכנון. קריאה שנכשלה בוולידציה, בפורמט או ב-timeout נשלחת שוב ומשלמים עליה פעמיים. בעומס אמיתי שיעור הניסיונות החוזרים הוא לרוב ההבדל בין תחזית לחשבונית.
הנוסחה: עלות ליחידת עבודה
במקום לעקוב אחרי צריכת טוקנים כוללת, הגדירו יחידת עבודה אחת שיש לה משמעות עסקית: פנייה שנפתרה, מסמך שסוכם, ליד שהועשר, שורה שסווגה. אז החשבון נראה כך:
| רכיב | איך מחשבים | הערה |
|---|---|---|
| עלות קריאה ממוצעת | (טוקני קלט × מחיר קלט) + (טוקני פלט × מחיר פלט) | מדדו בפועל, אל תעריכו |
| קריאות ליחידה | כולל שלבי אחזור, ניתוב, סיווג ובדיקה | סוכן טיפוסי עושה 3-8 קריאות ליחידה |
| מכפיל ניסיונות חוזרים | 1 חלקי שיעור ההצלחה מהניסיון הראשון | 85% הצלחה שווה מכפיל 1.18 |
| עלות בקרה אנושית | שיעור ההסלמה × עלות שעת אדם × זמן טיפול | לרוב השורה הכבדה ביותר |
| הקצאת עלויות קבועות | סך העלויות הקבועות חלקי מספר היחידות בחודש | יורד ככל שהנפח עולה |
בנצ׳מרקים שפורסמו במהלך 2026 בתחום שירות הלקוחות ממקמים פנייה שנפתרה על ידי סוכן AI בטווח של כחצי דולר עד שני דולרים ברמת היחידה, מול שישה עד שנים עשר דולרים לפנייה בטיפול אנושי. הפער נראה מוחץ, אבל הוא מצטמצם משמעותית כשמוסיפים את שורות הבקרה, ההערכה והתשתית, ויש פרסומים שמעמידים את העלות המלאה של פתרון אוטומטי סביב חמישה דולרים. ההבדל בין שתי הקריאות האלה הוא בדיוק ההבדל בין עלות טוקן לעלות בעלות.
שלושת המנופים שבאמת מזיזים את החשבון
לפני שמחליפים ארכיטקטורה, יש שלוש הנחות מובנות שהספקים כבר נותנים ורוב הצוותים לא מנצלים במלואן.
| מנוף | סדר גודל ההנחה | מתי מתאים |
|---|---|---|
| קאשינג של פרומפט | קריאת מטמון מתומחרת סביב עשירית ממחיר הקלט הרגיל | הוראות מערכת קבועות, מסמכי בסיס חוזרים |
| עיבוד באצווה | כמחצית מהמחיר | כל מה שלא חייב תשובה בזמן אמת |
| בחירת מודל לפי משימה | פער של פי עשרות בין שכבות מודלים | סיווג, חילוץ וניתוב לא צריכים מודל חזית |
מה זה עושה לדוח הרווח וההפסד
מוצר תוכנה מסורתי חי במרווח גולמי של 80%-90%, כי עלות ההגשה של משתמש נוסף שואפת לאפס. פיצ׳ר שנשען על מודל שובר את ההנחה הזו: לכל שימוש יש עלות מחשוב ממשית. פרסומים מ-2026 ממקמים את המרווח הגולמי של פיצ׳רים כאלה בטווח 50%-60%.
המשמעות המעשית אינה שהפיצ׳ר לא כדאי, אלא שמודל התמחור חייב להשתנות יחד איתו. תמחור לפי מושב, שאינו רגיש לשימוש, הופך משתמשי כוח לגירעון שקט: כשחמישה אחוזים מהמשתמשים מייצרים את רוב עלות המחשוב, מחיר אחיד לכולם פשוט מסבסד אותם. הרחבנו על כך במאמר על תמחור מוצר שנשען על מודל, ועל הקשר בין עלות ליחידה לרווחיות הכוללת במאמר על מודל היחידה של עסק דיגיטלי.
איך מודדים את זה בפועל
- תייגו כל קריאה ל-API במזהה של יחידת העבודה שהיא משרתת, ולא רק במזהה משתמש. בלי זה אי אפשר לחשב עלות ליחידה בדיעבד.
- שמרו בנפרד ספירת טוקני קלט, טוקני פלט, ומספר הניסיונות. סכום אחד של עלות מסתיר את כל מה שאפשר לתקן.
- מדדו את שיעור ההצלחה מהניסיון הראשון כמדד מוצר, לא כמדד תשתית. הוא מכפיל ישירות את העלות.
- הקצו את העלויות הקבועות ליחידות בכל חודש, אחרת פיצ׳ר בצמיחה ייראה גרוע מכפי שהוא.
- קבעו תקרת עלות ליחידה כקריטריון שחרור, באותו מעמד של קריטריון איכות. פיצ׳ר שעובר את התקרה לא עולה לאוויר.
הנקודה האחרונה מתחברת לשאלה רחבה יותר: איך בכלל מגדירים תנאי קבלה למערכת שהפלט שלה הסתברותי. פירטנו את זה במאמר על קריטריוני קבלה לפיצ׳ר AI, ואת הצד הפיננסי הרחב אנחנו מלווים בשירות תכנון פיננסי דיגיטלי.
שאלות נפוצות
מה חלקה של עלות ה-API מתוך עלות הבעלות הכוללת?
אין מספר אחד, אבל בפריסות שבהן יש בקרה אנושית, שכבת הערכה וניטור, עלות ה-API היא לרוב מיעוט מהעלות הכוללת. ככל שהמוצר יותר ממוכן ופחות מפוקח, חלקה עולה. לכן צריך לחשב את שבע השורות ולא להסתמך על המחירון.
איך מעריכים עלות לפני שיש פרודקשן?
מריצים מדגם מייצג של כמה מאות יחידות עבודה אמיתיות דרך הצינור המלא ומודדים טוקנים, קריאות וניסיונות חוזרים בפועל. הערכה מהפרומפט לבד תחטא כמעט תמיד כלפי מטה, כי היא מתעלמת מההקשר שנשלף ומהכשלים.
האם מודל קטן יותר תמיד זול יותר?
לא. מודל זול שנכשל לעיתים קרובות יותר מייצר ניסיונות חוזרים, פלטים ארוכים יותר והסלמות לאדם, וכל אלה יקרים יותר מהפער במחיר הטוקן. ההשוואה הנכונה היא עלות ליחידת עבודה שהושלמה בהצלחה, לא מחיר למיליון טוקנים.
מתי כדאי לעבור למודל בבעלות עצמית?
כשהעומס צר, חוזר על עצמו ובנפח גבוה, וכשעלות ה-API או ההשהיה הפכו לאילוץ הכובל. בנפח נמוך או במשימה רחבה, עלות ההנדסה והתחזוקה של מודל עצמי בדרך כלל עולה על החיסכון.
מה המדד היחיד שכדאי לעקוב אחריו?
עלות ליחידת עבודה שהושלמה בהצלחה, במעקב חודשי. הוא סופג בתוכו את מחיר הטוקנים, את שיעור הכשלים, את ההסלמות ואת יעילות האחזור, והוא היחיד שאפשר להשוות ישירות לתמחור ולעלות החלופה האנושית.
