Limites de débit et débit de l'API expliqués

Qu'est-ce qu'une limite de taux en réalité

UN limite de taux est une limite à la vitesse à laquelle vous pouvez utiliser une API. Les fournisseurs les imposent pour maintenir un service équitable et stable : sans eux, une seule boucle boguée ou un pic de trafic d'un client pourrait affamer tout le monde, donc les limites protègent la capacité, imposent des niveaux de forfait et éliminent les abus et les attaques par déni de service. Lorsque vous dépassez une limite, l'API cesse de vous servir pendant un moment et renvoie un HTTP 429 "Trop de requêtes" réponse au lieu de faire le travail.

Les limites se déclinent en quelques unités courantes, et vous pouvez d'abord atteindre n'importe laquelle d'entre elles :

Sur les API LLM, les deux qui piquent le plus souvent sont RPM et TPM, et ils sont indépendants. Cinquante petits appels de classification peuvent dépasser le RPM tout en touchant à peine le TPM ; un résumé de document de 100 000 jetons peut dépasser le TPM en une seule requête. Concevez en fonction du plafond que votre charge de travail atteint en premier.

Transformer une limite TPM en « combien d'utilisateurs puis-je servir ? »

La planification des capacités n’est qu’une question d’arithmétique. Commencez par les jetons un l'utilisateur consomme par minute, puis divisez votre limite par celle-ci.

• Jetons par demande = jetons d'entrée (invite + message système + contexte) plus jetons de sortie générés par le modèle. Les deux comptent contre le TPM.
• Requêtes par utilisateur et par minute = à quel point un utilisateur actif est bavard.
• Jetons par utilisateur et par minute = jetons par requête × requêtes par utilisateur et par minute.

Exemple : chaque tour de discussion utilise environ 1 500 entrées + ~ 500 sorties = 2 000 jetons, et un utilisateur actif envoie ~1,5 tours par minute → 3 000 jetons/utilisateur/minute. Avec un 300 000 TPM limite que vous pouvez servir environ 300 000 ÷ 3 000 = 100 utilisateurs actifs simultanés. Faites la même division par rapport à votre limite de RPM et prenez le plus petit des deux réponses – c’est votre véritable plafond. Notez que « actif » signifie l'envoi actif ; un produit avec 100 utilisateurs simultanés possède généralement des milliers de comptes connectés.

Niveaux : dépenser plus augmente vos limites

La plupart des fournisseurs fonctionnent niveaux d'utilisation. Les nouveaux comptes démarrent avec un RPM/TPM/RPD faible ; à mesure que vous dépensez plus et que votre compte vieillit, vous êtes automatiquement promu à des niveaux supérieurs avec des plafonds beaucoup plus élevés – parfois 10 × ou 100 × les numéros de départ. Si vous atteignez vos limites, les premières questions sont : à quel niveau suis-je et suis-je admissible au niveau suivant ? Les accords d'entreprise et d'engagement de dépenses peuvent abaisser davantage les limites ou ajouter de la capacité dédiée.

Des techniques qui optimisent votre débit effectif

• Traitement par lots - combinez de nombreux éléments en requêtes moins nombreuses et plus importantes pour réduire la pression RPM. Les API par lots dédiées des fournisseurs fonctionnent également à prix réduit pour les travaux non urgents.
• Streaming - La diffusion en continu des jetons n'augmente pas votre budget de jetons, mais elle réduit la latence perçue et libère les ressources client plus tôt, de sorte que les demandes qui se chevauchent sont supprimées plus rapidement.
• Retard et rythme - répartir les appels uniformément sur toute la minute au lieu de les lancer tous en même temps vous maintient sous des plafonds éclatants que vous auriez autrement trébuchés.
• Jetons de coupe - des invites plus courtes, une mise en cache des invites et des limites de sortie strictes augmentent directement le nombre de requêtes entrant dans un budget TPM fixe.

