LLMTokenQuota-Richtlinie

Erweiterbare Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Übersicht

Die LLMTokenQuota-Richtlinie dient dazu, den Tokenverbrauch für KI-/LLM-Arbeitslasten zu verwalten und zu steuern. Da Interaktionen mit Large Language Models (LLMs) tokenbasiert sind, ist eine effektive Verwaltung entscheidend für die Kostenkontrolle, Leistungsoptimierung und Plattformstabilität.

Ein Kontingent ist eine Zuteilung von LLM-Tokens (Eingabe oder Ausgabe), die ein API-Proxy über einen bestimmten Zeitraum verbrauchen darf, zum Beispiel pro Minute, Stunde, Tag, Woche oder Monat. Die LLMTokenQuota-Richtlinie verwaltet Zähler, mit denen die Anzahl der Tokens erfasst wird, die vom API-Proxy verbraucht werden. Mit dieser Funktion können API-Anbieter Limits für den Tokenverbrauch durch Apps in einem bestimmten Zeitraum durchsetzen.

Diese Richtlinie verwendet die Elemente <LLMTokenUsageSource> und <LLMModelSource>, um die Tokenanzahl aus der Antwort des LLM und den Modellnamen entweder aus der Anfrage oder der Antwort zu extrahieren. So ist eine präzise Kontingentdurchsetzung in Echtzeit möglich.

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 Erzwingung von LLMTokenQuota

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

  • Tokenzählung (<CountOnly>): Die LLMTokenQuota-Richtlinie verwaltet Zähler, mit denen die Anzahl der Tokens erfasst wird, die von LLM-Antworten verbraucht werden, die den API-Proxy passieren.
  • 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 LLMTokenQuota-Zähler 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.000ste Token gezählt wurde, unabhängig davon, wann dieses Limit innerhalb des Monats erreicht wird.

Funktionsweise von LLMTokenQuota mit API-Produkten

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

Proxy-Ablauf für LLMTokenQuota
  1. Wenden Sie die Richtlinie VerifyAPIKey oder VerifyAccessToken zusammen mit der Richtlinie zur Durchsetzung LLMTokenQuota in der Anfrage des API-Proxys an (Proxy oder Ziel ist egal).
  2. Wenden Sie die Zählrichtlinie LLMTokenQuota als 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, dem Vorgangssatz, dem Entwickler und der App ab. Sie stellt die Ablaufvariablen für das LLM-Kontingent für alle Modelle aus den übereinstimmenden LLM-Vorgangssätzen bereit.
  4. In der Richtlinie zur Durchsetzung von Kontingenten extrahieren wir das Modell gemäß der bereitgestellten Nachrichtenvorlage.
  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 gezeigt als Teil des Ereignisablaufs hinzu:

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

Bei der Verarbeitung des Ereignisstreams erfolgt die Tokenzählung nur, 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, wie der Kontingentzähler gestartet und zurückgesetzt wird. Mit dem Attribut type im Element <LLMTokenQuota> können Sie festlegen, welche Option 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 basierend auf den von Ihnen festgelegten Werten für <StartTime>, <Interval> und <TimeUnit> aktualisiert.
  • rollingwindow: Konfiguriert ein Kontingent, das ein rollierendes Zeitfenster verwendet, um die Kontingentnutzung zu bestimmen. Mit rollingwindow legen Sie die Größe des Fensters mit den Elementen <Interval> und <TimeUnit> fest, z. B. 1 Tag. Wenn eine Anfrage eingeht, wird in Apigee der genaue Zeitpunkt der Anfrage (z. B. 17:01 Uhr) berücksichtigt. Dann wird die Anzahl der Tokens gezählt, die zwischen diesem Zeitpunkt und 17:01 Uhr am Vortag (1 Tag) verbraucht wurden. Anschließend wird ermittelt, ob das Kontingent in diesem Zeitraum ü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 die einzelnen Typen 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 Kontingente mit rollierendem Zeitfenster etwas anders funktionieren, basierend auf einem Lookback-Window, z. B. einer Stunde oder einem Tag. Beim Typ rollingwindow wird der Zähler nie zurückgesetzt, sondern bei jeder Anfrage neu berechnet. Wenn eine neue Anfrage eingeht, wird anhand der Richtlinie ermittelt, ob das Kontingent im vergangenen Zeitfenster überschritten wurde.

