LLMTokenQuota-Richtlinie

Diese Seite gilt für Apigee, aber nicht für Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Übersicht

Die Richtlinie „LLMTokenQuota“ wurde entwickelt, um den Tokenverbrauch für KI-/LLM-Arbeitslasten zu verwalten und zu steuern. Da die Interaktionen mit Large Language Models (LLMs) tokenbasiert sind, ist ein effektives Management entscheidend für die Kostenkontrolle, die Leistungsoptimierung und die Plattformstabilität.

Ein Kontingent gibt die Anzahl der LLM-Tokens (Eingabe oder Ausgabe) an, die ein API-Proxy über einen bestimmten Zeitraum verarbeiten darf, z. B. pro Minute, Stunde, Tag, Woche oder Monat. Die LLMTokenQuota-Richtlinie verwaltet Zähler, in denen die Anzahl der vom API-Proxy verwendeten Tokens erfasst wird. Mit dieser Funktion können API-Anbieter Limits für den Tokenverbrauch durch Apps über einen bestimmten Zeitraum festlegen.

In dieser Richtlinie werden die Elemente <LLMTokenUsageSource> und <LLMModelSource> verwendet, um die Anzahl der Tokens aus der Antwort des LLM und den Modellnamen entweder aus der Anfrage oder der Antwort zu extrahieren. So kann das Kontingent präzise und in Echtzeit durchgesetzt werden.

Diese Richtlinie ist eine erweiterbare Richtlinie, deren Verwendung je nach Apigee-Lizenz Auswirkungen auf die Kosten oder die Nutzung haben kann. Informationen zu Richtlinientypen und Auswirkungen auf die Nutzung finden Sie unter Richtlinientypen.

So funktioniert die Durchsetzung des LLMTokenQuota

Im Folgenden wird die Funktionalität der Richtlinie „LLMTokenQuota“ beschrieben:

  • Token zählen (<CountOnly>): Die Richtlinie „LLMTokenQuota“ verwaltet Zähler, die die Anzahl der Tokens erfassen, die von LLM-Antworten verbraucht werden, die den API-Proxy durchlaufen.
  • Limits erzwingen (<EnforceOnly>):Mit dieser Funktion können API-Anbieter strenge Limits für die Anzahl der Tokens festlegen, die von Anwendungen in einem bestimmten Zeitraum verbraucht werden. Sie können Anwendungen beispielsweise auf 1.000 Tokens pro Minute oder 10.000.000 Tokens pro Monat beschränken.
  • Kontingentüberschreitung:Wenn ein API-Proxy das definierte Tokenkontingentlimit erreicht, lehnt Apigee nachfolgende tokenverbrauchende Anfragen ab. Es wird eine Fehlermeldung zurückgegeben, bis der Zähler „LLMTokenQuota“ am Ende des angegebenen Zeitintervalls automatisch zurückgesetzt wird. Wenn beispielsweise ein Kontingent von 10.000 Tokens pro Monat festgelegt ist, beginnt die Tokenbegrenzung, sobald das 10.000. Token gezählt wird, unabhängig davon, wann im Monat dieses Limit erreicht wird.

Funktionsweise von „LLMTokenQuota“ mit API-Produkten

Im Folgenden wird beschrieben, wie die Richtlinie „LLMTokenQuota“ mit API-Produkten funktioniert:

Proxy-Ablauf für LLMTokenQuota
  1. Wenden Sie die VerifyAPIKey- oder VerifyAccessToken-Richtlinie zusammen mit der LLMTokenQuota-Richtlinie in der Anfrage des API-Proxys an (Proxy oder Ziel spielt keine Rolle).
  2. Wenden Sie die LLMTokenQuota-Zählrichtlinie in Reaktion auf den API-Proxy an (Proxy oder Ziel spielt keine Rolle).
  3. Die Richtlinie VerifyAPIKey oder VerifyAccessToken gleicht den Schlüssel oder das Token mit dem API-Produkt, der Vorgangsmenge, dem Entwickler und der App ab. Sie macht die Ablaufvariablen für das LLM-Kontingent für alle Modelle aus den abgeglichenen LLM-Vorgangsmengen verfügbar.
  4. In der Richtlinie zur Durchsetzung von Kontingenten wird das Modell anhand der bereitgestellten Nachrichtenvorlage extrahiert.
  5. Anschließend werden die LLM-Kontingentvariablen für das Modell abgeglichen. Wenn eine Übereinstimmung gefunden wird, werden die Referenzen eingefügt.
  6. Sobald die Referenzen eingefügt wurden, werden diese Werte für die Kontingentvorgänge verwendet.

Funktionsweise von „LLMTokenQuota“ mit SSE-Antworten

Damit LLMTokenQuota mit SSE-Antworten funktioniert, fügen Sie die Richtlinie wie unten dargestellt in den Ereignisablauf ein:

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

Bei der Verarbeitung des Ereignisstreams wird die Tokenzählung nur ausgeführt, wenn die Metadaten zur Tokennutzung aus der LLM-Antwort im Ereignis gefunden werden. Wenn die Metadaten zur Tokennutzung erkannt werden, werden sie extrahiert und die Richtlinie wird ausgeführt. Bei allen anderen Ereignissen führt die Richtlinie zu NO-OP.

LLMTokenQuota-Richtlinientypen

Die LLMTokenQuota-Richtlinie unterstützt verschiedene Möglichkeiten zum Starten und Zurücksetzen des Kontingentzählers. Sie können festlegen, welche Möglichkeit mit dem Attribut type für das Element <LLMTokenQuota> verwendet werden soll, wie im folgenden Beispiel gezeigt:

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

Gültige Werte für type sind:

  • calendar: Konfigurieren Sie ein Kontingent anhand einer expliziten Startzeit. Der LLMTokenQuota-Zähler für jede App wird anhand der von Ihnen festgelegten Werte für <StartTime>, <Interval> und <TimeUnit> aktualisiert.
  • rollingwindow: Konfiguriert ein Kontingent, das ein rollierendes Fenster verwendet, um die Kontingentnutzung zu ermitteln. Mithilfe von rollingwindow legen Sie die Größe des Fensters mit den Elementen <Interval> und <TimeUnit> fest, zum Beispiel 1 Tag. Wenn eine Anfrage eingeht, prüft Apigee die genaue Zeit der Anfrage (z. B. 17:01 Uhr), die Anzahl der Tokens, die zwischen diesem Zeitpunkt und 17:01 Uhr am Vortag (1 Tag) verbraucht wurden, und bestimmt, ob das Kontingent während dieses Zeitfensters überschritten wurde.
  • flexi: Konfigurieren Sie ein Kontingent, das bewirkt, dass der Zähler startet, wenn die erste Anfragenachricht von einer Anwendung empfangen wird, und das auf Grundlage der Werte <Interval> und <TimeUnit> zurückgesetzt wird.

In der folgenden Tabelle wird beschrieben, wann das Kontingent für jeden Typ zurückgesetzt wird:

Zeiteinheit Typ
default (oder null) calendar flexi
Minute Beginn der nächsten Minute Eine Minute nach <StartTime> Eine Minute nach der ersten Anfrage
Stunde Volle nächste Stunde 1 Stunde nach <StartTime> 1 Stunde nach der ersten Anfrage
Tag Mitternacht GMT des aktuellen Tages 24 Stunden nach <StartTime> 24 Stunden nach der ersten Anfrage
Woche Sonntags um Mitternacht GMT am Ende der Woche Eine Woche nach <StartTime> Eine Woche nach der ersten Anfrage
Monat Mitternacht GMT am letzten Tag des Monats Einen Monat (28 Tage) nach <StartTime> Einen Monat (28 Tage) nach der ersten Anfrage

Für type="calendar" müssen Sie den Wert von <StartTime> angeben.

