Limites de débit

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

Pourquoi appliquer des limites de débit ?

Les limites de débit sont courantes dans les API et répondent à plusieurs besoins.

• Elles contribuent à protéger l’API contre les abus et les usages inappropriés. Par exemple, une personne malveillante pourrait inonder l’API de requêtes pour tenter de la surcharger ou de perturber le service. Les limites de débit permettent à OpenAI de prévenir ce type d’abus.
• Les limites de débit contribuent à garantir un accès équitable à l’API. Si une personne ou une organisation envoie un nombre excessif de requêtes, l’API risque de ralentir pour tous les autres utilisateurs. En plafonnant le nombre de requêtes par utilisateur, OpenAI permet au plus grand nombre d’utiliser l’API sans subir de ralentissements.
• Les limites de débit aident OpenAI à gérer la charge globale de son infrastructure. Une forte hausse du nombre de requêtes adressées à l’API risque de surcharger les serveurs et de dégrader les performances. En fixant des limites de débit, OpenAI contribue à maintenir un service fluide et stable pour tous les utilisateurs.

Comment fonctionnent les limites de débit ?

Les limites de débit reposent sur plusieurs indicateurs : RPM (requêtes par minute), RPD (requêtes par jour), TPM (tokens par minute), TPD (tokens par jour), IPM (images par minute) et, pour certains modèles audio en streaming, le nombre de minutes d’audio par minute. La première limite atteinte s’applique. Par exemple, si vos limites sont de 20 RPM et de 150 000 TPM, il suffit d’envoyer 20 requêtes au point de terminaison ChatCompletions en une minute pour atteindre votre limite de requêtes, même si ces requêtes ne représentent que 100 tokens au total.

Pour l’API Batch, la limite de la file d’attente dépend du nombre total de tokens d’entrée en attente pour un modèle donné. Les tokens des tâches de traitement par lot en attente sont comptabilisés dans cette limite. Dès qu’une tâche se termine, ses tokens cessent de compter dans la limite du modèle.

Autres points à retenir :

• Les limites de débit s’appliquent au niveau de l’organisation et du projet, et non à chaque utilisateur.
• Les limites de débit varient selon le modèle utilisé.
• Pour les modèles à long contexte comme GPT-5.5, les requêtes à long contexte ont leur propre limite de débit. Vous pouvez consulter ces limites dans la console de développement.
• OpenAI fixe un plafond mensuel d’utilisation autorisée pour chaque organisation. Ce plafond est distinct 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. Sur la page des limites de votre organisation, les modèles regroupés sous une même « limite partagée » ont une limite de débit commune. Par exemple, si la limite partagée affichée est de 3,5 millions de TPM, les tokens de tous les appels aux modèles de cette liste sont comptabilisés dans ces 3,5 millions.
• L’ingestion de données dans un magasin de vecteurs est également soumise à une limite de débit par identifiant de magasin. Les points de terminaison /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. Pour importer de gros volumes de données, privilégiez /vector_stores/{vector_store_id}/file_batches.

Niveaux d’utilisation

Les trois niveaux d’utilisation payants sont Build, Launch et Grow. Votre organisation passe automatiquement au niveau supérieur lorsque le montant cumulé de ses achats de crédits atteint le seuil correspondant. Les niveaux supérieurs offrent généralement des limites de débit plus élevées pour les différents modèles.

Limites de débit du mode Standard

Pour connaître les limites de chaque modèle à votre niveau d’utilisation, ouvrez Settings > Organization > Limits et consultez Rate limits. Pour passer au niveau supérieur, sélectionnez Upgrade tier dans la section Usage Tiers.

Les limites de débit du mode Standard diffèrent des limites de débit du mode Ultrafast.

Limites de dépenses

Pour maîtriser vos dépenses mensuelles liées à l’API, envisagez de fixer des limites de dépenses pour votre organisation ou vos projets. Ces paramètres sont indépendants des limites d’utilisation mensuelles indiquées ci-dessus.

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

Vous pouvez consulter vos limites de débit sur la page de votre compte. Les en-têtes de la réponse HTTP fournissent aussi des informations sur ces limites, notamment le nombre de requêtes et de tokens encore disponibles, ainsi que d’autres métadonnées.

Les réponses peuvent contenir 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 projet. L’en-tête Retry-After peut figurer 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. Sa présence ne signifie pas qu’une nouvelle tentative résoudra une erreur de quota, de facturation ou toute autre erreur nécessitant une intervention de votre part.

Limites de débit pour le fine-tuning

Vous pouvez consulter les limites de débit de votre organisation pour le fine-tuning dans le tableau de bord ou les récupérer via l’API :

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

Disponibilité des modèles

L’accès aux modèles et les limites de débit sont indépendants. Atteindre le seuil d’un niveau d’utilisation ne donne pas accès à tous les modèles. Si un modèle répertorié dans la documentation n’apparaît pas dans Playground ou dans la réponse à GET /v1/models, ou si une requête renvoie model_not_found, procédez comme suit :

