Comment créer un courtier de limite de débit neutre par rapport au fournisseur pour les API LLM multimodèles

Lorsque plusieurs équipes partagent plusieurs fournisseurs LLM, la limitation du débit cesse d'être un détail d'intégration du fournisseur. Cela devient un problème de capacité partagée. Un fournisseur peut limiter les demandes et les jetons d'entrée, un autre peut séparer les jetons d'entrée et de sortie, et un troisième peut appliquer des quotas au niveau du projet ou sur une fenêtre de dépenses glissante. Une boucle de nouvelle tentative à l'intérieur de chaque SDK ne peut pas coordonner ces contraintes entre les locataires, les applications, les clés de partenaire et les routes de modèle.

La solution pratique est un courtier central de limite de débit au niveau de la passerelle. Le courtier estime la demande, réserve la capacité avant l'expédition, met en file d'attente ou rejette le travail conformément à la politique et rapproche la réservation avec l'utilisation réelle une fois terminée. Les réponses du fournisseur affinent ensuite la vue du courtier sur la capacité disponible au lieu de déclencher des tempêtes de nouvelles tentatives indépendantes.

Cette architecture est utile pour tout LLM d'entreprise API qui a besoin d'un débit prévisible entre les équipes internes, les applications de production, les agents d'automatisation ou les partenaires externes.

Pourquoi les limites de débit des fournisseurs ne peuvent pas être réduites à des requêtes par minute

Fait : Les quotas des fournisseurs utilisent différentes dimensions et portées. Les dimensions courantes incluent les requêtes par minute, les jetons d'entrée par minute, les jetons de sortie par minute, le nombre total de jetons, les requêtes par jour, la simultanéité, les fenêtres de dépenses et les limites d'accélération ou de rampe. Le même fournisseur peut exposer différentes limites pour une organisation, un projet, un espace de travail, un modèle ou un API produit.

Par exemple, la documentation du fournisseur décrit des combinaisons telles que :

• Limites de requêtes et de jetons avec informations de capacité restante et de réinitialisation dans les en-têtes de réponse.
• Limites distinctes des jetons d'entrée et des jetons de sortie pour les API de message.
• Quotas au niveau du projet plutôt que quotas attachés à des API clés individuelles.
• Limites de requêtes quotidiennes réinitialisées à une heure définie par le fournisseur.
• Fenêtres glissantes basées sur les dépenses qui peuvent rejeter le trafic même lorsque les taux de requêtes et de jetons semblent acceptables.
• Limites d'accélération qui réagissent à une forte augmentation du trafic, même lorsque l'utilisation en régime permanent est inférieure au quota publié.

Une passerelle qui ne stocke qu'un seul numéro appelé RPM du fournisseur finira par suradmettre le trafic dans une dimension ou sous-utiliser la capacité dans une autre. Il ne peut pas non plus expliquer si un rejet provient d'une politique de locataire, d'un quota de projet du fournisseur, d'une limite quotidienne ou d'une réponse de surcharge.

Architecture de référence pour un courtier en limites de débit

Placez le courtier dans le chemin de la requête avant l'adaptateur du fournisseur. Chaque demande doit passer par le même flux de réservation, qu'elle soit arrivée via une clé SDK, un service interne, un agent d'automatisation ou une clé API partenaire.

1. Normaliser l'identité. Résoudre l'organisation, le locataire, l'équipe, l'application, l'environnement, le partenaire, la clé API, l'itinéraire du modèle et la classe de charge de travail.
2. Estimer la demande. Calculez les jetons d'entrée attendus, les jetons de sortie maximum, les dépenses estimées et tout coût de simultanéité.
3. Évaluez la politique. Vérifiez les budgets des locataires, les délais de file d'attente, l'éligibilité des itinéraires, la priorité et les règles de secours.
4. Réserver la capacité. Réserver atomiquement de la capacité dans les compartiments internes et côté fournisseur concernés.
5. Dispatch. Envoyez la demande uniquement une fois la réservation réussie.
6. Réconcilier. Remplacez les estimations par l'utilisation réelle, libérez les réservations inutilisées et enregistrez les en-têtes des fournisseurs et la classification des réponses.
7. Décidez de l'action suivante. Renvoyez le résultat, mettez le travail en file d'attente, réessayez de manière centralisée, revenez en arrière ou rejetez-le conformément au contrat de charge de travail.

