Gérer Azure OpenAI dans le quota des modèles Foundry de Microsoft

Le quota offre la possibilité de gérer activement l’allocation des limites de débit entre les déploiements au sein de votre abonnement. Cet article décrit le processus de gestion de votre quota openAI Azure.

Conditions préalables

Important

Pour toute tâche nécessitant l’affichage du quota disponible, nous vous recommandons d’utiliser le rôle Lecteur des utilisations de Cognitive Services. Ce rôle fournit l’accès minimal nécessaire pour afficher l’utilisation du quota sur un abonnement Azure. Pour en savoir plus sur ce rôle et les autres rôles dont vous avez besoin pour accéder à Azure OpenAI, consultez notre guide de contrôle d’accès en fonction du rôle Azure.

Ce rôle se trouve dans le portail Azure sous Abonnements>Contrôle d'accès (IAM)>Ajouter une attribution de rôle>, cherchez Lecteur d'usages des services cognitifs. Ce rôle doit être appliqué au niveau de l’abonnement, il n’existe pas au niveau de la ressource.

Si vous préférez ne pas utiliser ce rôle, le rôle d’abonnement Reader fournit un niveau d’accès équivalent, tout en accordant également un accès en lecture au-delà du périmètre nécessaire à la consultation du quota et du déploiement du modèle.

Introduction au quota

La fonctionnalité de quota d'Azure OpenAI permet d'attribuer des limites de débit à vos déploiements, jusqu'à une limite globale appelée quota. Le quota est attribué à votre abonnement sur une base par région, par modèle, par type de déploiement en unités de jetons par minute (TPM). Lorsque vous intégrez un abonnement à Azure OpenAI, vous recevez un quota par défaut pour la plupart des modèles disponibles. Ensuite, vous affectez un module TPM à chaque déploiement à mesure qu’il est créé, et le quota disponible pour ce modèle est réduit par ce montant. Vous pouvez continuer à créer des déploiements et à leur affecter des TPM jusqu’à ce que vous atteigniez votre limite de quota. Une fois que cela se produit, vous ne pouvez créer de nouveaux déploiements de ce modèle qu'en réduisant les TPM attribuées à d'autres déploiements du même modèle (libérant ainsi des TPM pour une utilisation) ou en demandant et en obtenant l'approbation pour une augmentation de quota de modèle dans la région souhaitée.

Note

Avec un quota de 240 000 TPM pour GPT-4o dans la région Est des États-Unis, un client peut créer un déploiement unique de 240 000 TPM, 2 déploiements de 120 000 TPM chacun, ou tout nombre de déploiements dans une ou plusieurs ressources Azure OpenAI tant que leur TPM totalise moins de 240 000 en tout dans cette région.

Lorsqu’un déploiement est créé, le TPM attribué correspond directement à la limite de débit en jetons par minute appliquée à ses requêtes d’inférence. Une limite de taux Requests-Per-Minute (RPM) est également appliquée, dont la valeur est définie proportionnellement à l’affectation TPM à l’aide du rapport suivant :

Important

Le ratio des demandes par minute (RPM) aux jetons par minute (TPM) pour le quota peut varier selon le modèle. Lorsque vous déployez un modèle par programmation ou que vous demandez une augmentation de quota , vous n’avez pas de contrôle granulaire sur TPM et RPM en tant que valeurs indépendantes. Le quota est alloué en unités de capacité, chacune correspondant à une quantité précise de RPM et TPM.

Modèle Capacité Demandes par minute (RPM) Jetons par minute (TPM)
Modèles de conversation plus anciens 1 Unité 6 tr/min 1 000 TPM
o1 & o1-préversion 1 Unité 1 tr/min 6 000 TPM
o3 1 Unité 1 tr/min 1 000 TPM
o4-mini 1 Unité 1 tr/min 1 000 TPM
o3-mini 1 Unité 1 tr/min 10 000 TPM
o1-mini 1 Unité 1 tr/min 10 000 TPM
o3-pro 1 Unité 1 tr/min 10 000 TPM

Cela est particulièrement important pour le déploiement de modèles programmatiques, car les modifications apportées au ratio RPM/TPM peuvent entraîner une désallocation accidentelle du quota.

