Passerelles API AI sensibles aux limites de débit : façonnez le RPM, le TPM, les rafales et l'équité des locataires avant l'atteinte des 429

Un 429 provenant d'un fournisseur LLM n'est pas simplement un signal de nouvelle tentative. En production, il est souvent évident que votre application a déjà perdu le contrôle de l'admission, de l'équité des locataires, de la latence ou de la comptabilité des quotas spécifiques au fournisseur.

La solution courante : l'intervalle exponentiel - est nécessaire mais incomplète. Backoff réagit après que le fournisseur a rejeté le trafic. Une passerelle d'IA API sensible aux limites de débit doit façonner le trafic avant que les requêtes ne quittent votre système : estimer la pression des jetons, réserver un quota, isoler les locataires, mettre en file d'attente le bon travail, rejeter le mauvais travail et s'adapter lorsque les limites du fournisseur changent.

Cet article décrit un régulateur de quota de passerelle pratique pour les équipes qui envoient des charges de travail de production à plusieurs fournisseurs LLM via un API.

Le problème du lecteur : les 429 sont multidimensionnels

De nombreuses équipes traitent les limites de débit comme s'il s'agissait d'un nombre unique de requêtes par minute. Cette hypothèse s'effondre rapidement avec les API LLM.

Faits tirés de la documentation actuelle du fournisseur :

• OpenAI documente que les limites peuvent être appliquées sur des fenêtres plus courtes que la limite par minute annoncée, de sorte que de courtes rafales peuvent échouer même lorsque la minute moyenne semble sûre.
Le quota
• Azure OpenAI est attribué par abonnement, région, modèle et type de déploiement en jetons par minute. L'attribution de TPM à un déploiement détermine également les limites de RPM d'inférence appliquées, et les ratios RPM/TPM varient selon le modèle.
• Azure OpenAI note également que les calculs de jetons de limite de débit sont estimés lorsque la demande est reçue et ne sont pas identiques au nombre final de jetons de facturation.
• Anthropic documente des limites distinctes de requêtes par minute, de jetons d'entrée par minute et de jetons de sortie par minute. Le dépassement des limites renvoie un 429 avec un en-tête de nouvelle tentative.
• Anthropic avertit que de fortes augmentations de trafic peuvent atteindre les limites d'accélération et recommande une accélération progressive.
• Pour la plupart des Claude modèles, Anthropic les documents qui mettent en cache les jetons d'entrée lus ne sont pas pris en compte dans les limites de jetons d'entrée par minute, ce qui signifie que la mise en cache des invites peut modifier la marge effective.
• Google Gemini API les limites de taux sont liées aux niveaux d'utilisation du projet, les niveaux plus élevés dépendant de la configuration de la facturation, des dépenses cumulées et du temps écoulé après les étapes de paiement.

La leçon opérationnelle est claire : une forme de requête compatible OpenAI n'implique pas un comportement de quota compatible OpenAI. Une passerelle multi-fournisseurs a besoin d'un modèle de quota interne plus riche que « réessayer si 429 ».

Objectif de conception : faire du contrôle d'admission une responsabilité de passerelle

Une passerelle prenant en compte les limites de débit doit répondre à cinq questions avant d'envoyer une requête :

1. Quel fournisseur, modèle, déploiement, région, projet ou espace de travail recevra la demande ?
2. Quelle quantité de capacité de requête, de jeton d'entrée, de jeton de sortie et de concurrence peut-il consommer ?
3. Quel locataire, équipe, API clé, client ou classe de charge de travail doit être facturé sur la capacité partagée ?
4. La demande doit-elle être admise maintenant, mise en file d'attente brièvement, rétrogradée, acheminée ailleurs ou rejetée ?
5. Comment la réservation doit-elle être rapprochée une fois que le fournisseur a renvoyé l'utilisation réelle ?

La passerelle devient un gouverneur de quota. Il ne remplace pas les limites du fournisseur. Cela rend les limites des fournisseurs visibles, prévisibles et équitables au sein de votre propre système.

Créer un modèle de quota normalisé

Commencez par définir des dimensions de limiteur interne qui peuvent représenter les principaux fournisseurs sans les forcer à se regrouper dans une catégorie trompeuse.

Dimensions recommandées du limiteur