In der Tabelle wird nicht beschrieben, wann die Zählung für den Typ rollingwindow zurückgesetzt wird. Das liegt daran, dass rollierende Fensterkontingente etwas anders funktionieren, basierend auf einem Rückblickfenster, z. B. eine Stunde oder ein Tag. Beim Typ rollingwindow wird der Zähler nie zurückgesetzt, sondern bei jeder Anfrage neu berechnet. Wenn eine neue Anfrage eingeht, bestimmt die Richtlinie, ob das Kontingent in der Vergangenheit überschritten wurde.

Sie definieren zum Beispiel ein zweistündiges Zeitfenster, in dem 1.000 Tokens zugelassen werden. Um 16:45 Uhr geht eine neue Anfrage ein. Die Richtlinie berechnet den Kontingentzähler für das letzte Fenster von zwei Stunden, d. h. die Anzahl der Tokens, die seit 14:45 Uhr verbraucht wurden. Wenn das Kontingentlimit in diesem zweistündigen Zeitraum nicht überschritten wurde, wird die Anfrage zugelassen.

Eine Minute später, um 16:46 Uhr, geht eine weitere Anfrage ein. Jetzt berechnet die Richtlinie den Kontingentzähler seit 14:46 Uhr, um zu ermitteln, ob das Limit überschritten wurde.

Informationen zu Kontingentzählern

Wenn eine LLMTokenQuota-Richtlinie in einem API-Proxy-Ablauf ausgeführt wird, wird ein Kontingentzähler erhöht. Wenn der Zähler sein Limit erreicht, sind keine weiteren API-Aufrufe zulässig, die mit diesem Zähler verknüpft sind. Je nach Konfiguration Ihres API-Produkts kann die LLMTokenQuota-Richtlinie einen einzelnen Zähler oder mehrere unabhängige Zähler verwenden. Es ist wichtig zu verstehen, in welchen Szenarien mehrere Zähler verwendet werden und wie sie sich verhalten.

Kontingenteinstellungen für API-Produkte konfigurieren

Ein API-Produkt kann Kontingenteinstellungen auf Produktebene oder auf Ebene einzelner Vorgänge oder beides angeben. Wenn Ihr API-Proxy in einem API-Produkt enthalten ist, können Sie die LLMTokenQuota-Richtlinie so konfigurieren, dass die in diesem Produkt definierten Kontingenteinstellungen (Anzahl der zulässigen Aufrufe, Zeiteinheit und Intervall) verwendet werden. Am einfachsten geht das über das Element useQuotaConfigInAPIProduct. Alternativ können Sie über einzelne Variablenverweise auf diese Einstellungen in der LLMTokenQuota-Richtlinie verweisen.

So werden Kontingente gezählt

Standardmäßig verwaltet Apigee einen separaten Kontingentzähler für jeden in einem API-Produkt definierten Vorgang. Dabei gelten die folgenden Regeln:

  • Wenn für einen Vorgang ein Kontingent definiert ist, haben die Kontingenteinstellungen des Vorgangs Vorrang vor den auf Produktebene definierten Kontingenteinstellungen.
  • Wenn für einen Vorgang kein Kontingent definiert ist, gelten die Kontingenteinstellungen auf Produktebene.
  • Wenn das API-Produkt keine Kontingenteinstellungen enthält – weder auf Produkt- noch auf Vorgangsebene –, gelten die in der LLMTokenQuota-Richtlinie angegebenen Kontingenteinstellungen für die zulässige Anzahl, die Zeiteinheit und das Intervall.

In jedem Fall verwaltet Apigee einen separaten Kontingentzähler für jeden in einem API-Produkt definierten Vorgang. Durch jeden API-Aufruf, der einem Vorgang entspricht, wird der Zähler erhöht.

Zähler auf API-Proxy-Ebene konfigurieren

Es ist möglich, ein API-Produkt so zu konfigurieren, dass eine Kontingentanzahl auf dem API-Proxy-Bereich verwaltet wird. In diesem Fall wird die auf API-Produktebene angegebene Kontingentkonfiguration von allen Vorgängen gemeinsam genutzt, für die kein eigenes Kontingent angegeben ist. Durch diese Konfiguration wird ein Zähler auf API-Proxy-Ebene für dieses API-Produkt erstellt.

Um diese Konfiguration zu erreichen, müssen Sie die /apiproducts Apigee API verwenden, um das Produkt zu erstellen oder zu aktualisieren, und das quotaCounterScope-Attribut in der Erstellungs- oder Aktualisierungsanfrage auf PROXY festlegen. In der Konfiguration PROXY nutzen Anfragen, die mit einem der für das API-Produkt definierten Vorgänge übereinstimmen, die mit demselben Proxy verknüpft sind und keine eigenen Kontingenteinstellungen haben, einen gemeinsamen Kontingentzähler für diesen Proxy.

In Abbildung 1 sind die Vorgänge 1 und 2 mit Proxy1 und die Vorgänge 4 und 5 mit Proxy3 verknüpft. Da quotaCounterScope=PROXY im API-Produkt festgelegt ist, verwenden alle diese Vorgänge die Kontingenteinstellung auf API-Produktebene. Die Vorgänge 1 und 2, die mit Proxy1 verknüpft sind, verwenden einen gemeinsamen Zähler. Die Vorgänge 4 und 5, die mit Proxy3 verknüpft sind, verwenden einen separaten gemeinsamen Zähler. Für Vorgang 3 gilt eine eigene Kontingentkonfiguration, sodass er unabhängig vom Wert des Attributs quotaCounterScope einen eigenen Zähler verwendet.

Abbildung 1: Verwendung des Flags „quotaCounterScope“

So werden Kontingente gezählt, wenn keine API-Produkte verwendet werden

Wenn mit einem API-Proxy kein API-Produkt verknüpft ist, verwaltet eine LLMTokenQuota-Richtlinie einen einzelnen Zähler, unabhängig davon, wie oft Sie in einem API-Proxy darauf verweisen. Der Name des Kontingentzählers basiert auf dem Attribut name der Richtlinie.

Sie erstellen beispielsweise eine LLMTokenQuota-Richtlinie namens MyLLMTokenQuotaPolicy mit einem Limit von fünf Tokens und platzieren diese in mehreren Abläufen (A, B und C) im API-Proxy. Auch wenn der Zähler in mehreren Abläufen verwendet wird, bleibt er ein einzelner Zähler, der von allen Instanzen der Richtlinie aktualisiert wird. Angenommen, für die LLM-Antwort wurde jeweils 1 Token verwendet:

  • Ablauf A wird ausgeführt –> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler = 1.
  • Ablauf B wird ausgeführt –> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler = 2.
  • Ablauf A wird ausgeführt –> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler = 3
  • Ablauf C wird ausgeführt –> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler = 4.
  • Ablauf A wird ausgeführt –> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler = 5.

Die nächste Anfrage an einen der drei Abläufe wird abgelehnt, da der Kontingentzähler sein Limit erreicht hat.

Die Verwendung derselben LLMTokenQuota-Richtlinie an mehreren Stellen in einem API-Proxy-Ablauf, die ungewollt dazu führen kann, dass das LLMTokenQuota schneller als erwartet verbraucht ist, wird als Anti-Muster bezeichnet (siehe Beschreibung unter Einführung in Antimuster).

Alternativ können Sie mehrere LLMTokenQuota-Richtlinien in Ihrem API-Proxy definieren und in jedem Ablauf eine andere Richtlinie verwenden. Jede LLMTokenQuota-Richtlinie nutzt dann einen eigenen Zähler, gemäß dem Attribut name der Richtlinie.

Mehrere Zähler anhand der Richtlinienkonfiguration erstellen

