Comparer les règles de limitation du débit

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Point essentiel :

Les règles Quota, SpikeArrest, PromptTokenLimit et LLMTokenQuota sont toutes utilisées pour limitation du débit, mais elles ont des objectifs différents et fonctionnent sur des métriques différentes. Alors que les règles Quota et SpikeArrest se concentrent sur le nombre de requêtes, les règles PromptTokenLimit et LLMTokenQuota gèrent et contrôlent la consommation en fonction des jetons, ce qui est essentiel pour les charges de travail d'IA et de grands modèles de langage (LLM).

Bien que SpikeArrest et PromptTokenLimit gèrent les décomptes avec une haute fiabilité, ils sont conçus pour utiliser un cache Redis optimisé pour stocker les décomptes. Comme le cache n'est pas répliqué, il peut arriver que les décomptes soient perdus, par exemple en cas de redémarrage des serveurs de cache ou d'autres événements rares.

Pour ces raisons, nous vous déconseillons d'utiliser SpikeArrest ou PromptTokenLimit pour les cas d'utilisation nécessitant un comptage précis. Seules les règles de quota ou LLMTokenQuota synchrones offrent un décompte précis dans toutes les régions pour une période donnée.

Le tableau comparatif ci-dessous vous aidera à déterminer la règle à utiliser pour votre cas d'utilisation de limitation du débit :

	Quota	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Utilisez-le pour :	Limiter le nombre d'appels de proxy d'API qu'un développeur ou une application peut effectuer sur une période spécifique. Elle est idéale pour limitation du débit sur des intervalles de temps plus longs (jours, semaines ou mois, par exemple), en particulier lorsque le comptage précis est requis.	Limiter le nombre d'appels d'API pouvant être effectués sur un même proxy d'API par l'ensemble des clients sur une courte période, par exemple en secondes ou en minutes.	Gérez et limitez la consommation totale de jetons pour les appels d'API LLM sur une période spécifiée (minute, heure, jour, semaine ou mois). Cela vous permet de contrôler les dépenses liées aux LLM et d'appliquer une gestion précise des quotas en fonction des produits d'API.	Protégez le backend cible de votre proxy d'API contre l'utilisation abusive de jetons, les requêtes massives et les tentatives potentielles de déni de service en limitant le nombre de jetons envoyés dans l'entrée. Pour ce faire, limitez les requêtes en fonction du nombre de jetons dans le message de requête de l'utilisateur. Il s'agit d'un paradigme comparatif à SpikeArrest pour le trafic d'API, mais pour les jetons.
Ne l'utilisez pas pour :	Protégez le backend cible de votre proxy d'API contre les pics de trafic. Utilisez SpikeArrest ou PromptTokenLimit pour cela.	Compter et limiter le nombre de connexions que les applications peuvent établir avec le backend cible de votre proxy d'API sur une période donnée, en particulier lorsque le comptage précis est requis.	Protégez le backend cible de votre proxy d'API contre l'utilisation abusive de jetons. Pour cela, utilisez PromptTokenLimit.	Comptez et limitez précisément le nombre total de jetons consommés pour la facturation ou la gestion des quotas à long terme. Pour cela, utilisez la règle LLMTokenQuota.
Stocke un décompte ?	Oui	Non	Oui, il gère des compteurs qui suivent le nombre de jetons consommés par les réponses du LLM.	Il comptabilise les jetons pour appliquer une limite de fréquence, mais ne stocke pas de nombre persistant à long terme comme la règle LLMTokenQuota.
Bonnes pratiques pour associer la règle :	Associez-la au PreFlow de requête ProxyEndpoint, généralement après l'authentification de l'utilisateur. Cela permet à la règle de vérifier le compteur de quotas au niveau du point d'entrée du proxy d'API.	Associez-la au PreFlow de requête ProxyEndpoint, généralement au tout début du flux. Cela offre une protection contre les pics au niveau du point d'entrée du proxy d'API. Si vous utilisez à la fois des règles SpikeArrest et de quota dans le même proxy, SpikeArrest doit toujours être associé avant la règle de quota dans le PreFlow de la requête ProxyEndpoint. SpikeArrest sert de première ligne de défense contre les pics de trafic soudains. Il permet de lisser le trafic avant que les requêtes ne soient évaluées par rapport aux limites de quota à long terme. Cela empêche les pics d'épuiser prématurément le quota.	Appliquez la règle d'application (EnforceOnly) dans le flux de requête et la règle de comptabilisation (CountOnly) dans le flux de réponse. Pour les réponses dynamiques, associez la règle de comptage à un EventFlow.	Associez-la au PreFlow de requête ProxyEndpoint, au début du flux, pour protéger votre backend contre les requêtes surdimensionnées. Si vous utilisez les règles PromptTokenLimit et LLMTokenQuota dans le même proxy, PromptTokenLimit doit toujours être associé avant la règle LLMTokenQuota dans le préflux de la requête ProxyEndpoint. PromptTokenLimit sert de première ligne de défense contre les requêtes trop volumineuses, en les refusant avant que les requêtes ne soient évaluées par rapport aux limites de quota LLMTokenQuota à long terme. Cela empêche les requêtes surdimensionnées d'épuiser prématurément le quota de jetons.
Code d'état HTTP une fois la limite atteinte :	429 (Trop de demandes)	429 (Trop de demandes)	429 (Trop de demandes)	429 (Trop de demandes)
Bon à savoir :	Le compteur de quota est stocké dans Cassandra. Vous pouvez configurer la règle afin de synchroniser le compteur de manière asynchrone pour enregistrer des ressources, mais cela peut autoriser un nombre d'appels légèrement supérieur à la limite.	Vous permet de choisir entre un algorithme à lissage et un algorithme de comptage efficace. Le premier lisse le nombre de requêtes pouvant survenir au cours d'une période spécifiée et le second limite le nombre total de requêtes pouvant être effectuées au cours d'une période spécifiée, indifféremment de la rapidité à laquelle elles sont envoyées. Le lissage n'est pas coordonné entre les processeurs de messages.	Peut être configuré sur CountOnly pour suivre l'utilisation des jetons ou sur EnforceOnly pour refuser les requêtes qui dépassent le quota. Il fonctionne avec les produits d'API pour permettre des configurations de quota précises en fonction de l'application, du développeur, du modèle ou d'un ensemble d'opérations LLM spécifiques. Utilise <LLMTokenUsageSource> pour extraire le nombre de jetons de la réponse du LLM et <LLMModelSource> pour identifier le modèle utilisé.	Le calcul des jetons peut différer légèrement de celui utilisé par le LLM. L'élément <UserPromptSource> spécifie l'emplacement du prompt utilisateur dans le message de la requête.
En savoir plus :	Règles relatives aux quotas	Règle SpikeArrest	Règle LLMTokenQuota	Règle PromptTokenLimit

Conseil : Vous pouvez également utiliser les éléments suivants pour protéger les backends lents sans affecter les performances des API :

• Créer des flux partagés réutilisables : combinez des règles et des ressources en un flux partagé que vous pouvez utiliser à partir de plusieurs proxys d'API et même d'autres flux partagés.
• Chaînage des proxys d'API : spécifiez qu'un proxy est le point de terminaison cible d'un autre proxy, en connectant efficacement les deux proxys dans une chaîne de proxy. L'association de proxys en chaîne permet d'éviter les sauts de réseau et donc d'améliorer les performances globales.