La flexibilité de distribuer le module de plateforme sécurisée (TPM) à l’échelle mondiale au sein d'un abonnement et d'une région a permis à Azure OpenAI d'assouplir d'autres restrictions.

  • Les ressources maximales par région sont augmentées à 30.
  • La limite de création d’un seul déploiement du même modèle dans une ressource a été supprimée.

Demander plus de quota

Soumettez le formulaire de demande d’augmentation de quota afin de demander des augmentations de quota pour les modèles Foundry commercialisés par Azure, les modèles Azure OpenAI et les modèles Anthropic. À l'exception des modèles Anthropic, modèles des partenaires et de la communauté ne prennent pas en charge les augmentations de quotas.

Les demandes d’augmentation de quota sont traitées dans l’ordre dans lequel elles sont reçues, et la priorité est accordée aux clients qui utilisent activement leur allocation de quota existante. Les demandes qui ne répondent pas à cette condition peuvent être refusées.

Paramètres spécifiques au modèle

Différents déploiements de modèles, également appelés classes de modèle, ont des valeurs TPM maximales uniques que vous pouvez désormais contrôler. Cela représente la quantité maximale de TPM qui peut être allouée à ce type de déploiement de modèle dans une région donnée.

Toutes les autres classes de modèle ont une valeur TPM maximale commune.

Note

L'allocation de Quota Tokens-Per-Minute (TPM) n'est pas liée à la limite maximale des jetons d'entrée d'un modèle. Les limites de jeton d’entrée de modèle sont définies dans la table des modèles et ne sont pas affectées par les modifications apportées au module TPM.

Afficher et demander des quotas dans le portail Foundry

Utilisez des quotas pour gérer l’allocation de quota de modèle entre plusieurs projets Foundry dans le même abonnement.

  1. Connectez-vous à Microsoft Foundry. Vérifiez que l'interrupteur New Foundry est activé. Ces étapes font référence à Foundry (nouveau).

  2. Les projets aident à organiser votre travail. Le projet sur lequel vous travaillez apparaît dans le coin supérieur gauche. Si vous souhaitez créer un projet, sélectionnez le nom du projet, puis créez un projet.

  3. Sélectionnez Utiliser dans le volet de navigation supérieur droit.

  4. Sélectionnez Quota dans le volet gauche pour atterrir dans le volet Quota . La vue quota comporte deux onglets :

    • Jeton par minute : affichez et gérez les allocations de quota de jetons par minute (TPM) pour les déploiements standard.
    • Unité de débit provisionnée : affichez et gérez les allocations d’unités de débit approvisionnées (PTU) pour les déploiements provisionnés, y compris les outils d’estimation de capacité.

  5. Sélectionnez l’un des déploiements de la liste pour ouvrir son volet d’informations sur le côté droit. Le volet d'informations affiche l'allocation de quota actuelle du déploiement, l'utilisation et les déploiements affiliés.

  6. Dans le volet d’informations du déploiement, accédez à la section Déploiements affiliés avec quotas partagés. Sélectionnez l’icône de crayon dans la colonne Actions de la table pour modifier l’allocation de quota pour le déploiement et libérer le quota inutilisé ou augmenter l’allocation si nécessaire.

  7. Sélectionnez le bouton Demander un quota dans le coin supérieur droit pour demander des augmentations de quota pour le type de déploiement standard.

Note

Après avoir modifié une allocation de quota ou envoyé une demande, autorisez jusqu’à 15 minutes pour que les modifications se propagent. Actualisez la page Quota pour vérifier l’allocation mise à jour.

Migration des déploiements existants

Dans le cadre de la transition vers le nouveau système de quota et l’allocation basée sur le module TPM, tous les déploiements Azure de modèles OpenAI existants ont été automatiquement migrés pour utiliser le quota. Dans les cas où l'allocation TPM/RPM existante dépasse les valeurs par défaut en raison d'augmentations précédentes de la limite de débit personnalisée, un nombre équivalent de TPM (Transactions Par Minute) a été attribué aux déploiements concernés.

Présentation des limites de débit

L'affectation de TPM à un déploiement définit les limites de taux Tokens-Per-Minute (TPM) et Requests-Per-Minute (RPM) pour le déploiement, comme décrit ci-dessus. Les limites de taux TPM sont basées sur le nombre maximal de jetons estimés à traiter par une demande lorsque la demande est reçue. Il n’est pas identique au nombre de jetons utilisé pour la facturation, qui est calculé une fois que tout traitement est terminé.