Sie können die Elemente <Class> oder <Identifier> in der LLMTokenQuota-Richtlinie verwenden, um mehrere eindeutige Zähler in einer einzelnen Richtlinie zu definieren. Wenn Sie diese Elemente verwenden, kann eine einzelne Richtlinie verschiedene Zähler verwalten – auf Grundlage der Anwendung, die die Anfrage stellt, des App-Entwicklers, der die Anfrage stellt, einer Client-ID, einer Client-Kennzeichnung und so weiter. Weitere Informationen zur Verwendung der Elemente <Class> und <Identifier> finden Sie in den obigen Beispielen.

Zeitnotation

Alle LLMTokenQuota-Zeiten sind auf die Zeitzone Coordinated Universal Time (UTC) eingestellt.

Die Notation für die LLMTokenQuota-Zeit entspricht der internationalen Standardschreibweise, die im internationalen Standard ISO 8601 definiert ist.

Datumsangaben sind als Jahr, Monat und Tag im folgenden Format definiert: YYYY-MM-DD. Beispielsweise steht 2025-02-04 für den 4. Februar 2025.

Die Tageszeit wird im folgenden Format als Stunden, Minuten und Sekunden angegeben: hours:minutes:seconds. Beispielsweise steht 23:59:59 für die Uhrzeit um eine Sekunde vor Mitternacht.

Beachten Sie, dass es zwei Notationen gibt, nämlich 00:00:00 und 24:00:00, um zwischen den beiden Uhrzeiten um Mitternacht zu unterscheiden, die einem Datum zugeordnet werden können. Daher ist 2025-02-04 24:00:00 dasselbe Datum und dieselbe Uhrzeit wie 2025-02-05 00:00:00. Letzteres ist normalerweise die bevorzugte Notation.

Kontingenteinstellungen aus der API-Produktkonfiguration abrufen

Sie können Kontingentlimits in API-Produktkonfigurationen festlegen. Diese Limits erzwingen nicht automatisch ein Kontingent. Stattdessen können Sie in einer LLMTokenQuota-Richtlinie auf die Einstellungen für das Produktkontingent verweisen. Beim Festlegen eines Kontingents für das Produkt haben Sie folgende Vorteile:

  • Bei LLMTokenQuota-Richtlinien kann eine einheitliche Einstellung für alle API-Proxys im API-Produkt verwendet werden.
  • Sie können Laufzeitänderungen an der Kontingenteinstellung eines API-Produkts vornehmen. Außerdem haben LLMTokenQuota-Richtlinien, die auf den Wert verweisen, automatisch aktualisierte Kontingentwerte.

Weitere Informationen zur Verwendung der Kontingenteinstellungen aus einem API-Produkt finden Sie im Beispiel Dynamisches Kontingent.

Informationen zum Konfigurieren von API-Produkten mit Kontingentlimits finden Sie unter API-Produkte verwalten.

Zähler für gemeinsame Kontingente konfigurieren

Im einfachen Fall wird der Zähler der LLMTokenQuota-Richtlinie einmal für jedes Token erhöht, das während der Verarbeitung der ursprünglichen Anfrage an einen API-Proxy gesendet wird. In einigen Fällen möchten Sie möglicherweise prüfen, ob das Kontingent bei der ersten Verarbeitung der eingehenden Anfrage überschritten wird, den Zähler jedoch erst bei der Verarbeitung der Antwort erhöhen.

Wenn Sie drei LLMTokenQuota-Richtlinienelemente zusammen verwenden – <SharedName>, <CountOnly> und <EnforceOnly> –, können Sie die LLMTokenQuota-Richtlinie anpassen, um das Kontingent für eingehende Anfragen zu erzwingen, den Zähler aber nur im Antwortfluss zu erhöhen.

Angenommen, Sie haben einen API-Proxy, der ein LLM als Ziel verwendet,und Sie möchten ein Kontingent von 100.000 Tokens pro Stunde erzwingen. Die LLM-Antworten enthalten einen totalTokenCount-Wert. Gehen Sie dazu so vor:

  • Hängen Sie dem ProxyEndpoint-Anfrageablauf eine LLMTokenQuota-Richtlinie an, bei der das Element <SharedName> mit einem Namenswert und das Element <EnforceOnly> auf true festgelegt ist.
  • Verwenden Sie das Element <LLMTokenUsageSource> in der LLMTokenQuota-Richtlinie, um die Anzahl der Tokens abzurufen.

Ein Beispiel für die Verwendung freigegebener Zähler finden Sie unter Freigegebene Zähler im Abschnitt Beispiele.

Beispiele

Diese Codebeispiele für Richtlinien zeigen, wie Sie das Start- und Enddatum für Kontingente festlegen:

Dynamischeres 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>

Mit dynamischen Kontingenten können Sie eine einzelne LLMTokenQuota-Richtlinie konfigurieren, die verschiedene Kontingenteinstellungen anhand der Angaben erzwingt, die an die LLMTokenQuota-Richtlinie übergeben werden. Eine weitere Bezeichnung für die Einstellungen für das LLMTokenQuota in diesem Kontext ist der Serviceplan. Das dynamische LLMTokenQuota prüft den Serviceplan der Anwendungen und erzwingt diese Einstellungen.

Wenn Sie beispielsweise ein API-Produkt erstellen, können Sie optional das zulässige Kontingentlimit, die Zeiteinheit und das Intervall festlegen. Wenn Sie diesen Wert für das API-Produkt festlegen, wird die Verwendung in einem API-Proxy jedoch nicht erzwungen. Sie müssen außerdem eine LLMTokenQuota-Richtlinie zum API-Proxy hinzufügen, die diese Werte liest. Weitere Informationen finden Sie unter API-Produkte erstellen.

Im obigen Beispiel verwendet der API-Proxy, der die LLMTokenQuota-Richtlinie enthält, eine VerifyAPIKey-Richtlinie mit dem Namen verify-api-key, um den in einer Anfrage übergebenen API-Schlüssel zu validieren. Die LLMTokenQuota-Richtlinie greift dann auf die Ablaufvariablen aus der VerifyAPIKey-Richtlinie zu, um die für das API-Produkt festgelegten Kontingentwerte zu lesen.

Eine weitere Option besteht darin, benutzerdefinierte Attribute für einzelne Entwickler oder Apps festzulegen und diese Werte dann in der LLMTokenQuota-Richtlinie zu lesen. Beispiel: Um verschiedene Kontingentwerte pro Entwickler festzulegen, legen Sie benutzerdefinierte Attribute für den Entwickler fest, die das Limit, die Zeiteinheit und das Intervall enthalten. Verweisen Sie dann in der Richtlinie „LLMTokenQuota“ auf diese Werte:

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

In diesem Beispiel werden auch die VerifyAPIKey-Ablaufvariablen verwendet, um auf die benutzerdefinierten Attribute zu verweisen, die für den Entwickler festgelegt wurden.

Sie können eine beliebige Variable verwenden, um die Parameter der LLMTokenQuota-Richtlinie festzulegen. Diese Variablen können aus folgenden Quellen stammen:

  • Ablaufvariablen
  • Attribute für das API-Produkt, die Anwendung oder den Entwickler
  • Eine Schlüssel/Wert-Paar-Zuordnung (KVM)
  • Header, Abfrageparameter, Formularparameter und anderes

Sie können für jeden API-Proxy eine LLMTokenQuota-Richtlinie hinzufügen, die entweder auf dieselbe Variable verweist wie alle anderen LLMTokenQuota-Richtlinien in allen anderen Proxys oder die LLMTokenQuota-Richtlinie kann auf Variablen verweisen, die für diese Richtlinie und diesen Proxy einzigartig sind.

Beginn

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

Für ein LLMTokenQuota, bei dem type als calendar festgelegt ist, müssen Sie einen expliziten Wert <StartTime> festlegen. Der Zeitwert ist die GMT-Zeit, nicht die Ortszeit. Wenn Sie keinen <StartTime>-Wert für eine Richtlinie vom Typ calendar angeben, gibt Apigee einen Fehler aus.

