אם אתם משיקים מוצר המבוסס על מודלי שפה גדולים, מתח הרווח שלכם יציב רק ככל שהתעריפון של הספק שלכם יציב. Novita ו-StreamLake עדכנו לאחרונה את תמחור המודלים שלהן, וזה אומר שהכלכלה היחידתית (unit economics) שלכם השתנתה, בין אם שמתם לב ובין אם לא. אלו אינם חלונות תחזוקה שגרתיים. כאשר ספקי אינפרנס משנים את התעריפים שלהם לכל טוקן, העלות לסיווג כרטיס תמיכה, סיכום מסמך או יצירת הצעת קוד משתנה בן לילה. מפתחים המתייחסים לתמחור API כרעש רקע סטטי בדרך כלל מגלים את הבעיה רק כשהחשבונית החודשית מגיעה.
למה שינוי מחיר שקט יכול להרוס תקציב
רוב צוותי ההנדסה בוחרים ספק אינפרנס, מריצים כמה מבחני latency, וממשיכים הלאה. תבניות הפרומפט נשמרות בבקרת גרסאות, קוד הלקוח עובר לסביבת ייצור, וצוות הכספים מקבל הערכה חודשית גסה. זרימת העבודה הזו עובדת עד שהיא מפסיקה לעבוד. טוקנים הם משאב מתכלה. החשבונית שלכם גדלה בהתאם לאימוץ המשתמשים, אורך ה-context והתנהגות הניסיונות החוזרים (retry). העלאת תעריפים שנראית מינורית בגיליון אלקטרוני יכולה למחוק את הרווח בפיצ'ר בעל נפח גבוה.
ההשפעה תלויה לחלוטין בדפוס השימוש שלכם. צוות השולח פרומפטים קצרים לסיווג עשוי לספוג התאמת מחיר מבלי לשנות דבר. צוות המעבד חלונות context ארוכים או מריץ עבודות batch על פני אלפי דפים עלול לראות את קצב ה-burn rate שלו מזנק במהירות. אותו שינוי באחוזים משפיע אחרת, תלוי בשאלה האם הקריאה הממוצעת שלכם היא מאתיים טוקנים או עשרים אלף. זו בדיוק הסיבה שעדכונים מ-Novita ו-StreamLake ראויים לבחינה מעמיקה. אתם צריכים לדעת אם העלות הממוצעת שלכם למשתמש חרגה מהתחזיות שלכם, והאם הגיע הזמן לנתב מחדש את התעבורה.
עדכון התמחור של Novita
Novita התאימה לאחרונה את מחירי המודלים שלה. הפלטפורמה מציעה גישה למגוון מודלי שפה, וכל שינוי שם זורם ישירות לעלויות התפעול של צוותים המשתמשים בה כשכבת אינפרנס ראשית. מכיוון ש-Novita מארחת מודלים מרובים, העדכון עשוי שלא להיות אחיד לאורך הקטלוג. משפחת מודלים אחת עשויה להישאר ללא שינוי בעוד אחרת משתנה. הפירוט הזה חשוב יותר ממה שמרמזת הודעה כללית.
אם אתם מנתבים את כל התעבורה דרך model ID יחיד, קל לחשב את ההוצאה החזויה החדשה שלכם. אם אתם משתמשים בקטלוג של Novita בצורה דינמית, תוך ניתוב פרומפטים מורכבים למודלים גדולים יותר ופרומפטים פשוטים לקטנים יותר, העלות הממוצעת המשולבת שלכם עשויה להשתנות בדרכים ששום התראה בודדת לא תסביר. הדרך היחידה לדעת היא לשלוף את יומני השימוש (usage logs) שלכם, לקבץ אותם לפי מודל, ולהכפיל את ספירת הטוקנים בפועל בתעריפון החדש. אל תסמכו על הזיכרון שלכם לגבי המחיר שהיה בעבר למיליון טוקנים. תכתבו זאת. שמרו רישום היסטורי. הפכו זאת לחלק ממחזור הסקירה הרבעוני שלכם כדי שהשינוי הבא לא יפתיע אתכם.
עדכון התמחור של StreamLake
גם StreamLake הוציאה עדכון מחירים למודלים שלה. עבור צוותים המשולבים ב-stack שלה, כל התאמה בתעריפי הטוקנים משנה את החישוב עבור ניתוח תוכן, מערכות תמלול (transcription back-ends), פיצ'רים גנרטיביים או כל עומס עבודה שפועל דרך הפלטפורמה. הגודל המוחלט של ההתאמה הוא משני לעומת האפקט המצטבר. אפילו עלייה מתונה לכל טוקן מצטברת כאשר מעבדים מיליוני טוקנים ביום בסביבות מרובות.
השאלה האמיתית היא לא מה המחיר החדש, אלא מה המחיר החדש הזה עושה למתח הרווח הגולמי שלכם לכל פיצ'ר. אם StreamLake מפעילה כלי סיכום הפונה ללקוחות או שכבת מודרציה פנימית, עלות המכר (COGS) שלכם הרגע השתנתה. עליכם לבודד את ההוצאה הזו בבירור בכלי ה-observability שלכם. תייגו את קריאות ה-API הללו לפי ספק ולפי פיצ'ר, כך שכאשר החשבונית תגיע, תוכלו לחלק אותה במדויק. אם מקרה שימוש מסוים הפך ללא רווחי, אתם צריכים את הנתונים ביד כדי להחליט אם להגביל אותו, להוריד גרסה למודל קטן יותר, או לספוג את ההפסד כעלות אסטרטגית.
איך לבצע ביקורת על הוצאות האינפרנס שלכם
קבלת