Limitation de débit des agents IA : Prévenir l'épuisement de l'API LLM

« Quota d'API épuisé en 20 minutes » n'est pas une histoire mythique d'ingénieur SRE ; c'est un mardi après-midi avec une boucle mal délimitée. Des seaux de jetons, des disjoncteurs et une chaîne de secours élégante — tous appliqués au niveau de la passerelle avant que la boucle n'atteigne un fournisseur.

Le 429 n'est pas un crash. C'est la passerelle qui dit à un agent incontrôlé de faire marche arrière. L'agent obéit, le disjoncteur tient, le budget survit à la journée.

La boucle incontrôlée est le mode de défaillance par défaut

Les agents LLM échouent d'une manière spécifique. L'incident de production le plus courant n'est pas un modèle qui donne une mauvaise réponse ; c'est un agent qui décide de réessayer, et de réessayer, et de réessayer, et de réessayer. Chaque nouvelle tentative est un appel complet au fournisseur. Chaque appel ajoute au contexte. Le contexte croît de manière quadratique. Les jetons sont consommés à un rythme qu'un humain devant son clavier ne produirait jamais — car il n'y a pas d'humain devant le clavier.

L'arithmétique est brutale. Un contexte initial de 4 000 jetons, doublant à chaque étape car la sortie de l'étape précédente est ajoutée, atteint 128 000 jetons à l'étape 5 et le coût par étape a été multiplié par 32. À l'étape 15, le contexte a dépassé la fenêtre du modèle et chaque appel paie le tarif du contexte maximal. À l'étape 30, la boucle a dépensé plus que le salaire mensuel d'un ingénieur compétent. L'agent ne l'a jamais remarqué ; le travail de l'agent est de continuer.

La première fois que la plupart des équipes voient cela, elles le voient sur la facture du lendemain. La deuxième fois, elles mettent en place une limitation de débit. Le bon endroit pour cette limitation de débit n'est pas l'application, c'est la passerelle, où une seule couche protège chaque charge de travail, quel que soit le framework qui a lancé la boucle. Une équipe qui place la limite à l'intérieur de chaque agent doit la réécrire pour chaque agent, l'oublier dans certains cas et découvrir les modes de défaillance individuellement. Une équipe qui la place au niveau de la passerelle l'écrit une seule fois et hérite de la protection pour chaque charge de travail qui appelle un modèle.

Trois couches d'application

Couche 1 — Seau de jetons par identité

Le seau est la première ligne de défense. Chaque tuple (utilisateur, dépôt, modèle) obtient son propre seau — par exemple, 100 requêtes par minute avec une rafale de 200. Les recharges se produisent en continu au rythme configuré. Lorsqu'une requête arrive et que le seau est vide, la passerelle renvoie immédiatement un HTTP 429, avant que la requête n'atteigne le fournisseur. Le 429 contient un Retry-After en-tête indiquant combien de temps l'appelant doit attendre.

Le choix de la granularité est important. Un seul seau par utilisateur est trop grossier — un script malveillant bloque tout le travail légitime de l'utilisateur, y compris le travail dont il a besoin pour déboguer le script malveillant. Un seau par requête est trop fin — il n'y a rien à réguler. Le tuple (utilisateur, dépôt, modèle) est généralement le bon niveau de granularité : il isole le dépôt incontrôlé des autres charges de travail de l'utilisateur, permet à l'équipe plateforme de définir des plafonds différents pour différents niveaux de modèles (plus permissifs sur les modèles bon marché, plus stricts sur les modèles de pointe), et produit des ventilations dimensionnelles utiles dans le tableau de bord de limitation de débit. Certaines équipes ajoutent une quatrième dimension — l'ID de pipeline ou de workflow — pour les produits d'IA multi-locataires où le seau devrait appartenir au client pour lequel la requête est effectuée, et non à l'équipe qui gère le service.

La plupart des frameworks d'agents interprètent le 429 comme un signal de recul standard. L'agent se met en pause, attend la durée suggérée et réessaie — exactement le comportement souhaité par la passerelle. Les frameworks qui ne gèrent pas le 429 correctement sont défectueux d'une autre manière, mais la passerelle a déjà fait son travail. Le contrat est standard HTTP : 429 avec Retry-After est ce que toute bibliothèque cliente HTTP sait gérer depuis quinze ans. Les équipes qui constatent que leur framework d'agent ne peut pas traiter correctement le 429 devraient corriger le framework, et non la passerelle.