Le service de réservation doit être évolutif horizontalement, mais sa décision doit être atomique pour chaque requête. Un compteur distribué qui permet à deux travailleurs d'observer la même capacité restante peut recréer le problème du fournisseur 429 à l'intérieur de la passerelle.

Utilisez un modèle de quota canonique sans masquer les différences entre les fournisseurs

Définissez un modèle canonique qui peut représenter des contraintes spécifiques au fournisseur au lieu de forcer chaque fournisseur à une seule abstraction.

Représentez chaque limite sous la forme d'un bucket avec une portée, une capacité, une règle de recharge ou de réinitialisation, une unité et une source. Un compartiment de projet fournisseur peut contenir des requêtes et des jetons d'entrée. Un compartiment d'espace de travail peut contenir des jetons de sortie. Une politique de partenariat interne peut ajouter des limites de concurrence et de dépenses. La décision d'admission n'est réussie que si toutes les réservations requises réussissent.

Ne considérez pas les en-têtes des fournisseurs comme une source complète de vérité. Utilisez-les pour corriger les estimations du courtier, mais conservez un modèle configuré pour les limites qui ne sont pas exposées à chaque réponse. Les noms d'en-tête, la disponibilité et la sémantique de réinitialisation varient selon le fournisseur et l'itinéraire.

Réservez les jetons avant leur expédition, puis réconciliez-les

La réservation de jetons est la différence la plus importante entre un courtier et un wrapper de nouvelle tentative. Le courtier a besoin d'une estimation de la demande avant d'envoyer la demande.

Pour les jetons d'entrée, estimez à partir des messages sérialisés, des définitions d'outils, du schéma de sortie structuré et de tout contexte récupéré. Pour les jetons de sortie, utilisez le nombre maximum de requêtes lorsqu'il est disponible, ou une estimation spécifique au modèle et à la charge de travail lorsque le client n'en fournit pas. Conservez l'estimation jointe à la réservation afin qu'elle puisse être comparée ultérieurement à l'utilisation réelle.

Un simple enregistrement de réservation peut contenir :

• Un identifiant de demande et de réservation unique.
• Client, application, clé API, route et classe de charge de travail.
• Estimation des jetons d'entrée, des jetons de sortie, du total des jetons et des dépenses.
• Chaque compartiment facturé par la réservation.
• Heure de création, heure d'expiration, date limite de file d'attente et clé d'idempotence.
• Utilisation finale réelle et montant débloqué ou facturé lors du rapprochement.

Les estimations prudentes réduisent le nombre de réponses des fournisseurs de 429, mais peuvent bloquer la capacité. Mesurez l’erreur d’estimation par modèle, itinéraire, famille d’invites, longueur de contexte et mode de sortie structurée. Ajustez ensuite les estimations à l'aide de corrections limitées plutôt que de permettre à une seule requête inhabituelle de déformer l'ensemble du modèle.

Le streaming nécessite une politique spécifique. Vous pouvez réserver la capacité de sortie maximale et libérer la partie inutilisée à la fin du flux, ou réserver la capacité de sortie par incréments plus petits à mesure que les jetons arrivent. La première approche est plus facile à raisonner ; la seconde peut améliorer l'utilisation mais nécessite une gestion fiable des annulations, des délais d'attente et des déconnexions.

Appliquer les quotas de manière hiérarchique

La capacité doit être vérifiée depuis la stratégie la plus étroite jusqu'à la ressource partagée la plus large. Une hiérarchie typique est :

1. API clé ou identité de service.
2. Application et environnement.
3. Client d'équipe ou client.
4. Compte partenaire ou revendeur.
5. Espace de travail ou sous-compte du fournisseur.
6. Projet ou organisation du fournisseur.
7. Modèle et itinéraire.

Une requête émanant d'une application partenaire peut donc nécessiter quatre réservations réussies : la politique de concurrence du partenaire, le budget de jetons du locataire client, l'allocation de routes de la passerelle et le quota disponible du projet fournisseur. Si une réservation échoue, libérez les réservations déjà acquises et appliquez la décision du bucket ayant échoué.

