Limites de débit LLM 2026 : RPM, TPM et plafonds de concurrence chez tous les fournisseurs

Requêtes par minute (RPM) limite le nombre d'appels API que vous pouvez émettre en une fenêtre de 60 secondes. Le plafond se réinitialise sur une base roulante — les comportements en rafales sont autorisés dans la fenêtre, mais un RPM élevé soutenu déclenche des 429. La plupart des charges de travail de production atteignent d'abord les plafonds RPM.

Jetons par minute (TPM) limite le total des jetons (entrée + sortie, sur la plupart des fournisseurs ; certains ne comptent que l'entrée) circulant dans votre compte par minute. Les appels long-contexte consomment rapidement le budget TPM : un seul appel avec 200k jetons d'entrée sur un plafond TPM de 200k laisse zéro budget pour les autres requêtes cette minute.

Les limites de requêtes concurrentes limitent le nombre de requêtes qui peuvent être en cours simultanément. OpenAI ne publie pas de limite de concurrence stricte sur les paliers standards (limitée indirectement par TPM/RPM). Together AI publie 200-500 concurrentes sur le palier standard. Atteindre les plafonds de concurrence apparaît comme un chemin d'erreur différent des RPM/TPM — généralement un 503 au lieu d'un 429.

Les trois plafonds se réinitialisent par modèle. GPT-5.5 et GPT-5.4-mini ont des quotas indépendants ; exécuter GPT-5.5 à son plafond n'affecte pas votre marge GPT-5.4-mini. C'est utile pour les modèles de secours — voir la section résilience ci-dessous.

Charge de travail de référence : un chatbot d'assistance client moyenne 1 500 jetons d'entrée + 500 jetons de sortie par appel.

Sur OpenAI Palier 2 (gpt-5.5 : 5 000 RPM / 450 000 TPM) : 5 000 RPM est la contrainte déterminante avec cette forme de jetons, puisque 5 000 appels × 2 000 jetons = 10 millions de jetons/min — bien au-dessus du TPM. Donc le plafond est 5 000 appels/min = 83 appels/seconde. Une rafale de 100 utilisateurs concurrents envoyant un message chacun, le modèle prenant ~5 secondes pour répondre, se situe confortablement sous le plafond.

Même charge de travail sur Anthropic Palier 2 (Claude Sonnet 4.6 : 1 000 RPM / 80 000 TPM entrée / 16 000 TPM sortie) : 1 000 RPM ÷ 60 = 17 RPS. Mais le TPM d'entrée est le véritable goulot d'étranglement ici — 1 000 appels × 1 500 jetons d'entrée = 1,5 million de jetons d'entrée, bien au-dessus de 80 000 TPM. Le plafond réel est 80 000 / 1 500 = 53 appels/min en entrée — bien plus serré que le 1 000 RPM affiché. Vous passez au Palier 3 ou déplacez le chatbot vers un modèle de palier supérieur avec des plafonds moins serrés.

Sur Google Gemini Palier 1 payant (Gemini 2.5 Pro : 1 000 RPM / 2 000 000 TPM) : 2 millions de TPM / 2 000 jetons par appel = 1 000 appels/min — correspondant exactement au RPM. Le Palier 1 soutient à peu près 17 appels/seconde ; suffisant pour une petite à moyenne application.

Planifiez pour la contrainte déterminante, pas le chiffre affiché. Le TPM limite souvent avant le RPM sur les charges de travail long-contexte.

Charge de travail de référence : un enrichissement unique de 1 million d'enregistrements, chacun nécessitant un appel de classification 500 jetons entrée / 100 jetons sortie.

Synchrone sur OpenAI Palier 4 (10 000 RPM / 2 000 000 TPM) : 10 000 RPM ÷ 60 = 167 RPS. 1 million d'appels / 167 RPS = ~100 minutes de rafales soutenues — ou 1 heure 40 minutes si vous pouvez fonctionner à plein régime. TPM à 600 jetons × 10 000 appels = 6 millions, bien au-dessus du plafond TPM de 2 millions, donc TPM est le goulot. Débit réel : 2 millions de TPM / 600 jetons = 3 333 appels/min, donc 1 million d'appels / 3 333 = 300 minutes = 5 heures.

Même tâche sur l'API Batch : soumettez 1 million d'appels dans un fichier JSONL, obtenez les résultats en jusqu'à 24 heures, à 50% de réduction sur l'entrée et la sortie. Pas de souci RPM ou TPM — la file d'attente batch gère l'étranglement en interne. Le coût passe de 0,005$ × 1 million = 5 000$ (standard GPT-5.4-mini) à 2 500$.

Pour les passages d'enrichissement ponctuels, batch est presque toujours la bonne réponse — même réduction de coût qu'une mise à niveau de palier synchrone, opérations plus simples, pas d'ingénierie de limite de débit. Pour l'ingestion continue, synchrone sur un palier supérieur est généralement le bon choix.

OpenAI promeut automatiquement les paliers en fonction des dépenses cumulées et de l'âge du compte. Palier 1 → 2 à 50$ en 7+ jours, Palier 2 → 3 à 100$ en 7+ jours, Palier 3 → 4 à 250$ en 14+ jours, Palier 4 → 5 à 1 000$ en 30+ jours. La progression est automatique ; aucun ticket de support nécessaire.

Anthropic utilise des dépôts plutôt que les dépenses. Palier 1 → 2 à 40$ de dépôt en 7+ jours, Palier 2 → 3 à 200$ en 14+ jours, Palier 3 → 4 à 400$ en 30+ jours. Pour des plafonds plus élevés, contactez l'équipe commerciale pour un plan personnalisé.

Google Gemini utilise les dépenses cumulées sur le palier payant. Le palier gratuit est fortement limité (10 RPM sur Flash, 5 sur Pro). Le Palier payant 1 est activé lors de la configuration de la facturation. Palier payant 2 à 250$ de dépenses cumulées en 30+ jours. Le Palier 3 nécessite de contacter l'équipe commerciale ou de passer à Vertex AI.

L'implication pratique : un déploiement de production doit se situer au Palier 3+ dans le premier mois. Si vous lancez au Palier 1 ou 2 et que le trafic augmente, vous atteindrez les plafonds et les 429 avant que la promotion de palier automatique ne commence. Le moyen le plus rapide de sauter l'attente est de déposer le montant complet à l'avance — la plupart des fournisseurs honorent le palier supérieur dans les heures suivant la détection.

Tous les fournisseurs majeurs retournent HTTP 429 (Trop de requêtes) quand un plafond RPM, TPM ou de concurrence est dépassé. La réponse inclut Retry-After en secondes, qui est le délai d'attente suggéré avant de retenter. Respecter Retry-After est la différence entre une dégradation gracieuse et un arrière-plan de file d'attente en cascade.

Mauvais modèle de retentative : tentative immédiate sans délai. Cause le même appel à échouer à plusieurs reprises et amplifie la charge sur le système de limite de débit du fournisseur. Déclenche souvent un bannissement IP temporaire sur les tempêtes de retentatives agressives.

Bon modèle de retentative : backoff exponentiel avec gigue. Commencez par la valeur Retry-After (ou 1 seconde si absente), doublez à chaque retentative jusqu'à un max (généralement 60 secondes), ajoutez 0-25% de gigue aléatoire pour éviter le troupeau qui tonne. La plupart des clients HTTP de production (le SDK OpenAI, le SDK anthropic, le SDK google-generativeai) implémentent ceci par défaut ; vérifiez que c'est activé.

Meilleur modèle : conscience des limites de débit au niveau de la file. Si vous avez 10 000 appels à faire et un plafond de 5 000 RPM, répartissez-les sur 2+ minutes de manière proactive plutôt que de tirer tous les 10 000 et de laisser la moitié 429. Utilisez un limiteur de débit leaky-bucket ou token-bucket au niveau de votre couche client API.

Meilleur modèle à l'échelle : une chaîne de secours multi-niveaux. Modèle principal sur son propre quota, modèle secondaire (moins cher) sur son propre quota pour le débordement, file d'attente batch pour le trafic non urgent. Quand le primaire 429, revenez au secondaire ; quand le secondaire 429, chutez à batch.

Modèle 1 : secours de modèle. Chaque modèle a des quotas indépendants. Quand RPM GPT-5.5 plafonne, retentez sur GPT-5.4. Quand Claude Sonnet 4.6 plafonne, retentez sur Claude Haiku 4.5. La qualité baisse légèrement mais la disponibilité reste à 100%. Implémentez avec un routeur simple retry-on-429 dans votre client.

Modèle 2 : secours de fournisseur. Redondance multi-fournisseur avec AI Gateway ou Portkey ou routage personnalisé. Primaire sur OpenAI, secondaire sur Anthropic, tertiaire sur Gemini. Quand un fournisseur a une panne ou rate-limite, routez vers le suivant. Ajoute une complexité d'éval (les réponses de chaque fournisseur diffèrent légèrement) mais élimine le risque d'un seul fournisseur.

Modèle 3 : étranglement côté client. Utilisez un limiteur de débit leaky-bucket (par ex. aiolimiter en Python, bottleneck en Node) dimensionné à 80% de votre plafond de palier. Empêche le burst dans les 429s en premier lieu.

Modèle 4 : accélération du palier de dépenses. Si vous êtes à 6 jours d'une promotion de palier qui résoudrait votre problème de débit, pré-déposez ou faites fonctionner un appel API unique pour atteindre le seuil de promotion plus rapidement.

Modèle 5 : batch où possible. Tout ce qui n'est pas face à l'utilisateur synchrone appartient à l'API Batch. Les points de terminaison Batch OpenAI et Anthropic ont des pools de quota séparés qui n'affectent pas vos limites synchrones.

Pour le côté coût de ces modèles, consultez calculateur de coûts GPT vs Claude vs Gemini, qui compare les chaînes de secours end-to-end.

Méthode 1 : dépenser au-delà du seuil. Le chemin le moins coûteux : exécuter du trafic réel pour atteindre le critère de dépenses cumulées. Brûlez le montant en dollars requis à travers la charge de travail légitime sur les jours requis. La plupart des équipes se situent au palier suivant dans 30-60 jours de lancement.

Méthode 2 : pré-dépôt. Certains fournisseurs (Anthropic) acceptent les pré-dépôts qui comptent immédiatement vers les critères de palier, accélérant la promotion sans attendre l'accumulation d'utilisation.

Méthode 3 : contacter l'équipe commerciale. Le chemin le plus rapide pour le volume entreprise. OpenAI, Anthropic, Google, Mistral et Together ont tous des équipes commerciales qui peuvent autoriser des limites de palier personnalisées plus élevées avec une discussion du volume attendu, du cas d'usage et de l'engagement de durée. Délai : généralement jours à semaines.

Méthode 4 : points de terminaison dédiés. Together AI, Anthropic (via Bedrock) et Google (via Vertex AI) offrent tous des points de terminaison de capacité réservée où les limites de débit disparaissent essentiellement en échange de paiements de capacité mensuelle engagée. Utile à volume soutenu élevé avec des formes de charge prévisibles.

Méthode 5 : distribution entre comptes. Certaines équipes fragmentent le trafic de production sur plusieurs comptes (généralement par environnement ou par fonctionnalité). Chaque compte reçoit son propre quota. Soyez prudent — les conditions de service des fournisseurs prohibent généralement l'utilisation de plusieurs comptes pour contourner les plafonds ; les cas d'usage légitimes (applications ou environnements véritablement séparés) vont bien.

La marge de débit n'est pas un nombre unique — c'est un nombre par région par fournisseur. Chaque fournisseur LLM majeur expose ses modèles phares via plus d'un point de terminaison, et chaque point de terminaison applique son propre quota RPM et TPM indépendant. Une équipe exécutant contre seulement le point de terminaison par défaut laisse 2x à 3x de capacité utilisable sur la table, souvent sans s'en rendre compte. Le modèle multi-région traite chaque point de terminaison régional comme un compartiment de quota parallèle et achemine le trafic à travers eux avec une politique de secours.

Anthropic est le plus flexible ici. Claude est disponible sur l'API Anthropic directe, sur AWS Bedrock en us-east-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-1, ap-northeast-1 et plusieurs régions plus récentes, et sur Google Cloud Vertex AI en us-east5, europe-west1 et asia-southeast1. Chacun de ces points de terminaison a un quota séparé. Une charge de travail qui atteint le plafond Tier 3 direct-API de 2 000 RPM peut router le débordement vers Bedrock us-east-1 (quota par compte séparé négocié contre AWS) et Vertex AI us-east5 (négocié contre GCP). Le même Claude Sonnet 4.6 sous-jacent sert les trois avec le même schéma de prompt, donc le risque de différence d'éval qui existe dans le secours multi-fournisseur est effectivement zéro.

OpenAI est plus contraint sur l'API directe — il présente un seul point de terminaison global avec un quota unique — mais Azure OpenAI Service réplique GPT-5.x sur les déploiements régionaux (East US, East US 2, West US, West US 3, North Central US, South Central US, North Europe, West Europe, Sweden Central, France Central, UK South, Japan East, Australia East et autres). Chaque région Azure a son propre quota RPM et TPM assigné à la création du déploiement. Une équipe bloquée au plafond de Tier 4 d'OpenAI de 10 000 RPM peut déployer GPT-5.5 dans trois régions Azure à 3 000 RPM chacun et router entre eux, ajoutant instantanément 9 000 RPM de capacité de canal latéral sans attendre la promotion de palier automatique.

Google Gemini suit le même modèle via Vertex AI. L'API AI Studio a un quota partagé ; Vertex AI publie des points de terminaison régionaux (us-central1, us-east1, us-east4, us-west1, europe-west1, europe-west4, asia-southeast1, asia-northeast1 et plus), chacun avec des quotas indépendants configurables par projet. Les quotas Vertex AI tendent aussi à être plus élevés que le palier payant AI Studio au même niveau de dépense, donc la migration est doublement intéressante pour les charges de travail à fort volume.

Les mathématiques sur une configuration trois régions ne cèdent rarement pas un 3x parfait. L'équilibrage de charge imparfait — formes de trafic inégales, tempêtes de retentatives concentrées sur la primaire, clients épinglés par région dans les charges de travail réglementées — livre généralement un multiplicateur effectif de 2,6x à 2,8x sur la plupart des charges de travail chatbot et d'ingestion réalistes. Utilisez 2,7x comme règle de planification. Un exemple concret : un chatbot à un plafond de 30 000 TPM par région, déployé primaire en us-east-1, secondaire en eu-west-1, tertiaire en ap-southeast-1, soutient à peu près 80 000 TPM agrégés avant que n'importe quelle région commence à retourner des 429. C'est l'équivalent d'une promotion de palier complète, réalisable en heures plutôt que les 14 à 30 jours qu'une promotion basée sur les dépenses nécessiterait, et sans engagement de dépôt minimum.

La surveillance est la partie que les équipes sous-investissent. Chaque région a besoin de son propre tableau de bord de marge, sa propre alerte de taux 429 et son propre budget de retentative suivi séparément — agréger entre régions cache la région qui est réellement saturée. Identifiez chaque requête avec sa région cible au niveau de la couche client, enregistrez les en-têtes de limite de débit régionaux (Azure retourne x-ratelimit-remaining-requests par déploiement ; Bedrock retourne les en-têtes x-amzn-bedrock-quota-* ; Vertex retourne les en-têtes de quota Google standard) dans votre pile d'observabilité, et graphique chaque région comme une série séparée. Le routeur de secours doit sélectionner la région avec la marge restante la plus élevée plutôt qu'une primaire fixe, ce qui lisse l'utilisation et rapproche le multiplicateur effectif du théorique 3x. Pour les implémentations sur AI Gateway de Vercel, la logique de routage régional peut résider dans une fine couche middleware devant la passerelle et passer à travers au point de terminaison choisi.

La plupart des fournisseurs retournent les en-têtes de limite de débit sur chaque réponse réussie. OpenAI : x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, x-ratelimit-reset-tokens. Anthropic : anthropic-ratelimit-requests-remaining, anthropic-ratelimit-tokens-remaining. Google : x-goog-api-client (moins détaillé ; interrogez l'API pour le statut de quota).

Enregistrez ces en-têtes par requête et construisez un tableau de bord montrant la marge roulante 1-minute et 5-minutes sur RPM et TPM. Quand la marge baisse régulièrement en dessous de 20% sur une base soutenue, le palier est votre véritable plafond de production ; planifiez une promotion avant que le trafic ne le dépasse.

Alertez sur trois signaux : taux 429 au-dessus de 0,1% du trafic total, marge soutenue inférieure à 20% pendant >5 minutes, et toutes les erreurs 503 (concurrence). Chaque signal indique une correction différente : 429 = bump de palier ou lissage de burst ; marge basse soutenue = mise à niveau de palier nécessaire ; 503 = diminuer la concurrence dans votre client ou mettre à niveau vers dédié.

La surveillance des coûts doit s'aligner : si votre tableau de bord de limite de débit montre que vous cognez régulièrement le plafond TPM, vous êtes à un palier où le coût marginal de la mise à niveau est bien inférieur au coût des requêtes perdues ou retardées. Pour la comparaison des coûts de fournisseur à l'échelle, consultez Tarification API OpenAI et Tarification Claude Anthropic.