Limites de débit LLM : jetons par minute, requêtes par minute et ce qui se passe lorsque vous les atteignez ou les dépassez

Les API de modèle de langage limitent votre trafic de 2 façons à la fois : nombre de demandes que vous envoyez par minute (RPM) et combien de jetons vous utilisez par minute (TPM). Vous pouvez rester bien sous votre limite de requête et toujours être limité, car quelques prompts longs ont utilisé votre budget de tokens. Lorsque vous atteignez l’une ou l’autre limite, l’API répond avec 429 Too Many Requests et votre application doit attendre.

Comment OpenAI, Azure OpenAI et Anthropic comptent

Provider Limitations Éléments à connaître
OpenAI RPM, demandes par jour, TPM, jetons par jour, et bien plus, par organisation et par projet, par modèle Vous atteignez la limite qui est atteinte en premier. Pour la limite de jetons, une requête est comptabilisée selon la plus élevée des deux valeurs : max_tokens et une estimation en fonction de ses caractères. Le nombre de requêtes ayant échoué compte également.
Azure OpenAI TPM que vous affectez à chaque déploiement, ainsi qu’une limite RPM définie en proportion de celui-ci Le RPM est vérifié sur des intervalles de 1 ou 10 secondes, donc une rafale reçoit une erreur 429 même lorsque le total par minute est correct. L’estimation du token inclut max_tokens.
Anthropic RPM, jetons d’entrée par minute (ITPM) et jetons de sortie par minute (OTPM), par modèle La capacité se reconstitue en continu, et 60 RPM peuvent être appliqués sous la forme d’une requête par seconde. Pour la plupart des modèles, les jetons d’entrée mis en cache ne comptent pas vers ITPM et max_tokens ne compte pas vers OTPM.

Si vous définissez max_tokens sur 4 000 et récupérez 200 jetons, OpenAI et Azure OpenAI comptent toujours les 4 000 par rapport à votre limite. C’est ainsi que vous pouvez obtenir 429 si vos métriques d’utilisation sont bien inférieures à votre quota.

Ce que signifie un 429 pour chaque fournisseur

Tous les 429 ne disparaissent pas si vous attendez.

Provider Attendre et réessayer Arrêtez et parlez-en à quelqu’un
OpenAI 429 pour les demandes ou jetons, 429 slow_down (votre trafic a augmenté trop rapidement, même dans vos limites) et 503 server_is_overloaded. Attendez Retry-After lorsqu’il est présent. 429 avec credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceededou organization_usage_limit_exceeded en error.code. Une nouvelle tentative ne rétablira pas l’accès.
Azure OpenAI 429 pour le TPM ou RPM du déploiement, pour la capacité du système ou pour une réduction temporaire de votre limite de taux. Attente de retry-after-ms. Erreurs 429 persistantes en production malgré un usage inférieur à votre quota approuvé. Vérifiez l’allocation TPM du déploiement, puis ouvrez une demande de support.
Anthropic 429 rate_limit_error avec un en-tête retry-after, y compris les limites de débit après une forte augmentation de l’utilisation, et 529 overloaded_error. 429 pour le plafond mensuel des dépenses. Il n’a pas d’en-tête retry-after, error.details.error_code est enforced_spend_limit_reached, et il continue à échouer jusqu’à ce que l’accès reprenne.

