Limites de taux de l'API GPT : niveaux, plafonds d'utilisation et tests avec Apidog

Vous déployez une fonction qui appelle l'API GPT. Elle fonctionne en staging. Les cent premiers utilisateurs arrivent en production, puis vos logs se remplissent de 429 Too Many Requests. Avant de modifier votre code, identifiez la limite exacte : requêtes par minute, jetons par minute, plafond journalier, niveau d'utilisation, ou limite spécifique au modèle.

Essayez Apidog aujourd’hui

💡 Objectif : vérifier vos limites GPT en direct, reproduire un dépassement contrôlé, puis enregistrer un scénario Apidog que votre équipe peut relancer dès qu'un problème de limite de débit apparaît.

Si vous avez déjà travaillé avec OpenAI, vous savez que les limites varient selon le modèle, le point de terminaison et le niveau d'utilisation. GPT-5.5 n'a pas forcément les mêmes plafonds que GPT-4.1, les modèles d'images ne sont pas comptabilisés comme les modèles de texte, et votre niveau peut évoluer avec vos dépenses. Apidog vous permet d'inspecter les en-têtes de réponse, de simuler du trafic concurrent et de confirmer quelle limite vous atteignez avant de déployer.

Les quatre limites à surveiller

OpenAI applique plusieurs limites à chaque clé API GPT. En production, vous rencontrerez surtout :

• RPM (requests per minute) : nombre d'appels API autorisés par minute.
• TPM (tokens per minute) : total des jetons d'entrée et de sortie traités par minute.
• RPD (requests per day) : plafond journalier, surtout présent sur les comptes gratuits et certains niveaux bas.
• IPM / TPD / file d'attente batch : limites spécifiques aux images, à l'audio, aux embeddings et aux traitements par lots.

Quand une requête est refusée, l'API renvoie généralement un 429 avec un corps JSON proche de celui-ci :

{
  "error": {
    "message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
    "type": "tokens",
    "param": null,
    "code": "rate_limit_exceeded"
  }
}

La clé à lire en premier est la dimension dépassée :

• tokens : dépassement TPM.
• requests : dépassement RPM.
• tokens_usage_based : dépassement lié à l'utilisation de jetons.

Un 429 n'a donc pas toujours la même cause. Un dépassement de RPM se corrige avec du contrôle de concurrence. Un dépassement de TPM se corrige plutôt avec des prompts plus courts, du cache ou du découpage de requête.

Pour le comportement HTTP général, consultez la documentation MDN sur le 429 et la RFC 6585. Pour les détails OpenAI, gardez aussi la page officielle sur les limites de débit à portée de main.

Comprendre les niveaux d'utilisation

Votre clé API appartient à une organisation OpenAI, elle-même associée à un niveau d'utilisation. Ce niveau détermine les plafonds RPM et TPM disponibles.

La progression dépend généralement de deux facteurs :

1. Le montant total payé.
2. Le délai écoulé depuis le premier paiement.

Structure indicative pour les modèles de texte :

Niveau	Seuil de dépense	Délai d'attente	RPM Texte	TPM Texte
Free	aucun	aucun	3	40k
1	5 $ payés	aucun	500	30k–200k selon le modèle
2	50 $ payés	7 jours	5,000	450k
3	100 $ payés	7 jours	5,000	1M
4	250 $ payés	14 jours	10,000	2M
5	1 000 $ payés	30 jours	10,000	2M+

Ces chiffres sont illustratifs. Les limites exactes changent selon les modèles et dans le temps. Pour dimensionner une charge réelle, lisez toujours les limites depuis les en-têtes de réponse de vos propres appels API.

Deux points pratiques :

1. La promotion est automatique. Une fois le seuil de paiement et le délai atteints, les nouvelles limites s'appliquent sans migration explicite.
2. Un déclassement est possible. Une inactivité longue, un problème de paiement ou un changement de facturation peut modifier vos plafonds. Après tout changement de facturation, refaites un test.