La rafale est le paramètre qui est ajusté. Réglez la rafale trop bas et les charges de travail légitimes et en rafale (déclencheurs CI, évaluations par lots, heures de pointe des chatbots pour les utilisateurs) recevront de faux 429 ; réglez-la trop haut et la limitation de débit ne contraint pas réellement un agent incontrôlé. Le bon point de départ est empirique — examinez la forme de rafale naturelle du trafic légitime du mois précédent, définissez la taille du seau à environ la rafale P99 observée, et ajustez à partir de là en fonction des plaintes de faux positifs.

Couche 2 — Disjoncteurs

Les seaux de jetons gèrent le volume. Les disjoncteurs gèrent les schémas. Certains processus incontrôlés passent sous le plafond du seau mais présentent d'autres signes de comportement pathologique — un agent qui respecte le seau de 100 requêtes par minute mais effectue 100 appels identiques par minute dans une boucle serrée est toujours un processus incontrôlé, juste un plus lent. La passerelle surveille le trafic récent de chaque identité et se déclenche lorsque l'une des conditions suivantes est remplie :

• Plus de N erreurs 429 consécutives. L'agent ne se retire pas correctement après son premier 429 — il ne fait que réessayer. Déclenchement pendant 60 secondes avec réouverture exponentielle. C'est le disjoncteur pour les frameworks qui ignorent l'en-tête Retry-After.
• Taux d'erreur supérieur au seuil. Plus de 50 % des requêtes des 60 dernières secondes échouent — erreurs du fournisseur, erreurs de validation de schéma, erreurs de délai d'attente. L'agent fait quelque chose de mal ; pause jusqu'à ce que l'équipe plateforme ou le propriétaire de la charge de travail puisse examiner la situation. Les faux positifs sont rares ici car les charges de travail légitimes n'ont pas de taux d'erreur de 50 % de manière soutenue.
• La vélocité des coûts dépasse le budget prévu × multiplicateur. Le rythme des dépenses est insoutenable. Une charge de travail avec un budget de 50 $/jour ne devrait pas dépenser 5 $/minute ; si c'est le cas, quelque chose ne va pas. Déclenchement avant que le taux ne devienne un chiffre sur la facture. Le seuil est configurable par charge de travail — certaines charges de travail ont des profils de coûts légitimement irréguliers et nécessitent des tolérances plus larges.
• Forme d'appel inhabituelle. Des invites identiques répétées dans une courte fenêtre, des signatures de boucle reconnaissables (le même appel d'outil répété avec les mêmes arguments), des contextes identiques avec des nombres de jetons augmentant de manière monotone. Ces heuristiques détectent les schémas que les limites de débit pures manquent — le processus incontrôlé lent qui reste sous le seau mais est toujours gaspilleur.

Chaque disjoncteur a sa propre logique de déclenchement et de réouverture. L'effet combiné est que les comportements pathologiques sont rapidement arrêtés sans faux positifs sur un trafic légitime et en rafale. Le disjoncteur est configuré au niveau de la plateforme et s'applique à chaque identité ; les seuils sont ajustés au fil du temps en fonction du taux de faux positifs que l'équipe est prête à tolérer.

La vélocité des coûts est le disjoncteur que la plupart des équipes sous-implémentent, car elle exige que la passerelle connaisse le coût de chaque requête en temps réel — jetons d'entrée, jetons de sortie, jetons mis en cache, tarification spécifique au modèle — et l'intègre à la logique du disjoncteur avant que la requête suivante ne soit admise. La passerelle de TrueFoundry calcule le coût par requête à la sortie en utilisant la tarification actuelle du fournisseur et expose le taux de coût courant au disjoncteur comme une entrée de premier ordre. Une charge de travail qui dépasse son taux de coût prévu d'un multiplicateur configurable se déclenche ; le disjoncteur est paramétré par rapport au budget de la charge de travail plutôt que par rapport à un montant absolu en dollars, ce qui rend le seuil durable malgré les changements de prix des fournisseurs. Les équipes qui adaptent la vélocité des coûts à une passerelle qui ne connaît pas nativement le coût par requête se retrouvent avec des tables de prix obsolètes et des seuils de disjoncteur nécessitant un recalibrage manuel chaque trimestre ; la version intégrée n'a pas cette surcharge de maintenance.

