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

Remarque

Des mises à jour significatives ont été apportées à l’offre Azure OpenAI Provisioned le 12 août 2024, notamment l’alignement du modèle d’achat sur les normes Azure et le passage à un quota indépendant du modèle. Nous recommandons vivement aux clients intégrés avant cette date de lire la mise à jour d’août d’Azure OpenAI Provisioned pour en savoir plus sur ces changements.

La capacité de débit approvisionnée vous permet de spécifier la quantité de débit dont vous avez besoin dans un déploiement. Le service alloue ensuite la capacité de traitement du modèle nécessaire et garantit qu’elle est prête pour votre utilisation. Le débit est défini en termes d’unités de débit approvisionnées (PTU), ce qui est une façon normalisée de représenter le débit pour votre déploiement. Chaque paire modèle-version nécessite des quantités différentes de PTU afin de déployer et de fournir des quantités différentes de débit par PTU.

Que fournissent les types de déploiement Approvisionné et Approvisionné global ?

• 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.

Un déploiement Azure OpenAI est une unité de gestion pour un modèle OpenAI spécifique. Un déploiement permet au client d’accéder à un modèle pour l’inférence et intègre plus de fonctionnalités telles que la modération du contenu (consultez la documentation relative à la modération du contenu). Les déploiements mondiaux sont disponibles dans les mêmes ressources Azure OpenAI que les types de déploiements non mondiaux, mais ils vous permettent de tirer parti de l’infrastructure mondiale d’Azure pour router dynamiquement le trafic vers le centre de données avec la meilleure disponibilité pour chaque requête.

Qu’obtenez-vous ?

Rubrique	approvisionné
De quoi s’agit-il ?	Fournit un débit garanti à des incréments plus petits que l'offre provisionnée existante. Les déploiements ont une latence maximale cohérente pour une paire modèle-version donnée.
Pour qui ?	Les clients qui veulent un débit garanti avec une variance de latence minimale.
Quota	Unité de débit géré par l’approvisionnement ou unité de débit géré par l’approvisionnement global affectée par région. Le quota peut être utilisé sur n’importe quel modèle Azure OpenAI disponible.
Latence	Latence maximale contrainte à partir du modèle. La latence globale est un facteur de forme d’appel.
Utilisation	Mesure v2 d’utilisation gérée par l’approvisionnement fournie dans Azure Monitor.
Estimation de la taille	Calculatrice fournie dans le studio et le script de point de référence.

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

Région	gpt-4, 0613	gpt-4, 1106-Preview	gpt-4, 0125-Preview	gpt-4, turbo-2024-04-09	gpt-4o, 2024-05-13	gpt-4o, 2024-08-06	gpt-4o-mini, 2024-07-18	gpt-4-32k, 0613	gpt-35-turbo, 1106	gpt-35-turbo, 0125
australiaeast	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
brazilsouth	✅	✅	✅	-	✅	-	✅	✅	✅	-
canadacentral	✅	-	-	-	-	-	-	✅	-	✅
canadaeast	✅	✅	-	✅	✅	-	✅	-	✅	-
eastus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
eastus2	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
francecentral	✅	✅	✅	-	✅	-	✅	✅	-	✅
germanywestcentral	✅	✅	✅	✅	✅	-	-	✅	✅	-
japaneast	-	✅	✅	✅	✅	-	✅	-	-	✅
KoreaCentral	✅	-	-	✅	✅	-	✅	✅	✅	-
northcentralus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
norwayeast	✅	-	✅	-	-	-	✅	✅	-	-
polognecentre	✅	✅	✅	✅	✅	-	-	✅	✅	✅
southafricanorth	✅	✅	-	✅	✅	-	-	✅	✅	-
southcentralus	✅	✅	✅	✅	✅	-	-	✅	✅	✅
southindia	✅	✅	✅	-	✅	-	✅	✅	✅	✅
centre de la suède	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
suisse nord	✅	✅	✅	✅	✅	-	✅	✅	✅	✅
switzerlandwest	-	-	-	-	-	-	-	-	-	✅
uksouth	✅	✅	✅	✅	✅	-	-	✅	✅	✅
westus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
westus3	✅	✅	✅	✅	✅	✅	-	✅	✅	✅

Remarque

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

Concepts clés

Types de déploiement

Lors de la création d’un déploiement provisionné dans Azure OpenAI Studio, le type de déploiement dans la boîte de dialogue Créer un déploiement est Provisionné-Managé. Lors de la création d’un déploiement géré par l’approvisionnement global dans Azure OpenAI Studio, le type de déploiement dans la boîte de dialogue Créer un déploiement est Géré par l’approvisionnement global.

Lors de la création d’un déploiement approvisionné dans Azure OpenAI via l’interface CLI ou l’API, vous devez définir sku-name sur ProvisionedManaged. Lors de la création d’un déploiement approvisionné global dans Azure OpenAI via l’interface CLI ou l’API, vous devez définir sku-name sur GlobalProvisionedManaged. sku-capacity spécifie le nombre de PTU attribués au déploiement.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613  \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged 

Quota

Unités de débit approvisionnées

Les unités de débit provisionné (PTU, Provisioned Throughput Unit) 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 prompts et la génération des complétions. Les unités de débit provisionné sont accordées à un abonnement en tant que quota sur une base régionale, ce qui définit le nombre maximal de PTU pouvant être affectées aux déploiements dans cet abonnement et cette région.

Quota indépendant du modèle

Contrairement au quota de jetons par minute (TPM) utilisé par d’autres offres Azure OpenAI, les PTU sont indépendantes du modèle. Les PTU peuvent être utilisées pour déployer n’importe quel modèle/version pris en charge dans la région.