Pour comparer avec d'autres fournisseurs, vous pouvez lire aussi notre explication des limites de débit utilisateur de l'API OpenAI, le guide des limites de débit de l'API Claude et le guide des limites de débit de l'API Grok-3.

Lire vos limites depuis les en-têtes de réponse

Chaque réponse GPT contient des en-têtes utiles pour diagnostiquer vos plafonds :

• x-ratelimit-limit-requests : plafond RPM.
• x-ratelimit-remaining-requests : requêtes restantes dans la fenêtre courante.
• x-ratelimit-limit-tokens : plafond TPM.
• x-ratelimit-remaining-tokens : jetons restants dans la fenêtre courante.
• x-ratelimit-reset-requests : durée avant réinitialisation côté requêtes.
• x-ratelimit-reset-tokens : durée avant réinitialisation côté jetons.

Exemples de valeurs possibles :

x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 497
x-ratelimit-limit-tokens: 30000
x-ratelimit-remaining-tokens: 28432
x-ratelimit-reset-tokens: 6s

La méthode la plus fiable consiste à envoyer une requête minimale, puis à lire ces en-têtes.

Étape 1 : créer une requête GPT dans Apidog

Dans Apidog :

1. Créez un projet.
2. Ajoutez une nouvelle requête.
3. Configurez-la comme suit :

POST https://api.openai.com/v1/chat/completions

Dans l'onglet Headers :

Clé	Valeur
Authorization	Bearer {{OPENAI_API_KEY}}
Content-Type	application/json

La syntaxe {{OPENAI_API_KEY}} utilise une variable d'environnement Apidog. Votre clé n'est donc pas codée en dur dans la requête.

Vous pouvez créer plusieurs environnements :

• local
• staging
• production
• team-key
• personal-key

Ensuite, changez simplement d'environnement pour tester différentes clés ou organisations.

Dans l'onglet Body, choisissez JSON et collez :

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "user",
      "content": "ping"
    }
  ],
  "max_tokens": 10
}

Cliquez sur Send.

Dans le panneau de réponse, ouvrez l'onglet des en-têtes et cherchez les lignes x-ratelimit-*. Ces valeurs sont votre base de diagnostic.

Si vous voulez tester plus de cas, le guide comment tester l'API ChatGPT avec Apidog couvre aussi l'authentification, le streaming et les appels d'outils.

Étape 2 : confirmer le RPM avec un pic contrôlé

Lire les en-têtes donne le plafond théorique. Pour vérifier le comportement réel, exécutez un petit test de charge.

Dans Apidog :

1. Ouvrez la requête enregistrée.
2. Cliquez sur le menu à côté de Send.
3. Lancez-la dans un scénario de test.
4. Configurez par exemple :

Itérations : 50
Concurrence : 10
Délai entre itérations : 0 ms

Interprétez les résultats :

• Si certaines requêtes renvoient 429, ouvrez leur corps JSON et vérifiez si le message mentionne requests per min.
• Si les 50 requêtes passent, regardez x-ratelimit-remaining-requests pour confirmer la décrémentation.

Le scénario enregistre chaque réponse. Triez par code HTTP pour isoler les 429, puis lisez le champ message.

Pour une vue plus large des erreurs de limite, consultez le guide limite de débit dépassée.

Étape 3 : tester séparément le TPM

Le test précédent utilise de petites requêtes. Il mesure surtout le RPM.

Pour tester le TPM, gardez moins de requêtes, mais augmentez la taille du contexte :

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "system",
      "content": "<3,000 tokens of context here>"
    },
    {
      "role": "user",
      "content": "Summarise the above in one sentence."
    }
  ],
  "max_tokens": 200
}

Lancez ensuite un scénario plus modéré :

Itérations : 20
Concurrence : 5
Délai entre itérations : 0 ms

Si vous êtes sur un niveau avec un TPM bas, vous atteindrez probablement la limite de jetons avant la limite de requêtes.

La correction dépend de la limite touchée :