À mesure que chaque requête est reçue, Azure OpenAI calcule un nombre maximal de jetons traités estimé qui inclut les éléments suivants :

  • Texte d’invite et nombre
  • Le réglage du paramètre max_tokens
  • Paramètre de configuration best_of

À mesure que les requêtes arrivent à l'interface de déploiement, le nombre maximal estimé de jetons traités est ajouté au compte total de jetons de toutes les requêtes, qui est réinitialisé chaque minute. Si à n'importe quel moment la limite de taux TPM est atteinte, toutes les nouvelles requêtes reçoivent un code de réponse 429 jusqu'à la réinitialisation du compteur.

Important

Le nombre de jetons utilisé dans le calcul de la limite de débit est une estimation basée en partie sur le nombre de caractères de la demande d’API. L’estimation du jeton de limite de débit n’est pas la même que le calcul du jeton utilisé pour la facturation/la détermination qu’une demande est inférieure à la limite du jeton d’entrée d’un modèle. En raison de la nature approximative du calcul du jeton de limite de débit, il est prévu qu’une limite de débit puisse être déclenchée avant ce qui peut être attendu par rapport à une mesure exacte du nombre de jetons pour chaque requête.

Les limites de débit RPM sont basées sur le nombre de demandes reçues au fil du temps. La limite de débit s’attend à ce que les demandes soient réparties uniformément sur une période d’une minute. Si ce flux moyen n’est pas conservé, les demandes peuvent recevoir une réponse de 429, même si la limite n’est pas remplie lorsqu’elle est mesurée au cours d’une minute. Pour implémenter ce comportement, Azure OpenAI évalue le taux de requêtes entrantes sur une petite période, généralement 1 ou 10 secondes. Si le nombre de demandes reçues pendant cette période dépasse ce qui serait attendu au niveau de la limite RPM définie, les nouvelles demandes reçoivent un code de réponse 429 jusqu’à la prochaine période d’évaluation. Par exemple, si Azure OpenAI surveille le taux de demandes à intervalles de 1 seconde, la limitation du débit se produit pour un déploiement de 600 RPM si plus de 10 requêtes sont reçues pendant chaque période de 1 seconde (600 requêtes par minute = 10 requêtes par seconde).

Note

Si vous utilisez des unités de débit approvisionnées (PTU), le système calcule les limites de débit différemment. Pour plus d’informations, consultez la section Évaluation des demandes basée sur l’utilisation de l’article « Qu’est-ce que le débit provisionné pour les modèles Foundry ? »

En-têtes de réponse de limite de débit

Azure OpenAI inclut des informations de limite de débit dans les en-têtes de réponse HTTP de chaque appel d’API. Utilisez ces en-têtes pour surveiller par programmation votre utilisation et éviter de manière proactive les erreurs 429.

En-tête Exemple de valeur Description
x-ratelimit-limit-requests 60 Nombre maximal de demandes autorisées par minute pour ce déploiement.
x-ratelimit-limit-tokens 150000 Nombre maximal de jetons autorisés par minute pour ce déploiement.
x-ratelimit-remaining-requests 59 Demandes restantes avant d’atteindre la limite de débit.
x-ratelimit-remaining-tokens 149984 Jetons restants avant d’atteindre la limite de débit.
x-ratelimit-reset-requests 10 Délai jusqu’à ce que la limite de débit basée sur la requête soit réinitialisée.
x-ratelimit-reset-tokens 300 Temps restant avant la réinitialisation de la limite de débit basée sur les jetons.
retry-after-ms 2000 Inclus dans 429 réponses. Temps d’attente recommandé (en millisecondes) avant de réessayer.

Conseil

Surveillez x-ratelimit-remaining-requests et x-ratelimit-remaining-tokens dans votre application afin de détecter lorsque vous approchez des limites et d’appliquer de manière proactive des restrictions sur les requêtes avant de recevoir une erreur 429.

Meilleures pratiques relatives à la limite de débit

Pour réduire les problèmes liés aux limites de débit, utilisez les techniques suivantes :

