Partage via

Qu’est-ce que le débit provisionné pour les modèles Foundry ?

Remarque

Cet article fait référence au portail Microsoft Foundry (classique).

🔄 Accédez à la documentation Microsoft Foundry (nouveau) si vous utilisez le nouveau portail.

Remarque

Cet article fait référence au portail Microsoft Foundry (nouveau).

Conseil / Astuce

Pour plus d’informations sur les modifications récentes apportées à l’offre de débit approvisionné, consultez l’article sur la mise à jour.

L’offre de débit provisionné de Microsoft Foundry est un type de déploiement qui vous permet de spécifier le débit nécessaire pour un modèle. Foundry alloue ensuite la capacité de traitement du modèle nécessaire et garantit qu’elle est prête pour vous. Utilisez le débit provisionné que vous avez demandé dans un portefeuille diversifié de modèles vendus directement par Azure. Ces modèles incluent des modèles Azure OpenAI et des familles de modèles phares récemment introduites comme Azure DeepSeek dans Foundry Models, avec plus de familles de modèles intégrées au fil du temps.

Le débit approvisionné fournit :

Avantage Descriptif
Choix plus large du modèle Accès aux derniers modèles phares
Flexibilité Changer de modèles et de méthodes de déploiement avec un quota de débit d'approvisionnement donné
Remises significatives Améliorer l’utilisation de votre réservation avec un choix de réservation plus flexible
Performances prévisibles Latence maximale et débit stables pour les charges de travail uniformes
Capacité de traitement allouée Le débit est disponible, qu’il soit utilisé ou non une fois déployé
Économies Les charges de travail à débit élevé peuvent fournir des économies de coûts par rapport à la consommation basée sur des jetons

Conseil / Astuce

Prerequisites

  • Un abonnement Azure. Créez-en un gratuitement.
  • Projet Microsoft Foundry avec un modèle déployé en utilisant un type de déploiement à débit déterminé à l'avance.
  • Quota de débit provisionné alloué à votre abonnement dans votre région cible.
  • Azure CLI (si vous envisagez de créer des déploiements via la ligne de commande).

Quand utiliser le débit provisionné

Envisagez des déploiements avec débit provisionné lorsque vous avez des exigences prédéfinies en matière de débit et de latence, typiquement pour les applications de production avec des modèles de trafic connus. Le débit provisionné est également utile pour les applications sensibles à la latence ou en temps réel.

Comprendre l’allocation PTU

Les unités de débit approvisionnées (PTU) et les types de déploiement sont les blocs de construction du débit approvisionné. Les sections suivantes expliquent comment elles fonctionnent.

Unités de débit approvisionné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 utilisez pour dimensionner les déploiements provisionnés afin d’obtenir le débit requis pour le traitement des requêtes et la génération de résultats. Les unités de débit fournies sont allouées à un abonnement sous forme de quota et servent à déterminer les coûts. Chaque quota est spécifique à une région et définit le nombre maximal de PTU qui peuvent être affectés aux déploiements dans cet abonnement et cette région.

Gestion des coûts dans le cadre d'une réservation PTU partagée

Utilisez la fonctionnalité PTU pour gérer en toute transparence les coûts des modèles Foundry sous une réservation PTU partagée. Toutefois, les unités PTU requises pour les performances de déploiement et de débit sont adaptées dynamiquement aux modèles choisis. Pour en savoir plus sur les coûts PTU et les points de latence de modèle, consultez Présentation des coûts associés à la PTU.

Les réservations PTU existantes sont automatiquement mises à niveau pour permettre aux clients d’améliorer leur efficacité et leurs économies au fur et à mesure qu’ils déploient des modèles Foundry. Par exemple, supposons que vous disposez d’une réservation PTU existante avec 500 PTU achetés. Vous utilisez 300 unités pour les modèles Azure OpenAI, et vous choisissez également d’utiliser PTU pour déployer Azure DeepSeek, Azure Llama ou d’autres modèles avec la fonctionnalité PTU sur les modèles Foundry.

  • Si vous utilisez les 200 PTU restants pour DeepSeek-R1, les 200 PTU partagent automatiquement la réduction de réservation et votre utilisation totale pour la réservation est de 500 PTU.

  • Si vous utilisez 300 PTU pour DeepSeek-R1, 200 PTU partagent automatiquement la remise de réservation alors que 100 PTU dépassent la réservation et sont facturés avec le tarif horaire de DeepSeek-R1.