Der LLMTokenQuota-Zähler wird pro Anwendung anhand der Werte <StartTime>, <Interval> und <TimeUnit> aktualisiert. In diesem Beispiel beginnt das LLMTokenQuota am 18. Februar 2025 um 10:30 Uhr GMT zu zählen. Die Aktualisierung erfolgt alle 5 Stunden. Die nächste Aktualisierung erfolgt also am 18. Februar 2025 um 15:30 Uhr GMT.

Access Counter

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

Ein API-Proxy hat Zugriff auf die durch die Richtlinie „LLMTokenQuota“ festgelegten Ablaufvariablen. Sie können auf diese Flussvariablen im API-Proxy zugreifen, um eine bedingte Verarbeitung durchzuführen, die Richtlinie im Blick zu behalten, wenn das Kontingentlimit erreicht wird, den aktuellen Kontingentzähler an eine Anwendung zurückzugeben oder aus anderen Gründen.

Da der Zugriff auf die Flussvariablen für die Richtlinie auf dem Attribut name der Richtlinie basiert, greifen Sie für die oben genannte Richtlinie mit dem Namen <LLMTokenQuota> so auf die Flussvariablen zu:

  • ratelimit.LLMTokenQuotaPolicy.allowed.count: Zugelassene Menge.
  • ratelimit.LLMTokenQuotaPolicy.used.count: Aktueller Zählerwert.
  • ratelimit.LLMTokenQuotaPolicy.expiry.time: UTC-Zeit, zu der der Zähler zurückgesetzt wird.

Es gibt viele weitere Flussvariablen, auf die Sie wie unten beschrieben zugreifen können.

Sie können beispielsweise die folgende AssignMessage-Richtlinie verwenden, um die Werte der Flussvariablen eines LLM-Tokenkontingents als Antwortheader zurückzugeben:

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

Freigegebene Zähler

Das folgende Beispiel zeigt, wie ein gemeinsam genutzter Zähler für einen API-Proxy konfiguriert wird, wobei der Kontingentzähler auch erhöht wird, wenn die Zielantwort der HTTP-Status 200 ist. Da beide LLMTokenQuota-Richtlinien denselben <SharedName>-Wert verwenden, teilen sich beide LLMTokenQuota-Richtlinien denselben Kontingentzähler. Weitere Informationen finden Sie unter Freigegebene Kontingentzähler konfigurieren.

Beispiel für eine ProxyEndpoint-Konfiguration: 

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

Beispiel für die erste LLMTokenQuota-Richtlinie:

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

Zweites Beispiel für die LLMTokenQuota-Richtlinie:

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

First Request

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

Verwenden Sie diesen Beispielcode,um ein Kontingent von 10.000 Tokens pro Stunde zu erzwingen. Die Richtlinie setzt den Kontingentzähler zu jeder vollen Stunde zurück. Wenn der Zähler das Kontingent von 10.000 Tokens vor Ablauf der Stunde erreicht,werden API-Aufrufe, die mehr als 10.000 Tokens verbrauchen,abgelehnt.

Wenn der Zähler beispielsweise bei 2025-07-08 07:00:00 beginnt, wird der Wert am 2025-07-08 08:00:00 (eine Stunde ab der Startzeit) auf 0 zurückgesetzt. Wenn die erste Anfrage am 2025-07-08 07:35:28 eingeht und die Anzahl der Tokens vor 2025-07-08 08:00:00 10.000 erreicht hat, werden Anfragen, die mehr Tokens verbrauchen, abgelehnt, bis der Zähler zur vollen Stunde zurückgesetzt wird.

Die Zeit bis zum Zurücksetzen des Zählers basiert auf der Kombination aus <Interval> und <TimeUnit>. Wenn Sie beispielsweise <Interval> für eine <TimeUnit>-Stunde auf 12 setzen, wird der Zähler alle 12 Stunden zurückgesetzt. Sie können <TimeUnit> auf Minute, Stunde, Tag, Woche oder Monat festlegen.

Sie können in Ihrem API-Proxy an mehreren Stellen auf diese Richtlinie verweisen. Sie können es beispielsweise im Proxy-PreFlow platzieren, damit es bei jeder Anfrage ausgeführt wird. Alternativ können Sie sie auch in mehreren Abläufen im API-Proxy platzieren. Wenn Sie diese Richtlinie an mehreren Stellen im Proxy verwenden, wird ein einzelner Zähler verwaltet, der von allen Instanzen der Richtlinie aktualisiert wird.

Alternativ können Sie mehrere LLMTokenQuota-Richtlinien in Ihrem API-Proxy definieren. Jede LLMTokenQuota-Richtlinie nutzt dann einen eigenen Zähler, gemäß dem Attribut name der Richtlinie.

ID festlegen

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

Bei einer LLMTokenQuota-Richtlinie wird standardmäßig ein einzelner Zähler für den API-Proxy definiert, unabhängig vom Ursprung einer Anfrage. Alternativ können Sie bei einer LLMTokenQuota-Richtlinie das Attribut <Identifier> verwenden, um separate Zähler basierend auf dem Wert des Attributs <Identifier> zu verwalten.

Beispielsweise können Sie mit dem Tag <Identifier> separate Zähler für jede Client-ID definieren. Bei einer Anfrage an Ihren Proxy übergibt die Clientanwendung, wie im obigen Beispiel gezeigt, einen Header, der clientID enthält.

Sie können eine beliebige Ablaufvariable im Attribut <Identifier> angeben. Beispiel: Sie können angeben, dass ein Abfrageparameter namens id die eindeutige Kennzeichnung enthält:

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

Wenn Sie die VerifyAPIKey-Richtlinie zur Validierung des API-Schlüssels oder der OAuthV2-Richtlinien mit OAuth-Tokens verwenden, können Sie Informationen im API-Schlüssel oder -Token nutzen, um einzelne Zähler für dieselbe LLMTokenQuota-Richtlinie zu definieren. Beispiel: Folgendes <Identifier>-Element verwendet die Ablaufvariable client_id einer VerifyAPIKey-Richtlinie mit dem Namen verify-api-key:

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

Jeder eindeutige client_id-Wert definiert nun einen eigenen Zähler in der LLMTokenQuota-Richtlinie.

Klasse

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

Sie können LLMTokenQuota-Limits dynamisch festlegen, indem Sie eine klassenbasierte LLMTokenQuota-Zählung verwenden. In diesem Beispiel wird das Kontingentlimit durch den Wert des Headers developer_segment bestimmt, der mit jeder Anfrage übergeben wird. Diese Variable kann den Wert platinum oder silver haben. Wenn der Header einen ungültigen Wert enthält, gibt die Richtlinie einen Fehler wegen Kontingentverletzung zurück.

Die folgenden Beispiele veranschaulichen verschiedene Konfigurationen der LLMTokenQuota-Richtlinie.

Tokens berechnen

In diesem Beispiel wird gezeigt, wie Tokens berechnet werden.

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

Kontingentvariablen mit API-Produkt, Entwickler und App zählen

In diesem Beispiel wird gezeigt, wie Sie dynamische Kontingentvariablen anhand von API-Produkt, Entwickler und App zählen.

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

Kontingent ohne API-Produkt erzwingen

In diesem Beispiel wird gezeigt, wie Sie Kontingente ohne API-Produkt erzwingen.

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

Kontingent mit API-Produkt, Entwickler und App erzwingen

In diesem Beispiel wird gezeigt, wie das Kontingent mit API-Produkt, Entwickler und App erzwungen wird.

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

Mit SSE-Stream

In diesem Beispiel wird gezeigt, wie LLMTokenQuota mit einem SSE-Stream verwendet wird.

Richtlinie für die Zählung des Tokenkontingents:

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

Ereignisfluss:

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

Element <LLMTokenQuota>