Comment gérer les limites de débit LLM

  1. Vérifiez quel 429 vous avez obtenu. Les erreurs de facturation, de coûts et de quota ont besoin d’une personne, et non d’une nouvelle tentative.
  2. Attendez aussi longtemps que l’API le demande. OpenAI et Anthropic envoient retry-after en secondes. Azure OpenAI envoie retry-after-ms en millisecondes. Sans indicateur, augmentez exponentiellement le délai entre les tentatives avec une gigue aléatoire et limitez le nombre de tentatives et le temps total.
  3. Sachez ce que fait déjà votre Kit de développement logiciel (SDK). Les SDK Python OpenAI et Anthropic réessaient en cas d’erreurs de connexion et de réponses 408, 409, 429 et 5xx, 2 fois par défaut. Si vous ajoutez votre propre boucle de nouvelle tentative, désactivez les nouvelles tentatives du Kit de développement logiciel (SDK), par exemple avec max_retries=0 dans Python, comme le recommande Azure OpenAI, ou les tentatives se multiplient.
  4. Réduisez ce qui compte. Sur OpenAI et Azure OpenAI, définissez max_tokens sur une valeur proche de la taille de réponse attendue. Sur Anthropic, cachez du contenu répété comme les instructions système.
  5. Augmentez progressivement. Une forte hausse du trafic déclenche les limites d’accélération du débit d’OpenAIslow_down et d’Anthropic, même si vous respectez vos propres limites. OpenAI suggère qu’une fois que vous atteignez 1 million de jetons d’entrée par minute, vous augmentez de pas plus de 50 % toutes les 15 minutes.
  6. Ne relisez pas un flux que vous avez déjà consommé. Une erreur après le démarrage d’un flux peut arriver en tant qu’événement de flux, et OpenAI déconseille de relancer automatiquement une requête après avoir consommé la sortie.
  7. Indiquez à l’utilisateur quand une demande se bloque sur un 429, au lieu d’afficher un spinner.

Comment tester que votre application gère les limites de débit LLM

Approach Ce que vous trouvez Ce qui vous manque
Simuler le client SDK dans vos tests, ou laisser votre agent de codage écrire la simulation Si votre branche d’erreur s’exécute Les codes d’état réels du fournisseur, les codes d’erreur du fournisseur et les en-têtes du fournisseur, ainsi que les nouvelles tentatives de votre Kit de développement logiciel (SDK). Votre application a également besoin d’un commutateur réservé aux tests pour atteindre le mock.
Appelez l’API réelle jusqu’à ce qu’elle applique une limitation de débit Comportement réel Vous payez pour chaque jeton, et vous ne pouvez pas déclencher slow_down, une surcharge ou une limite de dépense sur demande
Interceptez le trafic réel de votre application et renvoyez les erreurs du fournisseur, ou appliquez une limitation en fonction des jetons que votre application utilise Des URL réelles, la politique de nouvelle tentative de votre SDK et les corps de réponse d’erreur du fournisseur, avec une limite que vous choisissez Votre code isolé. Conservez vos tests unitaires pour cela.

Essayez-le sur votre application

Dev Proxy intercepte les requêtes de votre application à l’API du modèle de langage et retourne les propres erreurs du fournisseur, tandis que votre application continue d’appeler l’URL réelle. Pour OpenAI, téléchargez le préréglage et démarrez le proxy de développement avec celui-ci :

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

Le openai-throttling préréglage échoue sur 90 % des requêtes vers https://api.openai.com/* avec une erreur aléatoire : rate_limit_exceeded pour TPM ou RPM, slow_down, credit_balance_exhausted ou 503 server_is_overloaded. Le anthropic-throttling préréglage fait la même chose pour https://api.anthropic.com/* avec les limites de RPM, de jetons d’entrée, de jetons de sortie, ainsi que les erreurs 429 d’accélération et 529 overloaded_error. Les deux préréglages incluent RetryAfterPlugin, ce qui vous indique quand votre application appelle à nouveau l’API avant l’expiration du délai retry-after d’une erreur 429. Elle ne vérifie pas les réponses 503 et 529.

Pour appliquer une limitation de débit selon les jetons réellement utilisés par votre application, utilisez le module d’extension LanguageModelRateLimitingPlugin. Il compte les jetons d’invite et de complétion que chaque réponse signale et retourne 429 avec retry-after lorsque votre application dépasse les limites que vous avez définies. Il fonctionne avec les API compatibles OpenAI, notamment Azure OpenAI et les modèles locaux :

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "LanguageModelRateLimitingPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "languageModelRateLimitingPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.openai.com/*",
    "https://*.openai.azure.com/openai/deployments/*/chat/completions*"
  ],
  "languageModelRateLimitingPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/languagemodelratelimitingplugin.schema.json",
    "promptTokenLimit": 1000,
    "completionTokenLimit": 500,
    "resetTimeWindowSeconds": 60
  }
}

Le plug-in ne reproduit pas l’estimation max_tokens . Le corps de réponse 429 par défaut utilise le code insufficient_quota. Pour retourner le corps d’erreur attendu par votre application pour une limite de débit, définissez whenLimitExceeded sur Custom et pointez customResponseFile sur votre propre réponse. Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étapes suivantes

Voir aussi