Optimiser vos demandes

  • Définissez max_tokens la valeur minimale qui sert votre scénario. L’estimation du jeton de limite de débit inclut max_tokens, même si votre réponse réelle est beaucoup plus courte. Par exemple, si vous prévoyez des réponses d’environ 200 jetons, ne définissez pas max_tokens sur 4 000.
  • Définissez best_of sur 1 , sauf si vous avez spécifiquement besoin de plusieurs complétions. Chaque incrément de best_of multiplie le nombre de jetons en fonction de votre limite de taux.
  • Réduisez la taille des invites si possible. Les invites plus concises consomment moins de jetons par rapport à votre limite de débit.

Implémenter une logique de relance avec retrait exponentiel

Réessayez automatiquement les demandes lorsque vous recevez une réponse 429. Utilisez la valeur d’en-tête retry-after-ms si présente ; sinon, utilisez un retrait exponentiel avec un jitter aléatoire :

  1. Patientez un court délai aléatoire après le premier échec.
  2. Si le réessai échoue, doublez le délai (recul exponentiel).
  3. Ajoutez un délai aléatoire afin d’éviter que tous les clients ne réessaient simultanément.
  4. Définissez un nombre maximal de nouvelles tentatives (par exemple, 5 à 10) pour éviter les boucles infinies.

Important

Les demandes infructueuses comptent toujours vers votre limite de débit par minute. Le renvoi continu de requêtes sans temporisation accentue la limitation.

Option 1 : Utiliser la fonction de nouvelle tentative intégrée du Kit de Développement Logiciel (SDK) (la plus simple - recommandée)

Le SDK Azure OpenAI Python (openai v1.0+) a un réessai automatique intégré avec repli exponentiel pour les erreurs 429 et transitoires. La valeur par défaut est deux nouvelles tentatives. Vous pouvez l’augmenter :

from openai import AzureOpenAI

# Set max_retries globally on the client (default is 2)
client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=5  # up to 5 retries with automatic exponential backoff
)

# All calls through this client automatically retry on 429
response = client.chat.completions.create(
    model="gpt-4o",  # deployment name
    messages=[{"role": "user", "content": "Hello"}]
)

# Or override per-request:
response = client.with_options(max_retries=8).chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

Note

Le SDK respecte automatiquement les en-têtes retry-after et applique un backoff exponentiel avec gigue. Pour la plupart des applications, la configuration max_retries sur le client est suffisante : vous n’avez pas besoin d’une bibliothèque de nouvelles tentatives tierce.

Option 2 : Nouvelle tentative personnalisée avec la tenacity bibliothèque (avancé)

Utilisez cette option lorsque vous avez besoin d’un contrôle supplémentaire sur le comportement des nouvelles tentatives (par exemple, journalisation personnalisée, gestion sélective des exceptions, disjoncteurs) :

import openai
from openai import AzureOpenAI
from tenacity import (
    retry,
    retry_if_exception_type,
    stop_after_attempt,
    wait_random_exponential,
)

client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=0  # disable SDK built-in retry to avoid double-retrying
)

@retry(
    wait=wait_random_exponential(min=1, max=60),
    stop=stop_after_attempt(6),
    retry=retry_if_exception_type(openai.RateLimitError),  # only retry on 429
    reraise=True
)
def chat_completion_with_backoff(**kwargs):
    return client.chat.completions.create(**kwargs)

response = chat_completion_with_backoff(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

Important

Lorsque vous utilisez une bibliothèque de gestion des tentatives personnalisée, définissez max_retries=0 sur le client SDK pour désactiver sa gestion des tentatives intégrée. Dans le cas contraire, chaque tentative utilisant le module Tenacity peut entraîner jusqu’à deux nouvelles tentatives du SDK, ce qui entraîne bien plus de demandes que prévu.

Option 3 : Implémentation manuelle (aucune bibliothèque tierce)

import time
import random
import openai
from openai import AzureOpenAI

client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=0  # disable SDK built-in retry
)

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):
        num_retries = 0
        delay = initial_delay
        while True:
            try:
                return func(*args, **kwargs)
            except errors as e:
                num_retries += 1
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    ) from e
                delay *= exponential_base * (1 + jitter * random.random())
                time.sleep(delay)
            except Exception as e:
                raise e
    return wrapper

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

Exemple C# utilisant Polly (v7) :

using Azure;
using Azure.AI.OpenAI;
using Polly;

