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

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 ?

Quel débit d’unités de débit approvisionnées (PTU) obtenez-vous pour chaque modèle ?

La quantité de débit (jetons par minute ou TPM) obtenue par un déploiement par PTU est une fonction des jetons d’entrée et de sortie par minute. La génération de jetons de sortie nécessite davantage de traitement que les jetons d’entrée. Ainsi, vous générerez de jetons de sortie, plus vos TPM globaux seront faibles. Le service équilibre de manière dynamique les coûts d’entrée et de sortie. Les utilisateurs n’ont donc pas à définir de limites d’entrée et de sortie spécifiques. Cette approche signifie que votre déploiement est résilient aux fluctuations dans la forme de charge de travail.

Pour vous aider à simplifier l’effort de dimensionnement, le tableau suivant présente les TPM par PTU pour les modèles gpt-4o et gpt-4o-mini

Pour découvrir la liste complète, consultez la Calculatrice AOAI Studio.

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 approvisionnées sont octroyées à un abonnement sous forme de quota. 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.

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 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 supérieur est requis, les clients peuvent demander un quota via le lien Demander une augmentation de quota. Vous trouverez ce lien à droite des onglets de quota Unité de débit managée approvisionnée ou Unité de débit managée approvisionnée globale sur la plateforme Azure OpenAI Studio. Le formulaire permet au client de demander une augmentation du quota PTU indiqué pour une région donnée. Le client reçoit 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. 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ées 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 à leur déploiement, utilisez l’API de capacité ou l’expérience de déploiement de Studio pour fournir des informations en temps réel sur la disponibilité de la capacité.

Dans Azure OpenAI Studio, l’expérience de déploiement identifie le moment où une région ne dispose pas 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 des informations sur la nouvelle expérience de déploiement dans le guide de démarrage d’Azure OpenAI Provisioned.

Vous pouvez utiliser la nouvelle API de capacités de modèle pour identifier programmatiquement le déploiement maximal dimensionné 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 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
• Pour les modèles GPT-4o et ultérieurs, les TPM par PTU sont définis séparément pour les jetons d’entrée et de sortie. Pour les modèles antérieurs, 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. Cette hiérarchisation signifie que la distribution de ces formes d’appel est importante dans le débit global. Il est possible que les modèles de trafic avec une large distribution incluant des appels volumineux aient un débit par PTU inférieur par rapport à une distribution plus restreinte avec les mêmes tailles moyennes de jetons de saisie semi-automatique et de requête.

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 de type Managé-Approvisionné et Managé-Approvisionné global, l’API retourne une erreur d’état HTTP 429 en cas de dépassement de la capacité. Cette réponse rapide 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 utiliser 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. Pour les requêtes incluant au moins 1024 jetons mis en cache, les jetons mis en cache sont soustraits de la valeur des jetons de prompt. 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 > 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.

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 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 d’échantillonnage comme max_token, il accepte plus de demandes.

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

É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)