1. Vérifiez l’identifiant du modèle et le point de terminaison. Utilisez l’identifiant exact indiqué dans la documentation du modèle. Vérifiez que le modèle prend en charge votre point de terminaison et consultez les éventuels avis de retrait ou de disponibilité.
2. Comparez l’organisation, le projet et les informations d’authentification utilisés. Dans Playground, sélectionnez l’organisation et le projet visés. Appelez List models avec la même clé API que la requête qui a échoué et reprenez les en-têtes OpenAI-Organization et OpenAI-Project si cette requête les utilisait. Un modèle visible dans votre session du tableau de bord peut être inaccessible avec une autre clé API.
3. Vérifiez les restrictions du projet et les conditions d’accès au modèle. Demandez à une personne habilitée à gérer le projet de vérifier les autorisations d’accès aux modèles et les paramètres de conservation des données du projet. Respectez les éventuelles conditions d’accès propres au modèle et consultez les avis de déploiement dans sa documentation. L’absence d’un modèle ne suffit pas à en déterminer la cause.
4. Actualisez la liste et vérifiez de nouveau. Après avoir modifié les paramètres d’accès, actualisez la liste des modèles ou Playground. Si le modèle reste indisponible, contactez l’assistance. Indiquez les identifiants du modèle, de l’organisation et du projet, l’heure de la requête, le message d’erreur et, si vous en disposez, l’en-tête de réponse x-request-id. Ne communiquez pas votre clé API.

Prévention et gestion des erreurs

Gérez les hausses rapides de trafic et les surcharges de modèles

L’API peut renvoyer slow_down lorsque la fréquence de vos requêtes augmente trop vite, ou server_is_overloaded lorsque le modèle demandé est temporairement surchargé. Pour distinguer ces deux cas, vérifiez le statut HTTP et error.code :

En l’absence de Retry-After, augmentez le délai entre les tentatives et ajoutez un court délai aléatoire.

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

En règle générale, dès que votre trafic atteint 1 million de tokens d’entrée par minute (TPM), limitez sa hausse à 50 % par tranche de 15 minutes. Le seuil exact à partir duquel cette limite de montée en charge s’applique peut varier selon le modèle et les conditions de trafic.

Si vous êtes client Enterprise et que votre trafic facturé à l’usage atteint régulièrement les limites de montée en charge, envisagez 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 l’offre Reserved Tier. Quelle que soit l’offre de capacité, la marche à suivre en cas de réponse slow_down reste la même : respectez le délai indiqué par Retry-After s’il est présent, réduisez le trafic, puis augmentez-le progressivement.

Mettez à jour vos gestionnaires d’erreurs existants

Si votre application prenait en charge les anciennes réponses signalant une limitation du trafic ou une 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, une hausse trop rapide du trafic renvoie désormais 429 avec slow_down. Une surcharge du modèle renvoie toujours 503, mais avec le code server_is_overloaded.
• Dans ces deux cas, 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. Une hausse trop rapide du trafic renvoie désormais 429 avec rate_limit_error et slow_down. Une surcharge du modèle renvoie 503 avec service_unavailable_error et server_is_overloaded. Les erreurs signalées dans le statut d’une tâche vidéo constituent un cas distinct.

Prenez en charge 429 et 503 dans les gestionnaires d’erreurs de votre SDK. Par exemple, les SDK Python, TypeScript et Ruby utilisent RateLimitError pour 429 et InternalServerError pour 503. Le SDK Java utilise respectivement RateLimitException et InternalServerException. Continuez à gérer les anciens codes de réponse tant que votre application est susceptible de les recevoir. D’autres erreurs peuvent renvoyer les mêmes statuts HTTP. Examinez donc le corps de l’erreur avant de décider de la marche à suivre.

Pour les requêtes en streaming, ces réponses d’erreur HTTP s’appliquent avant le début du flux. Une fois le flux ouvert, une erreur peut vous parvenir sous forme d’événement dans le flux. Si vous avez déjà consommé des données du flux, ne renvoyez pas automatiquement la requête.

Comment réduire le risque d’erreur ?

L’OpenAI Cookbook propose un notebook Python qui explique comment éviter les erreurs de limite de débit. Vous y trouverez aussi un exemple de script Python pour traiter des requêtes API par lots tout en respectant ces limites.

Faites également preuve de prudence lorsque vous proposez un accès par programmation, des fonctionnalités de traitement en masse ou la publication automatique sur les réseaux sociaux. Envisagez de réserver ces fonctionnalités aux clients de confiance.

Pour prévenir les abus automatisés ou à grande échelle, fixez une limite d’utilisation par utilisateur sur une période donnée (jour, semaine ou mois). Envisagez d’appliquer un plafond strict ou de mettre en place une vérification manuelle pour les utilisateurs qui dépassent la limite.

