למה שיוך עלויות בינה מלאכותית הוא עדיין בעיה

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

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

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

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

הממדים, ואיך הם מגיעים אל הקריאה

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

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

שתי דרכים להגיע לסכום השקלי, והן לא בדיוק מסכימות

יש שתי דרכים להגיע למספר של עלות, והן לא אותו מספר.

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

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

כל ענן נושא את הממד אחרת

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

1. 01

   AWS Bedrock: תגיות סשן אל דוח העלויות

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

2. 02

   Google Vertex: תוויות, בקריאות שמקבלות אותן

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

3. 03

   Azure AI Foundry: ממדים בראש הבקשה, בלי סכום בשקלים

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

למה כלי שסופר טוקנים לא מספיק

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

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

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

ספר המחירים הוא נכס מהשורה הראשונה

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

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

למה משהו כזה בדרך כלל נבנה לבד

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

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

מה כבר עובד, ומה עוד בדרך

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

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