Tester la façon dont votre application gère les limites de débit OpenAI

En un clin d’œil
Objectif : Testez la façon dont votre application gère la limite de requêtes OpenAI et les erreurs de surcharge
Heure : 10 minutes
Plugins :GenericRandomErrorPlugin, RetryAfterPlugin
Prérequis :configurer le proxy de développement

Votre application fonctionne en développement, puis échoue en production avec 429 Too Many Requests. Les limites de débit OpenAI dépendent du niveau d’utilisation de votre organisation, de votre modèle et de tous les autres utilisateurs de la même organisation. Vous ne pouvez donc pas les atteindre de manière fiable exprès. Le proxy de développement retourne les mêmes erreurs que celles retournées par l’API OpenAI. Vous pouvez donc voir ce que fait votre application avant que vos utilisateurs ne le fassent.

Savoir ce que retourne OpenAI

Toutes les erreurs OpenAI ne signifient pas forcément « réessayer ». Votre application doit les distinguer.

Status error.code Ce que cela signifie Ce que votre application doit faire
429 rate_limit_exceeded Vous avez atteint la limite de requêtes par minute (RPM) ou de jetons par minute (TPM). Attendez l’heure indiquée dans l’en-tête Retry-After, puis réessayez.
429 slow_down Votre taux de requête a augmenté trop rapidement, même si vous êtes dans vos limites. Attendez Retry-After, réduisez votre taux de requête et augmentez-le progressivement.
429 credit_balance_exhausted Votre organisation n’a plus de crédits prépayés. Ne réessayez pas. Une nouvelle tentative ne rétablira pas l’accès. Indiquez à l’utilisateur ou alertez un administrateur.
503 server_is_overloaded Le modèle n’a pas suffisamment de capacité pour l’instant. Attendez Retry-After s’il est présent, puis réessayez avec des délais croissants.

Pour obtenir la liste complète, consultez les codes d’erreur dans la documentation OpenAI.

Important

Toutes les 3 erreurs dans les 429 lignes utilisent le même code d’état. Si votre application réessaie à chaque code 429, elle continue à réessayer les erreurs de facturation qui ne se résorbent jamais. Vérifiez error.code pour décider quoi faire.

Découvrez ce que le SDK OpenAI peut faire pour vous

Les SDK OpenAI officiels pour Python et JavaScript effectuent par défaut 2 nouvelles tentatives en cas de réponses 408, 409, 429 et 5xx, ainsi que d’erreurs de connexion, avec une temporisation exponentielle. Vous pouvez changer cela avec l’option max_retries en Python et maxRetries en JavaScript.

Les nouvelles tentatives du SDK prennent en charge de courtes périodes de pics. Votre application doit toujours déterminer ce qui se passe lorsque les tentatives de nouvelle exécution sont épuisées et comment gérer les erreurs que les nouvelles tentatives ne corrigent pas. Dans Python, un 429 lève RateLimitError et un 503 lève InternalServerError, donc gérer les deux.

Tip

Pour voir exactement ce que votre code de gestion des erreurs reçoit, définissez max_retries=0 (Python) ou maxRetries: 0 (JavaScript) lors de vos tests. Réactivez ensuite les tentatives automatiques du SDK.

Simuler des limites de débit OpenAI

Dev Proxy a un préréglage avec les erreurs OpenAI dans le tableau. Téléchargez-le :

devproxy config get openai-throttling

Démarrez le proxy de développement avec le préréglage :

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

Le préréglage échoue pour 90 % des requêtes vers https://api.openai.com/*, avec une erreur aléatoire provenant du tableau. Pour les réponses de limitation du débit, il définit l’en-tête Retry-After et utilise RetryAfterPlugin pour vérifier que votre application attend ce délai avant d’appeler à nouveau l’API.

Assurez-vous que votre application envoie ses requêtes via Dev Proxy et fait confiance au certificat Dev Proxy. Pour Node.js, consultez Utiliser le proxy de développement avec des applications Node.js. Pour d’autres runtimes, consultez Résoudre les problèmes liés au proxy de développement.

Exécutez votre application et vérifiez que :

  • Après une erreur slow_down ou rate_limit_exceeded, votre application attend le Retry-After temps. S’il appelle l’API trop tôt, Dev Proxy le signale et limite la requête.
  • Après une credit_balance_exhausted erreur, votre application cesse d’appeler l’API et affiche un message clair.
  • Après une erreur server_is_overloaded, votre application effectue une nouvelle tentative avec un délai et, lorsque les tentatives sont épuisées, bascule sur une solution de secours ou affiche un message clair au lieu d’une trace de pile.
  • Votre application ne vous fait pas perdre votre travail. Par exemple, une longue conversation de chat ou un travail de traitement par lots se poursuit après l’erreur.

Pour modifier la fréquence à laquelle les requêtes échouent, utilisez l’option --failure-rate . Par exemple, pour faire échouer chaque requête :

devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json" --failure-rate 100

Simuler des limites de jetons pour Azure OpenAI et d’autres fournisseurs

Le préréglage retourne des erreurs au hasard, quel que soit le nombre de jetons que votre application utilise. Pour limiter les demandes en fonction de l’utilisation réelle du token, par exemple pour voir ce qui se passe quand une longue conversation dépasse votre limite TPM, utilisez LanguageModelRateLimitingPlugin. Il fonctionne avec n’importe quelle API compatible OpenAI, notamment Azure OpenAI et les modèles locaux. Pour plus d’informations, consultez Limites des jetons de modèle de langage de test.

Étape suivante

Découvrez comment simuler des limites basées sur les tokens.

Tester les limites de jetons du modèle de langage

Voir aussi

  • Dernière mise à jour :