Richtlinien zur Ratenbegrenzung im Vergleich

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Wichtiger Hinweis:

Die Richtlinien Kontingent, SpikeArrest, PromptTokenLimit und LLMTokenQuota werden alle für die Ratenbegrenzung verwendet, dienen aber unterschiedlichen Zwecken und basieren auf unterschiedlichen Messwerten. Während sich „Kontingent“ und „SpikeArrest“ auf die Anzahl der Anfragen konzentrieren, verwalten und steuern die Richtlinien „PromptTokenLimit“ und „LLMTokenQuota“ die Nutzung basierend auf Tokens. Dies ist für KI- und LLM-Arbeitslasten (Large Language Model) von entscheidender Bedeutung.

SpikeArrest und PromptTokenLimit sorgen zwar für eine hohe Zuverlässigkeit, sind aber für die Verwendung eines Redis-Best-Effort-Caches vorgesehen, mit dem die Zählungen gespeichert werden. Da der Cache nicht repliziert wird, kann es vorkommen, dass Zählungen verloren gehen, z. B. bei einem Neustart der Cache-Server oder in anderen seltenen Fällen.

Aus diesem Grund empfehlen wir die Verwendung von SpikeArrest oder PromptTokenLimit für Anwendungsfälle, die eine genaue Zählung erfordern. Nur die synchrone Kontingentrichtlinie (Quota oder LLMTokenQuota) bietet eine genaue Zählung für alle Regionen in einem bestimmten Zeitraum.

Verwenden Sie die Vergleichstabelle unten, um zu entscheiden, welche Richtlinie für Ihren Ratenbegrenzungs-Anwendungsfall verwendet werden soll:

	Kontingent	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Anwendungsbeispiele:	Begrenzen Sie die Anzahl der API-Proxy-Aufrufe, die eine Entwickler-App oder ein Entwickler in einem bestimmten Zeitraum durchführen kann. Sie eignet sich am besten für die Ratenbegrenzung über längere Zeitintervalle wie Tage, Wochen oder Monate, insbesondere wenn eine genaue Zählung erforderlich ist.	Die Anzahl der API-Aufrufe begrenzen, die über einen kurzen Zeitraum (z. B. Sekunden oder Minuten) für alle Nutzer ausgeführt werden können.	Gesamt-Tokenverbrauch für LLM-API-Aufrufe über einen bestimmten Zeitraum (Minute, Stunde, Tag, Woche oder Monat) verwalten und begrenzen. So können Sie die Ausgaben für LLMs kontrollieren und eine detaillierte Kontingentverwaltung basierend auf API-Produkten anwenden.	Das Ziel-Back-End Ihres API-Proxy vor Tokenmissbrauch, massiven Prompts und potenziellen Denial-of-Service-Angriffen schützen, indem Sie die Rate der im Input gesendeten Tokens begrenzen. Dazu drosseln Sie Anfragen basierend auf der Anzahl der Tokens in der Prompt-Nachricht des Nutzers. Es ist ein vergleichbares Paradigma zu Spike Arrest für API-Traffic, aber für Tokens.