Pour en savoir plus sur les économies réalisées grâce aux réservations de débit provisionné, consultez Économiser sur les coûts avec les réservations de débit provisionné sur Microsoft Azure AI Foundry.

Types de déploiement

Lorsque vous créez un déploiement provisionné dans Foundry, le type de déploiement dans la boîte de dialogue Créer un déploiement peut être défini sur le débit global provisionné, le débit provisionné de zone de données ou le type de déploiement de débit provisionné régional en fonction des besoins de traitement des données pour la charge de travail donnée.

Lorsque vous créez un déploiement provisionné dans Foundry via le CLI ou l'API, vous pouvez définir sku-name sur GlobalProvisionedManaged, DataZoneProvisionedManaged, ou ProvisionedManaged selon les besoins de traitement des données de la charge de travail.

Type de déploiement Nom de référence sku dans l’interface CLI
Débit provisionné global GlobalProvisionedManaged
Débit provisionné pour la zone de données DataZoneProvisionedManaged
Débit approvisionné régional Approvisionné et Géré

Pour adapter l’exemple de commande Azure CLI suivant à un autre type de déploiement, mettez à jour le sku-name paramètre pour qu’il corresponde au type de déploiement que vous souhaitez déployer.

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

Gérer la capacité et la disponibilité

La capacité pour le débit approvisionné est soumise à la disponibilité régionale et à la demande en temps réel. Les sections suivantes décrivent le fonctionnement de la capacité et comment la trouver.

Transparence de la capacité

Les modèles vendus directement par Azure sont des services très recherchés où la demande du client peut dépasser la capacité gpu de 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 de leur modèle, version ou nombre de PTU souhaités dans une région souhaitée, même s’ils disposent d’un quota disponible dans cette région.

Important

Le quota limite le nombre maximal de PTUs qui peuvent être déployées dans un abonnement et une région, mais il ne garantit pas la disponibilité de la capacité nécessaire. La capacité est allouée au moment du déploiement.

D’une manière générale :

  • Le quota ne garantit pas la capacité. Le quota place une limite sur le nombre maximal de PTU pouvant être déployés dans un abonnement et une région.
  • La capacité est allouée au moment du déploiement et est conservée tant que le déploiement existe. Si la capacité du service n’est pas disponible, le déploiement échoue.
  • Utilisez des informations en temps réel sur le quota et la disponibilité de la capacité pour choisir une région appropriée pour votre scénario.
  • Réduire ou supprimer un déploiement renvoie la capacité à la région. Il n’existe aucune garantie que la capacité soit disponible si le déploiement est mis à l’échelle ou recréé 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 Foundry pour fournir des informations en temps réel sur la disponibilité de la capacité.

Dans Foundry, l’expérience de déploiement identifie lorsqu’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és. Si la capacité n’est pas disponible, l’expérience permet aux utilisateurs de 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 de Foundry Provisioned.

Utilisez l’API de capacité de modèle 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 une région acceptable n’est pas disponible pour prendre en charge le modèle, la version et/ou la PTU souhaités, les clients peuvent également essayer les étapes suivantes :

  • Essayez le déploiement avec un plus petit nombre de PTUs.
  • Essayez le déploiement à un moment différent. La disponibilité de la capacité change dynamiquement en fonction de la demande du client, et une plus grande capacité peut devenir disponible ultérieurement.
  • 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 Foundry prennent en compte la disponibilité de quotas afin de proposer d’autres régions pour la création d’un déploiement.

Surveiller l’utilisation et les performances

Les sections suivantes expliquent comment surveiller l’utilisation et gérer les limites de capacité.

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

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éploiement approvisionnés, lorsque la capacité est dépassée, l’API retourne une erreur d’état HTTP 429. La réponse rapide permet à l’utilisateur de prendre des décisions sur la façon de gérer 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 %.

Gérer les réponses HTTP 429

La réponse 429 n’est pas une erreur, mais elle fait plutôt 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 :

  • Envisagez 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 Foundry incluent des fonctionnalités intégrées pour la gestion des nouvelles tentatives.

Évaluation des demandes basées sur l’utilisation