• RPM : requêtes par minute.
• TPM d'entrée : jetons d'invite, de message, d'outil et de contexte par minute.
• TPM de sortie : jetons d'achèvement par minute, réservés séparément pour le streaming et les générations longues.
• TPM total : utile pour les fournisseurs ou les déploiements qui exposent une pression combinée de jetons.
• Concurrence : requêtes actives, flux actifs ou tâches en cours.
• Durée du streaming : les flux de longue durée peuvent occuper la marge de connexion et de jeton de sortie même lorsque le RPM est faible.
• Portée spécifique au fournisseur : abonnement/région/déploiement Azure, Anthropic espace de travail/classe de modèle, Google projet/niveau ou OpenAI organisation/projet/groupe de modèles.

Ne masquez pas les dimensions spécifiques au fournisseur. Normalisez-les dans un schéma commun, mais conservez suffisamment de détails pour expliquer un rejet plus tard.

{
  "provider": "provider_a",
  "model_profile": "fast-chat",
  "provider_scope": {
    "project": "prod",
    "region": "us-east",
    "deployment": "chat-large-01"
  },
  "limits": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "concurrency": 200
  }
}

Cet objet interne doit être configuré explicitement, et non déduit des seuls noms de modèle. Les tableaux de bord des fournisseurs, les niveaux de compte, les déploiements régionaux et les paramètres de l'espace de travail peuvent tous modifier la capacité effective d'une même famille de modèles.

Estimer la pression du jeton avant l'expédition

La limitation du débit côté fournisseur se produit souvent avant que l'utilisation finale de la facturation ne soit connue. Votre passerelle doit effectuer le même type d'estimation prudente avant d'envoyer du trafic.

Entrées de réservation en amont

• Invite sérialisée et longueur du message.
• Tokénisation et surcharge spécifiques au modèle pour les rôles, les outils, les images ou les instructions de sortie structurées.
• max_completion_tokens ou plafond de production équivalent.
• Taux d'achèvement historique pour ce point de terminaison, ce locataire, ce profil de modèle et cette classe de requête.
• Jetons de lecture du cache attendus si la mise en cache des invites est disponible et mesurable.
• Drapeau de diffusion en continu et durée de diffusion prévue.

Une simple règle de réservation suffit souvent pour démarrer :

estimated_input_tokens = tokenize(request_messages) + model_overhead
estimated_output_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
reserved_total_tokens = estimated_input_tokens + estimated_output_tokens

Pour les itinéraires inconnus, utilisez une valeur par défaut conservatrice. Pour des itinéraires de production stables, mettez à jour les estimations en permanence à partir de l'utilisation réelle.

Réservez, puis réconciliez

Les réservations de quota ne doivent pas devenir des frais permanents. Traitez-les comme des prises :

1. Citation : estimer la pression d'entrée et de sortie.
2. Réserve : déduire des compartiments de jetons concernés avant l'expédition.
3. Régler : remplacez l'estimation par l'utilisation signalée par le fournisseur lorsqu'elle est disponible.
4. Remboursement ou débit : restituez la capacité réservée inutilisée ou facturez les excédents à la fenêtre suivante si nécessaire.

Cela est particulièrement important pour les appels en contexte long et en streaming. Si vous vérifiez uniquement le TPM d’entrée avant l’envoi, un flux peut démarrer avec succès, puis se heurter ultérieurement à la pression du jeton de sortie. La réservation séparée de la marge de sortie réduit les pannes en cours de route et le risque de décrochage.

Utilisez des compartiments de jetons hiérarchiques pour l'équité des locataires

Un seul limiteur global protège le compte du fournisseur mais ne protège pas les locataires les uns des autres. Une tâche par lots à contexte long peut consommer un TPM partagé et entraîner l'échec des requêtes interactives des autres équipes.

Utilisez des buckets de jetons hiérarchiques :

organization
  └── tenant
      └── team
          └── api_key
              └── model_profile
                  └── provider_deployment

Une requête doit transmettre chaque bucket concerné. Cela vous permet d'appliquer plusieurs règles à la fois :

• L'organisation ne peut pas dépasser la capacité du fournisseur.
• Un locataire ne peut pas consommer plus que sa part contractuelle.
• Une clé API ne peut pas dépasser la limite de son environnement ou de son application prévue.
• Un profil de modèle par lots ne peut pas affamer un profil de modèle interactif.
• Un déploiement de fournisseur ne peut pas être surchargé même si un autre déploiement dispose d'un quota disponible.

Partage équitable versus utilisation

Recommandation : utilisez un partage équitable pondéré avec un emprunt en rafale contrôlé.

