כמה זה באמת עולה?

למה החשבון יוצא שונה ממה שחושבים

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

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

הטוקנים הסמויים

כל פנייה כוללת לא רק את הקלט הספציפי של המשתמש, אלא גם:

• System prompt - לרוב 500-3,000 טוקנים קבועים לכל פנייה. אם לא משתמשים ב-caching, כל פנייה משלמת על זה מחדש.
• Tool definitions - אם המודל יודע לקרוא לכלים, התיאור של כל כלי הוא טוקנים בקלט. 5 כלים עם תיאור מפורט = בקלות 2,000 טוקנים שלא ראיתם.
• היסטוריית שיחה- בצ'אטבוט, כל פנייה כוללת את כל ההיסטוריה הקודמת. השיחה ה-10 כוללת בקלט את 9 הסיבובים שקדמו לה.
• הקשר קבוע - מסמך שצירפתם, טבלת נתונים, או לוגים - מצורפים לכל פנייה רלוונטית.

איטרציות נסתרות

כל אפליקציה רצינית כוללת איטרציות שלא נחשפות למשתמש. דוגמאות:

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

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

פירוק משימה - משימה מורכבת מתפצלת ל-5 משימות קטנות, כל אחת נשלחת בנפרד. במקום קריאה אחת, יש 5.

תרבות שימוש

החישוב הראשוני מניח שמשתמש שואל שאלה אחת, מקבל תשובה, ומסיים. במציאות, השימוש אינטראקטיבי:

• משתמשים מנסים שוב כשהתשובה הראשונה לא מספקת
• שיחות נמשכות לעיתים עשרות סיבובים
• שאלות המשך לא רק שולחות עוד טוקנים, אלא גם שולחות שוב את כל ההיסטוריה
• אנשים מנסים “לבדוק” את המודל - שאלות מורכבות, מקרי קצה, פרובוקציות

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

דוגמה מספרית אמיתית

בואו ניקח אפליקציה ריאלית: צ'אטבוט לתמיכת לקוחות מבוסס Sonnet, עם המאפיינים הבאים:

• system prompt: 2,000 טוקנים
• 5 כלים מוגדרים: 1,500 טוקנים נוספים
• שיחה ממוצעת: 8 סיבובים
• הודעת משתמש ממוצעת: 100 טוקנים
• תשובה ממוצעת של המודל: 300 טוקנים
• 5,000 שיחות ביום

חישוב לסיבוב יחיד: בקלט - system prompt + כלים + ההיסטוריה הקודמת + הודעה חדשה. בסיבוב הראשון: 2,000 + 1,500 + 0 + 100 = 3,600. בסיבוב השמיני: כבר 3,600 + 7×400 = 6,400 טוקני קלט.

ממוצע לסיבוב בשיחה של 8 סיבובים: בערך 5,000 טוקני קלט + 300 פלט. עלות לסיבוב: 0.015 דולר (קלט) + 0.0045 (פלט) = בערך 0.02 דולר. 8 סיבובים × 5,000 שיחות = 40,000 סיבובים ביום =800 דולר ביום, או 24,000 דולר בחודש.

איך מעריכים נכון

ארבעה כללי אצבע שעוזרים לבנות הערכה מציאותית:

1. תמיד תוסיפו 50%. אם החישוב התיאורטי הוא X, החשבון בפועל יהיה לרוב 1.5X-2X. ההפרש בא משגיאות שלכם, לא משגיאות של אנתרופיק.

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

3. הגדירו תקרת חיוב. בקונסולה של אנתרופיק יש אפשרות להגדיר תקרה יומית או חודשית. הפעילו אותה. עדיף שהאפליקציה תפסיק לעבוד למשך שעה מאשר שהחשבון יקפוץ ל-10X של הציפייה.

4. שקלו תמהיל של מודלים. Haiku ל-90% מהמשימות, Sonnet ל-10%. רוב הפניות לא דורשות את המודל החזק - אבל מפתחים בוחרים בו כברירת מחדל.

המסקנה

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

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