למה החשבון התפוצץ

כשהצוות הוסיף לראשונה בינה מלאכותית יוצרת (generative AI), הם שלחו כל בקשת משתמש למודל החדש והיכול ביותר. ככל שתעבורת הבקשות גדלה, העלויות לכל בקשה עלו בתיאום, וגיליון הנתונים של ה-CFO הראה שההוצאות עוקפות את קצב צמיחת המשתמשים. הפתרון המהיר הרגיל — "פשוט תשתמשו במודל זול יותר" — נכשל בסביבת ייצור (production), מכיוון ששאילתות שונות זקוקות לרמות חשיבה שונות. המנוף האמיתי הוא איך הבקשה נשלחת, ולא איזה מודל תמיד משתמשים בו.

בניית שכבת ניתוב שחוסכת כסף

המהנדס התייחס לשירות ההסקה (inference service) כמו לכל רכיב ייצור אחר: הגדרת שכבות, קביעת SLAs ואכיפת תקציבי שיהוי (latency budgets). הארכיטקטורה שנוצרה כוללת ארבעה מרכיבים פעילים שביחד מביאים להפחתה של 95%.

ניתוב מבוסס שכבות (Tiered routing)

ממשק קצה (front-end) דק מסווג כל בקשה נכנסת לפי רמת הקושי שלה. בערך 95% מהשאילתות נוחתות בשכבה "זולה" המריצה מודל צנוע; רק ה-5% הקשות ביותר מועברות למודל פרימיום. הסיווג יכול להיות מבוסס חוקים (למשל, אורך הטקסט, נוכחות מילות מפתח ספציפיות לתחום) או נלמד מנתוני הסלמה היסטוריים. על ידי הגדרת שכבת העלות הנמוכה כברירת מחדל, העלות החודשית של הצ'אטבוט ירדה מ-$420 ל-$28.

התאמת המודל (Model right-sizing)

התאמת יכולות המודל למורכבות המשימה מניבה את החיסכון הגדול ביותר:

  • צ'אט פשוט – שימוש במודל קל משקל במקום במודל הדגל (חיסכון של 97.5%).
  • סיווג (Classification) – החלפת מודל בינוני בחלופה זולה יותר (חיסכון של 98.3%).
  • סיכום (Summarization) – החלפת המודל מהשכבה הגבוהה ביותר במודל בטווח הבינוני (חיסכון של 97.2%).

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

זיכרון מטמון חכם (Smart caching)

כל פגיעה בזיכרון המטמון (cache hit) מבטלת קריאת רשת וחיוב של API. מטמון Redis מבוזר שומר תגובות מוצלחות וגם תשובות "שליליות" ("אני לא יודע"). כאשר אותה שאלה ללא מענה מופיעה שוב, המערכת מחזירה את ה-"אני לא יודע" השמור במטמון במקום להפעיל את המודל פעם שנייה. על פני אלפי בקשות, פעולה זו לבדה מקצצת חלק ניכר מהחשבון.

דחיסת פרומפטים (Prompt compression)

פרומפטים ארוכים מגדילים את השימוש בטוקנים (tokens), מה שמתרגם ישירות לעלות. הצוות מריץ מסכם זול בצד הלקוח או בשלב עיבוד מקדים, המצמצם הקשר (context) של 2,000 טוקנים לכ-400 טוקנים לפני שהוא מגיע למודל היקר. הפחתת הטוקנים מכפילה את החיסכון בכל הבקשות, ומספקת חיסכון עצום מבלי לשנות את חוויית המשתמש הקצה.

אצווה אסטרטגית (Strategic batching)

אצווה (Batching) מקבצת מספר בקשות עצמאיות לקריאת API אחת. כלל האצבע הוא פשוט: אם משתמש ממתין לתשובה, אל תבצע אצווה; אם הבקשה רצה ברקע (דוחות ליליים, משימות מתוזמנות), קבץ הכל לאצווה. עבודות אצווה בלילה לבדן חוסכות עוד 10-20% מההוצאה.

ניטור לולאת האופטימיזציה

אי אפשר לשפר את מה שלא מודדים. המהנדס הגדיר ארבעה מדדים שבועיים:

  1. עלות לבקשה, מחולקת לפי שכבות.
  2. שיעור פגיעות במטמון (cache-hit rate) עבור כל נתיב ניתוב.
  3. שיעור ההסלמה משכבות זולות לשכבות פרימיום.
  4. הוצאה לפי פלח לקוחות.

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

שורה תחתונה

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