Par souci d'équité, utilisez une file d'attente équitable pondérée ou un round-robin déficitaire plutôt que de permettre au travailleur arrivé en premier de consommer le pool partagé. Attribuez des pondérations plus élevées au trafic de production et des pondérations plus faibles aux tâches en arrière-plan, tout en préservant les crédits en rafale pour chaque locataire. Le partitionnement dur est plus facile à expliquer mais peut laisser la capacité inactive lorsqu'un locataire est silencieux. Le partage pondéré utilise généralement la capacité plus efficacement, à condition que les locataires bruyants aient des limites de rafales limitées.

Concevoir des files d'attente autour des contrats de charge de travail

Une file d'attente n'est pas automatiquement une fonctionnalité de fiabilité. Il peut transformer un 429 visible en un délai invisible de dix minutes. Chaque classe de file d'attente nécessite une date limite, un comportement d'annulation, une profondeur maximale et une action de surcharge.

• Interactif : Délai court, petite file d'attente, rejet prévisible ou dégradation du modèle lorsque la capacité n'est pas disponible.
• Contexte de production : Délai plus long, file d'attente durable, clé d'idempotence et budget de nouvelle tentative contrôlé.
• Partenaire : Quotas spécifiques au locataire, métadonnées de réponse publiées et aucun accès à l'état de la file d'attente d'un autre locataire.
• Batchable : Exécution retardée, file d'attente plus grande et routage facultatif vers un lot fournisseur API lorsque la charge de travail le permet.

L'admission dans la file d'attente doit renvoyer une décision claire. En fonction du contrat API, exposez une réponse de surcharge 429 ou spécifique à la passerelle avec une valeur de nouvelle tentative, un identifiant de file d'attente et un code anomalie. Ne promettez pas de délai d'exécution à moins que le système ne puisse faire respecter cette promesse.

Le traitement par lots peut supprimer le travail non interactif de la capacité synchrone, mais il modifie le timing des résultats, le comportement des nouvelles tentatives, l'annulation et le rapprochement. Traitez-le comme un chemin d'exécution distinct plutôt que de simplement placer les requêtes synchrones dans une très longue file d'attente. Pour les charges de travail en arrière-plan, comparez les compromis opérationnels avec les politiques de contrôle des coûts de l'IA API et les opérations par lots existantes.

Centraliser la gestion des nouvelles tentatives et des surcharges

Fait : Les réponses de limite de débit temporaire utilisent généralement HTTP 429, tandis que les conditions de surcharge du fournisseur peuvent utiliser 503 ou un code d'erreur spécifique au fournisseur. Certains fournisseurs renvoient un en-tête Retry-After et la documentation du fournisseur recommande de l'honorer lorsqu'il est présent. Une rampe de circulation rapide peut également produire un comportement d'accélération ou de ralentissement sans épuisement ordinaire du godet.

Recommandation : Traitez Retry-After comme une limite inférieure, et non comme une suggestion facultative. Suspendez la portée du fournisseur concerné jusqu'à ce moment-là, ajoutez une instabilité limitée pour empêcher les réveils synchronisés et laissez le courtier décider quelles requêtes en file d'attente peuvent utiliser la capacité récupérée.

Lorsque Retry-After est absent ou invalide, utilisez un intervalle exponentiel plafonné avec instabilité. Conservez le budget de nouvelle tentative dans le courtier, et non séparément dans chaque SDK et adaptateur de fournisseur. Sinon, une requête logique peut produire une nouvelle tentative de passerelle, une SDK nouvelle tentative, une HTTP nouvelle tentative du client et une réexécution côté fournisseur.

Classez les erreurs avant de réessayer :

• Capacité réessayable : Réponse de quota temporaire 429 ou transitoire documentée.
• Surcharge réessayable : Signal de surcharge temporaire 503 ou équivalent du fournisseur.
• Échec de la stratégie non réessayable : Quota quotidien, plafond de dépenses, projet désactivé ou limite de locataire.
• Échec de la requête non réessayable : Schéma invalide, paramètre non pris en charge, échec d'authentification ou entrée mal formée.
• Échec du délai : Une requête dont le délai restant pour l'utilisateur ou le workflow est plus court que la prochaine tentative sécurisée.