var retryPolicy = Policy
    .Handle<RequestFailedException>(ex => ex.Status == 429)
    .WaitAndRetryAsync(
        retryCount: 6,
        sleepDurationProvider: (retryAttempt, exception, context) =>
        {
            // Use retry-after-ms header if available
            if (exception is RequestFailedException rfEx)
            {
                var raw = rfEx.GetRawResponse();
                if (raw != null && raw.Headers.TryGetValue("retry-after-ms", out string value)
                    && int.TryParse(value, out int ms))
                {
                    return TimeSpan.FromMilliseconds(ms);
                }
            }
            // Otherwise, exponential backoff with jitter
            return TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))
                + TimeSpan.FromMilliseconds(Random.Shared.Next(0, 1000));
        },
        onRetry: (exception, timespan, retryCount, context) =>
        {
            Console.WriteLine($"Retry {retryCount} after {timespan.TotalSeconds:F1}s due to: {exception.Message}");
        }
    );

// Usage
var endpoint = new Uri("https://<your-resource>.openai.azure.com/");
var credential = new AzureKeyCredential("<your-api-key>");
var client = new AzureOpenAIClient(endpoint, credential);

await retryPolicy.ExecuteAsync(async () =>
{
    var response = await client.GetChatClient("gpt-4o")
        .CompleteChatAsync([new UserChatMessage("Hello")]);
    Console.WriteLine(response.Value.Content[0].Text);
});

Note

La Kit de développement logiciel (SDK) Azure pour .NET a également une prise en charge intégrée des nouvelles tentatives. Lors de la construction de AzureOpenAIClientOptions, vous pouvez configurer options.Retry.MaxRetries et options.Retry.Mode = RetryMode.Exponential au lieu d'utiliser Polly. Utilisez Polly quand vous avez besoin de modèles plus avancés (disjoncteurs, cloisonnements, etc.).

Surveiller et gérer l’utilisation au niveau du déploiement

  • Vérifiez l'allocation TPM par déploiement, pas seulement le quota au niveau de l’abonnement. Vous pouvez disposer d’un quota approuvé au niveau de l’abonnement tout en rencontrant des erreurs 429, car le quota n’est pas attribué au déploiement spécifique qui reçoit le trafic.
  • Rééquilibrer le quota entre les déploiements en fonction de l’utilisation observée. Utilisez les métriques Azure Monitor pour passer en revue les tendances d’utilisation sur 24 heures et sur sept jours et détecter les schémas de comportement soudain.
  • Utilisez la gestion des quotas dans le portail Foundry pour augmenter les TPM sur les déploiements à trafic élevé et réduire les TPM sur ceux qui sont sous-utilisés.

Distribuer le trafic uniformément

  • Évitez les pics nets dans la charge de travail. Les limites de débit RPM s’attendent à ce que les demandes soient réparties uniformément sur chaque minute. Même si vos demandes totales sont inférieures à la limite par minute, une rafale dans une fenêtre de 1 seconde ou de 10 secondes peut déclencher un 429.
  • Augmentez progressivement le trafic lors de l’intégration de nouvelles charges de travail ou de l'augmentation de la charge existante.
  • Répartissez les demandes entre plusieurs déploiements ou régions si votre charge de travail nécessite un débit plus élevé qu’un seul déploiement prend en charge.

Utiliser le traitement asynchrone/par lots dans la cas où cela est possible

Si votre cas d’usage ne nécessite pas de réponses immédiates, envisagez d’utiliser des modèles asynchrones :

  • Mettre en file d'attente les demandes et les traiter à un débit contrôlé.
  • Utilisez plusieurs déploiements pour paralléliser le traitement sans dépasser la limite de débit d’un déploiement unique.

Comprendre les erreurs de restriction de débit 429 et ce qu’il faut faire

Une erreur 429 (« Trop de demandes ») signifie que le système a rejeté votre demande, car une limite de débit a été dépassée ou que le système ne peut pas traiter votre demande pour l’instant. Toutes les erreurs 429 n’ont pas la même cause racine, et l’action correcte dépend de la raison pour laquelle la version 429 s’est produite.

Types d’erreurs 429