Dans tous les types de déploiement provisionnés, chaque requête est évaluée individuellement en fonction de la taille de l'invite, de la taille de génération attendue et du modèle afin de déterminer l'utilisation prévue. Ce comportement est 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, ce comportement de limitation de débit personnalisé peut entraîner des erreurs HTTP 429 avant que les valeurs de quota définies ne soient dépassées 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é définie de capacité qu’il peut utiliser 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 délai avant 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 max_tokens paramètre 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 %. Les rafales d’un peu plus de 100 % peuvent être autorisées pendant de courtes périodes, mais au fil du temps, votre trafic est limité à 100 % d’utilisation.

Diagramme de l’algorithme de seau percé pour l’utilisation du débit provisionné montrant comment les requêtes entrantes ajoutent à l’utilisation tandis que la capacité diminue en fonction du nombre de PTU déployés.

Limites d’appel simultanées

Le nombre d’appels simultanés que vous pouvez effectuer sur un déploiement dépend de la forme de chaque appel (taille d’invite, max_tokens paramètre et facteurs similaires). 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.

Fonctionnalité de débit provisionnée pour les modèles vendus directement par Azure

Cette section répertorie les modèles Foundry qui prennent en charge la fonctionnalité de débit provisionnée. Utilisez votre quota PTU et votre réservation PTU sur les modèles indiqués dans le tableau.

  • La version du modèle n’est pas incluse dans ce tableau. Vérifiez la version prise en charge pour chaque modèle lorsque vous choisissez l’option de déploiement dans le portail Foundry.

  • Les options de déploiement de débit régional approvisionné varient selon la région.

  • Les nouveaux modèles vendus directement par Azure sont intégrés à l’option de déploiement de débit provisionné global en premier. L’option provisionnée de zone de données est disponible ultérieurement.

  • Les unités de type de produit sont gérées régionalement et par type d’offre. Le quota PTU et toutes les réservations doivent se trouver dans la région et la forme (Global, zone de données, régional) que vous souhaitez utiliser.

  • Le basculement est une fonctionnalité facultative qui gère les fluctuations du trafic sur les déploiements provisionnés. Pour plus d’informations sur le basculement, consultez Gérer le trafic avec un basculement pour les déploiements approvisionnés.

Famille de modèles Nom du modèle Approvisionné global Approvisionné dans les zones de données Disponibilité régionale Fonctionnalité de débordement
Azure OpenAI Gpt 5.2 ✅ ✅
Gpt 5.1 ✅ ✅ ✅
Gpt 5.1 codex ✅ ✅ ✅
Gpt 5 ✅ ✅ ✅ ✅
Gpt 5 mini ✅ ✅ ✅ ✅
Gpt 4.1 ✅ ✅ ✅ ✅
Gpt 4.1 mini ✅ ✅ ✅ ✅
Gpt 4.1 nano ✅ ✅ ✅ ✅
Gpt 4o ✅ ✅ ✅ ✅
Gpt 4o mini ✅ ✅ ✅ ✅
Gpt 3.5 Turbo ✅ ✅ ✅ ✅
o1 ✅ ✅ ✅ ✅
o3 ✅ ✅ ✅ ✅
o3 mini ✅ ✅ ✅ ✅
o4 mini ✅ ✅ ✅ ✅
Azure DeepSeek DeepSeek-R1 ✅
DeepSeek-V3-0324 ✅
DeepSeek-R1-0528 ✅

Disponibilité de la région pour la fonctionnalité de débit provisionnée

Disponibilité globale du modèle de débit provisionné

Région gpt-5.2, 2025-12-11 gpt-5.1, 2025-11-13 gpt-5.1-codex, 2025-11-13 gpt-5, 2025-08-07 gpt-5-mini, 2025-08-07 o3, 2025-04-16 o4-mini, 2025-04-16 gpt-4.1, 2025-04-14 gpt-4.1-nano, 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 - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
canadacentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Canada-Est - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centralus - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Allemagne Ouest-Centrale - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
italynorth - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
KoreaCentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norvège-Est - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
PolandCentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southafricanorth - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sud-estasia - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sud de l'Inde - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centre de la suède - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Suisse Nord - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
SuisseOuest - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uaenorth - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Europe de l’Ouest - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 - ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Remarque

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

Contenu connexe

  • Last updated on