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

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

שבעת הפריטים שמרכיבים את החשבון

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

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

למה שורת המודל היא רק חלק קטן מהעלות?

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

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

דוגמה מחושבת עם תעריפים מציינים בלבד

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

1. קובעים נפח: 4,000 ריצות בחודש.
2. מודדים ריצה ממוצעת: 3,000 טוקני קלט ו-600 טוקני פלט. מודדים, לא מנחשים.
3. מכפילים: 12 מיליון טוקני קלט ו-2.4 מיליון טוקני פלט בחודש.
4. מכפילים בתעריף מציין מקום של דולר אחד למיליון קלט וארבעה דולר למיליון פלט: 12 דולר ועוד 9.6 דולר, סך 21.6 דולר.
5. מוסיפים ניסיונות חוזרים בשיעור שמונה אחוזים: כ-23.3 דולר.
6. מוסיפים אחזור, אחסון וניטור בסכום מציין מקום של 55 דולר.
7. מוסיפים בקרה אנושית: חמישה עשר אחוז מהריצות נבדקות, שתי דקות לבדיקה, סך עשרים שעות בחודש.

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

מה קורה לחשבון כשהנפח מוכפל?

לא כל שורה מגיבה אותו דבר, וזו בדיוק הסיבה לבנות את המודל כנוסחה ולא כמספר יחיד.

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

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

איפה מורידים עלות בלי לשבור את התוצאה

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

איך מודדים עלות לריצה בתוך המערכת

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

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

הפער בין אומדן למדידה הוא שהאומדן עונה על שאלה אחת פעם אחת, והמדידה עונה על כל שאלה עתידית. אחרי חודש של נתונים אמיתיים, המודל שבנו בהתחלה הופך לכלי בקרה במקום לתירוץ.

מקורות

• OpenAI API pricing
• Claude platform pricing documentation