Im Folgenden sind Attribute und untergeordnete Elemente von <LLMTokenQuota> aufgeführt. Beachten Sie, dass einige Elementkombinationen sich gegenseitig ausschließen oder nicht erforderlich sind. Unter den jeweiligen Beispielen werden konkrete Anwendungsfälle gezeigt.

Die unten aufgeführten verifyapikey.my-verify-key-policy.apiproduct.*-Variablen sind standardmäßig verfügbar, wenn eine VerifyAPIKey-Richtlinie namens my-verify-key-policy verwendet wird, um den API-Schlüssel der Anwendung in der Anfrage zu prüfen. Die Variablenwerte stammen aus den Kontingenteinstellungen des API-Produkts, dem der Schlüssel zugeordnet ist, wie unter Kontingenteinstellungen aus der API-Produktkonfiguration abrufen beschrieben.

<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',response.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>

Die folgenden Attribute sind spezifisch für diese Richtlinie:

Attribut Beschreibung Standard Präsenz
type

Legt den Typ der LLMTokenQuota-Richtlinie fest, der bestimmt, wann und wie der Kontingentzähler die Kontingentnutzung prüft und wie er zurückgesetzt wird.

Wenn Sie type nicht festlegen, beginnt der Zähler am Anfang der Minute, der Stunde, des Tags, der Woche oder des Monats.

Gültige Werte sind:

  • calendar
  • rollingwindow
  • flexi

Eine vollständige Beschreibung der einzelnen Typen finden Sie unter LLMTokenQuota-Richtlinientypen.

 – Optional

In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:

Attribut Beschreibung Standard Presence
name

Der interne Name der Richtlinie. Der Wert des Attributs name kann Buchstaben, Ziffern, Leerzeichen, Bindestriche, Unterstriche und Punkte enthalten. Dieser Wert darf 255 Zeichen nicht überschreiten.

Optional können Sie das Element <DisplayName> verwenden, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

 – Erforderlich
continueOnError

Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten.

Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird. Siehe auch:

 false Optional
enabled

Setzen Sie den Wert auf true, um die Richtlinie zu erzwingen.

Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.

 true Optional
async

Dieses Attribut wurde verworfen.

 false Verworfen

<DisplayName>-Element

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

<DisplayName>Policy Display Name</DisplayName>
Standard

–

Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs name der Richtlinie verwendet.
Presence Optional
Typ String

<Allow>

Gibt die Gesamtzahl der Tokens an, die für das angegebene Zeitintervall zulässig sind. Wenn der Zähler für die Richtlinie dieses Limit erreicht, werden nachfolgende API-Aufrufe abgelehnt, bis der Zähler zurückgesetzt wird.

Kann auch ein <Class>-Element enthalten, das das <Allow>-Element basierend auf einer Ablaufvariable konditioniert.

Standardwert –
Erforderlich? Optional
Typ Ganzzahl- oder komplexer Typ
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente <Class>

Hier sehen Sie drei Möglichkeiten zum Festlegen des Elements <Allow>:

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

Wenn Sie sowohl count als auch countRef angeben, erhält countRef die Priorität. Wenn countRef zur Laufzeit nicht aufgelöst wird, wird der Wert von count verwendet.

Sie können auch ein <Class>-Element als untergeordnetes Element von <Allow> angeben, um die zulässige Anzahl der Richtlinie auf Basis einer Ablaufvariable zu bestimmen. Apigee ordnet den Wert der Ablaufvariable wie unten dargestellt dem Attribut class des <Allow>-Elements zu:

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

In der folgenden Tabelle sind die Attribute von <Allow> aufgeführt:

Attribut Beschreibung Standard Präsenz
count

Dient zum Angeben einer Tokenanzahl für das Kontingent.

Ein Wert von 100 für das Attribut count, ein Interval von 1 und die TimeUnit "Monat" geben beispielsweise ein Kontingent von 100 Tokens pro Monat an.

 2000 Optional
countRef

Dient zum Angeben einer Ablaufvariable, die die Anzahl der Tokens für ein Kontingent enthält. countRef hat Vorrang vor dem Attribut count.

 keine Optional

<Class>

Damit können Sie den Wert des Elements <Allow> basierend auf dem Wert einer Ablaufvariablen konditionieren. Für jedes unterschiedliche untergeordnete <Allow>-Tag von <Class> verwaltet die Richtlinie einen anderen Zähler.

Standardwert –
Erforderlich? Optional
Typ Komplexer Typ
Übergeordnetes Element <Allow>
Untergeordnete Elemente <Allow> (untergeordnet unter <Class>)

Wenn Sie das <Class>-Element verwenden möchten, geben Sie eine Ablaufvariable mithilfe des Attributs ref für das Element <Class> an. Apigee wählt dann anhand des Werts der Ablaufvariablen eines der untergeordneten <Allow>-Elemente aus, um die zulässige Anzahl der Richtlinie zu bestimmen. Apigee ordnet den Wert der Ablaufvariable wie unten dargestellt dem Attribut class des <Allow>-Elements zu:

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

In diesem Beispiel wird der aktuelle Kontingentzähler durch den Wert des an Ihrer Anfrage übergebenen Abfrageparameters time_variable bestimmt. Diese Variable kann den Wert peak_time oder off_peak_time haben. Wenn der Abfrageparameter einen ungültigen Wert enthält, gibt die Richtlinie einen Fehler wegen Kontingentverletzung zurück.

In der folgenden Tabelle sind die Attribute von <Class> aufgeführt:

Attribut Beschreibung Standard Präsenz
ref Dient zum Angeben einer Ablaufvariable, die die Kontingentklasse für ein Kontingent enthält. keine Erforderlich

<Allow> (untergeordnet unter <Class>)

Gibt das Limit für einen Kontingentzähler an, der durch das Element <Class> definiert wird. Für jedes unterschiedliche untergeordnete <Allow>-Tag von <Class> verwaltet die Richtlinie einen anderen Zähler.

Standardwert –
Erforderlich? Optional
Typ Komplexer Typ
Übergeordnetes Element <Class>
Untergeordnete Elemente Keins

Beispiel:

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

In diesem Beispiel nutzt die LLMTokenQuota-Richtlinie zwei Kontingentzähler mit den Namen peak_time und off_peak_time. Welcher konkret verwendet wird, hängt vom Abfrageparameter ab, der übergeben wird (siehe <Class>-Beispiel).

In der folgenden Tabelle sind die Attribute von <Allow> aufgeführt:

Attribut Beschreibung Standard Präsenz
class Definiert den Namen des Kontingentzählers. keine Erforderlich
count Gibt das Kontingentlimit für den Zähler an. keine Erforderlich

<IgnoreUnresolvedVariables>

Bestimmt, ob die Verarbeitung der LLMTokenQuota-Richtlinie beendet wird, wenn Apigee eine Variable nicht auflösen kann, auf die im Attribut ref der Richtlinie verwiesen wird.

Standardwert falsch
Erforderlich? Optional
Typ Boolescher Wert
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Auf true festlegen, um nicht aufgelöste Variablen zu ignorieren und die Verarbeitung fortzusetzen. Andernfalls false. Der Standardwert ist false.

Wenn <IgnoreUnresolvedVariables> auf true gesetzt ist und die in einem ref-Attribut angegebene Variable nicht aufgelöst werden kann, ignoriert Apigee das ref-Attribut. Wenn das Element, das das Attribut ref enthält, auch einen Wert wie <Allow count="2000"/> enthält, verwendet Apigee diesen Wert. Wenn kein Wert vorhanden ist, behandelt Apigee den Wert des Elements als null und setzt den Standardwert ein, sofern vorhanden, oder einen leeren String.

Wenn <IgnoreUnresolvedVariables> false ist und die in einem ref-Attribut angegebene Variable nicht aufgelöst werden kann, gibt Apigee einen Fehler zurück.

<Interval>

