מיקרוסופט הוסיפה AI Gateway tier ייעודי ל-Azure API Management (APIM). המהלך מסמן שקריאות LLM מטופלות כעת כעומס עבודה (workload) נפרד, ולא רק כנקודת קצה (endpoint) נוספת של API.
למה תעבורת LLM שוברת שערים (gateways) קלאסיים
פרומפט (prompt) בודד יכול לעלות פי מאה יותר מאחר, ובכל זאת API gateway סטנדרטי רואה בשניהם בקשה אחת. ה-gateway סופר קריאות, לא את מספר הטוקנים (tokens) שהמודל מעבד. בקשה ששולחת כמה מאות טוקנים ובקשה ששולחת אלפים רבים של טוקנים מייצרות מדדי מספר בקשות זהים, למרות שהאחרונה יכולה לעלות פי כמה וכמה.
ארבע עובדות הופכות מגבלות מבוססות-בקשה לחסרות תועלת עבור AI:
- עלות ≠ מספר בקשות. החיוב קשור לטוקנים, לא לכמות קריאות ה-HTTP שאתם מבצעים.
- נפח הטוקנים משתנה בצורה קיצונית. שאילתה אחת עשויה להיות שאלה קצרה; אחרת עשויה לכלול מסמך ארוך.
- בחירת המודל משנה את המחיר. LLMs שונים גובים תעריפים שונים לכל טוקן.
- Streaming מסתיר את החשבון הסופי. כאשר התגובות מועברות ב-streaming, סך הטוקנים אינו ידוע עד שהזרם (stream) מסתיים.
אם תמשיכו למדוד רק בקשות, תמצאו את עצמכם עם נתוני ניטור שלא אומרים לכם דבר על ההוצאה בפועל.
מה ה-AI Gateway tier משנה
רוב המדיניות (policies) הדרושה לפיקוח על שימוש בטוקנים כבר קיימת ב-tiers הסטנדרטיים של APIM — כתוארי XML המוצגים בלוחות בקרה (dashboards) מותאמים אישית. ה-AI tier מאחד את אותן יכולות בתוך חוויה שנבנתה במיוחד למטרה זו:
- בידוד של ה-scaling עבור תעבורת AI.
- קונפיגורציה (configuration) מפושטת שמסירה את הצורך במדיניות XML שנכתבו ידנית.
השינוי המרכזי הוא תפעולי: אתם לא צריכים יותר לכתוב קוד מורכב או לתחזק לוחות בקרה נפרדים כדי לאכוף תקציבי טוקנים. ה-tier מספק ממשק מוכן מראש עבור הבקרות הללו.
מתי לעבור – מדריך מבוסס תעבורה
- ה-AI הוא חלק קטן מתעבורת הנתונים שלכם. המשיכו להשתמש ב-APIM tier הקיים שלכם והוסיפו מדיניות טוקנים אם אתם זקוקים לשליטה מפורטת.
- ה-AI שולט ברוב הקריאות שלכם. עברו ל-AI tier כדי לבודד את ה-scaling ולשמור על ממשל עלויות (cost governance) נקי.
- אתם רוצים להימנע מעומס הנדסי (engineering overhead). הכלים המובנים ב-tier חוסכים את הזמן המושקע בבנייה ותחזוקה של מדיניות מותאמת אישית.
ההוצאה הגדולה ביותר היא לא מחיר המנוי; היא שעות ההנדסה המושקעות בתיקון פערים ב-gateway גנרי כדי לגרום לו להבין את הכלכלה של הטוקנים.
תוכנית פעולה לשלב ה-Preview
מיקרוסופט עדיין מציעה את ה-AI tier בגרסת preview. התייחסו אליו כסביבת בדיקות (testbed), ולא כהשקה לסביבת ייצור (production).
- בחרו עומס עבודה (workload) פנימי של AI בעל נפח גבוה. בחרו את השירות שמייצר את תעבורת הטוקנים הגבוהה ביותר.
- נתבו את עומס העבודה הזה דרך ה-AI tier. השתמשו בקונפיגורציה החדשה כדי לתפוס את השימוש בטוקנים לכל צרכן.
- אספו נתוני הוצאות טוקנים למשך מספר שבועות. השוו את ספירת הטוקנים והעלויות הנלוות לניטור הקיים שלכם.
- השתמשו בנתוני הבסיס (baseline) לצורך תכנון תקציב. החליטו האם יתרונות בקרת העלויות של ה-tier עולים על המגבלות של שלב ה-preview.
אל תעבירו עומסי עבודה קריטיים לסביבת ייצור (production) לשירות ה-preview עד שהוא יעבור לשלב הזמינות הכללית (general availability).
נקודת מבט נגדית: לא כולם זקוקים ל-tier נפרד
אם הארגון שלכם מבצע קריאות מזדמנות בלבד ל-LLM, ייתכן שהעלות הנוספת של ה-AI tier אינה מוצדקת. ניתן להשיג ממשל ברמת הטוקנים באמצעות מסגרת המדיניות הקיימת, אם כי במאמץ ידני רב יותר. ה-tier באמת מנצח כאשר תעבורת ה-AI היא חלק משמעותי וצומח ממרחב ה-API שלכם.
שורה תחתונה
ה-AI Gateway tier מכיר בכך שתעבורת LLM מתנהגת בצורה שונה מהיסוד מקריאות API מסורתיות. על ידי מעבר מספירת בקשות לממשל מבוסס-טוקנים, הוא מעניק למפתחים דרך מעשית לשלוט בהוצאות ה-AI מבלי לטבוע בקוד מותאם אישית. עבור צוותים שהשימוש שלהם ב-AI כבר משמעותי — או צפוי לצמוח — בדיקת ה-preview כבר עכשיו יכולה לסייע בבנישת בסיס נתונים (baseline) להוצאות טוקנים.