Nicht geeignete Einsatzzwecke:	Das Ziel-Back-End Ihres API-Proxy vor Trafficspitzen schützen. Verwenden Sie dazu SpikeArrest oder PromptTokenLimit.	Die Anzahl der Verbindungen erfassen und beschränken, die Anwendungen über einen bestimmten Zeitraum zum Ziel-Back-End Ihres API-Proxys herstellen können, insbesondere wenn eine genaue Zählung erforderlich ist.	Das Ziel-Back-End Ihres API-Proxy vor Tokenmissbrauch schützen. Verwenden Sie dazu PromptTokenLimit.	Die Gesamtzahl der für die Abrechnung oder langfristige Kontingentverwaltung verbrauchten Tokens muss genau gezählt und begrenzt werden. Verwenden Sie dazu die LLMTokenQuota-Richtlinie.
Wird eine Anzahl gespeichert?	Ja	Nein	Ja, es werden Zähler geführt, die die Anzahl der von LLM-Antworten verbrauchten Tokens erfassen.	Es werden Tokens gezählt, um ein Ratenlimit zu erzwingen, aber es wird keine dauerhafte, langfristige Anzahl wie bei der LLMTokenQuota-Richtlinie gespeichert.
Best Practices zum Anhängen der Richtlinie:	Hängen Sie sie an den ProxyEndpoint Request PreFlow an, normalerweise nach der Authentifizierung des Nutzers. Dadurch kann die Richtlinie den Kontingentzähler am Einstiegspunkt Ihres API-Proxy prüfen.	Hängen Sie sie an den ProxyEndpoint Request PreFlow an, normalerweise ganz am Anfang des Ablaufs. Dies ermöglicht einen Schutz vor Spitzen am Einstiegspunkt Ihres API-Proxys. Wenn Sie sowohl SpikeArrest- als auch Kontingentrichtlinien im selben Proxy verwenden, sollte SpikeArrest immer vor der Kontingentrichtlinie im ProxyEndpoint-Request-PreFlow angehängt werden. SpikeArrest dient als erste Verteidigungslinie gegen plötzliche Trafficspitzen. Der Traffic wird geglättet, bevor Anfragen anhand von langfristigen Kontingentlimits ausgewertet werden. So wird verhindert, dass das Kontingent durch Spitzen vorzeitig erschöpft wird.	Wenden Sie die Erzwingungsrichtlinie (EnforceOnly) im Anfrageablauf und die Zählrichtlinie (CountOnly) im Antwortablauf an. Hängen Sie für Streamingantworten die Zählrichtlinie an einen EventFlow an.	Hängen Sie sie an den ProxyEndpoint Request PreFlow an, am Anfang des Ablaufs, um Ihr Backend vor zu großen Prompts zu schützen. Wenn Sie sowohl die PromptTokenLimit- als auch die LLMTokenQuota-Richtlinie im selben Proxy verwenden, sollte PromptTokenLimit immer vor der LLMTokenQuota-Richtlinie im ProxyEndpoint Request PreFlow angehängt werden. „PromptTokenLimit“ dient als erste Verteidigungslinie gegen zu große Prompts. Sie werden abgelehnt, bevor Anfragen anhand der langfristigen „LLMTokenQuota“-Grenzwerte ausgewertet werden. So wird verhindert, dass das Tokenkontingent durch zu große Prompts vorzeitig aufgebraucht wird.
HTTP-Statuscode bei Erreichen des Limits:	429 (Zu viele Anfragen)	429 (Zu viele Anfragen)	429 (Zu viele Anfragen)	429 (Zu viele Anfragen)
Gut zu wissen:	Der Kontingentzähler wird in Cassandra gespeichert. Sie können die Richtlinie so konfigurieren, dass der Zähler asynchron synchronisiert wird, um Ressourcen zu sparen. Dadurch werden eventuell etwas mehr Aufrufe als das festgelegte Limit zugelassen.	Hier können Sie zwischen einem Glättungs-Algorithmus und einem Maximalwert-Algorithmus wählen. Der erstere glättet die Anzahl der Anfragen, die in einem bestimmten Zeitraum auftreten können, und beim letzteren wird die Gesamtzahl der Anfragen begrenzt, die in einem bestimmten Zeitraum auftreten können, unabhängig davon, wie schnell sie nacheinander gesendet werden. Die Glättung wird nicht über die Message Processors koordiniert.	Kann als CountOnly konfiguriert werden, um die Tokennutzung zu erfassen, oder als EnforceOnly, um Anfragen abzulehnen, die das Kontingent überschreiten. Sie funktioniert mit API-Produkten und ermöglicht detaillierte Kontingentkonfigurationen basierend auf der App, dem Entwickler, dem Modell oder einer bestimmten LLM-Vorgangsmenge. Verwendet <LLMTokenUsageSource>, um die Anzahl der Tokens aus der LLM-Antwort zu extrahieren, und <LLMModelSource>, um das verwendete Modell zu identifizieren.	Die Tokenberechnung kann sich geringfügig von der des LLM unterscheiden. Das <UserPromptSource>-Element gibt die Position des Nutzer-Prompts in der Anfragenachricht an.
Weitere Informationen	Kontingentrichtlinie	SpikeArrest-Richtlinie	LLMTokenQuota-Richtlinie	PromptTokenLimit-Richtlinie

Tipp:Sie können auch die folgenden Methoden verwenden, um langsame/träge Back-Ends zu schützen, ohne die Leistung der APIs zu beeinträchtigen:

• Wiederverwendbare freigegebene Abläufe erstellen:Kombinieren Sie Richtlinien und Ressourcen zu einem freigegebenen Ablauf, den Sie über mehrere API-Proxys und sogar über andere freigegebene Abläufe nutzen können.
• API-Proxys verketten: Sie können angeben, dass ein Proxy der Zielendpunkt eines anderen sein soll, wodurch die beiden Proxys in einer Proxykette miteinander verbunden werden. Durch diese Art der Verkettung von Proxys können Sie einen Netzwerk-Hop vermeiden und so die Gesamtleistung verbessern.