Limite touchée	Symptôme	Correction
RPM	Beaucoup de petites requêtes	File d'attente, batch, contrôle de concurrence
TPM	Moins de requêtes, mais très grosses	Réduire les prompts, découper, mettre en cache
RPD	Blocage après un volume journalier	Reporter, changer de niveau, déplacer la charge
Facturation	Message de quota ou billing	Vérifier le tableau de bord de facturation

Étape 4 : simuler des utilisateurs concurrents

Un pic fixe est utile, mais la production est plus irrégulière :

• tailles de prompts variables ;
• utilisateurs concurrents ;
• rafales courtes ;
• périodes calmes ;
• appels retry.

Dans Apidog, créez un scénario avec plusieurs variantes :

1. Requête courte.
2. Requête moyenne.
3. Requête longue.
4. Requête avec max_tokens plus élevé.

Ajoutez des scripts de pré-requête ou post-requête si nécessaire pour :

• choisir aléatoirement une variante ;
• modifier la longueur du message ;
• lire x-ratelimit-remaining-tokens après chaque réponse ;
• arrêter le scénario si le quota restant descend sous un seuil ;
• comparer la latence des réponses 200 et 429.

Exemple de logique à implémenter dans un script de scénario :

const variants = ["small", "medium", "large"];
const selected = variants[Math.floor(Math.random() * variants.length)];

pm.environment.set("prompt_variant", selected);

Puis dans le corps JSON, vous pouvez référencer une variable selon votre configuration de test.

À la fin, gardez le rapport de codes HTTP. Il devient un artefact opérationnel simple : si quelqu'un demande “sommes-nous limités en débit ?”, relancez le scénario et comparez les résultats.

Que faire si vous êtes bridé

Une fois la limite identifiée, appliquez la correction adaptée.

1. Réessayer avec backoff

Pour les appels synchrones, encapsulez chaque appel GPT dans une logique de retry.

Pseudo-code :

async function callWithRetry(fn, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (err) {
      if (err.status !== 429 || attempt === maxAttempts - 1) {
        throw err;
      }

      const delayMs = Math.min(1000 * 2 ** attempt, 30000);
      await new Promise((resolve) => setTimeout(resolve, delayMs));
    }
  }
}

Si la réponse 429 contient x-ratelimit-reset-tokens ou x-ratelimit-reset-requests, utilisez cette valeur comme délai prioritaire au lieu d'un délai arbitraire.

2. Mettre en file d'attente

Si votre trafic arrive par rafales, placez les requêtes dans une queue et videz-la à un rythme inférieur à votre limite.

Exemple de stratégie :

RPM OpenAI : 500
Marge de sécurité : 50 %
Débit applicatif cible : 250 requêtes/minute

Un limiteur de type token bucket est généralement adapté pour ce cas.

Pour les détails d'implémentation, consultez comment implémenter la limitation de débit d'API et implémenter la limitation de débit dans les API.

3. Réduire les jetons

Si le problème est le TPM :

• raccourcissez le prompt système ;
• supprimez les instructions redondantes ;
• limitez le nombre de documents RAG injectés ;
• réduisez max_tokens ;
• découpez les tâches longues ;
• mettez en cache les contextes réutilisables si votre architecture le permet.

4. Utiliser le traitement par lots

Si la charge n'a pas besoin d'une réponse immédiate, utilisez l'API batch pour les tâches différées :

• classification nocturne ;
• enrichissement de données ;
• reconstruction d'embeddings ;
• traitement de documents ;
• jobs internes non interactifs.

Cela libère votre quota synchrone pour les utilisateurs en temps réel.

Pour clarifier la terminologie avant de choisir une approche, lisez aussi bridage vs. limitation de débit.

Erreurs 429 GPT courantes

Rate limit reached... on requests per min (RPM)

Votre code envoie trop d'appels par minute.

Actions :

• limiter le nombre de workers ;
• éviter les Promise.all() non bornés ;
• ajouter une queue ;
• ajouter du jitter entre les appels ;
• regrouper plusieurs petites tâches si possible.

