Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Application des limites tarifaires
Cette rubrique décrit la manière dont la passerelle évalue et applique les limites de débit lors de l'exécution, notamment l'interaction avec d'autres fonctionnalités de la passerelle, les formats de réponse limités et l'observabilité.
Interaction avec les règles de passerelle
La passerelle évalue les limites de débit avant les règles de la passerelle. Si une limite de débit limite une demande, celle-ci n'atteint jamais la phase d'évaluation des règles.
Sémantique d'empilement
Lorsque plusieurs limites de débit s'appliquent à une demande, la passerelle utilise la logique ET : toutes les limites de débit doivent être dépassées pour que la demande soit traitée. Si une limite de débit unique refuse la demande, la passerelle la limite.
Correspondance et spécificité des entrées
Lorsqu'une limite de débit comporte plusieurs entrées, la passerelle sélectionne l'entrée correspondante la plus spécifique pour les valeurs de dimension résolues :
-
Une correspondance de valeur exacte a priorité sur une
*entrée. -
La
*valeur signifie « appliquer ce taux à toutes les valeurs de cette dimension ». Il s'agit d'une entrée par défaut. -
Pour les limites de débit multidimensionnelles, la passerelle utilise une solution de repli progressive : elle tente d'abord une correspondance exacte complète, puis remplace les dimensions de fin par
*une à la fois jusqu'à ce qu'une correspondance soit trouvée.
L'exemple suivant montre comment les entrées sont mises en correspondance pour une limite de débit avec le dimensionKeys: ["targetName", "toolName"] moment où les valeurs résolues sont ["my-target", "readData"] :
| Dimensions d'entrée | Des allumettes ? | Pourquoi |
|---|---|---|
|
|
Oui (coché en premier) |
Correspondance exacte sur les deux dimensions. C'est très précis. |
|
|
Oui (coché en deuxième position) |
Correspondance exacte sur la première dimension, |
|
|
Oui (coché en dernier) |
Entrée par défaut. Le moins spécifique. |
La première inscription correspondante gagne. Si aucune entrée ne correspond (et qu'aucune * valeur par défaut n'existe), la limite de débit est ignorée pour cette demande.
Ordre d’évaluation
La passerelle évalue les limites de débit dans l'ordre suivant :
-
La passerelle évalue d'abord les limites de débit avec un plus grand nombre de clés de dimension (les limites plus spécifiques sont prioritaires).
-
Dans le même nombre de dimensions, la passerelle évalue d'abord les limites de débit avec des taux plus serrés (inférieurs).
-
Courts-circuits d'évaluation lors du premier refus : la passerelle n'évalue pas les limites de débit restantes.
Interaction avec les limites gérées par les services
La passerelle applique à la fois les limites de débit définies par le client et les limites gérées par le service. Le tarif effectif pour toute demande est le minimum des deux :
-
La passerelle évalue d'abord les limites de débit définies par le client.
-
Si la demande dépasse les limites du client, les limites gérées par le service sont évaluées.
-
Un refus de la part de l'une ou l'autre des sources entraîne une limitation.
Réponses limitées
Lorsqu'une demande est limitée, la passerelle renvoie une réponse d'erreur spécifique au protocole contenant la retryAfter valeur dans le corps de la réponse.
Protocole HTTP :
{ "error": "Rate limit exceeded", "success": false, "limitKey": "rl-abc123/targetName=my-target", "metric": "requests", "retryAfter": 1 }
Protocole MCP (JSON-RPC) :
{ "jsonrpc": "2.0", "id": "request-1", "error": { "code": -32003, "message": "Rate limit exceeded", "data": { "limitKey": "rl-abc123/targetName=my-target", "metric": "requests", "retryAfter": 1 } } }
OpenAI-compatible protocole :
{ "error": { "message": "Rate limit exceeded", "type": "rate_limit_error", "code": "429", "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet", "metric": "tokens", "retryAfter": 60 } }
Anthropic-compatible protocole :
{ "type": "error", "error": { "type": "rate_limit_error", "message": "Rate limit exceeded", "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet", "metric": "tokens", "retryAfter": 60 } }
Le retryAfter champ indique combien de secondes l'appelant doit attendre avant de réessayer. Utilisez cette valeur directement dans votre logique de nouvelle tentative côté client.
Délai de propagation
Les modifications des limites de débit (création, mise à jour, suppression) se propagent au plan de données dans les 30 secondes. Pendant la propagation :
-
Les nouvelles limites de débit ne sont pas appliquées tant que la propagation n'est pas terminée.
-
Les limites de débit mises à jour continuent d'appliquer la configuration précédente jusqu'à ce que la mise à jour se propage.
-
Les limites de débit supprimées continuent de s'appliquer jusqu'à ce que la suppression se propage.
Exactitude de l'application et cohérence éventuelle
L'application des limites tarifaires est finalement cohérente plutôt qu'exacte. La précision de l'application est approximative dans les instants qui suivent le début du trafic d'une limite, et elle s'améliore au fur et à mesure que le trafic se poursuit. La précision que vous observez dépend donc de la structure de votre trafic.
Les comportements suivants sont attendus :
-
Les limites de froid sont trop admises au début. Une limite froide est une limite qui vient d'être créée ou qui n'a connu aucun trafic récent. Pendant une courte période initiale, la passerelle peut suradmettre (autoriser un plus grand nombre de demandes que le débit configuré) avant que l'application ne converge. Lorsqu'une limite est soumise à un trafic continu, la précision s'améliore et le taux d'accélération observé se rapproche du taux configuré.
-
Le trafic soutenu est appliqué avec précision, mais les courtes rafales peuvent ne pas l'être. Une brève rafale dépassant une limite de froid peut passer sans être étranglée. Le même débit envoyé que le trafic soutenu est appliqué, car la précision s'améliore à mesure qu'une limite s'échauffe. Pour observer ou démontrer l'application de la loi, envoyez le trafic soutenu à la limite pendant plusieurs minutes plutôt qu'une seule courte rafale. Par exemple, pour une limite de 4 requêtes par seconde, la passerelle risque de ne pas limiter la 5e requête au cours de la première seconde. Si vous envoyez 5 demandes par seconde en continu, les demandes supplémentaires seront constamment limitées une fois la limite atteinte.
-
Les taux très bas sont moins précis. Les taux inférieurs à environ 1 demande par seconde (par exemple, une petite limite de demandes par minute) sont plus difficiles à appliquer avec précision et seront plus variables. Préférez des taux plus élevés lorsqu'une application précise est importante, et considérez les limites très basses comme approximatives.
-
Les limites des jetons convergent plus lentement. Token-per-minute les limites mettent à jour (réconcilient) le total d'utilisation suivi uniquement une fois que le modèle a répondu. Une demande qui est en cours pendant plusieurs secondes ou minutes n'est comptabilisée que dans le budget prévu jusqu'à ce qu'elle soit traitée. Cela prolonge la fenêtre pendant laquelle la passerelle peut suradmettre les demandes, par rapport aux limites de demandes. Consultez la FAQ sur la limite de débit des jetons pour plus de détails.
Concevez vos limites en fonction d'une utilisation équitable et de la protection du backend. Cela signifie lisser les rafales et protéger les cibles des voisins bruyants pendant une période prolongée, plutôt que de bloquer un numéro de requête exact dès qu'un seuil est franchi. Les limites tarifaires ne constituent pas une porte précise et précise en fonction de la demande. Les limites de débit ne constituent pas non plus une limite de sécurité, comme expliqué dans la section suivante.
Fail-open comportement
La passerelle utilise une sémantique d'ouverture automatique pour l'évaluation des limites de débit. Le tableau suivant décrit le comportement lorsque le système de limitation de débit rencontre des erreurs :
| Scénario | Décision | Justification |
|---|---|---|
|
Délai d'expiration du service de limite de débit |
Allow |
La disponibilité prime sur l'application. |
|
Clé de dimension impossible à résoudre à partir de la demande |
Ignorer (autoriser) |
La limite de débit ne s'applique pas à ce type de demande. |
|
Échec de l'actualisation du cache de la limite |
Réessayez avec des données périmées |
La dernière configuration connue est utilisée jusqu'à la restauration du cache. |
Important
En raison du comportement d'ouverture automatique, ne vous fiez pas uniquement aux limites de débit comme limite de sécurité. Utilisez des limites de débit pour la gestion du trafic et la qualité de service, et utilisez les règles d'authentification, d'autorisation et de WAF pour renforcer la sécurité.
Traçage à l'aide de OpenTelemetry spans
La passerelle émet des attributs d'étendue OpenTelemetry (OTEL) sur l'étendue du serveur pour chaque demande pour laquelle les limites de débit des clients sont évaluées. Utilisez ces attributs pour le débogage et la surveillance.
| Attribut | Description | Exemple |
|---|---|---|
|
|
La décision d'exécution concernant cette demande. |
|
|
|
La limite |
|
|
|
Type de métrique épuisé. Présent uniquement lorsque la décision est prise |
|
|
|
Comma-separated valeurs dimensionnelles résolues de l'entrée qui a déclenché l'accélérateur. Présent uniquement lorsque la décision est prise |
|
|
|
Liste ordonnée de toutes les tranches de limites de débit vérifiées pour cette demande. Chaque entrée indique l'ID de limite de débit, la métrique et les valeurs de dimension résolues. Présent pour les deux |
|
evaluatedCet attribut est utile pour comprendre quelles limites de débit s'appliquent à une demande, même lorsqu'elle était autorisée. Chaque entrée de la liste suit le format{rateLimitId}:{metric}:{resolvedDimVal1,dimVal2,…}.