Espacez les tentatives avec un 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 contenir un en-tête Retry-After qui indique le nombre de secondes à attendre avant de réessayer. Attendez au moins le temps indiqué et ajoutez un court délai aléatoire pour éviter que plusieurs clients réessaient au même moment.

Chaque SDK officiel d’OpenAI relance automatiquement les requêtes ayant reçu une réponse 429 ou 503 lorsque celle-ci se prête à une nouvelle tentative et que les paramètres du SDK le permettent. La prise en charge de Retry-After, en particulier pour les délais longs, varie selon la version et la configuration du SDK. Vérifiez le comportement de la version installée avant de supposer qu’elle respecte tous les délais indiqués par le serveur.

Si le serveur indique un délai valide qui dépasse le délai maximal pris en charge ou configuré, cessez les tentatives et reportez la requête pour éviter de la relancer trop 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 annulations et les dépassements de délai : si la requête est annulée ou si son échéance est dépassée, les tentatives peuvent s’arrêter sans que le SDK renvoie cette erreur HTTP. Un délai maximal par tentative ne fixe 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 l’en-tête est présent et que sa valeur est valide. Si l’en-tête est absent ou sa valeur invalide, appliquez 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 votre application gère les nouvelles tentatives, désactivez celles du SDK ou comptabilisez-les dans ces limites pour éviter que des boucles imbriquées multiplient les requêtes. Ne relancez pas une requête en cas d’erreur de quota, de facturation ou de toute autre erreur nécessitant une intervention de votre part.

Avec un délai exponentiel, vous attendez brièvement après l’échec d’une requête, puis vous augmentez le délai après chaque nouvelle tentative infructueuse. Vous procédez ainsi jusqu’à ce que la requête aboutisse ou que la limite de tentatives configurée soit atteinte.

Cette approche présente plusieurs avantages :

• Les tentatives automatiques permettent de reprendre après une erreur de limite de débit sans plantage ni perte de données.
• Avec un délai exponentiel, les premières tentatives se succèdent rapidement et les suivantes s’espacent si les premières échouent.
• Une variation aléatoire du délai évite que toutes les nouvelles tentatives aient lieu au même moment.

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

Les exemples suivants montrent comment relancer une requête utilisant le modèle gpt-6-luna via l’API Responses. Chaque fonction d’encapsulation limite le nombre de tentatives et désactive les nouvelles tentatives automatiques du SDK.

Les exemples Python ci-dessous illustrent la stratégie de repli qui consiste à espacer les tentatives. Ils ne vérifient pas Retry-After. Avant de les utiliser, ajoutez la prise en charge des délais valides indiqués par le serveur pour que les fonctions d’encapsulation ne relancent pas les requêtes trop tôt. Désactivez les nouvelles tentatives du SDK ou comptabilisez-les dans les limites de votre application.

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
28from openai import OpenAI, RateLimitError
from tenacity import (
    retry,
    retry_if_exception_type,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

client = OpenAI(max_retries=0)


@retry(
    retry=retry_if_exception_type(RateLimitError),
    wait=wait_random_exponential(min=1, max=60),
    stop=stop_after_attempt(6),
    reraise=True,
)
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

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

client = OpenAI(max_retries=0)


@backoff.on_exception(backoff.expo, openai.RateLimitError, max_tries=6)
def response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

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
60
61
62
63
64
65
66
67
68# imports
import random
import time

import openai
from openai import OpenAI

client = OpenAI(max_retries=0)

# 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 response_with_backoff(**kwargs):
    return client.responses.create(**kwargs)


response = response_with_backoff(
    model="gpt-6-luna",
    input="Say hello in one sentence.",
    reasoning={"effort": "none"},
    max_output_tokens=64,
)
print(response.output_text)

Réduisez max_tokens en fonction de la taille des réponses attendues

Pour le calcul de votre limite de débit, l’API retient la plus élevée des deux valeurs suivantes : max_tokens et le nombre de tokens estimé à partir du nombre de caractères de votre requête. Réglez max_tokens au plus près de la taille de réponse attendue.

Regroupez les requêtes par lots

Si votre cas d’usage ne nécessite pas de réponse immédiate, utilisez l’API Batch pour soumettre et exécuter un grand nombre de requêtes sans entamer vos limites de débit pour les requêtes synchrones.

Si votre cas d’usage exige des réponses synchrones, l’API d’OpenAI applique des limites distinctes aux requêtes par minute et aux tokens par minute.

Si vous atteignez la limite de requêtes par minute mais disposez encore de tokens par minute, augmentez votre débit en regroupant plusieurs tâches dans chaque requête. Vous pourrez ainsi traiter davantage de tokens par minute, en particulier avec nos modèles de plus petite taille.

L’envoi d’un lot de prompts fonctionne comme un appel API ordinaire. La seule différence est que vous passez au paramètre prompt une liste de chaînes de caractères au lieu d’une seule chaîne. Consultez le guide de l’API Batch pour en savoir plus.