Exemple à éviter :

await Promise.all(records.map((record) => callOpenAI(record)));

Préférez une concurrence bornée :

import pLimit from "p-limit";

const limit = pLimit(5);

await Promise.all(
  records.map((record) =>
    limit(() => callOpenAI(record))
  )
);

Rate limit reached... on tokens per min (TPM)

Vos appels consomment trop de jetons.

Actions :

• auditer la taille réelle des prompts ;
• réduire les documents injectés dans le contexte ;
• limiter max_tokens ;
• découper les requêtes longues ;
• réutiliser ou mettre en cache les éléments stables.

You exceeded your current quota, please check your plan and billing details

Ce message ressemble à une erreur de limite, mais la cause est souvent la facturation :

• plafond mensuel atteint ;
• carte refusée ;
• solde prépayé à zéro ;
• compte ou organisation non autorisé.

Dans ce cas, la correction se fait dans le tableau de bord de facturation, pas dans le code.

Checklist de diagnostic rapide

Quand vous voyez un 429 en production :

1. Lisez le corps JSON de l'erreur.
2. Identifiez la dimension : requests, tokens, quota ou billing.
3. Vérifiez les en-têtes x-ratelimit-*.
4. Reproduisez dans Apidog avec une requête minimale.
5. Lancez un pic court pour confirmer le RPM.
6. Lancez un test avec gros contexte pour confirmer le TPM.
7. Ajoutez retry, queue ou réduction de tokens selon la cause.
8. Enregistrez le scénario Apidog dans un projet partagé.

FAQ

Le test des limites de débit GPT avec Apidog est-il payant ?

Non. Le plan gratuit couvre les requêtes simples et les petits tests concurrents. Un plan payant devient utile pour des charges plus importantes, des espaces de travail d'équipe ou des exécutions planifiées. Consultez les tarifs Apidog pour plus de détails.

Puis-je tester sans dépenser de jetons réels ?

Partiellement. La vérification la moins chère consiste à envoyer une requête avec max_tokens: 1 et un message très court. Les en-têtes reviennent quand même.

Pour les tests de pic, vous consommez des jetons réels. Gardez donc les prompts courts. Pour tester uniquement votre logique de retry sans appeler OpenAI, utilisez un serveur mock Apidog qui renvoie une réponse 429 simulée.

Pourquoi ma clé de niveau 1 semble-t-elle plus lente que celle d'un collègue ?

Les plafonds sont généralement appliqués au niveau de l'organisation, pas seulement de la clé. Si plusieurs services ou collègues utilisent la même organisation, ils partagent les mêmes quotas.

Dans Apidog, exécutez la même requête avec deux environnements différents et comparez :

• x-ratelimit-limit-requests
• x-ratelimit-remaining-requests
• x-ratelimit-limit-tokens
• x-ratelimit-remaining-tokens

Comment savoir quelle limite s'applique à quel modèle ?

Ne vous fiez pas uniquement aux tableaux génériques. Envoyez une requête minimale à chaque modèle depuis Apidog et enregistrez les en-têtes.

Même deux variantes proches, par exemple gpt-5.5 et gpt-5.5-0901, peuvent avoir des plafonds différents.

Les requêtes de streaming sont-elles comptabilisées différemment ?

Oui, surtout côté TPM. Une requête de streaming peut réserver des jetons en fonction de max_tokens. Si max_tokens est trop élevé, vous pouvez consommer votre budget TPM même si la réponse finale est courte.

Réglez max_tokens au plafond réaliste le plus bas. Le comportement du streaming est détaillé dans comment tester l'API ChatGPT avec Apidog.

Puis-je partager mon test Apidog avec mon équipe ?

Oui. Enregistrez la requête et le scénario dans un projet partagé. Chaque membre peut exécuter le même test avec sa propre clé en changeant d'environnement.

C'est le moyen le plus rapide de répondre à la question : “est-ce ma clé, notre organisation ou le modèle qui est limité ?”