Limites de débit

Les limites de débit restreignent le nombre de fois qu’un utilisateur ou un client peut accéder à nos services via notre API pendant une période donnée.

Pourquoi imposons-nous des limites de débit ?

Les limites de débit sont courantes pour les API et sont mises en place pour plusieurs raisons :

• Elles contribuent à protéger l’API contre les abus et les utilisations inappropriées. Par exemple, un acteur malveillant pourrait submerger l’API de requêtes pour tenter de la surcharger ou de perturber le service. En fixant des limites de débit, OpenAI peut prévenir ce type d’activité.
• Les limites de débit contribuent à garantir un accès équitable à l’API pour tous. Si une personne ou une organisation envoie un nombre excessif de requêtes, cela peut ralentir l’API pour tous les autres. En limitant le nombre de requêtes qu’un même utilisateur peut envoyer, OpenAI permet au plus grand nombre d’utiliser l’API sans subir de ralentissements.
• Les limites de débit peuvent aider OpenAI à gérer la charge globale sur son infrastructure. Une forte augmentation des requêtes adressées à l’API peut surcharger les serveurs et entraîner des problèmes de performances. En fixant des limites de débit, OpenAI peut contribuer à maintenir une expérience fluide et constante pour tous les utilisateurs.

Comment fonctionnent ces limites de débit ?

Les limites de débit reposent sur des indicateurs tels que les RPM (requêtes par minute), les RPD (requêtes par jour), les TPM (tokens par minute), les TPD (tokens par jour), les IPM (images par minute) et, pour certains modèles audio en streaming, les minutes d’audio par minute. La limite qui s’applique est celle qui est atteinte en premier, quel que soit l’indicateur. Par exemple, vous pourriez envoyer 20 requêtes avec seulement 100 tokens au point de terminaison ChatCompletions et atteindre votre limite si elle est de 20 RPM, même sans avoir envoyé 150 000 tokens dans ces 20 requêtes si votre limite est de 150 000 TPM.

Les limites de file d’attente de l’API Batch sont calculées à partir du nombre total de tokens d’entrée en attente pour un modèle donné. Les tokens des tâches de traitement par lots en attente sont comptabilisés dans votre limite de file d’attente. Une fois une tâche de traitement par lots terminée, ses tokens ne sont plus comptabilisés dans la limite de ce modèle.

Autres points importants à retenir :

• Les limites de débit sont définies au niveau de l’organisation et du projet, et non de l’utilisateur.
• Les limites de débit varient selon le modèle utilisé.
• Pour les modèles à contexte long comme GPT-5.5, une limite de débit distincte s’applique aux requêtes à contexte long. Vous pouvez consulter ces limites dans la console développeur.
• OpenAI fixe une limite d’utilisation mensuelle approuvée pour chaque organisation. Celle-ci est distincte des limites de dépenses que vous pouvez configurer pour une organisation ou un projet.
• Certaines familles de modèles partagent des limites de débit. Tous les modèles regroupés sous une « limite partagée » sur la page des limites de votre organisation ont une limite de débit commune. Par exemple, si la limite partagée affichée est de 3,5 millions de TPM, tous les appels à l’un des modèles de cette liste sont comptabilisés dans ces 3,5 millions.
• L’ingestion dans les magasins vectoriels est également soumise à une limite de débit par identifiant de magasin vectoriel. /vector_stores/{vector_store_id}/files et /vector_stores/{vector_store_id}/file_batches partagent une limite de 300 requêtes par minute pour chaque magasin vectoriel. Pour ingérer de plus grands volumes, privilégiez /vector_stores/{vector_store_id}/file_batches.

Paliers d’utilisation

Vous pouvez consulter les limites de débit et d’utilisation de votre organisation dans la section Limites des paramètres de votre compte. À mesure que vos dépenses liées à notre API augmentent, nous vous faisons automatiquement passer au palier d’utilisation suivant. Cela entraîne généralement une augmentation des limites de débit pour la plupart des modèles.

Pour obtenir un aperçu des limites de débit par modèle, consultez la page des modèles.

Limites de débit dans les en-têtes

Vous pouvez consulter votre limite de débit sur la page de votre compte, mais aussi trouver des informations importantes sur vos limites de débit dans les en-têtes de la réponse HTTP, notamment le nombre de requêtes et de tokens restants, ainsi que d’autres métadonnées.

Les réponses peuvent inclure les champs d’en-tête suivants :

Les en-têtes relatifs aux tokens du projet peuvent être présents lorsqu’une limite de tokens s’applique au niveau du projet. L’en-tête Retry-After peut être présent dans les réponses 429 dues à une limite de débit temporaire et dans les réponses 503 dues à une surcharge temporaire du modèle. Cela ne signifie pas qu’une nouvelle tentative peut résoudre les erreurs de quota, de facturation ou d’autres erreurs nécessitant une intervention de l’utilisateur.

Limites de débit pour l’affinage

Les limites de débit pour l’affinage de votre organisation sont également consultables dans le tableau de bord et peuvent aussi être récupérées via l’API :

