Token Economics — חישוב העלות האמיתית של מערכת Agentic

מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳

המחיר ל-1K טוקנים בדף התמחור הוא רק נקודת ההתחלה. מדריך לחישוב העלות המלאה של פייפליין agentic: קריאות כלים, retries, טוקני חשיבה ו-context שמצטבר.

מנהל מוצר שהריץ POC של סוכן AI לטיפול בפניות לקוחות תמחר את הפרויקט לפי חישוב פשוט: מחיר הטוקן מדף התמחור של הספק, כפול הערכת אורך שיחה ממוצעת. התוצאה בפועל בפרודקשן הייתה גבוהה פי שבעה מהתחזית. הפער לא נבע מטעות בהבנת מחיר הטוקן — הוא נבע מכך שהחישוב המקורי התעלם משרשרת שלמה של עלויות נסתרות: כל קריאת כלי (tool call) שולחת מחדש context שלם, כל retry אחרי כשל מכפיל את הבקשה, וכל צעד תיכנון (planning) בתוך agent loop צורך טוקני קלט ופלט משלו. חישוב עלות אמיתי של מערכת agentic דורש לספור לא את "התשובה" אלא את כל מה שקרה בדרך אליה.

למה מחיר לטוקן הוא רק שכבה אחת בחישוב

ספקי מודלים מפרסמים מחיר לפי אלף או מיליון טוקני קלט ופלט, ולפעמים מחיר נפרד (זול משמעותית) לטוקני קלט שנשלפים מ-cache. זה מחיר יחידה מדויק — אבל הוא לא אומר כלום על כמות היחידות שבפועל נצרכות במשימה אחת. סוכן agentic טיפוסי לא שולח פרומפט אחד ומקבל תשובה אחת; הוא רץ בלולאה של תכנון-פעולה-תצפית (plan-act-observe) שיכולה לכלול חמישה עד עשרים סבבים לפני שהמשימה נסגרת. כל סבב שולח מחדש את כל ה-context המצטבר — כולל תוצאות כלים קודמים, החלטות ביניים והוראות המערכת — כך שהעלות גדלה לא ליניארית אלא בערך ריבועית ביחס למספר הסבבים, אלא אם משתמשים ב-Prompt Caching כדי לצמצם את התופעה הזו.

נקודה נוספת שמפתיעה צוותים: טוקני חשיבה (thinking tokens) במודלים עם extended reasoning נחשבים אצל חלק מהספקים כטוקני פלט לצורך תמחור, למרות שהם "בלתי נראים" למשתמש הסופי. משימה שמייצרת 3,000 מילים של תשובה גלויה יכולה לצרוך בפועל 15,000 טוקני חשיבה מאחורי הקלעים — פי חמישה מהעלות שמישהו רואה כשהוא סופר את התשובה בעיניים.

מפת העלויות המלאה של פייפליין agentic

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

• System prompt וכלים זמינים — נשלחים בכל קריאה, גם אם לא נעשה בהם שימוש בפועל. עשרות tool definitions מפורטות יכולות להוסיף אלפי טוקנים לכל בקשה בודדת.
• Context מצטבר — תוצאות כלים, פלט ביניים, זיכרון שיחה. גדל עם כל סבב, ולכן משימה ארוכה בת 15 סבבים עולה משמעותית יותר מ-15 פעמים משימה בת סבב אחד.
• טוקני חשיבה — כאמור, יכולים להוות את הרוב המכריע של העלות במודלים עם extended thinking, במיוחד תחת Dynamic Reasoning Budget גבוה.
• Retries וכשלים — כל ניסיון כושל (JSON לא תקין, timeout, תשובה שנפסלה ב-validation) חוזר על כל הקריאה מההתחלה, בעלות מלאה נוספת.

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

כדי להמחיש בסדר גודל: משימה שבה התשובה הסופית היא 500 טוקן בלבד יכולה בפועל לגרור לאורך הריצה 4,000 טוקן system prompt וכלים (שנשלחים מחדש בכל סבב), 6,000 טוקן context מצטבר עד הסבב האחרון, 9,000 טוקן חשיבה, ועוד סבב retry שלם שמכפיל כ-30% מהעלות הזו בגלל תשובת JSON לא תקינה בניסיון הראשון. סך הכול מדובר בסביבות 25,000-30,000 טוקן בפועל מול 500 טוקן "תשובה" שרואים על המסך — יחס של פי 50-60. כל תחזית תקציב שמתעלמת מהיחס הזה תפספס בגדול, ולכן אי אפשר לבסס תמחור ללקוח על "אורך תשובה משוער" בלבד.

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

ברמת התפעול היומיומי, שני מדדים חשובים יותר מ"עלות ממוצעת לבקשה": עלות למשימה שהושלמה בהצלחה (לא לכל קריאת API בודדת — כדי לתפוס את מחיר ה-retries בתוך התמונה), ויחס טוקני עבודה לטוקני תשובה — כמה טוקנים "מתבזבזים" על תכנון, קריאות כלים ותצפיות ביחס לתשובה הסופית שהמשתמש רואה. יחס גבוה מדי (למשל פי 20 ומעלה) הוא סימן ל-agent loop לא יעיל שכדאי לבדוק — אולי המודל "מתלבט" יותר מדי, או שהכלים מחזירים יותר מידע ממה שנחוץ.

שילוב המדדים האלה עם עקרונות רחבים יותר של אופטימיזציית עלויות AI מאפשר לבנות תחזית תקציב שמדויקת ברמת ה-1K$ הבודד, לא רק ברמת "בערך נראה סביר". כשמדובר בפרויקט שאמור לשרת אלפי משתמשים, ההבדל בין תחזית מדויקת לתחזית אופטימית הוא ההבדל בין תמחור ללקוח שמכסה עלויות לבין תמחור שגורם להפסיד כסף על כל שיחה.

מדד שלישי ששווה לעקוב אחריו הוא עקומת עלות לפי אורך שיחה — כלומר לצייר גרף שמראה כמה עולה כל סבב נוסף בתוך אותה שיחת agent. ברוב המערכות העקומה הזו לא ליניארית אלא מאיצה, כי context מצטבר ולא מתאפס בין סבבים. זיהוי הנקודה שבה עלות הסבב הבא עוברת סף כלכלי סביר (למשל, יקרה יותר מהערך העסקי הצפוי מהמשך השיחה) מאפשר להגדיר "תקרת סבבים" הגיונית לפני שממשיכים אוטומטית, במקום לתת לשיחה להמשיך עד שהמודל עצמו מחליט לעצור.

מי בארגון בעצם "צורך" את העלות הזו

ברגע שיש מודל עלות מדויק ברמת המשימה, השאלה הטבעית הבאה היא איך מייחסים אותה לצוותים, לקוחות או פיצ'רים ספציפיים בתוך הארגון — במיוחד כשכמה מחלקות חולקות את אותה תשתית AI. זו בדיוק השאלה שנדונה במאמר Agent Cost Attribution, שמראה איך להפוך את המספרים שנאספו כאן ל-chargeback תפעולי אמיתי, ולא רק לחשבונית חודשית אחת גדולה שאף אחד לא יודע לפרק.

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

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

תגיות: Token Economics · LLM Cost · Agent Loop · Prompt Caching · Model Economics

← חזרה לבלוג · צור קשר