מדיניות LLMTokenQuota

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

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

לעיון במסמכי התיעוד של Apigee Edge

סקירה כללית

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

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

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

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

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

בהמשך מפורטת הפונקציונליות של המדיניות 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 בבקשה של ה-API Proxy (לא משנה אם מדובר ב-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 נמצאים באירוע. כשמגלים את המטא-נתונים של השימוש באסימון, הם מחולצים והמדיניות מופעלת. לגבי כל שאר האירועים, המדיניות מניבה NO-OP.

סוגי מדיניות 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> שעה אחרי הבקשה הראשונה
יום חצות לפי שעון גריניץ' של היום הנוכחי 24 שעות אחרי <StartTime> ‫24 שעות אחרי הבקשה הראשונה
שבוע חצות שעון גריניץ' ביום ראשון בסוף השבוע שבוע אחרי <StartTime> שבוע אחרי הבקשה הראשונה
month חצות לפי שעון GMT ביום האחרון של החודש חודש אחד (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 טוקנים ומציבים אותה בכמה תהליכים (Flow A,‏ Flow B ו-Flow C) ב-proxy ל-API. למרות שהיא משמשת בכמה תהליכים, היא שומרת על מונה יחיד שמתעדכן על ידי כל המופעים של המדיניות. בהנחה שהתשובה של ה-LLM השתמשה בטוקן אחד בכל פעם:

  • תהליך A מבוצע -> מדיניות MyLLMTokenQuotaPolicy מבוצעת והמונה שלה = 1
  • תהליך B מבוצע -> מדיניות MyLLMTokenQuota מבוצעת והמונה שלה = 2
  • תהליך A מבוצע -> מדיניות MyLLMTokenQuota מבוצעת והמונה שלה = 3
  • תהליך C מופעל -> מדיניות MyLLMTokenQuotaPolicy מופעלת והמונה שלה = 4
  • תהליך A מבוצע -> מדיניות MyLLMTokenQuota מבוצעת והמונה שלה = 5

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

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

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

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

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

סימון זמן

כל השעות ב-LLMTokenQuota מוגדרות לפי אזור הזמן Coordinated Universal Time (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 בהקשר הזה הוא תוכנית תחזוקה. התכונה 'מכסת טוקנים דינמית של LLM' בודקת את תוכנית התחזוקה של האפליקציות ואז אוכפת את ההגדרות האלה.

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

בדוגמה שלמעלה, פרוקסי ה-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 בכל שאר הפרוקסי, או שמדיניות LLMTokenQuota יכולה להפנות למשתנים ייחודיים למדיניות ולפרוקסי הזה.

שעת התחלה

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

אם מגדירים LLMTokenQuota עם type כ-calendar, צריך להגדיר ערך <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>, ולכן הן ישתמשו באותו מונה של מכסת השימוש. מידע נוסף זמין במאמר בנושא הגדרת מוני מכסות משותפים.

דוגמה להגדרת 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. אם משתמשים במדיניות הזו בכמה מקומות בשרת הפרוקסי, היא שומרת על מונה יחיד שמתעדכן על ידי כל המופעים של המדיניות.

לחלופין, אפשר להגדיר כמה כללי מדיניות של 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 Product,‏ Developer ו-App.

<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 Product.

<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> על סמך הערך של משתנה זרימה. לכל תג צאצא שונה של <Class>, המדיניות שומרת על מונה שונה.<Allow>

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג סוג מורכב
רכיב אב <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>

כשהמדיניות היא חלק מעיבוד של זרם אירועים בפורמט Server-Sent Events (SSE), השימוש באסימון מחולץ מנתוני האירוע הנוכחי במקום מתוכן התגובה המלא. משתמשים ב-response.event.current.data בתור המקור ומגדירים את הארגומנט השלישי של הפונקציה jsonPath (want-array) ל-false כדי שהערך של השימוש באסימון יחיד יוחזר ולא מערך. פרטים על הארגומנט הזה זמינים במאמר פונקציית נתיב JSON. בדוגמה הבאה מוצגת הגדרת ה-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. בדוגמה הבאה מוצגת הגדרת ה-SSE:

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

<Identifier>

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

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

באמצעות רכיב המזהה, אפשר להקצות ספירות של אסימונים לדליים נפרדים שמוגדרים לפי הערך במשתנה של זרימת נתונים. לדוגמה, אפשר להשתמש במשתנה 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 מוצרי ה-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>
רכיבי צאצא ללא

משתני זרימה

משתני ה-Flow המוגדרים מראש הבאים מאוכלסים באופן אוטומטי כשמדיניות 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