curl https://api.openai.com/v1/fine_tuning/model_limits \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Réduction des erreurs

Gérez les hausses rapides du trafic et la surcharge des modèles

L’API peut renvoyer slow_down lorsque votre débit de requêtes augmente trop vite, ou server_is_overloaded lorsque le modèle demandé est temporairement surchargé. Vérifiez le statut HTTP et error.code pour distinguer ces situations :

Si Retry-After est absent, augmentez le délai entre les tentatives et ajoutez un court délai aléatoire.

Une erreur slow_down peut survenir même lorsque votre trafic respecte les limites de requêtes par minute et de tokens par minute. Elle indique que le trafic a augmenté trop vite, et non que ces limites ont été atteintes.

En règle générale, dès que votre trafic atteint 1 million de tokens d’entrée par minute (TPM), ne l’augmentez pas de plus de 50 % toutes les 15 minutes. Le seuil exact auquel la limite de montée en charge s’applique peut varier selon le modèle et les conditions de trafic.

Les clients entreprises dont le trafic facturé à l’usage atteint régulièrement les limites de montée en charge peuvent envisager l’offre Scale pour bénéficier d’une capacité plus prévisible sur les modèles éligibles. Pour GPT-5.6 et les modèles ultérieurs, consultez Reserved Tier. Les offres de capacité ne changent pas la façon de gérer une réponse slow_down : respectez le délai indiqué par Retry-After lorsque cet en-tête est présent, réduisez le trafic, puis augmentez-le progressivement.

Mettez à jour les gestionnaires d’erreurs existants

Si votre application gérait les anciennes réponses de limitation de débit et de surcharge, vérifiez à la fois le statut HTTP et error.code :

• Sur les points de terminaison qui renvoyaient auparavant 503 avec le code slow_down dans les deux cas, les hausses rapides du trafic renvoient désormais 429 avec slow_down. La surcharge du modèle conserve le statut 503, mais utilise le code server_is_overloaded.
• Dans ces situations, les requêtes vidéo rejetées avant la création d’une tâche renvoyaient auparavant 429 avec le type invalid_request_error et le code rate_limit_exceeded. Les hausses rapides du trafic renvoient désormais 429 avec rate_limit_error et slow_down ; la surcharge du modèle renvoie 503 avec service_unavailable_error et server_is_overloaded. Les erreurs signalées dans l’état d’une tâche vidéo constituent un cas distinct.

Prenez en charge à la fois 429 et 503 dans vos gestionnaires d’erreurs du SDK. Par exemple, Python, TypeScript et Ruby utilisent RateLimitError pour 429 et InternalServerError pour 503 ; Java utilise RateLimitException et InternalServerException. Conservez la prise en charge des anciens codes de réponse tant que votre application peut encore les recevoir. D’autres erreurs peuvent utiliser les mêmes statuts HTTP : examinez donc le corps de la réponse d’erreur avant de choisir une mesure corrective.

Pour les requêtes en streaming, ces réponses d’erreur HTTP s’appliquent avant le démarrage du flux. Une erreur survenant après le début du streaming peut être transmise sous forme d’événement du flux ; ne relancez pas automatiquement une requête après avoir consommé des données de sortie.

Quelles mesures puis-je prendre pour réduire ces erreurs ?

L’OpenAI Cookbook propose un notebook Python qui explique comment éviter les erreurs de limite de débit, ainsi qu’un exemple de script Python permettant de respecter les limites de débit lors du traitement par lots de requêtes API.

Faites également preuve de prudence lorsque vous proposez un accès programmatique, des fonctionnalités de traitement en masse et la publication automatisée sur les réseaux sociaux. Envisagez de ne les activer que pour les clients de confiance.

Pour vous protéger contre les usages abusifs automatisés et à grande échelle, fixez une limite d’utilisation par utilisateur sur une période donnée (jour, semaine ou mois). Envisagez de mettre en place un plafond strict ou une procédure de vérification manuelle pour les utilisateurs qui dépassent cette limite.

Nouvelles tentatives avec délai exponentiel

Lorsqu’une requête dépasse une limite de débit temporaire, l’API renvoie une erreur 429. La réponse peut inclure un en-tête Retry-After qui indique le nombre de secondes à attendre avant de réessayer. Considérez cette valeur comme un minimum : attendez au moins ce délai et ajoutez un court délai aléatoire pour éviter que plusieurs clients ne réessaient en même temps.

Chaque SDK OpenAI officiel relance automatiquement les requêtes ayant reçu une réponse 429 ou 503 permettant une nouvelle tentative, selon ses paramètres de nouvelle tentative. La prise en charge de Retry-After, en particulier des délais longs, varie selon la version et la configuration du SDK. Vérifiez le comportement de la version installée au lieu de supposer que tous les délais indiqués par le serveur sont pris en charge.