Scénario Indicateur de message d’erreur Cause Racine Action recommandée
Limite de débit dépassée "Demandes à ... a été limitée » ou « La limitation du taux est excédée » Vos requêtes ont dépassé la limite de taux TPM ou RPM pour le quota attribué à votre déploiement. Augmentez l’allocation TPM du déploiement, rééquilibrez le quota entre les déploiements ou demandez une augmentation du quota.
Limitation de la capacité du système « Le service est temporairement incapable de traiter votre demande » ou « Le système rencontre une forte demande » La capacité back-end est limitée. Cette condition est souvent temporaire. Réessayez après le retry-after-ms délai. Si elle est persistante, envisagez la mise à niveau vers le débit provisionné (PTU) pour une capacité garantie.
Ajustement de la limite de débit temporaire 429 réponses se produisent, mais votre quota configuré n’a pas changé ; x-ratelimit-limit-tokens dans les en-têtes de réponse est inférieur au TPM configuré de votre déploiement Les déploiements standard (paiement à l’utilisation) partagent un pool de ressources. Lorsque la demande approche des limites de capacité, le système réduit temporairement la limite de débit effective de votre déploiement pour maintenir la fiabilité pour tous les clients. Cette réduction est protectrice et temporaire. Réessayez avec un backoff retry-after-ms. L’ajustement se résout généralement dans quelques heures. Pour les charges de travail nécessitant un débit constant, envisagez le débit provisionné (PTU).
Budget de jeton dépassé par les paramètres de requête La limite de taux a été déclenchée, mais les indicateurs d'utilisation des jetons semblent faibles. Le calcul de la limitation du débit prend en compte max_tokens ainsi qu’une estimation immédiate, et pas uniquement les jetons facturés. Une demande avec une valeur élevée max_tokens peut consommer un budget de limite de débit même si la réponse réelle est petite. Réduisez max_tokens pour correspondre à votre taille de réponse attendue.

Important

De nombreux clients n’interprètent pas correctement les problèmes liés à la capacité 429 en tant que problèmes de quota, ce qui entraîne une correction incorrecte (par exemple, la demande d’augmentations de quota lorsque le problème est une pression de capacité temporaire). Vérifiez toujours les en-têtes de message d’erreur et de réponse pour identifier la cause racine avant d’agir.

Pourquoi des erreurs 429 peuvent survenir même lorsque les métriques d’utilisation des jetons restent inférieures au quota

Azure OpenAI limitation du taux et métriques d'utilisation ne sont pas les mêmes :

  • Token usage metrics affichent dans Azure Monitor les jetons facturés des requêtes traitées avec succès.
  • La limitation du débits’applique aux demandes d’API au moment où elles sont reçues, y compris les demandes qui sont rejetées ultérieurement ou qui ne sont jamais facturées.

En raison de cette différence, vous pouvez obtenir 429 réponses même lorsque vos métriques d’utilisation des jetons sont bien inférieures au quota. Les raisons courantes sont les suivantes :

  • max_tokens surestimation : les limites de débit sont calculées à l’aide du nombre de jetons maximal estimé (invite + max_tokens), et non des jetons réels générés.
  • Demandes rejetées : les demandes rejetées en raison de limites de longueur d’entrée (HTTP 400) peuvent toujours compter vers la limitation du débit, mais n’apparaissent pas dans les métriques de jeton facturées.
  • Modèles de pics de trafic : le contrôle du RPM évalue les requêtes sur de courtes plages horaires (1 à 10 secondes). Une rafale de requêtes sur une courte période déclenche la limitation, même si le volume total par minute demeure dans les limites autorisées.
  • Ajustement temporaire de la limite de débit pour la fiabilité du service : les déploiements standard (paiement à l’utilisation) partagent un pool de ressources commun entre les clients. Pour maintenir le service fiable et équitable, le système surveille en permanence la demande sur ce pool partagé. Lorsque la demande d’un déploiement approche ou dépasse les limites de capacité, le système peut réduire temporairement la limite de débit effective pour ce déploiement. Pendant cette période d’ajustement, les demandes qui auraient été acceptées dans des conditions normales retournent 429 réponses, même si votre quota configuré n’a pas changé. Cette mesure de protection empêche la dégradation des services pour tous les clients partageant le pool de ressources. L’ajustement est temporaire et se résout généralement dans quelques heures une fois le trafic stabilisé. Vous pouvez surveiller cette condition en vérifiant si votre limite de débit effective (visible dans x-ratelimit-limit-tokens les en-têtes de réponse) est inférieure à votre allocation TPM configurée.
  • Application distribuée : l’application de la limite de débit sur l’infrastructure distribuée peut ne pas être parfaitement précise ou immédiatement reflétée dans les métriques agrégées.