Pour les déploiements approvisionnés, le nouveau quota apparaît dans Azure OpenAI Studio sous la forme d’un élément de quota nommé Unité de débit managé par l’approvisionnement. Pour les déploiements gérés par l’approvisionnement global, le nouveau quota apparaît dans Azure OpenAI Studio sous la forme d’un élément de quota nommé Unité de débit managé par l’approvisionnement global. Dans le volet Quota de Studio, vous pouvez développer l’élément de quota pour afficher les déploiements contribuant à l’utilisation de chaque quota.

Obtention d’un quota PTU

Le quota PTU est disponible par défaut dans de nombreuses régions. Si un quota supplémentaire est nécessaire, les clients peuvent en demander un à l’aide du lien Demander un quota à droite des éléments de quota Unité de débit géré par l’approvisionnement ou Unité de débit géré par l’approvisionnement global dans Azure OpenAI Studio. Le formulaire permet au client de demander une augmentation du quota PTU indiqué pour une région donnée. Le client recevra un e-mail à l’adresse indiquée une fois la demande approuvée, généralement dans un délai de deux jours ouvrables.

Nombre minimum de PTU par modèle

La capacité minimale de déploiement, d’incréments et de traitement PTU associée à chaque unité varie selon la version et le type de modèle.

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. Cela 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 aider les utilisateurs à trouver la capacité nécessaire à leurs déploiements, les clients utilisent une nouvelle API et une nouvelle expérience Studio pour fournir des informations en temps réel.

Dans Azure OpenAI Studio, l’expérience de déploiement identifie quand une région manque de capacité pour prendre en charge le modèle, la version et le nombre de PTU souhaités, et dirige l’utilisateur vers une autre région si nécessaire.

Vous trouverez des informations sur la nouvelle expérience de déploiement dans le guide de démarrage d’Azure OpenAI Provisioned.

Vous pouvez également utiliser la nouvelle API de capacités de modèle pour identifier par programmation la taille maximale du déploiement d’un modèle spécifié qu’il est possible de créer dans chaque région en fonction de la disponibilité du quota dans l’abonnement et de 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 de capacités de modèle et l’expérience Studio prennent en compte la disponibilité des quotas dans le retour d’autres régions pour la création d’un déploiement.

Détermination du nombre de PTU nécessaires pour une charge de travail

Les PTU représentent une quantité de capacité de traitement du modèle. Comme pour votre ordinateur ou vos bases de données, différentes charges de travail ou requêtes adressées au modèle consomment différentes quantités de capacité de traitement sous-jacente. La conversion des caractéristiques de forme d’appel (taille de prompt, taille de génération et taux d’appel) en PTU est complexe et non linéaire. Pour simplifier ce processus, vous pouvez utiliser la calculatrice de capacité Azure OpenAI pour dimensionner des formes de charge de travail spécifiques.

Quelques considérations générales :

• Les générations nécessitent plus de capacité que les invites
• Les appels plus volumineux sont progressivement plus coûteux à calculer. Par exemple, 100 appels avec une taille de prompt de 1 000 jetons nécessitent moins de capacité qu’un appel avec 100 000 jetons dans le prompt. Cela signifie également que la distribution de ces formes d’appel est importante dans le débit global. Les modèles de trafic avec une large distribution qui inclut des appels très volumineux peuvent se heurter à un débit inférieur par PTU qu’une distribution plus restreinte avec les mêmes tailles moyennes de jetons de prompt et de saisie semi-automatique.

Fonctionnement des performances d'utilisation

Les déploiements approvisionnés et approvisionnés globaux 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 les déploiements gérés par l’approvisionnement ou par l’approvisionnement global, l’API retourne immédiatement une erreur d’état HTTP 429 lors d’un dépassement de la capacité. Cela permet à l’utilisateur de prendre des décisions sur la gestion de son trafic. Les utilisateurs peuvent rediriger des requêtes vers un déploiement distinct, vers une instance standard de paiement à l’utilisation ou tirer profit d’une stratégie de nouvelle tentative pour gérer une demande donnée. Le service continue à retourner le code d’état HTTP 429 jusqu’à ce que l’utilisation passe en dessous de 100 %.

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. Les déploiements gérés par l’approvisionnement et par l’approvisionnement global sont optimisés pour s’assurer que les appels acceptés sont traités avec un temps de traitement de modèle cohérent (la latence réelle de bout en bout dépend des caractéristiques d’un appel).

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 les offres Géré par l’approvisionnement et Géré par l’approvisionnement global, chaque requête est évaluée individuellement, en fonction de sa taille d’invite, de sa taille de génération attendue et du modèle pour déterminer son utilisation attendue. Ceci vient contraster avec les déploiements avec paiement à l’utilisation qui ont un comportement de limitation de débit personnalisé en fonction de la charge estimée du trafic. Pour les déploiements avec paiement à l’utilisation, 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 Géré par l’approvisionnement et Géré par l’approvisionnement global, nous utilisons une variante de l’algorithme de compartiment qui fuit pour maintenir une utilisation inférieure à 100 %, tout en permettant certaines rafales 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 des jetons d’invite et le max_tokens spécifié dans l’appel. 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 > estimée, la différence est ajoutée à l’utilisation b du déploiement. 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.

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_token, etc.). Le service continuera à accepter des appels jusqu’à ce que l’utilisation atteigne 100 %. Pour 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 d’échantillonnage comme max_token, il accepte plus de demandes.

Étapes suivantes

• En savoir plus sur les étapes d’intégration pour les déploiements approvisionnés
• Guide de démarrage des unités de débit approvisionnées (PTU)