Gibt die Anzahl der Zeiträume an, in denen Kontingente berechnet werden.

Standardwert –
Erforderlich? Erforderlich
Typ Ganzzahl
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Wird zur Angabe einer Ganzzahl verwendet (z. B. 1, 2, 5, 60 usw.), die mit dem von Ihnen angegebenen <TimeUnit>-Element (Minute, Stunde, Tag, Woche oder Monat) gekoppelt wird, um einen Zeitraum zu bestimmen, in dem Apigee die Kontingentnutzung berechnet.

Zum Beispiel ein Intervall von 24 mit einer <TimeUnit> von hour bedeutet, dass das Kontingent über einen Zeitraum von 24 Stunden berechnet wird.

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

In der folgenden Tabelle sind die Attribute von <Interval> aufgeführt:

Attribut Beschreibung Standard Präsenz
ref

Wird verwendet, um eine Ablaufvariable anzugeben, die das Intervall für ein Kontingent enthält. ref hat Vorrang vor einem expliziten Intervallwert. Wenn sowohl Referenz als auch Wert angegeben sind, erhält die Referenz die Priorität. Wenn ref nicht zur Laufzeit aufgelöst wird, wird der Wert verwendet.

 keine Optional

<TimeUnit>

Gibt die für das Kontingent geltende Zeiteinheit an.

Standardwert –
Erforderlich? Erforderlich
Typ String
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Wählen Sie minute, hour, day, week, month oder year aus.

Ein Interval von 24 mit einer TimeUnit von hour bedeutet, dass das Kontingent über einen Zeitraum von 24 Stunden berechnet wird.

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

In der folgenden Tabelle sind die Attribute von <TimeUnit> aufgeführt:

Attribut Beschreibung Standard Präsenz
ref Gibt eine Ablaufvariable an, die die Zeiteinheit für ein Kontingent enthält. ref hat Vorrang vor einem expliziten Intervallwert. Wenn ref nicht zur Laufzeit aufgelöst wird, wird der Intervallwert verwendet. keine Optional

<StartTime>

Wenn type auf calendar gesetzt ist, werden hiermit Datum und Uhrzeit für den Start des Kontingentzählers angegeben, unabhängig davon, ob Anfragen von Anwendungen empfangen wurden.

Standardwert –
Erforderlich? Optional (erforderlich, wenn type auf calendar gesetzt ist)
Typ String im Datums- und Zeitformat nach ISO 8601.
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Beispiel:

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

<Distributed>

Bestimmt, ob Apigee einen oder mehrere Knoten zum Verarbeiten von Anfragen verwendet.

Standardwert falsch
Erforderlich? Optional
Typ Boolescher Wert
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Setzen Sie den Wert auf true, um anzugeben, dass die Richtlinie einen zentralen Zähler beibehalten und fortlaufend auf allen Knoten synchronisieren soll. Die Knoten können sich in Verfügbarkeitszonen und/oder Regionen befinden.

Wenn Sie den Standardwert false verwenden, kann Ihr Kontingent überschritten werden, da der Zähler für jeden Knoten nicht geteilt wird:

<Distributed>false</Distributed>

Um dafür zu sorgen, dass die Zähler bei jeder Anfrage synchronisiert und aktualisiert werden, legen Sie <Distributed> und <Synchronous> auf true fest:

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

<Synchronous>

Legt fest, ob ein verteilter Kontingentzähler synchron aktualisiert wird.

Standardwert falsch
Erforderlich? Optional
Typ Boolescher Wert
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Legen Sie true fest, um einen verteilten Kontingentzähler synchron zu aktualisieren. Dies bedeutet, dass die Aktualisierungen an den Zählern gleichzeitig durchgeführt werden, wenn das Kontingent für eine Anfrage an die API geprüft wird. Setzen Sie den Wert auf true, wenn Sie keine API-Aufrufe über das Kontingent zulassen möchten.

Setzen Sie den Wert auf false, um den Kontingentzähler asynchron zu aktualisieren. Dies bedeutet, dass einige API-Aufrufe trotz Überschreitung des Kontingents möglicherweise ausgeführt werden. Dies hängt davon ab, wann der Kontingentzähler im zentralen Repository asynchron aktualisiert wird. Es bestehen jedoch keine Auswirkungen auf die Leistung wie bei einer synchronen Aktualisierung.

Bei asynchroner Aktualisierung beträgt das Standardaktualisierungsintervall 10 Sekunden. Verwenden Sie das Element <AsynchronousConfiguration>, um dieses asynchrone Verhalten zu konfigurieren.

<Synchronous>false</Synchronous>

<AsynchronousConfiguration>

Konfiguriert das Synchronisierungsintervall zwischen verteilten Kontingentzählern, wenn das Richtlinienkonfigurationselement <Synchronous> nicht vorhanden ist oder vorhanden und auf false festgelegt ist. Apigee ignoriert dieses Element, wenn <Synchronous> auf true festgelegt ist.

Standardwert –
Erforderlich? Optional
Typ Komplexer Typ
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente <SyncIntervalInSeconds>
<SyncMessageCount>

Sie können das Synchronisierungsverhalten mit den untergeordneten Elementen <SyncIntervalInSeconds> oder <SyncMessageCount> angeben. Verwenden Sie entweder eines oder beide Elemente. Beispiel:

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

oder

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>
  • Wenn nur <SyncIntervalInSeconds> vorhanden ist, wird das Kontingent alle N Sekunden synchronisiert. N ist der im Element angegebene Wert, unabhängig davon, wie viele Nachrichten verarbeitet wurden.
  • Wenn nur <SyncMessageCount> vorhanden ist, wird das Kontingent alle M Nachrichten synchronisiert, wobei M der im Element angegebene Wert ist, oder alle 10 Sekunden, je nachdem, was zuerst eintritt.
  • Wenn beide Elemente vorhanden sind, wird das Kontingent alle M Nachrichten oder alle N Sekunden synchronisiert, je nachdem, was zuerst eintritt.
  • Wenn <AsynchronousConfiguration> nicht vorhanden ist oder keines der untergeordneten Elemente vorhanden ist, wird das Kontingent alle 10 Sekunden synchronisiert, unabhängig davon, wie viele Nachrichten verarbeitet wurden.

<SyncIntervalInSeconds>

Überschreibt das Standardverhalten, in dem asynchrone Updates nach einem Intervall von 10 Sekunden ausgeführt werden.

Standardwert 10 Sekunden
Erforderlich? Optional
Typ Ganzzahl
Übergeordnetes Element <AsynchronousConfiguration>
Untergeordnete Elemente Keins
 
<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

Das Synchronisierungsintervall muss mindestens 10 Sekunden lang sein, wie unter Limits beschrieben.

<SyncMessageCount>

Gibt die Anzahl der Anfragen an, die vor der Synchronisierung des Kontingentzählers verarbeitet werden sollen.

Standardwert –
Erforderlich? Optional
Typ Ganzzahl
Übergeordnetes Element <AsynchronousConfiguration>
Untergeordnete Elemente Keins
 
<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

Bei der Konfiguration in diesem Beispiel wird die Kontingentanzahl auf jedem Knoten nach jeweils 5 Anfragen oder alle 10 Sekunden synchronisiert, je nachdem, was zuerst eintritt.

<LLMTokenUsageSource>

Gibt die Quelle der Tokennutzung aus der LLM-Antwort an. Dies muss eine Nachrichtenvorlage sein, die in einen einzelnen Wert für die Tokennutzung aufgelöst wird. Wenn die Richtlinie nicht Teil eines Ereignisablaufs ist und die Anzahl der Tokens nicht aus der angegebenen Quelle extrahiert werden kann, wird ein policies.ratelimit.FailedToResolveTokenUsageCount-Laufzeitfehler ausgegeben.