Les plafonds stricts par locataire sont faciles à expliquer, mais peuvent bloquer la capacité inutilisée. L'emprunt en rafale améliore l'utilisation en permettant à un locataire d'utiliser temporairement le quota inactif d'un pool partagé. Le compromis est la complexité : les tableaux de bord doivent montrer ce qui a été garanti, ce qui a été emprunté et quand l'emprunt a été révoqué.

Une règle pratique :

• Donnez à chaque locataire une référence garantie.
• Autoriser l'emprunt en rafale à partir de capacités partagées inutilisées.
• Récupérez la capacité empruntée lorsqu'un trafic plus prioritaire ou garanti apparaît.
• Ne laissez jamais le trafic emprunté créer des 429 au niveau du fournisseur pour un trafic garanti.

Séparez les classes de trafic avant qu'elles ne s'affrontent

Toutes les requêtes ne méritent pas le même comportement en file d'attente. Placez le trafic dans des profils de modèle avec des files d'attente et des pools de quotas séparés.

La mise en file d'attente améliore le taux de réussite mais augmente la latence de fin. Une passerelle devrait rendre ce compromis explicite. Par exemple, une requête interactive peut attendre jusqu'à 300 millisecondes pour obtenir un quota, puis revenir en arrière ou échouer. Un travail par lots nocturne peut attendre 20 minutes et être néanmoins considéré comme réussi.

Normaliser les 429 en un seul schéma d'erreur

Même avec un bon contrôle d'admission, des erreurs 429 du fournisseur se produiront toujours. Les limites peuvent changer, les estimations des fournisseurs peuvent différer des vôtres et le trafic peut arriver en rafales plus brusques que prévu.

Normalisez chaque fournisseur 429 en un objet d'erreur de passerelle :

{
  "error": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "fast-chat",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interactive",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": false,
    "trace_id": "trace_abc"
  }
}

Le champ clé est gateway_decision. Un 429 après que la passerelle a admis la demande est différent d'une demande que la passerelle a rejetée localement avant l'expédition. Le premier indique un problème de calibrage du limiteur. La seconde indique une protection intentionnelle.

Adaptez-vous des en-têtes du fournisseur, mais n'en dépendez pas

Certains fournisseurs renvoient des en-têtes utiles tels que des indicateurs de nouvelle tentative ou de capacité restante. Utilisez-les lorsqu'ils sont disponibles.

Recommandation : les en-têtes de fournisseur doivent ajuster votre gouverneur local, et non le remplacer.

Raisons :

• La disponibilité des en-têtes diffère selon le fournisseur et le point de terminaison.
• Les en-têtes peuvent ne pas exposer toutes les dimensions du limiteur.
• Réessayer après vous indique quand réessayer, et non quel locataire devrait obtenir de la capacité ensuite.
• Les estimations de jetons côté fournisseur peuvent différer de votre facturation ou de votre comptabilité interne.

Une implémentation robuste met à jour les taux de remplissage et les temps de recharge du bucket local en fonction des en-têtes, tout en appliquant les limites de locataire, API de clé, de classe de trafic et de déploiement de fournisseur à l'intérieur de la passerelle.

Ajouter des régulateurs de rampe pour les migrations et les tâches planifiées

De nombreux incidents de limite de débit se produisent lors de modifications planifiées : passage d'un modèle à un autre, changement de fournisseur, activation d'un nouveau flux de travail d'agent ou lancement d'une exécution d'évaluation planifiée.

Recommandation : traitez la croissance du trafic comme un déploiement contrôlé.

• Migrations de modèles d'indicateurs de fonctionnalités par locataire, itinéraire ou pourcentage de trafic.
• Définissez des plafonds de croissance par minute pour les déploiements de nouveaux fournisseurs.
• Réchauffez le trafic progressivement au fil des heures au lieu de basculer tout le trafic instantanément.
• Suspendre le déploiement lorsque le taux 429, le taux de rétrogradation, la profondeur de la file d'attente ou la latence p95 dépassent un seuil.
• Gardez un itinéraire de restauration d'urgence avec une politique de compatibilité, pas seulement un modèle de rechange.

Prévision : à mesure que les modes de routage des fournisseurs, les niveaux de priorité et les contrôles au niveau de l'espace de travail deviennent plus courants, la gouvernance par rampe deviendra une fonctionnalité de passerelle standard plutôt qu'un script de réponse aux incidents.

Le repli est une décision politique, pas seulement une décision de capacité

Lorsqu'un fournisseur renvoie un 429, le routage vers un autre fournisseur peut être la bonne solution. Cela peut également être dangereux.

La solution de secours peut changer :

