הגדרת מעקב עלויות לבקשות בינה מלאכותית: ניטור עלות טוקנים

מעקב עלויות AI: מדוע צריכת הטוקנים גדלה בלי שמבחינים בכך

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

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

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

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

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

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

מה נותנת חשבונאות מקצה-לקצה של צריכת בקשות למודלים

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

ייחוס צריכה לפי מוצרים וצוותים

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

מגבלות וצפיות בצריכה

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

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

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

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

דיוק הייחוס

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

עלויות תפעול בפרודקשן

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

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

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

1. ביקורת קריאות ומקורות. מרכיבים מרשם של שירותים, מפתחות ומודלים; מסמנים בנפרד משימות רקע, ניסיונות חוזרים ותשובות זורמות — אלה לרוב מייצרים צריכה שלא נספרת.
2. סכימת תיוג. קובעים תגיות חובה: צוות, מוצר, סביבה, תרחיש. קריאה בלי תגית לא עוברת ולידציה בשער, אחרת גדל שיעור הצריכה שאינה מזוהה.
3. הגדרת איסוף מדדים. השער שלפני המודל מתעד טוקנים בקלט ובפלט, סוג המודל, משך וסימן זרימה; האגרגטים נשמרים במאגר בפרקי זמן.
4. בדיקה על קריאות זורמות וחוזרות. בהזרמה המונה מגיע בסוף התשובה, ובחזרה — משוכפל: כאן תופסים כפל חשבונאות ואובדנים בעת ניתוק החיבור.
5. התאמה מול דוח הספק. משווים אגרגטים על אותן תקופות: פער בטווח של כמה אחוזים — עיגול, פער גדול יותר — מפרקים לפי קריאות ספציפיות.
6. מסירת נהלים. מעבירים תיאור תגיות, ספי התראות, סדר ניתוח אנומליות וכללים להוספת תרחישים חדשים.

בדיקת התכנסות עם נתוני הספק

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

מה מוסרים לידיים: קונפיגורציות, מדיניות, נהלים

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

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

מדיניות גישה ותפקידים

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

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

נוהל תגובה לאנומליות

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

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

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

מה הראו המדידות לפני ההטמעה

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

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

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

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

במה נבדלת חשבונאות בשער מאינסטרומנטציה של הקוד?

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

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

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

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

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

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

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

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

כיצד מפרידים צריכה כאשר כמה מוצרים פונים דרך שירות קריאות משותף?

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

מה קורה בתשובות זורמות?

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

האם נלקחות בחשבון קריאות חוזרות ופסקי זמן?

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

האם אפשר לעקוף את החשבונאות?

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

נדון במשימה: נחזור עם הערכה ותוכנית חשבונאות

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

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

מה להכין לשיחה:

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

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