Partage via

Qu’est-ce que le débit approvisionné ?

  • Article

Remarque

Si vous recherchez ce qui a récemment changé avec l’offre de débit approvisionné, consultez l’article de mise à jour pour plus d’informations.

L’offre de débit provisionné est un type de déploiement de modèle qui vous permet de spécifier la quantité de débit dont vous avez besoin dans un déploiement de modèle. Azure OpenAI alloue ensuite la capacité de traitement du modèle nécessaire et garantit qu’elle est prête pour vous. Le débit approvisionné fournit :

  • Performances prévisibles : latence maximale et débit stables pour les charges de travail uniformes.
  • Capacité de traitement réservée : un déploiement configure la quantité de débit. Une fois déployé, le débit est disponible, qu’il soit utilisé ou non.
  • Économies de coûts : les charges de travail à débit élevé peuvent entraîner des économies de coûts par rapport à la consommation basée sur les jetons.

Conseil / Astuce

Quand utiliser le débit provisionné

Vous devez envisager de passer des déploiements standard aux déploiements managés provisionnés lorsque vous avez des exigences de débit et de latence bien définies et prévisibles. Cela se produit généralement quand l’application est prête pour la production ou a déjà été déployée en production et qu’il existe une compréhension du trafic attendu. Cela permet aux utilisateurs de prévoir avec précision la capacité requise et d’éviter une facturation inattendue. Les déploiements managés provisionnés sont également utiles pour les applications qui ont des exigences sensibles en temps réel/latence.

Concepts clés

Unités de débit provisionnées (PTU)

Les unités de débit provisionnées (PTU) sont des unités génériques de capacité de traitement de modèle que vous pouvez utiliser pour dimensionner les déploiements provisionnés afin d'atteindre le débit requis pour le traitement des invites et la génération des complétions. Les unités de débit provisionnées sont accordées dans le cadre d'un abonnement en tant que quota et sont utilisées pour définir les coûts. Chaque quota est spécifique à une région et définit le nombre maximal de PTU que vous pouvez attribuer aux déploiements dans cet abonnement et cette région. Pour plus d’informations sur les coûts associés à l’offre gérée et aux PTU, consultez Compréhension des coûts associés à la PTU.

Types de déploiement

Lors de la création d’un déploiement approvisionné dans Azure AI Foundry, le type de déploiement dans la boîte de dialogue Créer un déploiement peut être défini sur le type Déploiement global approvisionné managé de zone de données ou sur le type Déploiement managé approvisionné régional, en fonction des besoins de traitement des données pour la charge de travail concernée.

Lors de la création d’un déploiement approvisionné dans Azure OpenAI via l’interface CLI ou l’API, le sku-name peut être défini sur GlobalProvisionedManaged, DataZoneProvisionedManaged ou ProvisionedManaged, en fonction du besoin de traitement des données pour la charge de travail concernée. Pour adapter l’exemple de commande Azure CLI ci-dessous à un autre type de déploiement, mettez simplement à jour le paramètre sku-name pour le faire correspondre au type de déploiement que vous souhaitez.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06  \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged

Transparence de la capacité

Azure OpenAI étant un service très recherché, la demande des clients peut dépasser la capacité en GPU du service. Microsoft s’efforce de fournir une capacité pour l’ensemble des régions et des modèles demandés, mais il est toujours possible qu’une région soit épuisée. Cette contrainte peut limiter la capacité de certains clients à créer un déploiement avec le modèle, la version ou le nombre de PTU souhaités dans une région spécifique, même s’ils disposent d’un quota dans cette région. De manière générale :

  • Le quota limite le nombre maximal de PTU pouvant être déployées dans un abonnement et une région, et ne constitue pas une garantie de disponibilité de la capacité.
  • La capacité est allouée au moment du déploiement et est maintenue tant que le déploiement existe. Si la capacité de service n’est pas disponible, le déploiement échoue
  • Les clients utilisent des informations en temps réel sur la disponibilité des quotas/capacités pour choisir une région adaptée à leur scénario avec la capacité de modèle nécessaire
  • Le scale-down ou la suppression d’un déploiement libère de la capacité dans la région. La disponibilité de la capacité n’est pas garantie si le déploiement est recréé ou fait l’objet d’un scale-up ultérieurement.

