פיתוח בילינג pay-per-inference עבור מודלי AI

חיוב pay-per-inference: היכן נשברת ספירת הקריאות למודל

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

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

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

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

אפקט מדיד: דיוק החיובים וזמני השבתה

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

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

מודלי תמחור pay-per-inference: השוואת גישות

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

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

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

שלבי הטמעת מעגל החיוב

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

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

סכמות ספירה, מדיניות מגבלות ותיעוד

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

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

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

מקרה בוחן: כיצד הסרנו פערים בחיובים

מה היה

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

הפערים בחיובים הגיעו ל-4% מהפניות, ושיעור החשבוניות השנויות במחלוקת היה כ-5%, והתמיכה עשתה את הסיכום ביד: יומיים-שלושה בסוף כל תקופת חישוב.

מה שינו

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

מה נהיה

הפערים בחיובים ירדו מתחת ל-0.1% מהפניות, ושיעור החשבוניות השנויות במחלוקת — עד 0.4%. הסיכום האוטומטי מתבצע מדי יום, נמשך 10-15 דקות ומעלה התראה כאשר הסטייה גבוהה מהסף: השגיאה נראית למחרת, לא בסגירת התקופה.

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

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

מה לעשות אם החיוב כבר עובד על ספירה עצמית?

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

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

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

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

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

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

ספקות טכניים: קריאות חוזרות, מגבלות, סיכום

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

כיצד נקבעים מגבלות ומכסות?

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

כיצד בנויים זיכויים של חיובים?

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

כיצד מתבצע סיכום סכומים ומה עושים עם פערים?

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

האם הספירה לא תכביד על המעגל הראשי?

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

נדון במשימה: סכמת ספירה ותמחור

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

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

לניתוח ענייני מספיק לשלוח:

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

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