Conseil

Si vous voyez 429 réponses pendant une période d’ajustement temporaire de la limite de taux :

  1. Réessayer avec un délai d’attente — respecter l’en-tête retry-after-ms. L’ajustement est temporaire et se résout à mesure que la demande se stabilise.
  2. Répartir le trafic : si possible, distribuez les demandes entre plusieurs déploiements ou régions.
  3. Passez en revue votre modèle de trafic : les rafales lourdes soutenues sont le déclencheur le plus courant. L’augmentation progressive des charges de travail réduit la probabilité d’ajustements.
  4. Envisagez le débit approvisionné (PTU) pour les charges de travail de production qui exigent un débit constant sans variabilité liée au pool partagé, le débit approvisionné offre une capacité dédiée avec des taux garantis.

Sur quoi s’appuyer :

  • Utilisez les métriques d’utilisation des jetons pour comprendre la consommation facturée.
  • Utilisez des codes de réponse HTTP (429) et des en-têtes de réponse (x-ratelimit-remaining-*, x-ratelimit-limit-*) pour détecter et répondre à l’application de la limite de débit en temps réel.
  • Comparez les en-têtes de réponse x-ratelimit-limit-tokens avec votre TPM configuré pour détecter si un ajustement temporaire est actif.

Quand réessayer et quand remonter

Situation Action
Erreurs 429 ponctuelles se résolvant après un délai d’attente de retry-after-ms Nouvelle tentative : ce comportement est normal et attendu pour les déploiements partagés (standard).
Erreur 429 pendant le développement ou les tests Souvent acceptable — les 429 hors production peuvent constituer des mesures de contrôle des coûts délibérées.
Erreurs 429 persistantes en production malgré un niveau inférieur au quota approuvé Escaler — ouvrir une requête d’assistance pour une analyse technique.
Augmentations de la limite de débit non reflétées dans les limites effectives Escalate — vérifiez d’abord l’attribution des quotas au niveau du déploiement, puis escaladez si le problème persiste.
Charges de travail de production sensibles à la latence ou critiques pour l’activité subissant des erreurs 429 fréquentes Procédez à une mise à niveau — envisagez le débit approvisionné (PTU) pour une capacité garantie et un SLA de latence garanti.

Note

Les déploiements standard (paiement à l’utilisation) utilisent un pool de ressources partagé. La limitation protège la fiabilité globale du service pour tous les utilisateurs. Les 429 temporaires occasionnels sont des comportements attendus, et non un défaut de service. Pour les charges de travail qui nécessitent une latence prévisible et un débit garanti, le débit approvisionné (PTU) est le type de déploiement recommandé.

Vérifier par programmation le quota et la capacité

Outre le portail Foundry, vous pouvez utiliser deux API REST Azure Resource Manager pour vérifier par programme la consommation de quota de votre abonnement et la capacité de modèle disponible.

Choisir l’API appropriée

API Utilisation API des capacités du modèle
Question à laquelle il répond Combien de mon quota ai-je consommé par rapport à ma limite ? Quelle est la capacité déployable disponible pour un modèle spécifique ?
Étendue Abonnement + emplacement Abonnement (tous les emplacements simultanément)
Input Emplacement uniquement Nom du modèle, version et format
Retour Chaque ligne de quota de cette région : utilisation et limite actuelles Capacité disponible par emplacement et type de déploiement pour un modèle
Cas d’utilisation classique Surveiller la consommation, déclencher des alertes lors de l’approche des limites Pré-vérifier la capacité avant de créer ou de mettre à l’échelle un déploiement
Informations de référence sur l’API Utilisations - Liste Capacités de modèle - Liste

Utilisez l’API Utilisation lorsque vous avez besoin d’une vue de registre de ce que vous avez consommé et de ce qui est laissé. Utilisez l’API Capacités de modèle lorsque vous souhaitez savoir où vous pouvez déployer un modèle et la quantité de capacité disponible dans chaque emplacement.

Note

Les deux API retournent des informations pour tous les modèles associés à votre abonnement, y compris les modèles supprimés qui ne sont plus disponibles pour les nouveaux déploiements.

Utilisation de l’API

L’API Utilisation retourne chaque ligne de quota pour une région donnée, y compris votre consommation actuelle (currentValue) et votre limite affectée.

