מדיניות LLMTokenQuota

מדיניות ניתנת להרחבה

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

אפשר לעיין במסמכי העזרה של Apigee Edge.

סקירה כללית

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

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

במדיניות הזו נעשה שימוש ברכיבים <LLMTokenUsageSource> ו-<LLMModelSource> כדי לחלץ את מספר הטוקנים מהתגובה של ה-LLM ואת שם המודל מהבקשה או מהתגובה, וכך לאפשר אכיפה מדויקת של המכסה בזמן אמת.

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

איך פועלת האכיפה של LLMTokenQuota

בטבלה הבאה מתוארת הפונקציונליות של המדיניות LLMTokenQuota:

  • ספירת טוקנים (<CountOnly>): המדיניות LLMTokenQuota מנהלת מונים שעוקבים אחרי מספר הטוקנים שנצרכו על ידי תשובות של LLM שעוברות דרך שרת ה-proxy ל-API.
  • אכיפת מגבלות (<EnforceOnly>): היכולת הזו מאפשרת לספקי API להגדיר מגבלות מחמירות על מספר הטוקנים שנצרכים על ידי אפליקציות במרווח זמן מוגדר. לדוגמה, אתם יכולים להגביל את האפליקציות ל-1,000 טוקנים לדקה או ל-10,000,000 טוקנים לחודש.
  • חריגה מהמכסה: כש-proxy ל-API מגיע למגבלת המכסה של הטוקנים שהוגדרה לו, Apigee דוחה בקשות עתידיות שצורכות טוקנים. הודעת שגיאה מוחזרת עד שהמונה LLMTokenQuota מתאפס אוטומטית בסוף מרווח הזמן שצוין. לדוגמה, אם המכסה מוגדרת ל-10,000 טוקנים בחודש, הגבלת הטוקנים מתחילה ברגע שהטוקן ה-10,000 נספר, לא משנה מתי בחודש הגעתם למגבלה הזו.

איך LLMTokenQuota פועל עם מוצרי API

בהמשך מוסבר איך מדיניות LLMTokenQuota פועלת עם מוצרי API:

תהליך שרת proxy ל-LLMTokenQuota
  1. מחילים את המדיניות VerifyAPIKey או VerifyAccessToken יחד עם מדיניות האכיפה LLMTokenQuota בבקשה של proxy ל-API (לא משנה אם זה Proxy או Target).
  2. מחילים את מדיניות הספירה LLMTokenQuota בתגובה ל-API Proxy (לא משנה אם מדובר ב-Proxy או ב-Target).
  3. המדיניות VerifyAPIKey או VerifyAccessToken מתאימה למפתח או לטוקן עם מוצר API, קבוצת פעולות, מפתח ואפליקציה. היא חושפת את משתני הזרימה למכסת LLM עבור כל המודלים מקבוצות הפעולות התואמות של LLM.
  4. בתוך מדיניות אכיפת המכסות, אנחנו מחלצים את המודל בהתאם לתבנית ההודעה שסופקה.
  5. לאחר מכן, משתני מכסת ה-LLM מותאמים למודל. אם נמצאת התאמה, ההפניות מוזרקות.
  6. אחרי שההפניות מוזרקות, הערכים האלה משמשים לביצוע פעולות המכסה.

איך LLMTokenQuota פועל עם תגובות SSE

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

<EventFlow content-type="text/event-stream">
    <Response>
      <Step>
        <Name>LLM_TOKEN_QUOTA_COUNT_POLICY_NAME</Name>
      </Step>
    </Response>
  </EventFlow>

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

סוגי המדיניות LLMTokenQuota

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

<LLMTokenQuota name="LLMTokenQuotaPolicy" type="calendar">
  ...
</LLMTokenQuota>

הערכים התקינים של type כוללים:

  • ‫calendar: הגדרת מכסה על סמך שעת התחלה מפורשת. המונה LLMTokenQuota לכל אפליקציה מתרענן על סמך הערכים של <StartTime>,‏ <Interval> ו-<TimeUnit> שהגדרתם.
  • ‫rollingwindow: הגדרת מכסה שמשתמשת בחלון זמן דינמי כדי לקבוע את השימוש במכסה. ב-rollingwindow, אתם קובעים את גודל החלון באמצעות הרכיבים <Interval> ו-<TimeUnit>, לדוגמה, יום אחד. כשמתקבלת בקשה, מערכת Apigee בודקת את השעה המדויקת של הבקשה (לדוגמה, 17:01), סופרת את מספר האסימונים שנצרכו בין השעה הזו לבין השעה 17:01 ביום הקודם (יום אחד), וקובעת אם חרגתם מהמכסה במהלך חלון הזמן הזה.
  • ‫flexi: מגדירה מכסה שגורמת למונה להתחיל לפעול כשמתקבלת הודעת הבקשה הראשונה מאפליקציה, ומתאפסת על סמך הערכים של <Interval> ו-<TimeUnit>.

בטבלה הבאה מוסבר מתי המכסה מתאפסת בכל סוג:

יחידת זמן סוג
‫default (או null) calendar flexi
דקה תחילת הדקה הבאה דקה אחרי <StartTime> דקה אחת אחרי הבקשה הראשונה
hour בתחילת השעה הבאה שעה אחרי <StartTime> שעה אחרי הבקשה הראשונה
יום חצות לפי שעון גריניץ' (GMT) של היום הנוכחי ‫24 שעות אחרי <StartTime> ‫24 שעות אחרי הבקשה הראשונה
שבוע חצות (שעון גריניץ') ביום ראשון בסוף השבוע שבוע אחרי <StartTime> שבוע אחרי הבקשה הראשונה
month חצות (שעון גריניץ') ביום האחרון של החודש חודש אחד (28 ימים) אחרי <StartTime> חודש אחד (28 ימים) אחרי הבקשה הראשונה

בשביל type="calendar", צריך לציין את הערך של <StartTime>.

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

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

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

הסבר על מוני המכסות

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

קביעת הגדרות המכסות למוצרי API

במוצר API אפשר לציין הגדרות מכסה ברמת המוצר או ברמת הפעולה הספציפית, או בשתיהן. אם ה-proxy ל-API נכלל במוצר API, אתם יכולים להגדיר את מדיניות LLMTokenQuota כך שתשתמש בהגדרות המכסה (מספר הפעמים המותר, יחידת הזמן והמרווח) שמוגדרות במוצר הזה. הדרך הכי קלה לעשות את זה היא באמצעות הרכיב useQuotaConfigInAPIProduct. אפשרות אחרת היא להפנות להגדרות האלה במדיניות LLMTokenQuota באמצעות הפניות למשתנים ספציפיים.

איך המכסות נספרות

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

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

בכל המקרים, Apigee מנהלת מונה מכסות נפרד לכל פעולה שמוגדרת במוצר API. כל קריאה ל-API שתואמת לפעולה תגדיל את המונה שלה.

הגדרת מוניטורים ברמת ה-proxy ל-API

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

כדי להגדיר את התצורה הזו, צריך להשתמש ב-Apigee API‏/apiproducts כדי ליצור או לעדכן את המוצר ולהגדיר את המאפיין quotaCounterScope לערך PROXY בבקשת היצירה או העדכון. בהגדרה PROXY, בקשות שתואמות לאחת מהפעולות שהוגדרו למוצר ה-API שמשויך לאותו שרת proxy, ואין להן הגדרות מכסה משלהן, ישתפו מונה מכסות משותף לאותו שרת proxy.

באיור 1, פעולות 1 ו-2 משויכות ל-Proxy1 ופעולות 4 ו-5 משויכות ל-Proxy3. מכיוון שהערך quotaCounterScope=PROXY מוגדר במוצר ה-API, כל אחת מהפעולות האלה משתמשת בהגדרת המכסה ברמת מוצר ה-API. פעולות 1 ו-2, שמשויכות ל-Proxy1, משתמשות במונה משותף, ופעולות 4 ו-5, שמשויכות ל-Proxy3, משתמשות במונה משותף נפרד. לפעולה 3 יש הגדרת מכסה משלה, ולכן היא משתמשת במונה משלה, בלי קשר לערך של המאפיין quotaCounterScope.

איור 1: שימוש בדגל quotaCounterScope

איך המכסות נספרות אם לא משתמשים במוצרי API

אם אין מוצר API שמשויך ל-proxy ל-API, מדיניות LLMTokenQuota מנהלת מונה אחד, לא משנה כמה פעמים מפנים אליה ב-proxy ל-API. השם של מונה המכסות מבוסס על המאפיין name של המדיניות.

לדוגמה, אתם יוצרים מדיניות LLMTokenQuota בשם MyLLMTokenQuotaPolicy עם מגבלה של 5 טוקנים, ומציבים אותה בכמה תהליכים (תהליך A, ‏ B ו-C) בשרת ה-proxy ל-API. למרות שמשתמשים בה בכמה תהליכים, היא שומרת מונה אחד שמתעדכן על ידי כל המופעים של המדיניות. נניח שהתשובה של ה-LLM השתמשה בטוקן אחד בכל פעם:

  • תהליך א' מופעל -> המדיניות MyLLMTokenQuotaPolicy מופעלת והמונה שלה = 1
  • מתבצעת הרצה של תהליך ב' -> מתבצעת הרצה של MyLLMTokenQuotaPolicy והמונה שלו = 2
  • Flow א' מופעל -> המדיניות MyLLMTokenQuotaPolicy מופעלת והמונה שלה = 3
  • מתבצעת הרצה של תהליך C ‏-> מתבצעת הרצה של MyLLMTokenQuotaPolicy והמונה שלו = 4
  • תהליך א' מופעל -> המדיניות MyLLMTokenQuotaPolicy מופעלת והמונה שלה = 5

הבקשה הבאה לאחד משלושת התהליכים נדחית כי מונה המכסות הגיע למגבלה שלו.

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

אפשר גם להגדיר כמה כללי מדיניות של LLMTokenQuota ב-proxy ל-API, ולהשתמש בכלל מדיניות אחר בכל תהליך. כל מדיניות LLMTokenQuota מנהלת מונה משלה, על סמך המאפיין name של המדיניות.

יצירת כמה מונים באמצעות הגדרת מדיניות

אפשר להשתמש ברכיבים <Class> או <Identifier> במדיניות LLMTokenQuota כדי להגדיר כמה מונים ייחודיים במדיניות אחת. באמצעות הרכיבים האלה, מדיניות אחת יכולה לנהל מונים שונים על סמך האפליקציה ששולחת את הבקשה, מפתח האפליקציה ששולח את הבקשה, מזהה לקוח או מזהה לקוח אחר ועוד. למידע נוסף על השימוש ברכיבים <Class> או <Identifier>, עיינו בדוגמאות שלמעלה.

פורמט השעה

כל השעות ב-LLMTokenQuota מוגדרות לפי אזור הזמן זמן אוניברסלי מתואם (UTC).

השעה ב-LLMTokenQuota מוצגת לפי התקן הבינלאומי ISO 8601.

התאריכים מוגדרים לפי שנה, חודש ויום, בפורמט הבא: YYYY-MM-DD. לדוגמה, 2025-02-04 מייצג את 4 בפברואר 2025.

השעה ביום מוגדרת כשעות, דקות ושניות בפורמט הבא: hours:minutes:seconds. לדוגמה, 23:59:59 מייצג את השעה שנייה אחת לפני חצות.

שימו לב שיש שני סימונים, 00:00:00 ו-24:00:00, כדי להבחין בין שתי חצות שאפשר לשייך לתאריך אחד. לכן, 2025-02-04 24:00:00 הם אותו תאריך ואותה שעה כמו 2025-02-05 00:00:00. בדרך כלל עדיף להשתמש בסימון השני.

קבלת הגדרות המכסה מהגדרות המוצר של ה-API

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

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

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

מידע על הגדרת מוצרי API עם מגבלות מכסה זמין במאמר ניהול מוצרי API.

הגדרה של מוני מכסה משותפים

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

שלושה רכיבי מדיניות של LLMTokenQuota – ‏<SharedName>, ‏<CountOnly> ו-<EnforceOnly> – מאפשרים לכם להתאים אישית את המדיניות של LLMTokenQuota כדי לאכוף את המכסה על בקשות נכנסות, אבל להגדיל את המונה רק בתהליך התגובה.

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

  • מצרפים מדיניות LLMTokenQuota לזרימת הבקשות של ProxyEndpoint עם רכיב <SharedName> שהוגדר עם ערך שם ועם רכיב <EnforceOnly> שהוגדר לערך true.
  • כדי לאחזר את מספר הטוקנים, משתמשים ברכיב <LLMTokenUsageSource> במדיניות LLMTokenQuota.

דוגמה לשימוש במונים משותפים מופיעה בקטע מונים משותפים בדוגמאות.

דוגמאות

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

More Dynamic LLMTokenQuota

<LLMTokenQuota name="CheckLLMTokenQuota">
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.limit"/>
</LLMTokenQuota>

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

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

בדוגמה שלמעלה, שרת ה-proxy של ה-API שמכיל את מדיניות LLMTokenQuota משתמש במדיניות VerifyAPIKey בשם verify-api-key כדי לאמת את מפתח ה-API שמועבר בבקשה. אחרי זה, המדיניות LLMTokenQuota ניגשת למשתני הזרימה מהמדיניות VerifyAPIKey כדי לקרוא את ערכי המכסות שהוגדרו במוצר ה-API.

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

<LLMTokenQuota name="DeveloperLLMTokenQuota">
  <Identifier ref="verifyapikey.verify-api-key.client_id"/>
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/>
</LLMTokenQuota>

בדוגמה הזו נעשה שימוש גם במשתני הזרימה של VerifyAPIKey כדי להפנות למאפיינים המותאמים אישית שהוגדרו למפתח.

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

  • משתני זרימה
  • מאפיינים של מוצר ה-API, האפליקציה או המפתח
  • מפת צמדי מפתח/ערך (KVM)
  • כותרת, פרמטר של שאילתה, פרמטר של טופס ועוד

לכל שרת proxy ל-API, אתם יכולים להוסיף מדיניות LLMTokenQuota שמפנה לאותו משתנה כמו כל כללי המדיניות האחרים של LLMTokenQuota בכל שרתי ה-proxy האחרים, או שמדיניות LLMTokenQuota יכולה להפנות למשתנים ייחודיים למדיניות ולשרת ה-proxy האלה.

שעת התחלה

<LLMTokenQuota name="LLMTokenQuotaPolicy" type="calendar">
  <StartTime>2025-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</LLMTokenQuota>

אם type מוגדר ל-calendar ב-LLMTokenQuota, צריך להגדיר ערך <StartTime> מפורש. ערך הזמן הוא לפי שעון גריניץ' (GMT), ולא לפי השעון המקומי. אם לא מציינים ערך <StartTime> למדיניות מסוג calendar, מערכת Apigee מציגה שגיאה.

המונה LLMTokenQuota של כל אפליקציה מתעדכן על סמך הערכים <StartTime>,‏ <Interval> ו-<TimeUnit>. בדוגמה הזו, המכסה LLMTokenQuota מתחילה להיספר ב-18 בפברואר 2025 בשעה 10:30 לפי שעון GMT, ומתרעננת כל 5 שעות. לכן, החידוש הבא יתבצע ב-18 בפברואר 2025 בשעה 15:30 לפי שעון GMT.

מונה גישה

<LLMTokenQuota name="LLMTokenQuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</LLMTokenQuota>

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

מכיוון שהגישה למשתני הזרימה של המדיניות מבוססת על המאפיין name של המדיניות, במדיניות שלמעלה שנקראת <LLMTokenQuota>, אתם ניגשים למשתני הזרימה שלה בפורמט:

  • ‫ratelimit.LLMTokenQuotaPolicy.allowed.count: מספר הפעמים המותר.
  • ‫ratelimit.LLMTokenQuotaPolicy.used.count: הערך הנוכחי של המונה.
  • ‫ratelimit.LLMTokenQuotaPolicy.expiry.time: זמן UTC שבו המונה מתאפס.

יש הרבה משתני זרימה אחרים שאפשר לגשת אליהם, כמו שמתואר בהמשך.

לדוגמה, אפשר להשתמש במדיניות AssignMessage הבאה כדי להחזיר את הערכים של משתני הזרימה LLMTokenQuota ככותרות תגובה:

<AssignMessage continueOnError="false" enabled="true" name="ReturnQuotaVars">
  <AssignTo createNew="false" type="response"/>
  <Set>
    <Headers>
      <Header name="LLMTokenQuotaLimit">{ratelimit.LLMTokenQuotaPolicy.allowed.count}</Header>
      <Header name="LLMTokenQuotaUsed">{ratelimit.LLMTokenQuotaPolicy.used.count}</Header>
      <Header name="LLMTokenQuotaResetUTC">{ratelimit.LLMTokenQuotaPolicy.expiry.time}</Header>
    </Headers>
  </Set>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

מונים משותפים

בדוגמה הבאה מוצג אופן ההגדרה של מונה משותף ל-proxy ל-API, שבו מונה המכסה גדל גם כשסטטוס התגובה של היעד הוא 200 HTTP. מכיוון שבשני כללי המדיניות של LLMTokenQuota נעשה שימוש באותו ערך של <SharedName>, שני כללי המדיניות של LLMTokenQuota ישתפו את אותו מונה מכסות. מידע נוסף זמין במאמר הגדרת מוני מכסות משותפים.

דוגמה להגדרה של ProxyEndpoint: 

<ProxyEndpoint name="default">
  <PreFlow name="PreFlow">
    <Request>
      <Step>
        <Name>LLMTokenQuota-Enforce-Only</Name>
      </Step>
    </Request>
    <Response>
      <Step>
        <Name>LLMTokenQuota-Count-Only</Name>
      </Step>
    </Response>
    <Response/>
  </PreFlow>
  <Flows/>
  <PostFlow name="PostFlow">
    <Request/>
    <Response/>
  </PostFlow>
  <HTTPProxyConnection>
    <BasePath>/quota-shared-name</BasePath>
  </HTTPProxyConnection>
  <RouteRule name="noroute"/>
</ProxyEndpoint>

דוגמה ראשונה למדיניות LLMTokenQuota:

<LLMTokenQuota name="LLMTokenQuota-Enforce-Only" type="rollingwindow">
  <SharedName>common-counter</SharedName>
  <EnforceOnly>true</EnforceOnly>
  <Allow count="15000"/>
  <Interval>30</Interval>
  <TimeUnit>minute</TimeUnit>
  <Distributed>true</Distributed>
</LLMTokenQuota>

דוגמה שנייה למדיניות LLMTokenQuota:

<LLMTokenQuota name="LLMTokenQuota-Count-Only" type="rollingwindow">
  <SharedName>common-counter</SharedName>  <!-- Same name as the first LLMTokenQuota policy -->
  <CountOnly>true</CountOnly>
  <Allow count="15000"/>
  <Interval>30</Interval>
  <TimeUnit>minute</TimeUnit>
  <Distributed>true</Distributed>
  <LLMTokenUsageSource>
    {jsonPath('$.usageMetadata.candidatesTokenCount',response.content,true)}
  </LLMTokenUsageSource>
  <LLMModelSource>{jsonPath('$.model',response.content,true)}</LLMModelSource>
</LLMTokenQuota>

בקשה ראשונה

<LLMTokenQuota name="MyLLMTokenQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</LLMTokenQuota>

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

לדוגמה, אם המונה מתחיל בשעה 2025-07-08 07:00:00, הוא מתאפס ל-0 בשעה 2025-07-08 08:00:00 (שעה אחת אחרי שעת ההתחלה). אם הבקשה הראשונה מתקבלת בשעה 2025-07-08 07:35:28 ומספר הטוקנים מגיע ל-10,000 לפני השעה 2025-07-08 08:00:00, בקשות שצורכות טוקנים מעבר למספר הזה נדחות עד שהמספר מתאפס בתחילת השעה הבאה.

השעה לאיפוס המונה מבוססת על השילוב של <Interval> ושל <TimeUnit>. לדוגמה, אם מגדירים את <Interval> ל-12 עבור <TimeUnit> של שעה, המונה מתאפס כל 12 שעות. אפשר להגדיר את <TimeUnit> לדקה, שעה, יום, שבוע או חודש.

אפשר להפנות למדיניות הזו בכמה מקומות ב-proxy ל-API. לדוגמה, אפשר למקם אותו ב-Proxy PreFlow כדי שהוא יופעל בכל בקשה. או להציב אותו בכמה תהליכים ב-proxy ל-API. אם משתמשים במדיניות הזו בכמה מקומות בשרת ה-proxy, היא שומרת מונה אחד שמתעדכן על ידי כל המופעים של המדיניות.

אפשר גם להגדיר כמה כללי מדיניות של LLMTokenQuota בשרת ה-proxy ל-API. לכל כלל מדיניות LLMTokenQuota יש מונה משלו, שמבוסס על המאפיין name של כלל המדיניות.

הגדרת מזהה

<LLMTokenQuota name="LLMTokenQuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/>
  <StartTime>2025-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</LLMTokenQuota>

כברירת מחדל, מדיניות LLMTokenQuota מגדירה מונה יחיד ל-proxy ל-API, ללא קשר למקור הבקשה. אפשר גם להשתמש במאפיין <Identifier> עם מדיניות LLMTokenQuota כדי לשמור על מוני נפרדים על סמך הערך של המאפיין <Identifier>.

לדוגמה, אפשר להשתמש בתג <Identifier> כדי להגדיר מונה נפרד לכל מזהה לקוח. בבקשה לשרת ה-proxy, אפליקציית הלקוח מעבירה כותרת שמכילה את clientID, כמו בדוגמה שלמעלה.

אפשר לציין כל משתנה זרימה במאפיין <Identifier>. לדוגמה, אפשר לציין שפרמטר של שאילתה בשם id מכיל את המזהה הייחודי:

<Identifier ref="request.queryparam.id"/>

אם משתמשים במדיניות VerifyAPIKey כדי לאמת את מפתח ה-API, או במדיניות OAuthV2 עם אסימוני OAuth, אפשר להשתמש במידע במפתח ה-API או באסימון כדי להגדיר מוניטורים נפרדים לאותה מדיניות LLMTokenQuota. לדוגמה, הרכיב <Identifier> הבא משתמש במשתנה הזרימה client_id של מדיניות VerifyAPIKey בשם verify-api-key:

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

כל ערך ייחודי של client_id מגדיר עכשיו מונה משלו במדיניות LLMTokenQuota.

מחלקה

<LLMTokenQuota name="LLMTokenQuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</LLMTokenQuota>

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

בדוגמאות הבאות מוצגות הגדרות שונות של מדיניות LLMTokenQuota.

חישוב טוקנים

בדוגמה הזו מוסבר איך לחשב את האסימונים.

<LLMTokenQuota name="LTQ-Count-Only" type="rollingwindow">
  <SharedName>common-counter</SharedName>
  <CountOnly>true</CountOnly>
  <Allow count="15000"/>
  <Interval>30</Interval>
  <TimeUnit>minute</TimeUnit>
  <Distributed>true</Distributed>
  <LLMTokenUsageSource>
    {jsonPath('$.usageMetadata.candidatesTokenCount',response.content,true)}
  </LLMTokenUsageSource>
  <LLMModelSource>{jsonPath('$.model',response.content,true)}</LLMModelSource>
</LLMTokenQuota>

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

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

<LLMTokenQuota name="LTQ-Count-Only" type="rollingwindow">
  <SharedName>common-counter</SharedName>
  <CountOnly>true</CountOnly>
<Interval ref="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.limit"/>
  <Distributed>true</Distributed>
  <LLMTokenUsageSource>
    {jsonPath('$.usageMetadata.candidatesTokenCount',response.content,true)}
  </LLMTokenUsageSource>
  <LLMModelSource>{jsonPath('$.model',response.content,true)}</LLMModelSource>
</LLMTokenQuota>

אכיפת מכסה בלי מוצר API

בדוגמה הזו מוסבר איך לאכוף מכסה בלי מוצר API.

<LLMTokenQuota name="Quota-Enforce-Only" type="rollingwindow">
  <SharedName>common-counter</SharedName>
  <EnforceOnly>true</EnforceOnly>
  <Allow count="15000"/>
  <Interval>30</Interval>
  <TimeUnit>minute</TimeUnit>
  <Distributed>true</Distributed>
</LLMTokenQuota>

אכיפת מכסה באמצעות מוצר API, מפתח ואפליקציה

בדוגמה הזו מוסבר איך לאכוף מכסה באמצעות מוצר API, מפתח ואפליקציה.

<LLMTokenQuota name="Quota-Enforce-Only" type="rollingwindow">
  <SharedName>common-counter</SharedName>
  <EnforceOnly>true</EnforceOnly>
<Interval ref="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.llmQuota.limit"/>
  <Distributed>true</Distributed>
</LLMTokenQuota>

עם מקור נתונים של SSE

בדוגמה הזו אפשר לראות איך משתמשים ב-LLMTokenQuota עם זרם SSE.

מדיניות בנושא מכסת טוקנים:

<LLMTokenQuota name="LTQ-Count-Only" type="rollingwindow">
  <SharedName>common-counter</SharedName>
  <CountOnly>true</CountOnly>
  <Allow count="15000"/>
  <Interval>30</Interval>
  <TimeUnit>minute</TimeUnit>
  <Distributed>true</Distributed>
  <LLMTokenUsageSource>
    {jsonPath('$.usageMetadata.candidatesTokenCount',response.event.current.data,false)}
  </LLMTokenUsageSource>
  <LLMModelSource>{jsonPath('$.modelVersion',response.event.current.data,false)}</LLMModelSource>
</LLMTokenQuota>

הזרימה של האירוע:

<EventFlow content-type="text/event-stream">
    <Response>
      <Step>
        <Name>LTQ-Count-Only</Name>
      </Step>
    </Response>
  </EventFlow>

רכיב <LLMTokenQuota>

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

המשתנים verifyapikey.my-verify-key-policy.apiproduct.* שבהמשך זמינים כברירת מחדל כשמשתמשים במדיניות VerifyAPIKey שנקראת my-verify-key-policy כדי לבדוק את מפתח ה-API של האפליקציה בבקשה. ערכי המשתנים מגיעים מהגדרות המכסה במוצר ה-API שהמפתח משויך אליו, כפי שמתואר בקטע קבלת הגדרות המכסה מהגדרות המוצר ב-API.

<LLMTokenQuota continueOnError="false" enabled="true" name="LTQ-TokenQuota-1" type="calendar">
  <DisplayName>Quota 3</DisplayName>
  <LLMTokenUsageSource>{jsonPath('$.usageMetadata.candidatesTokenCount',response.content,true)}</LLMTokenUsageSource>
  <LLMModelSource>{jsonPath('$.model',request.content,true)}</LLMModelSource>
  <Allow count="UPPER_REQUEST_LIMIT"
      countRef="verifyapikey.my-verify-key-policy.apiproduct.developer.llmQuota.limit"/>
  <Allow>
    <Class ref="request.queryparam.time_variable">
      <Allow class="peak_time" count="UPPER_LIMIT_DURING_PEAK"/>
      <Allow class="off_peak_time" count="UPPER_LIMIT_DURING_OFFPEAK"/>
    </Class>
  </Allow>
  <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.llmQuota.interval">
    1
  </Interval>
  <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.llmQuota.timeunit">
    month
  </TimeUnit>
  <StartTime>2025-7-16 12:00:00</StartTime>
  <Distributed>false</Distributed>
  <Synchronous>false</Synchronous>
  <AsynchronousConfiguration>
    <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
    <SyncMessageCount>5</SyncMessageCount>
  </AsynchronousConfiguration>
  <Identifier/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <UseQuotaConfigInAPIProduct>
    <DefaultConfig>
      <Allow>
        <Class ref="request.queryparam.time_variable">
          <Allow class="peak_time" count="5000"/>
          <Allow class="off_peak_time" count="1000"/>
        </Class>
      </Allow>
      <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.llmQuota.interval">
        1
      </Interval>
      <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.llmQuota.timeunit">
        month
      </TimeUnit>
    </DefaultConfig>
  </UseQuotaConfigInAPIProduct>
  <SharedName/>
  <EnforceOnly>true</EnforceOnly>
</LLMTokenQuota>

המאפיינים הבאים ספציפיים למדיניות הזו:

מאפיין תיאור ברירת מחדל נוכחות
type

מגדירים את סוג המדיניות LLMTokenQuota, שקובע מתי ואיך מונה המכסה בודק את השימוש במכסה, וגם איך הוא מתאפס.

אם לא מגדירים את type, המונה מתחיל בתחילת הדקה/השעה/היום/השבוע/החודש.

הערכים התקינים כוללים:

  • calendar
  • rollingwindow
  • flexi

תיאור מלא של כל סוג מופיע במאמר סוגי מדיניות של LLMTokenQuota.

 לא רלוונטי אופציונלי

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

מאפיין תיאור ברירת מחדל נוכחות
name

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

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

 לא רלוונטי חובה
continueOnError

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

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

 FALSE אופציונלי
enabled

מגדירים את המדיניות למצב true כדי לאכוף אותה.

מגדירים את הערך false כדי להשבית את המדיניות. המדיניות לא תיאכף גם אם היא תישאר מצורפת לזרימה.

 TRUE אופציונלי
async

המאפיין הזה הוצא משימוש.

 FALSE הוצא משימוש

אלמנט <DisplayName>

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

<DisplayName>Policy Display Name</DisplayName>
ברירת מחדל

לא רלוונטי

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

<Allow>

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

יכול להכיל גם רכיב <Class> שמתנה את הרכיב <Allow> על סמך משתנה זרימה.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג סוג Integer או Complex
רכיב הורה <LLMTokenQuota>
רכיבי צאצא <Class>

למטה מוצגות שלוש דרכים להגדיר את הרכיב <Allow>:

<Allow count="2000"/>
 
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.llmQuota.limit"/>
 
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.llmQuota.limit"/>

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

אפשר גם לציין רכיב <Class> כרכיב צאצא של <Allow> כדי לקבוע את המספר המותר של המדיניות על סמך משתנה זרימה. ‫Apigee מתאימה את הערך של משתנה הזרימה למאפיין class של הרכיב <Allow>, כמו שמוצג כאן:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

בטבלה הבאה מפורטים המאפיינים של <Allow>:

מאפיין תיאור ברירת מחדל נוכחות
count

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

לדוגמה, אם ערך המאפיין count הוא 100, Interval הוא 1, ו-TimeUnit הוא month, המכסה היא 100 טוקנים לחודש.

 2000 אופציונלי
countRef

משתמשים במשתנה הזה כדי לציין משתנה של זרימת עבודה שמכיל את מספר האסימונים למכסת שימוש. המאפיין countRef מקבל עדיפות על פני המאפיין count.

 ללא אופציונלי

<Class>

מאפשר להגדיר תנאי לערך של הרכיב <Allow> על סמך הערך של משתנה זרימה. המדיניות מנהלת מונה נפרד לכל תג צאצא <Allow> שונה של <Class>.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג סוג מורכב
רכיב אב <Allow>
רכיבי צאצא ‫<Allow> (צאצא של <Class>)

כדי להשתמש ברכיב <Class>, צריך לציין משתנה זרימה באמצעות המאפיין ref של הרכיב <Class>. לאחר מכן, Apigee משתמש בערך של משתנה הזרימה כדי לבחור אחד מרכיבי הצאצא של <Allow> ולקבוע את המספר המותר של המדיניות. ‫Apigee מתאימה את הערך של משתנה הזרימה למאפיין class של הרכיב <Allow>, כמו שמוצג בהמשך:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

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

בטבלה הבאה מפורטים המאפיינים של <Class>:

מאפיין תיאור ברירת מחדל נוכחות
ref משמש לציון משתנה זרימה שמכיל את סיווג המכסה. ללא חובה

<Allow> (צאצא של <Class>)

מציין את המגבלה של מונה המכסות שמוגדר על ידי הרכיב <Class>. המדיניות מנהלת מונה נפרד לכל תג צאצא <Allow> שונה של <Class>.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג סוג מורכב
רכיב אב <Class>
רכיבי צאצא אין

לדוגמה:

    <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
    </Allow>

בדוגמה הזו, מדיניות LLMTokenQuota מתחזקת שני מוני מכסה בשמות peak_time ו-off_peak_time. השימוש בכל אחד מהם תלוי בפרמטר השאילתה שמועבר, כמו שמוצג בדוגמה של <Class>.

בטבלה הבאה מפורטים המאפיינים של <Allow>:

מאפיין תיאור ברירת מחדל נוכחות
class מגדיר את השם של מונה המכסות. ללא חובה
count מציין את מגבלת המכסה של המונה. ללא חובה

<IgnoreUnresolvedVariables>

קובעת אם העיבוד של המדיניות LLMTokenQuota ייפסק אם ל-Apigee אין אפשרות לפתור משתנה שאליו מתבצעת הפניה באמצעות המאפיין ref במדיניות.

ערך ברירת מחדל FALSE
חובה? אופציונלי
סוג בוליאני
רכיב אב <LLMTokenQuota>
רכיבי צאצא ללא

מגדירים את הערך true כדי להתעלם ממשתנים לא פתורים ולהמשיך בעיבוד, אחרת מגדירים את הערך false. ערך ברירת המחדל הוא false.

אם הערך של <IgnoreUnresolvedVariables> הוא true, ואי אפשר לפתור את המשתנה שצוין במאפיין ref, אז Apigee מתעלם מהמאפיין ref. אם הרכיב שמכיל את המאפיין ref מכיל גם ערך, כמו <Allow count="2000"/>, אז Apigee משתמש בערך הזה. אם אין ערך, Apigee מתייחסת לערך של הרכיב כ-null ומחליפה אותו בערך ברירת המחדל, אם יש כזה, או במחרוזת ריקה.

אם הערך של <IgnoreUnresolvedVariables> הוא false, ואי אפשר לפתור את המשתנה שצוין במאפיין ref, אז Apigee מחזירה שגיאה.

<Interval>

מציין את מספר תקופות הזמן שבהן מחושבות המכסות.

ערך ברירת המחדל לא רלוונטי
חובה? חובה
סוג מספר שלם
רכיב אב <LLMTokenQuota>
רכיבי צאצא אין

משמש לציון מספר שלם (לדוגמה, 1, 2, 5, 60 וכו') שישויך לרכיב <TimeUnit> שציינתם (דקה, שעה, יום, שבוע או חודש) כדי לקבוע את פרק הזמן שבו Apigee מחשבת את השימוש במכסה.

לדוגמה, מרווח של 24 עם <TimeUnit> של hour פירושו שהמכסה תחושב במהלך 24 שעות.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.llmQuota.interval">1</Interval>

בטבלה הבאה מפורטים המאפיינים של <Interval>:

מאפיין תיאור ברירת מחדל נוכחות
ref

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

 ללא אופציונלי

<TimeUnit>

מציינת את יחידת הזמן שחלה על המכסה.

ערך ברירת המחדל לא רלוונטי
חובה? חובה
סוג String
רכיב אב <LLMTokenQuota>
רכיבי צאצא אין

בוחרים מבין האפשרויות minute,‏ hour,‏ day,‏ week,‏ month או year.

לדוגמה, אם Interval הוא 24 ו-TimeUnit הוא hour, המכסה תחושב במהלך 24 שעות.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.llmQuota.timeunit">month</TimeUnit>

בטבלה הבאה מפורטים המאפיינים של <TimeUnit>:

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

<StartTime>

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

ערך ברירת מחדל לא רלוונטי
חובה? אופציונלי (חובה כשהערך של type הוא calendar)
סוג מחרוזת בפורמט תאריך ושעה של ISO 8601
רכיב הורה <LLMTokenQuota>
רכיבי צאצא ללא

לדוגמה:

<StartTime>2025-7-16 12:00:00</StartTime>

<Distributed>

קובעת אם Apigee משתמש בצומת אחד או יותר כדי לעבד בקשות.

ערך ברירת המחדל FALSE
חובה? אופציונלי
סוג בוליאני
רכיב אב <LLMTokenQuota>
רכיבי צאצא אין

הערך true מציין שהמדיניות צריכה לשמור על מונה מרכזי ולסנכרן אותו באופן רציף בכל הצמתים. הצמתים יכולים להיות באזורי זמינות או באזורים שונים.

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

<Distributed>false</Distributed>

כדי לוודא שהמונים מסונכרנים ומתעדכנים בכל בקשה, מגדירים את <Distributed> ואת <Synchronous> לערך true:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

<Synchronous>

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

ערך ברירת מחדל FALSE
חובה? אופציונלי
סוג בוליאני
רכיב אב <LLMTokenQuota>
רכיבי צאצא ללא

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

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

מרווח הזמן שמוגדר כברירת מחדל לעדכון אסינכרוני הוא 10 שניות. כדי להגדיר את ההתנהגות האסינכרונית הזו, משתמשים ברכיב <AsynchronousConfiguration>.

<Synchronous>false</Synchronous>

<AsynchronousConfiguration>

המדיניות הזו מגדירה את מרווח הזמן בין סנכרונים של מוניטורים מבוזרים של מכסות, אם רכיב ההגדרה של המדיניות <Synchronous> לא קיים או קיים ומוגדר לערך false. מערכת Apigee מתעלמת מהרכיב הזה כשמגדירים את <Synchronous> כ-true.

ערך ברירת מחדל לא רלוונטי
חובה? אופציונלי
סוג סוג מורכב
רכיב אב <LLMTokenQuota>
רכיבי צאצא <SyncIntervalInSeconds>
<SyncMessageCount>

אפשר לציין את אופן הסנכרון באמצעות רכיבי הצאצא <SyncIntervalInSeconds> או <SyncMessageCount>. אפשר להשתמש באחד מהרכיבים או בשניהם. לדוגמה,

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

או

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>
  • אם קיים רק <SyncIntervalInSeconds>, המכסה מסתנכרנת כל N שניות, כאשר N הוא הערך שצוין ברכיב, ללא קשר למספר ההודעות שטופלו.
  • אם מופיע רק <SyncMessageCount>, המכסה מסתנכרן כל M הודעות, כאשר M הוא הערך שצוין ברכיב, או כל 10 שניות, לפי המוקדם מביניהם.
  • אם שני הרכיבים קיימים, המכסה מסתנכרנת כל M הודעות או כל N שניות, המוקדם מביניהם.
  • אם התג <AsynchronousConfiguration> לא מופיע או שאף אחד מרכיבי הצאצא לא מופיע, המכסה מסתנכרנת כל 10 שניות, בלי קשר למספר ההודעות שטופלו.

<SyncIntervalInSeconds>

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

ערך ברירת מחדל ‫10 שניות
חובה? אופציונלי
סוג מספר שלם
רכיב אב <AsynchronousConfiguration>
רכיבי צאצא אין
 
<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

מרווח הסנכרון חייב להיות >= 10 שניות, כמו שמתואר בקטע מגבלות.

<SyncMessageCount>

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

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג מספר שלם
רכיב אב <AsynchronousConfiguration>
רכיבי צאצא ללא
 
<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

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

<LLMTokenUsageSource>

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

ערך ברירת מחדל {jsonPath('$.usageMetadata.candidatesTokenCount',response.content,true)}
חובה? אופציונלי
סוג String
רכיב אב <LLMTokenQuota>
רכיבי צאצא אין

בדוגמה הבאה אפשר לראות איך מציינים את המקור של השימוש באסימון:

<LLMTokenUsageSource>{jsonPath('$.usageMetadata.candidatesTokenCount', response.content, true)}</LLMTokenUsageSource>

כשהמדיניות היא חלק מתהליך אירועים שמעבד זרם של אירועים שנשלחו מהשרת (SSE), השימוש בטוקנים נשלף מנתוני האירוע הנוכחי במקום מתוכן התגובה המלא. משתמשים ב-response.event.current.data בתור המקור ומגדירים את הארגומנט השלישי של הפונקציה jsonPath (want-array) ל-false כדי שהערך של השימוש בטוקן יחיד יוחזר ולא מערך. פרטים נוספים על הארגומנט הזה זמינים במאמר פונקציית JSON Path. בדוגמה הבאה מוצגת הגדרת ה-SSE:

<LLMTokenUsageSource>{jsonPath('$.usageMetadata.candidatesTokenCount',response.event.current.data,false)}</LLMTokenUsageSource>

<LLMModelSource>

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

ערך ברירת המחדל {jsonPath('$.model',request.content,true)}
חובה? אופציונלי
סוג String
רכיב אב <LLMTokenQuota>
רכיבי צאצא אין

בדוגמה הבאה אפשר לראות איך מציינים את מקור המודל מהבקשה:

<LLMModelSource>{jsonPath('$.model', request.content, true)}</LLMModelSource>

כשהמדיניות היא חלק מעיבוד של זרימת אירועים בסטרימינג של אירועים שנשלחים מהשרת (SSE), שם המודל מחולץ מנתוני האירוע הנוכחי במקום מתוכן התגובה המלא. משתמשים ב-response.event.current.data כמקור ומגדירים את הארגומנט השלישי של הפונקציה jsonPath (want-array) כ-false כדי שיוחזר ערך שם המודל היחיד במקום מערך. פרטים נוספים על הארגומנט הזה זמינים במאמר פונקציית JSON Path. בדוגמה הבאה מוצגת הגדרת ה-SSE:

<LLMModelSource>{jsonPath('$.modelVersion',response.event.current.data,false)}</LLMModelSource>

<Identifier>

הגדרת המדיניות ליצירת מוניטורים ייחודיים על סמך משתנה זרימה.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג String
רכיב אב <LLMTokenQuota>
רכיבי צאצא אין

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

<Identifier ref="client_id"/>

אפשר להפנות למשתנה מותאם אישית שאפשר להגדיר באמצעות מדיניות AssignMessage או מדיניות JavaScript, או למשתנה שמוגדר באופן משתמע, כמו אלה שמוגדרים על ידי מדיניות VerifyAPIKey או מדיניות VerifyJWT. מידע נוסף על משתנים זמין במאמר שימוש במשתני Flow. רשימה של משתנים מוכרים שהוגדרו על ידי Apigee זמינה במאמר Flow variables reference.

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

בטבלה הבאה מתוארים המאפיינים של <Identifier>:

מאפיין תיאור ברירת מחדל נוכחות
ref

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

בדרך כלל משתמשים ב-client_id בתור המשתנה. ה-client_id נקרא גם מפתח API או טוקן צרכן, והוא נוצר לאפליקציה כשהיא רשומה בארגון ב-Apigee. אפשר להשתמש במזהה הזה אם הפעלתם מדיניות הרשאות של מפתח API או OAuth עבור ה-API שלכם.

 לא רלוונטי אופציונלי

<UseQuotaConfigInAPIProduct>

הגדרות המכסה של מוצר API, כמו יחידות הזמן, המרווח והמקסימום המותר.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג סוג מורכב
רכיב אב <LLMTokenQuota>
רכיבי צאצא <DefaultConfig>

אם מוסיפים את הרכיב <UseQuotaConfigInAPIProduct> למדיניות LLMTokenQuota, אז Apigee מתעלמת מכל הרכיבים המשניים <Allow>,‏ <Interval> ו-<TimeUnit> של LLMTokenQuotaPolicy.

הרכיב <UseQuotaConfigInAPIProduct> הוא פשוט מאגר להגדרות ברירת המחדל שאתם מגדירים באמצעות הרכיב <DefaultConfig>, כמו בדוגמה הבאה:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME">
  <DefaultConfig>...</DefaultConfig>
</UseQuotaConfigInAPIProduct>

אתם יכולים להשתמש במאפיין stepName כדי להפנות למדיניות VerifyAPIKey או לפעולת מדיניות ValidateToken של מדיניות OAuthv2 בתהליך.

בטבלה הבאה מתוארים המאפיינים של <UseQuotaConfigInAPIProduct>:

מאפיין תיאור ברירת מחדל נוכחות
stepName מזהה את השם של מדיניות האימות בתהליך. היעד יכול להיות מדיניות VerifyAPIKey או מדיניות OAuthv2. לא רלוונטי חובה

למידע נוסף, קראו את המאמרים הבאים:

<DefaultConfig>

מכיל ערכי ברירת מחדל למכסה של מוצר API. כשמגדירים <DefaultConfig>, צריך להגדיר את כל שלושת רכיבי הצאצא.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג סוג מורכב
רכיב אב <UseQuotaConfigInAPIProduct>
רכיבי צאצא <Allow>
<Interval>
<TimeUnit>

אפשר להגדיר את הערכים האלה גם בפעולה של מוצר ה-API (באמצעות ממשק המשתמש או API products API) וגם במדיניות LLMTokenQuota. עם זאת, אם תעשו זאת, ההגדרות במוצר ה-API יקבלו עדיפות וההגדרות במדיניות LLMTokenQuota יתעלמו.

התחביר של הרכיב הזה הוא:

<UseQuotaConfigInAPIProduct stepName="POLICY_NAME">
  <DefaultConfig>
    <Allow>allow_count</Allow>
    <Interval>interval</Interval>
    <TimeUnit>[minute|hour|day|week|month]</TimeUnit>
  </DefaultConfig>
</UseQuotaConfigInAPIProduct>

בדוגמה הבאה מצוינת מכסת שימוש של 10,000 בכל שבוע:

<DefaultConfig>
  <Allow>10000</Allow>
  <Interval>1</Interval>
  <TimeUnit>week</TimeUnit>
</DefaultConfig>

למידע נוסף, קראו את המאמרים הבאים:

<SharedName>

המדיניות הזו של LLMTokenQuota מזוהה כמשותפת. כל כללי המדיניות של LLMTokenQuota ב-proxy ל-API עם אותו ערך <SharedName> חולקים את אותו מונה מכסות בסיסי.

מידע נוסף ודוגמאות זמינים במאמר הגדרת מוני מכסות משותפים.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג String
רכיב אב <LLMTokenQuota>
רכיבי צאצא ללא

<CountOnly>

מציבים מדיניות LLMTokenQuota עם הרכיב הזה שמוגדר ל-true בשלב בתהליך התגובה של ProxyEndpoint כדי לעקוב אחרי מספר האסימונים בלי לשלוח שגיאה בחזרה ללקוח כשחורגים ממכסת האסימונים. אם הרכיב הזה קיים, צריך לציין גם את הרכיב <SharedName> ואסור לציין את הרכיב <EnforceOnly>.

מידע נוסף ודוגמאות זמינים במאמר הגדרת מוני מכסות משותפים.

ערך ברירת מחדל FALSE
חובה? אופציונלי
סוג בוליאני
רכיב אב <LLMTokenQuota>
רכיבי צאצא ללא

<EnforceOnly>

כדי לאכוף מגבלת טוקנים בלי להגדיל את מונה המכסות, צריך להוסיף מדיניות LLMTokenQuota כשהרכיב הזה מוגדר ל-true בתהליך הבקשה של שרת proxy ל-API. אם הרכיב הזה קיים, גם הרכיב <SharedName> חייב להיות קיים, והרכיב <CountOnly> לא יכול להיות קיים.

מידע נוסף ודוגמאות זמינים במאמר הגדרת מוני מכסות משותפים.

ערך ברירת מחדל FALSE
חובה? אופציונלי
סוג בוליאני
רכיב אב <LLMTokenQuota>
רכיבי צאצא ללא

משתני זרימה

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

משתנים סוג הרשאות תיאור
ratelimit.{policy_name}.allowed.count ארוכה הרשאת קריאה בלבד הפונקציה מחזירה את מספר המכסות המותרות.
ratelimit.{policy_name}.used.count ארוכה הרשאת קריאה בלבד הפונקציה מחזירה את המכסה הנוכחית שהייתה בשימוש במרווח זמן של מכסה.
ratelimit.{policy_name}.available.count ארוכה הרשאת קריאה בלבד הפונקציה מחזירה את מספר המכסות הזמינות במרווח המכסות.
ratelimit.{policy_name}.exceed.count ארוכה הרשאת קריאה בלבד הפונקציה מחזירה את הערך 1 אחרי חריגה מהמכסה.
ratelimit.{policy_name}.total.exceed.count ארוכה הרשאת קריאה בלבד הפונקציה מחזירה את הערך 1 אחרי חריגה מהמכסה.
ratelimit.{policy_name}.expiry.time ארוכה הרשאת קריאה בלבד

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

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

ratelimit.{policy_name}.identifier String הרשאת קריאה בלבד הפונקציה מחזירה את ההפניה למזהה (הלקוח) שמצורפת למדיניות
ratelimit.{policy_name}.class String הרשאת קריאה בלבד הפונקציה מחזירה את המחלקה שמשויכת למזהה הלקוח
ratelimit.{policy_name}.class.allowed.count ארוכה הרשאת קריאה בלבד הפונקציה מחזירה את מספר המכסות המותרות שמוגדרות בכיתה
ratelimit.{policy_name}.class.used.count ארוכה קריאה בלבד הפונקציה מחזירה את המכסה שהייתה בשימוש בכיתה
ratelimit.{policy_name}.class.available.count ארוכה קריאה בלבד הפונקציה מחזירה את מספר המכסות הזמינות בכיתה
ratelimit.{policy_name}.class.exceed.count ארוכה קריאה בלבד הפונקציה מחזירה את מספר הטוקנים שחורג מהמגבלה במחלקה במרווח הזמן הנוכחי של המכסה
ratelimit.{policy_name}.class.total.exceed.count ארוכה הרשאת קריאה בלבד הפונקציה מחזירה את המספר הכולל של האסימונים שחורגים מהמגבלה במחלקה בכל מרווחי הזמן של המכסה, כלומר הסכום של class.exceed.count בכל מרווחי הזמן של המכסה.
ratelimit.{policy_name}.failed בוליאני הרשאת קריאה בלבד

מצוין אם המדיניות נכשלה או לא (True או False).
llmtokenquota.{policy_name}.model String הרשאת קריאה בלבד הפונקציה מחזירה את המודל שחולץ.

הפניה לשגיאה

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

שגיאות זמן ריצה

השגיאות האלה יכולות להתרחש כשהמדיניות מופעלת.

קוד תקלה סטטוס HTTP מטרה תיקון
policies.llmtokenquota.FailedToResolveModelName 400 לא ניתן היה לזהות את שם המודל. לא רלוונטי
policies.llmtokenquota.FailedToResolveTokenUsageCount 500 לא ניתן לפענח את מספר השימוש בטוקן. לא רלוונטי
policies.llmtokenquota.MessageTemplateExtractionFailed 400 החילוץ של תבנית ההודעה נכשל. לא רלוונטי
policies.llmtokenquota.LLMTokenQuotaViolation 429 הייתה חריגה ממגבלת מכסת הטוקנים של ה-LLM. לא רלוונטי
policies.ratelimit.FailedToResolveQuotaIntervalReference 500 השגיאה מתרחשת אם הרכיב <Interval> לא מוגדר במדיניות LLMTokenQuota. האלמנט הזה הוא חובה ומשמש לציון מרווח הזמן שרלוונטי למכסת האסימונים של מודל שפה גדול. מרווח הזמן יכול להיות דקות, שעות, ימים, שבועות או חודשים, כמו שמוגדר ברכיב <TimeUnit>.
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference 500 השגיאה מתרחשת אם הרכיב <TimeUnit> לא מוגדר במדיניות LLMTokenQuota. זהו רכיב חובה שמשמש לציון יחידת הזמן שרלוונטית למכסת הטוקנים של מודל ה-LLM. מרווח הזמן יכול להיות בדקות, בשעות, בימים, בשבועות או בחודשים.

שגיאות בהטמעה

שם השגיאה מטרה תיקון
policies.llmtokenquota.MessageWeightNotSupported שגיאה כשמשתמשים ברכיב MessageWeight, כי הוא לא נתמך. לא רלוונטי
policies.llmtokenquota.InvalidConfiguration צריך להגדיר בדיוק אחד מהערכים <CountOnly> או <EnforceOnly> כ-true. לא רלוונטי
InvalidQuotaInterval אם מרווח מכסת הטוקנים של ה-LLM שצוין ברכיב <Interval> אינו מספר שלם, פריסת proxy ל-API תיכשל. לדוגמה, אם מרווח המכסה שצוין הוא 0.1 ברכיב <Interval>, ה-Deployment (פריסה) של ה-proxy ל-API ייכשל.
InvalidQuotaTimeUnit אם יחידת הזמן שצוינה ברכיב <TimeUnit> לא נתמכת, פריסת ה-proxy ל-API תיכשל. יחידות הזמן הנתמכות הן minute,‏ hour,‏ day,‏ week ו-month.
InvalidQuotaType אם הסוג של מכסת הטוקנים של מודל שפה גדול (LLM) שצוין במאפיין type ברכיב <LLMTokenQuota> לא תקין, הפריסה של proxy ל-API תיכשל. סוגי המכסות הנתמכים הם default,‏ calendar,‏ flexi ו-rollingwindow.
InvalidStartTime אם הפורמט של השעה שצוינה ברכיב <StartTime> לא תקין, פריסת ה-proxy ל-API תיכשל. הפורמט התקין הוא yyyy-MM-dd HH:mm:ss, שהוא פורמט התאריך והשעה של ISO 8601. לדוגמה, אם השעה שצוינה ברכיב <StartTime> היא 7-16-2017 12:00:00, פריסת ה-proxy ל-API תיכשל.
StartTimeNotSupported אם מציינים את הרכיב <StartTime> שסוג המכסה שלו לא מוגדר כ-calendar, פריסת proxy ל-API תיכשל. האלמנט <StartTime> נתמך רק בסוג המכסה calendar. לדוגמה, אם המאפיין type מוגדר לערך flexi או rolling window ברכיב <LLMTokenQuota>, הפריסה של proxy ל-API תיכשל.
InvalidSynchronizeIntervalForAsyncConfiguration אם הערך שצוין לרכיב <SyncIntervalInSeconds> בתוך הרכיב <AsynchronousConfiguration> במדיניות LLMTokenQuota קטן מאפס, הפריסה של proxy ל-API נכשלת.
InvalidAsynchronizeConfigurationForSynchronousQuota אם הערך של רכיב <AsynchronousConfiguration> מוגדר כ-true במדיניות LLMTokenQuota, שמוגדרת בה גם הגדרה אסינכרונית באמצעות רכיב <AsynchronousConfiguration>, הפריסה של ה-proxy ל-API תיכשל.

משתני תקלות

המשתנים האלה מוגדרים כשהמדיניות הזו מפעילה שגיאה. מידע נוסף על שגיאות שקשורות למדיניות

משתנים כאשר: דוגמה
fault.name="fault_name" ‫fault_name הוא שם התקלה, כפי שמופיע בטבלה Runtime errors שלמעלה. שם התקלה הוא החלק האחרון של קוד התקלה. fault.name Matches "LLMTokenQuotaViolation"
ratelimit.policy_name.failed ‫policy_name הוא השם שהמשתמש הגדיר למדיניות שגרמה לשגיאה. ratelimit.QT-LLMTokenQuotaPolicy.failed = true

דוגמה לתגובת שגיאה

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.llmtokenquota.LLMTokenQuotaViolation"
      },
      "faultstring":"Rate limit LLM Token quota violation. Quota limit exceeded.

 Identifier : _default"
   }
}

דוגמה לכלל שגיאה

<FaultRules>
    <FaultRule name="LLMTokenQuota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "LLMTokenQuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.LLMTokenQuota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

סכימות

נושאים קשורים

המדיניות PromptTokenLimit