Sie definieren beispielsweise ein Zeitfenster von zwei Stunden, in dem 1.000 Tokens zulässig sind. Um 16:45 Uhr geht eine neue Anfrage ein. Die Richtlinie berechnet die Kontingentanzahl für das vergangene zweistündige Zeitfenster, d. h. die Anzahl der seit 14:45 Uhr verbrauchten Tokens. 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 der Konfiguration, die Sie für Ihr API-Produkt verwenden, kann die LLMTokenQuota-Richtlinie einen einzelnen Zähler oder mehrere unabhängige Zähler verwenden. Es ist wichtig zu verstehen, in welchen Fällen 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 der einzelnen Vorgangsebene oder auf beiden Ebenen 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 (zulässige Anzahl, 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.

Wie Kontingente gezählt werden

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 alle API-Aufrufe, die mit einem Vorgang übereinstimmen, 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 Vorgänge übereinstimmen, die für das API-Produkt definiert sind, 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 mit dem Namen MyLLMTokenQuotaPolicy mit einem Limit von 5 Tokens und platzieren sie in mehreren Abläufen (Ablauf A, B und C) im API-Proxy. Auch wenn sie in mehreren Abläufen verwendet wird, wird nur ein Zähler geführt, 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 ist 1.
  • Ablauf B wird ausgeführt -> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler ist 2.
  • Flow A wird ausgeführt -> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler ist 3.
  • Flow C wird ausgeführt -> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler ist 4
  • Flow A wird ausgeführt -> MyLLMTokenQuotaPolicy wird ausgeführt und der Zähler ist 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 ist ein Antipattern, das in Einführung in Antipatterns beschrieben wird. Dadurch kann das LLMTokenQuota unbeabsichtigt schneller aufgebraucht werden als erwartet.

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 Koordinierte Weltzeit (UTC) eingestellt.

Die Zeitangabe für LLMTokenQuota folgt der internationalen Standarddatumsangabe, die in der internationalen Norm ISO 8601 definiert ist.

Datumsangaben sind als Jahr, Monat und Tag im folgenden Format definiert: YYYY-MM-DD. 2025-02-04 steht beispielsweise 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 Kontingenteinstellungen des Produkts verweisen. Hier sind einige Vorteile, wenn Sie ein Kontingent für das Produkt festlegen, auf das sich LLMTokenQuota-Richtlinien beziehen:

  • LLMTokenQuota-Richtlinien können eine einheitliche Einstellung für alle API-Proxys im API-Produkt verwenden.
  • Sie können die Kontingenteinstellung für ein API-Produkt zur Laufzeit ändern. LLMTokenQuota-Richtlinien, die auf den Wert verweisen, haben dann automatisch aktualisierte Kontingentwerte.

Weitere Informationen zur Verwendung von 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 erhöht die LLMTokenQuota-Richtlinie ihren Zähler einmal für jedes Token, das während der Verarbeitung der Erstanfrage 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 aber nur während der Antwortverarbeitung erhöhen.

Mit den drei LLMTokenQuota-Richtlinienelementen <SharedName>, <CountOnly> und <EnforceOnly> können Sie die LLMTokenQuota-Richtlinie so anpassen, dass das Kontingent für eingehende Anfragen durchgesetzt wird, der Zähler aber nur im Antwortablauf erhöht wird.

Angenommen, Sie haben einen API-Proxy, der ein LLM als Ziel verwendet,und 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 eine LLMTokenQuota-Richtlinie an den ProxyEndpoint-Anfrageablauf an, wobei das Element <SharedName> mit einem Namenswert und das Element <EnforceOnly> auf true gesetzt 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:

Dynamischere 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 je nach den an die LLMTokenQuota-Richtlinie übergebenen Informationen unterschiedliche Kontingenteinstellungen erzwingt. Ein anderer Begriff für LLMTokenQuota-Einstellungen in diesem Kontext ist Diensttarif. Das dynamische LLMTokenQuota prüft den Diensttarif der Apps und erzwingt dann 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 dem API-Proxy auch eine LLMTokenQuota-Richtlinie 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 der VerifyAPIKey-Richtlinie zu, um die für das API-Produkt festgelegten Kontingentwerte zu lesen.

Eine weitere Möglichkeit besteht darin, benutzerdefinierte Attribute für einzelne Entwickler oder Apps festzulegen und diese Werte dann in der LLMTokenQuota-Richtlinie zu lesen. Wenn Sie beispielsweise unterschiedliche Kontingentwerte pro Entwickler festlegen möchten, legen Sie benutzerdefinierte Attribute für den Entwickler fest, die das Limit, die Zeiteinheit und das Intervall enthalten. Anschließend verweisen Sie in der LLMTokenQuota-Richtlinie auf diese Werte, wie unten gezeigt:

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

Für jeden API-Proxy können Sie eine LLMTokenQuota-Richtlinie hinzufügen, die entweder auf dieselbe Variable wie alle anderen LLMTokenQuota-Richtlinien in allen anderen Proxys verweist, oder die LLMTokenQuota-Richtlinie kann auf Variablen verweisen, die für diese Richtlinie und diesen Proxy eindeutig 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 mit type auf calendar müssen Sie einen expliziten <StartTime>-Wert definieren. 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 für jede App wird basierend auf den Werten <StartTime>, <Interval> und <TimeUnit> aktualisiert. In diesem Beispiel beginnt die Zählung für das LLMTokenQuota am 18. Februar 2025 um 10:30 Uhr GMT und wird alle 5 Stunden aktualisiert. 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 Ablaufvariablen, die von der LLMTokenQuota-Richtlinie festgelegt werden. Sie können auf diese Ablaufvariablen im API-Proxy zugreifen, um eine bedingte Verarbeitung durchzuführen, die Richtlinie zu überwachen, wenn sie sich dem Kontingentlimit nähert, den aktuellen Kontingentzähler an eine Anwendung zurückzugeben oder aus anderen Gründen.

Da der Zugriff auf die Ablaufvariablen für die Richtlinie auf dem Attribut name der Richtlinie basiert, greifen Sie für die oben genannte Richtlinie <LLMTokenQuota> auf ihre Ablaufvariablen in folgender Form 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 Ablaufvariablen, auf die Sie zugreifen können, wie unten beschrieben.

Sie können beispielsweise die folgende AssignMessage-Richtlinie verwenden, um die Werte der LLMTokenQuota-Ablaufvariablen 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, nutzen 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>

Erstes Beispiel für eine 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 eine 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>

Mit diesem Beispielcode können Sie ein Kontingent von 10.000 Tokens pro Stunde 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 um 2025-07-08 07:35:28 eingeht und die Tokenanzahl vor 2025-07-08 08:00:00 10.000 erreicht, werden Anfragen, die darüber hinaus Token verbrauchen, abgelehnt, bis die Anzahl 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 ihn beispielsweise im Proxy PreFlow platzieren, damit er 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>

Standardmäßig wird in einer LLMTokenQuota-Richtlinie ein einzelner Zähler für den API-Proxy definiert, unabhängig vom Ursprung einer Anfrage. Alternativ können Sie das Attribut <Identifier> mit einer LLMTokenQuota-Richtlinie 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 zum Validieren des API-Schlüssels oder die OAuthV2-Richtlinien mit OAuth-Tokens verwenden, können Sie Informationen im API-Schlüssel oder Token verwenden, um individuelle 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 jetzt 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 Richtlinie LLMTokenQuota.

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 dynamisch zählen – API-Produkt, Entwickler und App

In diesem Beispiel wird gezeigt, wie Sie dynamische Kontingentvariablen mithilfe 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 Sie Kontingente mit API-Produkt, Entwickler und App erzwingen.

<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 Tokenkontingentzählung:

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

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 sich einige Elementkombinationen gegenseitig ausschließen oder nicht erforderlich sind. Beispiele für die spezifische Verwendung finden Sie in den Beispielen.

Die folgenden verifyapikey.my-verify-key-policy.apiproduct.*-Variablen sind standardmäßig verfügbar, wenn eine VerifyAPIKey-Richtlinie mit dem Namen 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 für das API-Produkt, 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',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>

Die folgenden Attribute sind spezifisch für diese Richtlinie:

Attribut Beschreibung Standard Präsenz
type

Legt den LLMTokenQuota-Richtlinientyp 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 diesen Grenzwert 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

Wird verwendet, um eine Tokenanzahl für das Kontingent anzugeben.

Wenn Sie beispielsweise für das Attribut count den Attributwert „100“, für Interval den Wert „1“ und für TimeUnit den Wert „month“ angeben, beträgt das Kontingent 100 Tokens pro Monat.

 2000 Optional
countRef

Gibt eine Ablaufvariable an, die die Tokenanzahl 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 verwaltet 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, auf die das Attribut ref in der Richtlinie verweist, nicht auflösen kann.

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 ersetzt ihn durch den Standardwert, falls vorhanden, oder durch einen leeren String.

Wenn <IgnoreUnresolvedVariables> den Wert false hat 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 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 verarbeitet werden sollen, bevor der Kontingentzähler synchronisiert wird.

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

Im folgenden Beispiel wird gezeigt, wie die Quelle für die Tokennutzung angegeben wird:

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

Wenn die Richtlinie Teil eines Ereignisflusses ist, der einen SSE-Stream (Server-Sent Events) verarbeitet, wird die Tokennutzung aus den Daten des aktuellen Ereignisses und nicht aus dem vollständigen Antwortinhalt extrahiert. Verwenden Sie response.event.current.data als Quelle und setzen Sie das dritte Argument der Funktion jsonPath (want-array) auf false, damit der Wert für die Nutzung eines einzelnen Tokens anstelle eines Arrays zurückgegeben wird. Weitere Informationen zu diesem Argument finden Sie unter JSON-Pfadfunktion. Das folgende Beispiel zeigt die SSE-Konfiguration:

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

<LLMModelSource>

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

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

Im folgenden Beispiel wird gezeigt, wie Sie die Modellquelle aus der Anfrage angeben:

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

Wenn die Richtlinie Teil eines Ereignisablaufs ist, der einen SSE-Stream (Server-Sent Events) verarbeitet, wird der Modellname aus den Daten des aktuellen Ereignisses und nicht aus dem vollständigen Antwortinhalt extrahiert. Verwenden Sie response.event.current.data als Quelle und setzen Sie das dritte Argument der Funktion jsonPath (want-array) auf false, damit der einzelne Modellname und kein Array zurückgegeben wird. Weitere Informationen zu diesem Argument finden Sie unter JSON-Pfadfunktion. Das folgende Beispiel zeigt die SSE-Konfiguration:

<LLMModelSource>{jsonPath('$.modelVersion',response.event.current.data,false)}</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 Tokenanzahlen 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 Ablaufvariable 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 Tokenanzahl zugewiesen wird.

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 das <UseQuotaConfigInAPIProduct>-Element der LLMTokenQuota-Richtlinie 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 Products API) als auch in der LLMTokenQuota-Richtlinie zu definieren. In diesem Fall haben jedoch die Einstellungen für das API-Produkt Vorrang und die Einstellungen für die 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>

Kennzeichnet diese LLMTokenQuota-Richtlinie als freigegeben. Alle LLMTokenQuota-Richtlinien in einem API-Proxy mit demselben <SharedName>-Wert verwenden 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 verfolgen, ohne einen Fehler an den Client zurückzusenden, wenn das Tokenkontingent ü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 mit diesem Element, das auf true gesetzt ist, im Anfrageablauf eines API-Proxy, um ein Tokenlimit durchzusetzen, ohne den Kontingentzähler zu erhöhen. Wenn dieses Element vorhanden ist, muss auch <SharedName> vorhanden sein und das Element <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 in der 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, die bestimmt, wann das Kontingent abläuft und wann das neue Kontingentintervall beginnt.

Wenn der Typ der LLMTokenQuota-Richtlinie rollingwindow ist, ist dieser Wert nicht gültig, da das Kontingentintervall nie 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 über alle Kontingentintervalle hinweg überschreiten. Dies 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