Requête :

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/locations/{location}/usages?api-version=2024-10-01

Exemple : vérifiez l’utilisation du quota dans la région USA Est :

import requests
import json
from azure.identity import DefaultAzureCredential

subscription_id = "<your-subscription-id>"
location = "eastus"

credential = DefaultAzureCredential()
token = credential.get_token("https://management.azure.com/.default")
headers = {"Authorization": f"Bearer {token.token}"}

url = (
    f"https://management.azure.com/subscriptions/{subscription_id}"
    f"/providers/Microsoft.CognitiveServices/locations/{location}/usages"
    f"?api-version=2024-10-01"
)

response = requests.get(url, headers=headers)
usages = response.json()

# Show quota lines that have a non-zero limit
for item in usages["value"]:
    if item["limit"] > 0:
        print(f"{item['name']['localizedValue']}: {item['currentValue']}/{item['limit']}")

Champs clés :

Champ Description
name.value Nom du quota au format {Provider}.{DeploymentType}.{Model}
name.localizedValue Description compréhensible par l’utilisateur, y compris l’unité
currentValue Combien de ce quota est actuellement consommé par les déploiements
limit Limite de quota de votre abonnement pour ce modèle et ce type de déploiement

API des capacités du modèle

L’API Capacité de modèle retourne la capacité de déploiement disponible pour un modèle spécifique sur tous les emplacements et types de déploiement de votre abonnement.

Requête :

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/modelCapacities?api-version=2024-10-01&modelFormat={format}&modelName={name}&modelVersion={version}

Exemple : vérifiez où la capacité gpt-4o est disponible :

import requests
import json
from azure.identity import DefaultAzureCredential

subscription_id = "<your-subscription-id>"
model_name = "gpt-4o"
model_version = "2024-08-06"

credential = DefaultAzureCredential()
token = credential.get_token("https://management.azure.com/.default")
headers = {"Authorization": f"Bearer {token.token}"}

url = (
    f"https://management.azure.com/subscriptions/{subscription_id}"
    f"/providers/Microsoft.CognitiveServices/modelCapacities"
    f"?api-version=2024-10-01"
    f"&modelFormat=OpenAI&modelName={model_name}&modelVersion={model_version}"
)

response = requests.get(url, headers=headers)
capacities = response.json()

# Show locations with available capacity for Standard deployments
for item in capacities["value"]:
    props = item["properties"]
    if props["availableCapacity"] > 0 and "Standard" in props["skuName"]:
        print(f"{item['location']} ({props['skuName']}): {props['availableCapacity']} available")

Champs clés :

Champ Description
location Région Azure
properties.skuName Type de déploiement (Standard, GlobalStandard, DataZoneStandard, ProvisionedManaged, etc.)
properties.availableCapacity Unités de capacité disponibles dans votre abonnement pour ce modèle, cet emplacement et ce type de déploiement
properties.availableFinetuneCapacity Capacité de réglage affinée disponible (le cas échéant)

Automatiser le déploiement

Pour créer par programmation des déploiements Azure OpenAI et attribuer un quota de jetons par minute (TPM) à l’aide de REST, d’Azure CLI, d’Azure PowerShell, d’ARM, de Bicep ou de Terraform, consultez Automatisez les déploiements Azure OpenAI avec quota dans Microsoft Foundry.

Suppression de ressources

Lorsqu’une tentative de suppression d’une ressource OpenAI Azure est effectuée à partir du portail Azure si des déploiements sont toujours présents, la suppression est bloquée jusqu’à ce que les déploiements associés soient supprimés. La suppression des déploiements permet d’abord de libérer correctement les allocations de quota afin qu’elles puissent être utilisées sur de nouveaux déploiements.

Toutefois, si vous supprimez une ressource à l’aide de l’API REST ou d’une autre méthode programmatique, cela ignore la nécessité de supprimer d’abord les déploiements. Lorsque cela se produit, l’allocation de quota associée reste indisponible pour être affectée à un nouveau déploiement pendant 48 heures jusqu’à ce que la ressource soit vidée. Pour déclencher une purge immédiate pour une ressource supprimée afin de libérer le quota, suivez les instructions de suppression d’une ressource supprimée.

Étapes suivantes

  • Pour consulter les valeurs par défaut du quota pour Azure OpenAI, consultez l’article quotas & limites
  • Last updated on