Gestion des 429 : interruption, tentatives et mise en file d'attente

Il est normal d'atteindre une limite : la question est de savoir si votre application récupère correctement. Le modèle standard est recul exponentiel avec gigue: sur un 429, attendez un peu, puis réessayez ; s'il échoue à nouveau, doublez environ le délai à chaque fois (par exemple 1 s, 2 s, 4 s, 8 s) et ajoutez un petit décalage aléatoire afin que de nombreux clients ne réessayent pas en même temps. Respectez toujours un Réessayer après en-tête si le fournisseur en envoie un – il vous indique exactement combien de temps attendre.

Limite dure vs limite douce/éclatée

UN limite stricte est un plafond absolu – dépassez-le et chaque demande est rejetée jusqu'à ce que la fenêtre se réinitialise. UN limite douce ou éclatée permet de courts pics au-dessus de votre taux constant (souvent via un seau à jetons qui se remplit au fil du temps), de sorte que de brèves rafales passent mais une surcharge soutenue est toujours limitée. Savoir à quoi vous faites face change votre stratégie : les limites de rafale récompensent le lissage du trafic sur la fenêtre ; les limites strictes nécessitent un réel file d'attente qui mesure les demandes à un tarif sûr.

• Mettre en file d'attente les travaux non urgents il s'écoule donc à un rythme contrôlé au lieu de marteler l'API.
• Répartir la charge uniformément plutôt que d'éclater au début de chaque minute.
• Limiter le nombre total de tentatives donc une requête vouée à l'échec échoue proprement au lieu de boucler indéfiniment.

L’aspect coût : les limites façonnent l’architecture, pas la facture

Les limites de taux ne coûtent pas d'argent directement : vous n'êtes jamais facturé pour un 429. Mais elles influencent fortement la façon dont vous construisez et ces choix. faire avoir un coût. Lorsqu'une seule clé ne peut pas fournir le débit dont vous avez besoin, les équipes recherchent généralement une chaîne de repli (basculement vers un deuxième modèle ou fournisseur lorsque le principal limite), plusieurs clés ou fournisseurs mutualiser les capacités, et un API par lots pour déplacer les travaux non urgents vers des voies moins chères et à limites plus élevées. Chacun ajoute de la résilience et de la marge, mais aussi de la complexité d’intégration et parfois un prix par jeton plus élevé en cas de repli. L’approche la plus saine consiste d’abord à augmenter votre niveau et à réduire les jetons, puis à ajouter de la redondance uniquement là où une limite stricte vous bloque réellement.

Questions fréquemment posées

Quelle est la différence entre RPM et TPM ?

Le RPM (requêtes par minute) limite le nombre d'appels d'API que vous pouvez effectuer chaque minute, tandis que le TPM (jetons par minute) limite la quantité de texte que ces appels peuvent déplacer. Vous pouvez d'abord atteindre l'un ou l'autre plafond : de nombreux petits appels épuisent le RPM, tandis que quelques appels à grand contexte épuisent le TPM.

Comment transformer une limite TPM en nombre d’utilisateurs que je peux servir ?

Estimez les jetons qu'un utilisateur consomme par minute (les jetons par requête multipliés par les requêtes par utilisateur et par minute, en comptant à la fois les entrées et les sorties), puis divisez votre limite TPM par ce chiffre. Si un utilisateur a besoin de 3 000 jetons/minute et que votre limite est de 300 000 TPM, vous pouvez servir environ 100 utilisateurs actifs simultanés.

Comment dois-je gérer une erreur 429 Too Many Requests ?

Réessayez avec un espacement exponentiel et une gigue : attendez progressivement plus longtemps entre les tentatives et respectez tout en-tête Retry-After renvoyé par le fournisseur. Mettez en file d'attente les travaux non urgents, répartissez la charge uniformément au lieu d'éclater et limitez le nombre total de tentatives afin qu'une requête finisse par échouer proprement plutôt que de boucler indéfiniment.