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.
Qu’est-ce que le type de déploiement provisionné 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.
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).
Remarque
Le quota des unités de débit approvisionnées (PTU) est différent du quota standard dans Azure OpenAI et n’est pas disponible par défaut. Pour en savoir plus sur cette offre, contactez l'équipe de votre compte Microsoft.
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és de débit managées approvisionnées pour un modèle donné. |
| Latence | Latence maximale contrainte à partir du modèle. La latence globale est un facteur de forme d’appel. |
| Utilisation | Mesure d’utilisation managée approvisionnée fournie dans Azure Monitor. |
| Estimation de la taille | Calculatrice fournie dans le studio et le script de point de référence. |
Comment obtenir l’accès à Provisioned ?
Vous devez communiquer avec votre équipe de ventes/comptes Microsoft pour acquérir un débit approvisionné. Si vous n’avez pas d’équipe de ventes/comptes, malheureusement à ce stade, vous ne pouvez pas acheter de débit approvisionné.
Concepts clés
Unités de débit approvisionnées
Les unités de débit provisionnées (PTU) sont des unités de capacité de traitement du modèle que vous pouvez réserver et déployer pour traiter les prompts et générer des complétions. 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.
Types de déploiement
Lors du déploiement d’un modèle dans Azure OpenAI, vous devez définir sku-name sur Provisioned-Managed. 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
Le quota de débit provisionné représente une quantité spécifique de débit total que vous pouvez déployer. Le quota dans Azure OpenAI Service est géré au niveau de l’abonnement. Toutes les ressources Azure OpenAI dans l’abonnement partagent ce quota.
Le quota est spécifié dans les unités de débit approvisionnées et est spécifique à un triplet (type de déploiement, modèle, région). Le quota n’est pas interchangeable. Cela signifie que vous ne pouvez pas utiliser le quota pour GPT-4 pour déployer GPT-35-turbo. Vous pouvez faire une demande de support pour déplacer le quota entre les types de déploiement, les modèles ou les régions, mais l’échange n’est pas garanti.
Bien que nous fassions tout notre possible pour que le quota soit déployé, le quota ne représente pas une garantie que la capacité sous-jacente est disponible. Le service attribue la capacité pendant l’opération de déploiement et, si la capacité n’est pas disponible, le déploiement échoue avec une erreur de capacité insuffisante.
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 d’invite, 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 d’invite de jetons de 1 000 nécessitent moins de capacité que 1 appel avec 100 000 jetons dans l’invite. 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 rencontrer un débit inférieur par PTU qu’une distribution plus restreinte avec les mêmes tailles moyennes de jetons d’invite et de saisie semi-automatique.
Fonctionnement de l’application de l’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é. La métrique Provisioned-Managed Utilization dans Azure Monitor mesure une utilisation des déploiements donnée par incréments de 1 minute. Les déploiements managés approvisionnés 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). Lorsque la charge de travail dépasse la capacité de PTU allouée, le service renvoie un code d’état HTTP 429 jusqu’à ce que l’utilisation descende 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.
- 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 ?
Nous utilisons une variante de l’algorithme de compartiment qui fuit pour maintenir une utilisation inférieure à 100 % tout en permettant une certaine rafale dans le trafic. La logique générale est la suivante :
Chaque client dispose d’une quantité de capacité définie pouvant être utilisée sur un déploiement
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-msdé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_tokensspécifié dans l’appel. Si le paramètremax_tokensn’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 valeurmax_tokenssoit aussi proche que possible de la taille de génération réelle.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.
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 %. Les rafales légèrement supérieures à 100 % peuvent être autorisées sur des 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.