Standardwert {jsonPath('$.usageMetadata.candidatesTokenCount',response.content,true)}
Erforderlich? Optional
Typ String
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Das folgende Beispiel zeigt, wie die Quelle der Tokennutzung angegeben wird:

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

<LLMModelSource>

Gibt die Quelle des Modellnamens aus der LLM-Antwort oder LLM-Anfrage an. Dies muss eine Nachrichtenvorlage sein, die einen einzelnen Modellnamenwert enthält.

Standardwert
Erforderlich? Optional
Typ String
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Im folgenden Beispiel wird gezeigt, wie die Modellquelle in der Anfrage angegeben wird:

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

<Identifier>

Konfiguriert die Richtlinie, um eindeutige Zähler anhand einer Ablaufvariablen zu erstellen.

Standardwert –
Erforderlich? Optional
Typ String
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Mit dem Kennzeichnungselement können Sie bestimmten Buckets Tokenanzahlen zuweisen, die durch den Wert in einer Ablaufvariable definiert werden. Sie können beispielsweise die Variable developer.id verwenden, die nach einer VerifyAPIKey-Richtlinie ausgefüllt wird, um ein Kontingentlimit für alle Instanzen aller von den jeweils angegebenen Entwicklern erstellten Anwendungen zu erzwingen. Alternativ können Sie client_id verwenden, um ein Kontingentlimit für jede bestimmte Anwendung zu erzwingen. Die Konfiguration für die zweite Option sieht so aus:

<Identifier ref="client_id"/>

Sie können entweder auf eine benutzerdefinierte Variable verweisen, die Sie mit der AssignMessage-Richtlinie oder der JavaScript-Richtlinie erstellen können, oder auf eine implizit festgelegte Variable wie sie von der VerifyAPIKey-Richtlinie oder der VerifyJWT-Richtlinie eingestellt wird. Weitere Informationen zu Variablen finden Sie unter Ablaufvariablen verwenden. Eine Liste der von Apigee definierten bekannten Variablen finden Sie in der Übersicht über Ablaufvariablen.

Wenn Sie dieses Element nicht verwenden, weist die Richtlinie alle Token in einem einzelnen Zähler für die jeweilige LLMTokenQuota-Richtlinie zu.

In der folgenden Tabelle werden die Attribute von <Identifier> beschrieben:

Attribut Beschreibung Standard Präsenz
ref

Gibt eine Flussvariable an, mit der der Zähler identifiziert wird, der für die Anfrage verwendet wird. Die Variable kann auf einen HTTP-Header, einen Abfrageparameter, einen Formularparameter oder ein Element des Nachrichteninhalts oder einen anderen Wert verweisen, mit dem angegeben wird, wie die Tokenmengen zugewiesen werden.

client_id wird im Allgemeinen als Variable verwendet. Der client_id wird auch als API-Schlüssel oder Consumer-Schlüssel bezeichnet und für eine Anwendung generiert, wenn sie in einer Organisation in Apigee registriert wird. Sie können diese ID verwenden, wenn Sie für Ihre API die API-Schlüssel- oder OAuth-Autorisierungsrichtlinien aktiviert haben.

 – Optional

<UseQuotaConfigInAPIProduct>

Definiert Kontingenteinstellungen für ein API-Produkt, z. B. Zeiteinheiten, Intervalle und Maximalwerte.

Standardwert –
Erforderlich? Optional
Typ Komplexer Typ
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente <DefaultConfig>

Wenn Sie der LLMTokenQuota-Richtlinie das Element <UseQuotaConfigInAPIProduct> hinzufügen, ignoriert Apigee alle untergeordneten Elemente <Allow>, <Interval> und <TimeUnit> von LLMTokenQuotaPolicy.

Das <UseQuotaConfigInAPIProduct>-Element ist einfach ein Container für die Standardeinstellungen, die Sie mithilfe des Elements <DefaultConfig> definieren, wie das folgende Beispiel zeigt:

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

Sie können mit dem Attribut stepName entweder auf eine VerifyAPIKey-Richtlinie oder auf einen ValidateToken-Richtlinienvorgang der OAuthv2-Richtlinie im Ablauf verweisen.

In der folgenden Tabelle werden die Attribute von <UseQuotaConfigInAPIProduct> beschrieben:

Attribut Beschreibung Standard Präsenz
stepName Gibt den Namen der Authentifizierungsrichtlinie im Ablauf an. Das Ziel kann entweder eine VerifyAPIKey-Richtlinie oder eine OAuthv2-Richtlinie sein. – Erforderlich

Hier finden Sie weitere Informationen:

<DefaultConfig>

Enthält Standardwerte für das Kontingent eines API-Produkts. Wenn Sie eine <DefaultConfig> definieren, sind alle drei untergeordneten Elemente erforderlich.

Standardwert –
Erforderlich? Optional
Typ Komplexer Typ
Übergeordnetes Element <UseQuotaConfigInAPIProduct>
Untergeordnete Elemente <Allow>
<Interval>
<TimeUnit>

Es ist möglich, diese Werte sowohl für den Vorgang des API-Produkts (entweder über die Benutzeroberfläche oder über die API für API-Produkte) als auch in der LLMTokenQuota-Richtlinie zu definieren. In diesem Fall haben die Einstellungen im API-Produkt jedoch Vorrang und die Einstellungen in der LLMTokenQuota-Richtlinie werden ignoriert.

Die Syntax für dieses Element sieht so aus:

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

Im folgenden Beispiel wird ein Kontingent von 10.000 pro Woche angegeben:

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

Hier finden Sie weitere Informationen:

<SharedName>

Gibt diese LLMTokenQuota-Richtlinie als shared an. Alle LLMTokenQuota-Richtlinien in einem API-Proxy mit demselben <SharedName>-Wert haben denselben zugrunde liegenden Kontingentzähler.

Weitere Informationen und Beispiele finden Sie unter Freigegebene Kontingentzähler konfigurieren.

Standardwert –
Erforderlich? Optional
Typ String
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

<CountOnly>

Platzieren Sie eine LLMTokenQuota-Richtlinie, bei der dieses Element auf true gesetzt ist, in einem Schritt im ProxyEndpoint-Antwortablauf, um die Anzahl der Tokens zu erfassen, ohne einen Fehler an den Client zurückzugeben, wenn das Tokenkontingentlimit überschritten wird. Wenn dieses Element vorhanden ist, muss auch das Element <SharedName> vorhanden sein und das Element <EnforceOnly> darf nicht vorhanden sein.

Weitere Informationen und Beispiele finden Sie unter Freigegebene Kontingentzähler konfigurieren.

Standardwert falsch
Erforderlich? Optional
Typ Boolescher Wert
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

<EnforceOnly>

Platzieren Sie eine LLMTokenQuota-Richtlinie, bei der dieses Element auf true gesetzt ist, im Anfrageablauf eines API-Proxy, um ein Tokenlimit zu erzwingen, ohne den Kontingentzähler zu erhöhen. Wenn dieses Element vorhanden ist, muss auch <SharedName> vorhanden sein und <CountOnly> darf nicht vorhanden sein.

Weitere Informationen und Beispiele finden Sie unter Freigegebene Kontingentzähler konfigurieren.

Standardwert falsch
Erforderlich? Optional
Typ Boolescher Wert
Übergeordnetes Element <LLMTokenQuota>
Untergeordnete Elemente Keins

Ablaufvariablen

Die folgenden vordefinierten Ablaufvariablen werden automatisch ausgefüllt, wenn eine LLMTokenQuota-Richtlinie ausgeführt wird. Weitere Informationen finden Sie unter Referenz zu Ablaufvariablen.