Aide sur la capacité régionale

Pour trouver la capacité nécessaire à leurs déploiements, utilisez l’API de capacité ou l’expérience de déploiement d’Azure AI Foundry afin de fournir des informations en temps réel sur la disponibilité des capacités.

Dans Azure AI Foundry, l’expérience de déploiement identifie le moment où une région ne dispose plus de la capacité nécessaire pour déployer le modèle. Il examine le modèle, la version et le nombre de PTU souhaitées. Si la capacité n’est pas disponible, l’expérience invite les utilisateurs à sélectionner une autre région.

Vous trouverez plus d’informations sur l’expérience de déploiement dans le guide de prise en main d’Azure OpenAI Provisioned.

L’API de capacité de modèle peut être utilisée pour identifier par programmation le déploiement de taille maximale d’un modèle spécifié. L’API considère votre quota et la capacité de service dans la région.

Si aucune région acceptable n’est disponible pour prendre en charge le modèle, la version et/ou les PTU souhaités, les clients peuvent également essayer d’effectuer les étapes suivantes :

  • Essayez le déploiement avec un plus petit nombre de PTU.
  • Essayez le déploiement à un moment différent. La disponibilité de la capacité change de manière dynamique en fonction de la demande du client, et une capacité supplémentaire peut devenir disponible par la suite.
  • Vérifiez que le quota est disponible dans toutes les régions acceptables. L’API des capacités de modèle et l’expérience d’Azure AI Foundry prennent en compte la disponibilité des quotas en retournant d’autres régions pour la création d’un déploiement.

Comment analyser la capacité ?

La métrique Utilisation gérée provisionnée V2 dans Azure Monitor mesure une utilisation particulière du déploiement par incréments d'une minute. Tous les types de déploiements approvisionnés sont optimisés pour faire en sorte que les appels acceptés soient traités avec un temps de traitement cohérent du modèle (la latence réelle de bout en bout dépend des caractéristiques d’un appel).

Fonctionnement des performances d'utilisation

Les déploiements approvisionnés vous permettent de disposer d’une quantité allouée de capacité de traitement de modèle pour l’exécution d’un modèle donné.

Dans tous les types de déploiements approvisionnés, quand la capacité est dépassée, l’API va retourner une erreur d’état HTTP 429. Cette réponse rapide permet à l’utilisateur de prendre des décisions sur la gestion de son trafic. Les utilisateurs peuvent rediriger les demandes vers un déploiement distinct, vers une instance de déploiement standard ou utiliser une stratégie de nouvelle tentative pour gérer une requête donnée. Le service continue à retourner le code d’état HTTP 429 jusqu’à ce que l’utilisation passe en dessous de 100 %.

Que dois-je faire lorsque je reçois une réponse 429 ?

La réponse 429 n’est pas une erreur, mais fait à la place partie de la conception pour indiquer aux utilisateurs qu’un déploiement donné est entièrement utilisé à un moment donné. Grâce à une réponse en cas d’échec rapide, vous avez le contrôle sur la façon de gérer ces situations d’une manière qui correspond au mieux aux exigences de votre application.

Les en-têtes retry-after-ms et retry-after dans la réponse vous indiquent le temps d’attente avant l’acceptation de l’appel suivant. La façon dont vous choisissez de traiter cette réponse dépend des exigences de votre application. Voici quelques éléments à prendre en compte :

  • Vous pouvez envisager de rediriger le trafic vers d’autres modèles, déploiements ou expériences. Cette option est la solution avec la plus faible latence car l’action peut être entreprise dès que vous recevez le signal 429. Pour obtenir des idées sur la façon d’implémenter efficacement ce modèle, consultez ce billet de la communauté.
  • Si vous êtes d’accord avec des latences plus longues par appel, implémentez la logique de nouvelle tentative côté client. Cette option vous offre la plus grande quantité de débit par PTU. Les bibliothèques clientes Azure OpenAI incluent des capacités intégrées pour la gestion des nouvelles tentatives.

Comment le service décide-t-il quand envoyer un signal 429 ?