Si un délai valide indiqué par le serveur dépasse le délai maximal de nouvelle tentative pris en charge ou configuré, arrêtez les tentatives et reportez la requête au lieu de réessayer plus tôt. Un SDK peut renvoyer l’erreur HTTP d’origine lorsqu’il refuse un délai supérieur à sa limite. Continuez à traiter séparément les erreurs d’annulation et d’expiration du délai : une requête annulée ou une échéance dépassée peut interrompre les tentatives sans renvoyer cette erreur HTTP. Un délai maximal pour chaque tentative ne constitue pas nécessairement une échéance pour l’ensemble de l’opération.

Si vous utilisez votre propre client HTTP, respectez le délai indiqué par Retry-After lorsque cet en-tête est présent et contient une valeur valide. S’il est absent ou invalide, utilisez un délai exponentiel avec une variation aléatoire. Limitez à la fois le nombre de tentatives et le temps total qui leur est consacré. Si vous gérez les nouvelles tentatives dans votre application, désactivez celles du SDK ou prenez-les en compte dans ces limites pour éviter que des boucles de tentatives imbriquées ne multiplient les requêtes. Ne réessayez pas en cas d’erreurs de quota, de facturation ou d’autres erreurs nécessitant une intervention de votre part.

Le délai exponentiel consiste à attendre brièvement après l’échec d’une requête, puis à augmenter le délai après chaque nouvelle tentative infructueuse. Ce processus se poursuit jusqu’à ce que la requête réussisse ou que la limite de tentatives configurée soit atteinte.

Cette approche présente de nombreux avantages :

• Les nouvelles tentatives automatiques permettent de reprendre après des erreurs de limite de débit sans plantage ni perte de données
• Le délai exponentiel permet d’effectuer rapidement les premières tentatives, tout en prévoyant des délais plus longs si celles-ci échouent
• L’ajout d’une variation aléatoire au délai permet d’éviter que toutes les tentatives aient lieu en même temps.

Les requêtes infructueuses sont prises en compte dans votre limite par minute. Renvoyer continuellement une requête ne résoudra donc pas le problème.

Les exemples Python ci-dessous illustrent le délai exponentiel utilisé en solution de repli. Ils n’examinent pas Retry-After : avant de les utiliser, ajoutez la prise en charge des indications valides du serveur pour que les fonctions d’encapsulation ne relancent pas les requêtes avant le délai demandé. Désactivez les nouvelles tentatives du SDK ou prenez-les en compte dans les limites de tentatives de votre application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19from openai import OpenAI
from tenacity import (
    retry,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

client = OpenAI()


@retry(wait=wait_random_exponential(min=1, max=60), stop=stop_after_attempt(6))
def completion_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completion_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16import backoff
import openai
from openai import OpenAI

client = OpenAI()


@backoff.on_exception(backoff.expo, openai.RateLimitError)
def completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completions_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59# imports
import random
import time

import openai
from openai import OpenAI

client = OpenAI()

# define a retry decorator


def retry_with_exponential_backoff(
    func,
    initial_delay: float = 1,
    exponential_base: float = 2,
    jitter: bool = True,
    max_retries: int = 10,
    errors: tuple = (openai.RateLimitError,),
):
    """Retry a function with exponential backoff."""

    def wrapper(*args, **kwargs):
        # Initialize variables
        num_retries = 0
        delay = initial_delay

        # Loop until a successful response or max_retries is hit or an exception is raised
        while True:
            try:
                return func(*args, **kwargs)

            # Retry on specific errors
            except errors:
                # Increment retries
                num_retries += 1

                # Check if max retries has been reached
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    )

                # Increment the delay
                delay *= exponential_base * (1 + jitter * random.random())

                # Sleep for the delay
                time.sleep(delay)

            # Raise exceptions for any errors not specified
            except Exception:
                raise

    return wrapper


@retry_with_exponential_backoff
def completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)

Réduisez max_tokens pour l’adapter à la taille de vos réponses

Votre limite de débit est calculée à partir de la plus grande des deux valeurs suivantes : max_tokens et le nombre de tokens estimé d’après le nombre de caractères de votre requête. Essayez de définir max_tokens au plus près de la taille de réponse attendue.

Regroupement des requêtes

Si votre cas d’utilisation ne nécessite pas de réponses immédiates, vous pouvez utiliser la Batch API pour soumettre et exécuter plus facilement de grands ensembles de requêtes sans affecter les limites de débit de vos requêtes synchrones.

Pour les cas d’utilisation qui nécessitent effectivement des réponses synchrones, l’API OpenAI impose des limites distinctes pour les requêtes par minute et les tokens par minute.

Si vous atteignez la limite de requêtes par minute, mais disposez encore d’une marge pour les tokens par minute, vous pouvez augmenter votre débit en regroupant plusieurs tâches dans chaque requête. Cela vous permettra de traiter davantage de tokens par minute, notamment avec nos modèles les plus petits.

L’envoi d’un lot de prompts fonctionne exactement comme un appel d’API classique, à ceci près que vous passez une liste de chaînes au paramètre prompt au lieu d’une seule chaîne. Pour en savoir plus, consultez le guide de la Batch API.