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

Affichage actuel :Version du portail - Passer à la version du nouveau portail Foundry

Note

Les liens de cet article peuvent ouvrir du contenu dans la nouvelle documentation Microsoft Foundry au lieu de la documentation Foundry (classique) que vous affichez maintenant.

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.

Attribuer un quota

Lorsque vous créez un déploiement de modèle, vous avez la possibilité d’attribuer des jetons-Per-Minute (TPM) à ce déploiement. TPM peut être modifié par incréments de 1 000, et correspond aux limites de taux TPM et RPM appliquées à votre déploiement, comme mentionné ci-dessus.

Pour créer un déploiement à partir du portail Microsoft Foundry sélectionnez Déploiements>Déployer>Deploy base model>Select Model>Confirm.

Après le déploiement, vous pouvez ajuster votre allocation TPM en sélectionnant et en modifiant votre modèle à partir de la page Déploiements dans le portail Foundry. Vous pouvez également modifier ce paramètre à partir de la page Gestion>Quota du modèle.

Important

Les quotas et les limites sont susceptibles de changer. Pour obtenir les informations les plus up-to-date, consultez notre article sur les quotas et les limites.

Afficher et demander un quota

Pour obtenir une vue globale de vos allocations de quota sur l’ensemble des déploiements d’une région donnée, sélectionnez Management>Quota dans le portail Foundry :

  • Déploiement : déploiements de modèles divisés par classe de modèle.
  • Type de quota : il y a une valeur de quota par région pour chaque type de modèle. Le quota couvre toutes les versions de ce modèle.
  • Répartition des quotas : pour chaque nom de quota, cette section indique la quantité de quota utilisée par les déploiements ainsi que le quota total approuvé pour cet abonnement et cette région. Cette quantité de quota utilisée est également représentée dans le graphique à barres.
  • Demande de quota : l'icône permet d'accéder à ce formulaire pour envoyer des demandes d'augmentation de quota.

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'assignation de TPM à un déploiement définit les limites des taux de jetons par minute (TPM) et de requêtes par 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 qui doivent être traités lors de la réception d'une demande. 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
  • Configuration du paramètre max_tokens
  • Le paramètre best_of

À mesure que les requêtes arrivent au point de terminaison de déploiement, le nombre estimé de jetons traités est ajouté à un compteur de jetons de toutes les requêtes, qui est réinitialisé chaque minute. Si, à tout moment, la limite de taux TPM est atteinte, les demandes supplémentaires reçoivent un code de réponse 429 jusqu’à ce que le compteur soit réinitialisé.

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 relatifs à la limitation du 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 limitation de débit fondé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 pour détecter quand vous approchez des limites et throttlez proactivement les requêtes avant de recevoir un 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 attendez des réponses d’environ 200 jetons, ne définissez pas max_tokens à 4 000.
  • Définissez best_of sur 1 , sauf si vous avez spécifiquement besoin de complétions multiples. Chaque incrément de best_of multiplie le nombre de jetons par rapport à votre taux limite.
  • Réduisez la taille des invites si possible. Les instructions plus courtes utilisent moins de jetons et vous aident à gérer votre limite de débit.

Implémenter une logique de nouvelle tentative avec retrait exponentiel

Réessayez automatiquement les demandes lorsque vous recevez une réponse 429. Utilisez la valeur de l’en-tête retry-after-ms lorsqu’elle est disponible ; sinon, appliquez un backoff exponentiel avec gigue aléatoire :

  1. Patientez un court délai aléatoire après le premier échec.
  2. Si la nouvelle tentative échoue, doublez le délai (repli 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 reprise intégrée du Kit de développement logiciel (SDK) (la plus simple - recommandée)

Le SDK Python Azure OpenAI (openai v1.0+) intègre un mécanisme de nouvelle tentative automatique avec backoff exponentiel pour les erreurs 429 et les erreurs 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 réessais personnalisée, définissez max_retries=0 sur le client SDK afin de désactiver son mécanisme de réessais intégré. Sinon, chaque tentative de Tenacity pourrait entraîner jusqu'à deux réessais supplémentaires du SDK, entraînant ainsi beaucoup plus de requêtes 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, et pas seulement le quota au niveau de l’abonnement. Vous avez peut-être approuvé le quota au niveau de l'abonnement, mais vous avez reçu une erreur 429, car le quota n'est pas alloué 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 examiner les tendances d’utilisation sur 24 heures et sept jours et détecter les schémas d'utilisation en rafale.
  • Utilisez la gestion des quotas dans le portail Foundry pour augmenter les Transactions Par Minute (TPM) sur les déploiements à trafic élevé et réduire les TPM sur ceux 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 en cas d'augmentation de la charge.
  • 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 requêtes et les traiter à un rythme 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 limitation de seuil 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 première Action recommandée
Limite de débit dépassée "Demandes à ... ont été limités » ou « La limite de taux est excédée » Vos requêtes ont dépassé la limite de débit TPM ou RPM correspondant au 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 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 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 indiquent une faible utilisation. 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 vous pouvez voir des codes d'état HTTP 429 même lorsque les métriques d’utilisation des jetons sont inférieures au quota

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

  • Les mesures d’utilisation des jetons dans Azure Monitor affichent les jetons facturés issus 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 pourrait réduire temporairement la limite de débit effectivement 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