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 qu'il faut 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 le délai indiqué par Retry-After, s'il est présent, puis réessayez en augmentant progressivement les délais d'attente.

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 effectue une nouvelle tentative à chaque erreur 429, elle continue de réessayer des requêtes qui échouent pour des raisons de facturation et qui ne pourront jamais aboutir. 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 couvrent les pics de courte durée. 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. En Python, une erreur 429 déclenche RateLimitError et une erreur 503 déclenche InternalServerError ; vous devez 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 propose un préréglage contenant les erreurs OpenAI répertoriées 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"

Ce préréglage fait échouer 90 % des requêtes vers https://api.openai.com/* en renvoyant une erreur aléatoire parmi celles du tableau. Pour les réponses de limitation de débit, il définit l'en-tête Retry-After et utilise RetryAfterPlugin pour vérifier que votre application attend bien la durée indiquée 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 rate_limit_exceeded ou slow_down, votre application attend pendant la durée Retry-After. Si elle appelle l'API trop tôt, Dev Proxy le signale et limite le débit de 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 server_is_overloaded erreur, votre application attend le Retry-After temps avant de réessayer. Si elle appelle l'API trop tôt, Dev Proxy le signale et limite le débit de la requête. Lorsque les tentatives sont épuisées, votre application bascule sur une solution de repli 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 :