Dans tous les types de déploiements approvisionnés, chaque requête est évaluée individuellement, en fonction de sa taille définie pour les requêtes, de sa taille de génération attendue et du modèle pour déterminer son utilisation attendue. Contrairement aux déploiements standard, qui ont un comportement de limitation de débit personnalisé en fonction de la charge estimée du trafic. Pour les déploiements standard, cela peut entraîner la génération d’erreurs HTTP 429 avant le dépassement des valeurs de quota définies si le trafic n’est pas distribué uniformément.

Pour les déploiements approvisionnés, nous utilisons une variante de l’algorithme du seau percé pour maintenir une utilisation inférieure à 100 %, tout en permettant certains pics dans le trafic. La logique générale est la suivante :

  1. Chaque client dispose d’une quantité de capacité définie pouvant être utilisée sur un déploiement

  2. Lorsqu’une requête est effectuée :

    a) Lorsque l’utilisation actuelle est supérieure à 100 %, le service retourne un code 429 avec l’en-tête retry-after-ms défini sur le temps jusqu’à ce que l’utilisation soit inférieure à 100 %

    b. Sinon, le service estime la modification incrémentielle de l’utilisation nécessaire pour traiter la requête en combinant les jetons d’invite, moins les jetons mis en cache, et la valeur max_tokens spécifiée dans l’appel. Un client peut recevoir une remise de jusqu’à 100 % sur ses jetons de prompt selon la taille de ses jetons mis en cache. Si le paramètre max_tokens n’est pas spécifié, le service estime une valeur. Cette estimation peut entraîner une concurrence inférieure à celle prévue quand le nombre de jetons générés réels est faible. Pour la concurrence la plus élevée, veillez à ce que la valeur max_tokens soit aussi proche que possible de la taille de génération réelle.

  3. Lorsqu’une requête se terminé, nous connaissons désormais le coût de calcul réel de l’appel. Pour garantir une comptabilité précise, nous corrigeons l’utilisation à l’aide de la logique suivante :

    a) Si l’utilisation réelle est > à l’utilisation estimée, la différence est ajoutée à l’utilisation du déploiement.

    b. Si l’utilisation réelle < estimée, la différence est soustraite.

  4. L’utilisation globale est décrémentée à un rythme continu en fonction du nombre de PTU déployés.

Remarque

Les appels sont acceptés jusqu’à ce que l’utilisation atteigne 100 %. Des rafales légèrement supérieures à 100 % peuvent être autorisées sur de courtes périodes, mais au fil du temps, votre trafic est limité à 100 % d’utilisation.

Diagramme illustrant comment les appels suivants sont ajoutés à l’utilisation.

Combien d’appels simultanés puis-je avoir sur mon déploiement ?

Le nombre d’appels simultanés que vous pouvez obtenir dépend de la forme de chaque appel (taille de l’invite, paramètre max_tokens, etc.). Le service continue d’accepter des appels jusqu’à ce que l’utilisation atteigne 100 %. Si vous souhaitez déterminer le nombre approximatif d’appels simultanés, vous pouvez modéliser le nombre maximal de requêtes par minute d’une forme particulière d’appel dans la calculatrice de capacité. Si le système génère moins de jetons que le nombre de jetons de sortie définis pour le paramètre max_tokens, le déploiement approvisionné accepte plus de requêtes.

Quels sont les modèles et régions disponibles pour le débit approvisionné ?

Disponibilité globale du modèle managé approvisionné

Région gpt-4.1, 2025-04-14 gpt-4.1-mini, 2025-04-14 o3-mini, 2025-01-31 o1, 2024-12-17 gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o, 2024-11-20 gpt-4o-mini, 2024-07-18
australiaeast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Brésil Sud ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Canada-Est ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Allemagne Ouest-Centrale ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
italynorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
KoreaCentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norvège-Est ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
polognecentre ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southafricanorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southeastasia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sud de l'Inde ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centre de la suède ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
suisse nord ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
SuisseOuest ✅ - ✅ ✅ ✅ ✅ ✅ ✅
uaenorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westeurope ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Remarque

La version approvisionnée de gpt-4Version :turbo-2024-04-09 est actuellement limitée au texte uniquement.

Étapes suivantes