Couche 3 — Chaîne de secours

Lorsque le chemin principal est indisponible — le seau de jetons est limité, le disjoncteur est ouvert, le fournisseur lui-même subit une panne — faire échouer chaque requête est le mauvais résultat. Une chaîne de secours configurable fournit une sortie dégradée à la place. La chaîne est une configuration déclarative, par route :

# Per-route configuration
fallback_chain:
  - model: "claude-4-6-sonnet"        # primary
  - model: "claude-4-5-haiku"         # cheaper, still capable
  - source: "semantic-cache"          # cached response if similar
  - response: 503                     # last resort, descriptive error

La chaîne est un paramètre de configuration, pas un comportement codé en dur. Différentes routes ont différentes chaînes. Un pipeline de codage peut avoir une chaîne en 2 étapes (Sonnet → Haiku → 503) car un résultat Haiku dégradé est parfois pire qu'un échec clair. Un chatbot destiné aux utilisateurs peut avoir une chaîne en 4 étapes qui inclut le cache sémantique comme solution de secours élégante, car toute réponse est meilleure que pas de réponse pour l'utilisateur. Un flux de travail à enjeux élevés (rédaction juridique, analyse financière) peut n'avoir aucune chaîne de secours — le seul comportement acceptable en cas de défaillance primaire est de signaler l'erreur afin qu'un humain puisse décider.

L'idée est que la plateforme décide ce que signifie "dégradé" pour chaque charge de travail, au lieu que chaque charge de travail décide par elle-même. En pratique, c'est ce qui transforme 90 % des incidents de "capacité épuisée" en incidents "dégradés mais fonctionnels" — visibles par l'équipe plateforme, invisibles pour l'utilisateur final. Le cache sémantique est l'élément sous-utilisé de la chaîne dans la plupart des configurations d'équipes ; une charge de travail avec un taux de succès de cache raisonnable (disons 30 %) survit à la plupart des pannes de courte durée en servant des réponses mises en cache pour des requêtes suffisamment similaires.

Ce que cela représente en termes de coûts

L'argument économique est celui qui permet de financer le projet de limitation de débit. Un seul incident incontrôlé sans application coûte généralement entre 2 000 et 8 000 $ au moment où quelqu'un le remarque ; le même incident avec les trois couches en place coûte entre 20 et 100 $ et produit un post-mortem traitable au lieu d'un e-mail d'excuses aux finances. Le premier incident amortit l'effort d'ingénierie pour construire la couche de limitation de débit cinq à dix fois.

Ce que cela représente pour l'appelant

Le contrat du point de vue de l'appelant est standard HTTP. Les quatre résultats couvrent tous les états que la couche de limitation de débit peut produire, et chacun correspond à une remédiation bien comprise. Le code de l'agent n'a pas besoin de savoir que l'architecture de limitation de débit existe ; il doit savoir comment gérer les codes 429, 503 et l'en-tête d'identification du modèle. Trois lignes de code de gestion des erreurs suffisent pour la plupart des frameworks d'agents.

Ce que cela représente pour l'ingénieur SRE

Les alertes paginables ne se déclenchent que lorsque le disjoncteur se déclenche réellement, et non à chaque 429. Un 429 est normal ; un disjoncteur déclenché est une anomalie. L'ingénieur d'astreinte reçoit une alerte Slack unique et exploitable :

[BREAKER TRIPPED] runaway-agent detection on identity=devops-bot/infra-tf
  trace_id: 7e9d8a1b
  pattern: 110 req/s sustained, repeated identical prompts
  cost velocity: $42/min (planned: $4/min)
  action taken: requests blocked for 5 min, exponential reopen
  suggested mitigation: review pipeline logs at <link>