Variablen Typ Berechtigungen Beschreibung
ratelimit.{policy_name}.allowed.count Long Schreibgeschützt: Gibt die zulässige Kontingentzahl zurück.
ratelimit.{policy_name}.used.count Long Schreibgeschützt: Gibt das aktuell in einem Kontingentintervall verwendete Kontingent zurück.
ratelimit.{policy_name}.available.count Long Schreibgeschützt: Gibt die verfügbare Kontingentzahl im Kontingentintervall zurück.
ratelimit.{policy_name}.exceed.count Long Schreibgeschützt: Gibt 1 zurück, wenn das Kontingent überschritten wurde.
ratelimit.{policy_name}.total.exceed.count Long Schreibgeschützt: Gibt 1 zurück, wenn das Kontingent überschritten wurde.
ratelimit.{policy_name}.expiry.time Long Schreibgeschützt:

Gibt die UTC-Zeit in Millisekunden zurück. Damit wird festgelegt, wann das Kontingent abläuft und ein neues Kontingentintervall beginnt.

Wenn der Typ der Richtlinie „LLMTokenQuota“ rollingwindow lautet, ist dieser Wert nicht gültig, da das Kontingentintervall niemals abläuft.

ratelimit.{policy_name}.identifier String Schreibgeschützt: Gibt den mit der Richtlinie verknüpften (Client-)ID-Verweis zurück
ratelimit.{policy_name}.class String Schreibgeschützt: Gibt die der Client-ID zugeordnete Klasse zurück
ratelimit.{policy_name}.class.allowed.count Long Schreibgeschützt: Gibt die in der Klasse definierte zulässige Kontingentzahl zurück
ratelimit.{policy_name}.class.used.count Long Schreibgeschützt: Gibt das verwendete Kontingent innerhalb einer Klasse zurück.
ratelimit.{policy_name}.class.available.count Long Schreibgeschützt: Gibt die verfügbare Kontingentzahl in der Klasse zurück
ratelimit.{policy_name}.class.exceed.count Long Schreibgeschützt: Gibt die Anzahl der Tokens zurück, die das Limit in der Klasse im aktuellen Kontingentintervall überschreiten.
ratelimit.{policy_name}.class.total.exceed.count Long Schreibgeschützt: Gibt die Gesamtzahl der Tokens zurück, die das Limit in der Klasse aller Kontingentintervalle überschreiten. Es ist also die Summe von class.exceed.count für alle Kontingentintervalle.
ratelimit.{policy_name}.failed Boolesch Schreibgeschützt:

Gibt an, ob die Richtlinie fehlgeschlagen ist ("true" oder "false").
llmtokenquota.{policy_name}.model String Schreibgeschützt: Gibt das extrahierte Modell zurück.

Fehlerreferenz

In diesem Abschnitt werden die zurückgegebenen Fehlercodes und Fehlermeldungen beschrieben, die von Apigee festgelegt werden, wenn die Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Fehlercode HTTP-Status Ursache Korrigieren
policies.llmtokenquota.FailedToResolveModelName 400 Der Modellname konnte nicht aufgelöst werden. –
policies.llmtokenquota.FailedToResolveTokenUsageCount 500 Die Anzahl der Tokennutzungen konnte nicht ermittelt werden. –
policies.llmtokenquota.MessageTemplateExtractionFailed 400 Die Nachrichtenvorlage konnte nicht extrahiert werden. –
policies.llmtokenquota.LLMTokenQuotaViolation 429 Das Kontingentlimit für LLM-Tokens wurde überschritten. –
policies.ratelimit.FailedToResolveQuotaIntervalReference 500 Tritt auf, wenn das <Interval>-Element nicht in der LLMTokenQuota-Richtlinie definiert ist. Dieses Element ist obligatorisch und wird verwendet, um das Zeitintervall anzugeben, das für das LLM-Tokenkontingent gilt. Das Zeitintervall kann Minuten, Stunden, Tage, Wochen oder Monate sein, wie mit dem Element <TimeUnit> definiert.
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference 500 Tritt auf, wenn das <TimeUnit>-Element nicht in der LLMTokenQuota-Richtlinie definiert ist. Dieses Element ist obligatorisch und wird verwendet, um die Zeiteinheit anzugeben, die für das LLM-Tokenkontingent gilt. Das Zeitintervall kann in Minuten, Stunden, Tagen, Wochen oder Monaten angegeben werden.

Bereitstellungsfehler

Fehlername Ursache Korrigieren
policies.llmtokenquota.MessageWeightNotSupported Fehler bei Verwendung des Elements „MessageWeight“, da es nicht unterstützt wird. –
policies.llmtokenquota.InvalidConfiguration Genau eines von <CountOnly> oder <EnforceOnly> muss auf „true“ gesetzt sein. –
InvalidQuotaInterval Wenn das im <Interval>-Element angegebene LLM-Tokenkontingentintervall keine Ganzzahl ist, schlägt die Bereitstellung des API-Proxy fehl. Wenn das angegebene Kontingentintervall beispielsweise 0,1 im <Interval>-Element lautet, schlägt die Bereitstellung des API-Proxys fehl.
InvalidQuotaTimeUnit Wenn die im <TimeUnit>-Element angegebene Zeiteinheit nicht unterstützt wird, schlägt die Bereitstellung des API-Proxys fehl. Die unterstützten Zeiteinheiten sind minute, hour, day, week und month.
InvalidQuotaType Wenn der Typ des LLM-Tokenkontingents, das im type-Attribut des <LLMTokenQuota>-Elements angegeben ist, ungültig ist, dann schlägt die Bereitstellung des API-Proxy fehl. Unterstützte Kontingenttypen sind default, calendar, flexi und rollingwindow.
InvalidStartTime Wenn das im <StartTime>-Element angegebene Zeitformat ungültig ist, schlägt die Bereitstellung des API-Proxys fehl. Das gültige Format ist yyyy-MM-dd HH:mm:ss, also das Datums- und Uhrzeitformat ISO 8601. Wenn beispielsweise die im <StartTime>-Element angegebene Zeit 7-16-2017 12:00:00 lautet, schlägt die Bereitstellung des API-Proxys fehl.
StartTimeNotSupported Wenn das <StartTime>-Element angegeben ist, dessen Kontingenttyp nicht calendar ist, schlägt die Bereitstellung des API-Proxys fehl. Das <StartTime>-Element wird nur für den calendar-Kontingenttyp unterstützt. Wenn beispielsweise für das type-Attribut im <LLMTokenQuota>-Element der Wert flexi oder rolling window festgelegt ist, schlägt die Bereitstellung des API-Proxys fehl.
InvalidSynchronizeIntervalForAsyncConfiguration Ist der für das <SyncIntervalInSeconds>-Element im <AsynchronousConfiguration>-Element in einer LLMTokenQuota-Richtlinie angegebene Wert kleiner als null, so schlägt die Bereitstellung des API-Proxys fehl.
InvalidAsynchronizeConfigurationForSynchronousQuota Wenn der Wert des <AsynchronousConfiguration>-Elements in einer LLMTokenQuota-Richtlinie auf true gesetzt wird, aber auch eine asynchrone Konfiguration mithilfe des <AsynchronousConfiguration>-Elements vorliegt, dann wird die Bereitstellung des API-Proxy schlägt fehl.

Fehlervariablen

Diese Variablen werden festgelegt, wenn die Richtlinie einen Fehler auslöst. Weitere Informationen finden sich unter Was Sie über Richtlinienfehler wissen müssen.

Variablen Definition Beispiel
fault.name="fault_name" fault_name ist der Name des Fehlers, wie in der obigen Tabelle Laufzeitfehler aufgeführt. Der Fehlername ist der letzte Teil des Fehlercodes. fault.name Matches "LLMTokenQuotaViolation"
ratelimit.policy_name.failed policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgegeben hat. ratelimit.QT-LLMTokenQuotaPolicy.failed = true

Beispiel für eine Fehlerantwort

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

 Identifier : _default"
   }
}

Beispiel für eine Fehlerregel

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

Schemas

Weitere Informationen

PromptTokenLimit-Richtlinie