Meilleures pratiques en matière de limites de débit

Créez plusieurs limites de débit avec la même clé de dimension ($.context.jwt.subou$.context.jwt.tier) mais des entrées différentes pour chaque niveau. Utilisez des entrées exactes pour les utilisateurs premium connus et une * entrée comme niveau par défaut.

Limites de débit de couche à plusieurs granularités. Par exemple, combinez une limite de RPS par cible (protège la capacité du backend) avec une limite de RPS par appelant (empêche les abus individuels) et une limite de jeton par outil (contrôle des coûts).

Utilisez-le BatchPutGatewayRateLimits pour gérer de manière déclarative la configuration de votre limite de débit. Batch put utilise une sémantique ascendante, ce qui permet de l'exécuter à plusieurs reprises en toute sécurité à partir de CI/CD pipelines ou de modèles d'infrastructure.

Commencez par des limites tarifaires généreuses et resserrez-les au fil du temps en fonction des tendances de trafic observées. Surveillez l'attribut d'étendue aws.agentcore.gateway.throttle.customer.decision OTEL et les taux de réponse de 429 avant de réduire les limites.

Utilisez des rate: 0 entrées pour bloquer des appelants, des cibles ou des outils spécifiques lors d'un incident. Le blocage prend effet une fois la propagation terminée (30 secondes maximum).

La passerelle utilise un modèle d'exécution basé sur le budget. Lorsqu'une demande arrive, la passerelle estime le nombre de jetons d'entrée et réserve ce montant à partir de votre budget TPM configuré. Si l'estimation dépasse le budget restant, la demande est rejetée avec une réponse HTTP 429 avant d'atteindre le modèle. Une fois la demande terminée, la passerelle réconcilie le budget en remplaçant l'estimation initiale par l'utilisation réelle des jetons (jetons d'entrée + jetons de sortie) signalée par le fournisseur du modèle.

La passerelle prend en compte les jetons en fonction des output_tokens valeurs input_tokens et que le fournisseur de modèle renvoie dans la réponse d'inférence. La passerelle n'effectue pas le suivi ou ne s'ajuste pas de manière indépendante pour une mise en cache rapide. L'inclusion des jetons mis en cache input_tokens dépend de la manière dont votre fournisseur de modèles signale l'utilisation. Ce comportement varie d'un fournisseur à l'autre. Consultez la documentation de votre fournisseur de modèles pour comprendre comment la mise en cache rapide affecte le nombre de jetons signalés et votre consommation effective de TPM.

Oui. La passerelle évalue l'estimation du tokenizer par rapport au budget TPM restant avant de transmettre la demande. Si l'estimation dépasse le budget disponible, la demande est rejetée avec une réponse HTTP 429. La réponse inclut un retryAfter champ indiquant quand un budget suffisant sera disponible.

Non Une fois que la passerelle accepte et transmet une demande, la réponse est toujours fournie dans son intégralité. La passerelle réserve des jetons estimés au moment de la demande, et les autres demandes continuent d'être évaluées par rapport au budget restant pendant que la demande est en cours de traitement. Une fois la réponse terminée, la passerelle concilie l'utilisation réelle avec l'estimation. Si la consommation réelle était plus élevée, le budget est ajusté, ce qui peut entraîner une limitation des demandes ultérieures, mais la réponse initiale n'est jamais interrompue.

La passerelle utilise le segment de réponse final comme source de vérité pour la réconciliation des jetons. Les fournisseurs de modèles ne signalent pas tous l'utilisation de jetons dans chaque segment diffusé en streaming ; certains ne l'incluent que dans le dernier segment. La passerelle attend la réponse complète avant de réconcilier le budget du TPM. Pour le streaming OpenAI Chat Completions, la passerelle ajoute automatiquement "stream_options": {"include_usage": true} au corps de la requête lorsqu'une limite de débit de jetons est active et que cette option n'est pas déjà présente, garantissant ainsi un nombre précis de jetons disponibles dans le dernier segment.

Les modifications des limites de débit peuvent prendre jusqu'à 30 secondes pour se propager. Prévoyez ce délai en cas d'incident : une entrée bloquée (rate: 0) n'est pas immédiate.

Un taux de 0 bloque tout le trafic correspondant. Utilisez-le délibérément pour un blocage d'urgence. Double-check valeurs de dimension d'entrée avant le réglage rate: 0 pour éviter de bloquer accidentellement le trafic légitime.

Vous ne pouvez pas modifier dimensionKeys la limite de débit existante. Si vous avez besoin de dimensions différentes, supprimez la limite de débit existante et créez-en une nouvelle. Planifiez votre structure de clés dimensionnelles avant de créer des limites de cadence de production.