ID de trace, identité, modèle, coût, atténuation. Tout ce dont l'ingénieur a besoin pour décider s'il doit prolonger le disjoncteur, augmenter le quota ou contacter l'équipe responsable du pipeline incriminé. L'alerte est conçue pour être triée en 30 secondes : 90 % du temps, l'alerte signale une dérive légitime et l'ingénieur prolonge le disjoncteur, publie un message sur le canal de l'équipe incriminée et reprend ses activités. 10 % du temps, il s'agit d'un faux positif (un pic légitime que les seuils n'avaient pas anticipé) et l'ingénieur augmente le quota et ajoute le cas à l'examen d'ajustement des seuils.

Le format de l'alerte est l'artefact opérationnel qui est ajusté plus souvent que les seuils du disjoncteur eux-mêmes. La première version de l'alerte est généralement trop verbeuse (tout le monde veut tout savoir) et est ignorée ; la septième version est celle qui contient exactement les cinq faits dont l'ingénieur a réellement besoin. La discipline consiste à traiter l'alerte comme un produit, l'ingénieur d'astreinte étant l'utilisateur.

Le format d'alerte par défaut de TrueFoundry inclut ces cinq faits (ID de trace, identité, modèle, vitesse de coût, lien profond vers le tableau de bord de la charge de travail) calibrés en fonction des leçons opérationnelles tirées de l'exécution de cette couche de limitation de débit pour les clients existants de la plateforme. Les équipes peuvent remplacer le format par route ; la plupart ne le font pas, car le format par défaut est déjà celui vers lequel elles auraient convergé à la septième itération. La conception structurelle est la contribution — nommer les cinq faits pertinents avec la bonne granularité — et non le schéma YAML qui les contient.

La configuration qui maintient l'ensemble

Les trois couches se combinent pour former une configuration par route dont l'équipe plateforme est propriétaire. Voici à quoi ressemble une configuration fonctionnelle pour une charge de travail agentique CI/CD — le cas canonique où la limitation de débit est la plus importante car le mécanisme de régulation humaine est absent :

name: ci-cd-agent-routing
type: gateway-load-balancing-config

rules:
  - id: ci-agent-primary-route

    when:
      subjects:
        - team:platform
      models:
        - ci-agent

    type: priority-based-routing

    load_balance_targets:

      - target: anthropic/claude-sonnet

        priority: 0

        retry_config:
          attempts: 3
          delay: 200
          on_status_codes: ["429", "500", "503"]

        fallback_status_codes: ["429", "500", "502", "503"]


      - target: anthropic/claude-haiku

        priority: 1

        retry_config:
          attempts: 2
          delay: 100

      - target: cache/semantic-cache

        priority: 2
        fallback_candidate: true

La configuration est l'artefact. Elle est examinée dans les pull requests, gérée par version en parallèle du déploiement de la passerelle, et modifiée lorsque la tolérance de l'équipe change (un nouveau type de charge de travail avec des schémas de rafale différents, un plafond de coût plus strict, une nouvelle option de modèle dans la chaîne de secours). L'équipe plateforme est propriétaire du schéma ; les équipes de charge de travail individuelles peuvent remplacer des champs spécifiques pour leurs routes dans les limites définies par l'équipe plateforme.