La solution de remplacement est une décision distincte. Un fournisseur différent peut avoir des limites de comportement de sortie, de tarification, de latence, de résidence ou de contexte différentes. Utilisez la solution de secours uniquement lorsque la stratégie de routage confirme que le contrat de charge de travail peut tolérer ces différences.

Exposer les décisions et mesurer la saturation

Les équipes ne peuvent pas résoudre les problèmes de limitation si la passerelle renvoie uniquement un 429 générique. Renvoie des métadonnées sécurisées telles que la limite applicable, la capacité restante, le temps de réinitialisation, la décision de file d'attente, la classe de charge de travail et le motif du rejet. Évitez d'exposer l'utilisation d'un autre locataire ou les informations d'identification brutes du fournisseur.

Au minimum, surveillez :

• Taux de réussite et de rejet des réservations par locataire, itinéraire et bucket.
• Profondeur de la file d'attente, temps d'attente dans la file d'attente, expiration des délais et annulations.
• Taux des fournisseurs 429 et 503, fréquence de nouvelle tentative et taux de rejet progressif.
• Utilisation estimée par rapport à l'utilisation réelle des jetons et capacité gaspillée par une surréservation.
• Saturation de la concurrence et part de capacité consommée par chaque locataire.
• Nouvelles tentatives par requête logique et fréquence de repli.
• Quota quotidien et marge de dépenses.

Les tests de charge doivent inclure le trafic en rafale, les requêtes à contexte long, les requêtes de sortie maximale, les déconnexions de streaming, l'épuisement des quotas quotidiens, les réponses des fournisseurs 429 et 503 et un locataire bruyant en concurrence avec le trafic de production. Vérifiez non seulement si les demandes finissent par aboutir, mais également si les délais de file d'attente, l'équité et les budgets de nouvelles tentatives restent intacts.

Liste de contrôle de mise en œuvre

• Définissez les dimensions canoniques sans ignorer les limites spécifiques au fournisseur.
• Attribuez à chaque requête un locataire, une route, une classe de charge de travail et une clé d'idempotence normalisés.
• Estimez et réservez les entrées, les sorties, le total des jetons, les dépenses, les demandes et la simultanéité avant l'expédition.
• Rendre les réservations multi-buckets atomiques et faire expirer les réservations abandonnées en toute sécurité.
• Réconciliez l'utilisation réelle du fournisseur et les en-têtes de réponse après chaque tentative.
• Utilisez l'équité pondérée, les crédits en rafale et les classes de priorité explicites.
• Attribuez à chaque file d'attente une date limite, une profondeur maximale et une action de surcharge.
• Centralisez les tentatives et respectez les valeurs Retry-After du fournisseur.
• Séparez les erreurs de capacité temporaires des erreurs permanentes de politique et de demande.
• Publiez les métadonnées de limitation et surveillez la saturation par locataire et par route.
• Testez l'épuisement des quotas du fournisseur, les limites de rampe, le streaming, le repli et le comportement des voisins bruyants.

Conclusion

Une passerelle multimodèle doit gérer le quota du fournisseur en tant que capacité d'infrastructure partagée, et non en tant qu'ensemble de paramètres SDK indépendants. Un courtier de limites de taux indépendant du fournisseur offre aux équipes de plate-forme une seule voie d'admission, une seule politique d'équité, un seul budget de nouvelle tentative et un seul endroit pour rapprocher les estimations avec la réalité.

La conception nécessite bien plus qu'un simple bucket de jetons générique. Il doit représenter les demandes, les jetons d'entrée et de sortie, les quotas quotidiens, les fenêtres de dépenses, la simultanéité, la portée du fournisseur et le taux d'augmentation. Une fois ces dimensions explicites, la passerelle peut faire des choix prévisibles : expédier maintenant, faire la queue avec une date limite, abandonner le travail, réessayer de manière centralisée ou utiliser une solution de repli sécurisée par contrat. C'est ainsi que le contrôle du débit devient une capacité opérationnelle plutôt qu'une source récurrente d'incidents de production 429 et 503.

Lecture connexe

• traitement par lots pour les charges de travail LLM non interactives