• Qualité de sortie et suivi des instructions.
• Longueur du contexte.
• Comportement d'appel d'outil.
• Fiabilité de sortie structurée.
• Conservation des données et posture de résidence.
• Coût et latence.

Le gouverneur de quota doit demander à une couche de compatibilité si le repli est autorisé pour cette classe de requête. Dans le cas contraire, il doit être mis en file d'attente ou échouer avec une réponse locale claire de limite de débit plutôt que de modifier silencieusement la sémantique.

Exposer des tableaux de bord de quotas qui expliquent les décisions

Un système de quotas que personne ne peut comprendre sera contourné. Créez des tableaux de bord autour de questions opérationnelles :

• Quels locataires consomment le plus de RPM, de TPM d'entrée et de TPM de sortie ?
• Quels profils de modèles sont en file d'attente, rejetés ou en retrait ?
• Quelle étendue de fournisseur constitue le goulot d'étranglement : projet, région, déploiement, espace de travail, classe de modèle ou niveau de compte ?
• À quelle fréquence les estimations de la passerelle diffèrent-elles de l'utilisation du fournisseur ?
• Quelle est la répartition des nouvelles tentatives par fournisseur et type de limiteur ?
• Quelle est la marge effective créée par les lectures rapides du cache ?
• Quelles classes de trafic empruntent de la capacité en rafale ?

Pour les produits destinés aux clients ou aux partenaires, exposez des contrôles sécurisés :

• Limites de débit par clé.
• Limites de rafale par équipe.
• Plafonds quotidiens par client.
• Pause d'urgence pour un locataire ou une clé.
• Alertes pour les pics 429, la croissance de la file d'attente et la pression anormale des jetons.
• Partenaire API points de terminaison pour la gestion des quotas des revendeurs.

Cela transforme la limitation de débit d'une mystérieuse erreur de fournisseur en un élément vérifiable de la gouvernance de l'équipe API.

Liste de contrôle de mise en œuvre

Phase 1 : observer et classer

• Fournisseur de journaux, modèle, déploiement, région, espace de travail, projet, locataire, clé API et classe de requête pour chaque appel.
• Capturez les 429 du fournisseur avec les métadonnées de nouvelle tentative et d'erreur brute.
• Enregistrez séparément les jetons d'entrée/sortie estimés et réels.
• Séparez le trafic interactif, par lots, d'évaluation et en arrière-plan dans la télémétrie.

Phase 2 : contrôle d'admission local

• Créez des objets limiteurs internes pour le RPM, le TPM d'entrée, le TPM de sortie, le TPM total et la concurrence.
• Ajouter une estimation du jeton de contrôle en amont.
• Réservez le quota avant l'envoi et effectuez le rapprochement après l'arrivée de l'utilisation du fournisseur.
• Rejeter localement lorsqu'une requête ne peut pas correspondre à son bucket de locataire ou de fournisseur.

Phase 3 : équité et files d'attente

• Ajoutez des buckets hiérarchiques du déploiement de l'organisation au fournisseur.
• Attribuez des parts garanties aux locataires et des emprunts rafales contrôlés.
• Créez des files d'attente distinctes par classe de trafic.
• Définissez des temps d'attente maximaux et des règles de secours spécifiques à la classe.

Phase 4 : adaptation et opérations

• Utilisez les en-têtes du fournisseur pour ajuster les temps de recharge et les hypothèses de recharge.
• Ajoutez des régulateurs de rampe pour les migrations et les tâches planifiées.
• Exposer les tableaux de bord et les alertes de quotas.
• Examinez chaque semaine l'erreur d'estimation et le quota bloqué.

Conclusion exploitable

Si votre passerelle ne réessaye que les 429, elle fonctionne après l'échec. Une passerelle IA API de niveau production devrait éviter la plupart des échecs de limite de débit en décidant qui est autorisé à envoyer quoi, quand et selon le quota de quel fournisseur.

Commencez avec un modèle de limiteur normalisé, une réservation de jetons de contrôle en amont et des files d'attente de classe de trafic. Ajoutez ensuite l’équité hiérarchique des locataires, l’adaptation des en-têtes de fournisseur et des régulateurs de rampe. Le résultat n’est pas seulement moins de 429. Vos équipes d'ingénierie, de finance et de support client peuvent réellement expliquer une allocation de capacité plus claire, une latence plus prévisible, des migrations plus sûres et un comportement de limite de débit.

Lecture connexe

• réservation en amont et rapprochement de l'utilisation
• comptabilisation rapide du cache et accès au cache Analytics
• politiques de routage de secours compatibles