Chaque primitive dans le manifeste ci-dessus — les seaux de jetons par identité, les quatre disjoncteurs nommés, la chaîne de secours déclarative, l'alerte au format exploitable — est une primitive de passerelle TrueFoundry plutôt qu'un middleware personnalisé. L'équipe plateforme choisit la granularité, définit les seuils, configure la chaîne ; il n'y a pas de middleware de limitation de débit à construire, tester et maintenir. Les équipes qui ont implémenté les mêmes trois couches au-dessus d'une passerelle sans ces primitives finissent par écrire les mêmes centaines de lignes de middleware Lua ou Python, le même stockage de seaux basé sur Redis, le même formateur d'alertes — et découvrent la plupart des cas limites (conditions de concurrence sur les recharges de seaux, propagation de l'état du disjoncteur entre les répliques, ordonnancement de la chaîne de secours lors de pannes partielles) la troisième ou quatrième fois que la dérive se produit en production.

Erreurs de configuration courantes

Quatre schémas apparaissent régulièrement dans les premières tentatives de limitation de débit des équipes, et chacun produit un mode de défaillance différent qu'il est utile de connaître.

Erreur 1 : clé de seau trop grossière. Un seul seau par utilisateur signifie qu'un agent en dérive bloque le travail de débogage de l'utilisateur — y compris le travail dont il a besoin pour trouver et corriger la dérive. Le tuple (utilisateur, dépôt, modèle) est généralement la bonne granularité ; les équipes qui agrègent à un niveau supérieur à celui-ci se retrouvent avec des incidents opérationnellement douloureux.

Erreur 2 : pas de chaîne de secours. Une charge de travail qui échoue brutalement à chaque 429 produit une expérience utilisateur pire que nécessaire. Même si l'équipe ne souhaite pas de modèle de secours (les préoccupations de qualité sont légitimes), servir une réponse mise en cache ou un message "temporairement indisponible" est préférable à un 5xx que l'utilisateur interprète comme "l'IA est en panne".

Erreur 3 : alerte sur chaque 429. Les 429 sont normaux — c'est le système qui fonctionne comme prévu. Les alertes ne devraient se déclencher que lorsque le disjoncteur se déclenche, et non lorsque le seau limite le débit. Les équipes qui alertent sur chaque 429 finissent par ignorer les alertes (car la plupart sont du bruit) ou par utiliser des seaux configurés si haut que la limite ne contraint rien.

Erreur 4 : seuils de vitesse de coût définis comme des montants statiques en dollars. Un seuil statique ("10 $/minute, c'est trop") devient rapidement obsolète à mesure que le trafic et la tarification de l'équipe évoluent. Le seuil devrait être relatif au budget prévu de la charge de travail — "10 fois le taux prévu" est durable malgré les changements de coût ; "10 $/minute" est fragile.

Comment déployer cela sans tout casser

La limitation de débit est l'un des rares changements de plateforme où le risque de déploiement est asymétrique : ne pas l'appliquer est le statu quo (avec des incidents coûteux occasionnels), l'appliquer trop agressivement perturbe les charges de travail légitimes. La séquence de déploiement devrait privilégier l'observation d'abord, l'application ensuite.

Semaine 1 — Buckets en mode audit seulement, disjoncteurs en mode audit seulement. Déployer la couche de limitation de débit avec chaque seuil configuré pour "journaliser mais ne pas appliquer". Chaque requête passe toujours ; la passerelle enregistre ce qui aurait été ralenti ou ce qui aurait déclenché un disjoncteur. Le tableau de bord à la fin de la semaine répond aux questions dont l'équipe ignorait avoir besoin : quelles charges de travail sont en rafale, lesquelles présentent déjà des signatures de boucles, combien de requêtes/minute l'utilisateur légitime le plus actif produit réellement.

Semaine 2 — Activer le seau à jetons uniquement, sur une classe de charge de travail. Choisir la classe la plus à risque — généralement les pipelines CI/CD basés sur des agents, où il n'y a pas de mécanisme de régulation humaine. Activer le seau à jetons avec des seuils définis au P99 du trafic légitime observé plus une marge. Surveiller les erreurs 429 pendant la semaine. Les faux positifs (charges de travail légitimes atteignant la limite) entraînent une augmentation du seuil ; en l'absence de faux positifs, la classe de charge de travail suivante est activée.

Semaine 3 — Ajouter le disjoncteur de vitesse de coût. Le disjoncteur de vitesse de coût est celui qui détecte les dérives lentes que le seau à jetons ne parvient pas à intercepter. Le configurer par défaut à 10 fois le taux prévu ; l'ajuster par charge de travail après une semaine de données d'audit. Les alertes sont configurées mais acheminées uniquement à l'équipe plateforme pendant la semaine 3, pas aux astreintes produit — le seuil est toujours en cours d'ajustement.

Semaine 4 — Autres disjoncteurs, chaîne de repli. Ajouter le détecteur de signature de boucle. Configurer les chaînes de repli par route, en étroite consultation avec les propriétaires des charges de travail — ils savent à quoi devrait ressembler un état "dégradé" pour leur cas d'utilisation. Le cache sémantique se remplit au cours de la première semaine d'opération ; les taux de succès du cache augmentent progressivement et se stabilisent autour de 20-40% pour la plupart des charges de travail.

Semaine 5+ — État stable. Les alertes sont acheminées aux astreintes produit. Le tableau de bord de limitation de débit fait partie de l'examen régulier de l'équipe. Les nouvelles charges de travail passent par défaut en état d'audit seulement et sont explicitement promues à l'application. Les seuils sont réajustés trimestriellement à mesure que les schémas de trafic évoluent ; les règles des disjoncteurs sont étendues à mesure que de nouveaux schémas pathologiques sont découverts. Le système fonctionne comme une infrastructure, pas comme un projet.

Le modèle opérationnel autour de la couche de limitation de débit

La couche de limitation de débit est la propriété de l'équipe plateforme. Les seuils spécifiques aux charges de travail sont co-gérés avec les équipes de charge de travail. Il est important de bien définir la limite car chacun a des droits de décision et des horizons temporels différents.

L'équipe plateforme est propriétaire de l'architecture. Quels disjoncteurs existent, quel est le format d'alerte, ce que le journal d'audit capture, comment la configuration est examinée. Ceux-ci sont stables pour toutes les charges de travail ; ils changent rarement. Le rôle de l'équipe plateforme est de fournir des primitives, de les documenter et d'ajuster les valeurs par défaut.

L'équipe de charge de travail est propriétaire des paramètres. La taille du compartiment pour leur charge de travail, l'ordre de la chaîne de repli, le seuil de vélocité des coûts. Ceux-ci sont spécifiques à la charge de travail et évoluent avec ses exigences. L'équipe plateforme examine les modifications (une charge de travail demandant un compartiment énorme donne lieu à une discussion, pas à une approbation automatique), mais l'équipe en charge de la charge de travail en a la responsabilité opérationnelle.

L'astreinte est alternée entre la plateforme et le produit. Les alertes de la couche de limitation de débit sont dirigées vers une rotation partagée. Les ingénieurs plateforme gèrent les alertes lorsque le problème concerne l'infrastructure de la plateforme (la logique du disjoncteur elle-même est erronée) ; les ingénieurs produit gèrent les alertes lorsque le problème concerne leur charge de travail (le processus incontrôlé est dans leur code). Le transfert se fait via le contenu de l'alerte ; si l'alerte indique "votre flux de travail a bouclé 200 fois en 5 minutes, voici la trace", l'ingénieur produit est le bon intervenant.

Le modèle qui échoue est celui où la plateforme gère tout de bout en bout. Les ingénieurs plateforme ne savent pas ce que signifie "dégradé mais acceptable" pour le chatbot de support client ; les ingénieurs produit n'ont pas de visibilité sur les signaux à l'échelle de la plateforme. Cette répartition est ce qui rend le modèle opérationnel durable.

Limitation de débit multi-locataire — le cas du SaaS B2B

Le cas d'une organisation unique où chaque appelant appartient à une seule équipe est le plus simple. De nombreux déploiements d'IA en production sont multi-locataires : un produit SaaS B2B offre des fonctionnalités d'IA à ses propres clients, chacun d'eux pouvant générer un trafic de forme arbitraire. La couche de limitation de débit doit isoler les locataires les uns des autres et appliquer des niveaux de tarification par locataire sans modifier l'architecture.

Le modèle qui fonctionne ajoute le locataire comme une autre dimension à la clé du compartiment. Le compartiment est indexé par (locataire, charge de travail, modèle) — l'agent incontrôlé d'un locataire ne limite que le trafic de ce locataire ; les autres locataires ne sont pas affectés. Le plafond de coût global de la plateforme se situe au-dessus des plafonds par locataire ; un seul locataire dépassant son niveau atteint son compartiment en premier, et le disjoncteur à l'échelle de la plateforme fournit un filet de sécurité pour le cas où plusieurs locataires se comportent mal simultanément.

Le dimensionnement des compartiments en fonction du niveau est le deuxième modèle. Le client du niveau gratuit obtient un compartiment plus petit que le client du niveau entreprise ; les tailles des compartiments sont dérivées du plan du locataire. Lorsqu'un locataire met à niveau ses plans, la taille du compartiment est mise à jour sans modification du code — le niveau est une métadonnée de l'identité du locataire, la taille du compartiment est une fonction du niveau. Les équipes qui codent en dur les tailles des compartiments dans le code de l'application finissent par les réécrire à chaque changement de tarification ; les équipes qui les dérivent des métadonnées du locataire héritent automatiquement du bon comportement.

Le troisième modèle : l'attribution des coûts par locataire passe par la même dimension. Si le compartiment est indexé par locataire, le grand livre des coûts est indexé par locataire, le journal d'audit est indexé par locataire, le tableau de bord de limitation de débit est indexé par locataire. L'histoire FinOps de la plateforme (quels locataires sont les plus coûteux, lesquels sont rentables, lesquels abusent du système) devient traitable à partir des mêmes données que la couche de limitation de débit produisait déjà.

‍

FAQ

Quelle est la bonne valeur pour la limite du compartiment de jetons ?

Partez de la forme naturelle du trafic — examinez le pic P99 pour la charge de travail du mois précédent et dimensionnez le compartiment à peu près à ce niveau. Ajustez en fonction du taux de faux positifs (charges de travail légitimes se plaignant de 429) et du taux de déclenchement du disjoncteur (processus incontrôlés échappant au compartiment). Le compartiment est un paramètre par charge de travail ; une taille unique ne convient pas à tous.

La limitation de débit au niveau de la passerelle remplace-t-elle les propres limites de débit du fournisseur ?

Non — elles se cumulent. Les limites du fournisseur sont absolues ; les limites de la passerelle sont par identité et plus granulaires. La limite du fournisseur pourrait être "100 000 requêtes/minute à l'échelle de l'organisation" ; la limite de la passerelle est "100 requêtes/minute pour ce pipeline CI". Les deux s'appliquent ; la limite de la passerelle se déclenchera généralement en premier pour les charges de travail individuelles.

Comment gérer le cas où l'agent a légitimement besoin de faire de nombreux appels ?

Configurez un compartiment plus élevé pour cette charge de travail. Une charge de travail connue pour nécessiter 1 000 requêtes par minute (rpm) obtient un compartiment dimensionné en conséquence ; le seuil est par charge de travail, pas à l'échelle de la plateforme. La discipline consiste à examiner le compartiment plus élevé avec l'équipe plateforme avant de l'accorder, et non à accorder une capacité illimitée par défaut.

Qu'en est-il des réponses en streaming — comptent-elles différemment ?

Oui. Une réponse en streaming qui dure deux minutes consomme un jeton de compartiment au moment de la requête mais génère un coût significatif sur la durée du flux. Le disjoncteur de vélocité des coûts gère ce cas ; la couche de compartiment de jetons est augmentée d'un moniteur de coût de streaming qui peut annuler le flux si la vélocité des coûts dépasse le seuil en cours de flux.

Est-ce que le coupe-circuit peut se déclencher pour une seule requête très coûteuse ?

Oui — le coupe-circuit de vélocité des coûts inclut la "détection de pics" : une seule requête dont le coût dépasse N fois le coût moyen de la charge de travail (généralement 50x ou 100x) déclenche le coupe-circuit même si aucun modèle de débit n'est visible. Cela permet de détecter le cas où un agent soumet une requête avec un contexte débordant qui coûte 50 $ au lieu des 0,05 $ habituels.

Comment ajustons-nous les seuils sans perturber les charges de travail légitimes ?

Déployez d'abord en mode audit seul — le coupe-circuit calcule s'il se serait déclenché mais ne bloque pas réellement. Après une semaine, l'équipe dispose d'une distribution réelle : quelles charges de travail se seraient déclenchées, à quelle fréquence, et dans quelles conditions. Ajustez les seuils en fonction des données d'audit uniquement, puis activez l'application. La semaine en mode audit seul est une assurance bon marché contre les faux positifs.

Que se passe-t-il lorsque le coupe-circuit est ouvert — l'application plante-t-elle ?

Non — la chaîne de secours prend le relais. Si la chaîne de secours est épuisée, l'application reçoit un code HTTP 503 propre avec un corps d'erreur structuré qu'elle peut afficher à l'utilisateur. Les plantages ne se produisent pas au niveau de la passerelle ; ils se produisent dans un code d'application mal géré qui ne sait pas quoi faire avec un 503. La solution est la gestion des erreurs côté application, et non des modifications de la passerelle.

‍