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

L’offre de débit provisionné Microsoft Foundry 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. 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 approvisionné que vous avez demandé dans un portefeuille diversifié de models vendus directement par Azure. Ces modèles incluent les modèles Azure OpenAI et les familles de modèles phares récemment introduites comme Azure DeepSeek dans les modèles Foundry, avec l'intégration de nouvelles familles de modèles au fil du temps.

Le débit approvisionné fournit :

Avantage Description
Choix plus large du modèle Accès aux derniers modèles phares
Flexibilité Changer de modèles et de déploiements avec un quota de débit provisionné 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

Conditions préalables

  • Un abonnement Azure. Créez-en un gratuitement.
  • Un projet Microsoft Foundry avec un modèle déployé à l’aide d’un type de déploiement de capacité de traitement approvisionnée.
  • 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 d’approvisionner des déploiements de débit lorsque vous avez des exigences de débit et de latence bien définies, prévisibles, généralement 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é (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 traiter les requêtes et générer des complétions. Les unités de débit approvisionnées sont allouées à un abonnement comme quota et utilisées pour 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 Azure modèles 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 restantes pour DeepSeek-R1, les 200 PTU partagent automatiquement la remise de réservation et votre usage total 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 l'économie des coûts avec les réservations PTU, consultez Économiser sur les coûts avec les réservations de débit alloué de Microsoft 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 l'interface CLI ou l'API, sku-name peut être défini sur GlobalProvisionedManaged, DataZoneProvisionedManaged ou ProvisionedManaged en fonction du besoin de traitement des données de la charge de travail concernée.

Type de déploiement sku-name dans l’interface CLI
Débit provisionné global GlobalProvisionedManaged
Débit provisionné de zone de données DonnéesZoneApprovisionnéeGérée
Débit provisionné régional ProvisionedManaged

Pour adapter l’exemple de commande Azure CLI suivant à un autre type de déploiement, mettez à jour le paramètre sku-name 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 toutes les régions et modèles à la demande, mais la vente d’une région est toujours une possibilité. 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és dans un abonnement et une région, mais il ne garantit pas la disponibilité de la capacité. La capacité est allouée au moment du déploiement.

Manière générale:

  • Le quota ne garantit pas la capacité. Le quota définit une limite sur le nombre maximal de PTUs pouvant être déployées 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 l'échelle ou supprimer un déploiement libère de la capacité vers 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.

Conseils 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 à la fois votre quota et votre 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 nombre moindre 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 des capacités de modèle et l’expérience Foundry prennent en compte la disponibilité des quotas lors de la proposition 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é.

Surveiller la capacité

La métrique Provisioned-Managed Utilisation V2 dans Azure Monitor mesure l'utilisation d'un déploiement donné par incréments d'une minute. Tous les types de déploiement provisionné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).

Performances d’utilisation

Les déploiements provisionnés vous fournissent une quantité allouée de capacité de traitement de modèle pour exécuter 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 de retourner le code d’état HTTP 429 jusqu’à ce que l’utilisation tombe 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é. En fournissant une réponse à échec rapide, vous avez le contrôle sur la façon de gérer ces situations d’une manière qui répond le mieux aux besoins de votre application.

Les en-têtes retry-after-ms et retry-after dans la réponse vous indiquent le temps d'attente avant que l'appel suivant soit accepté. La façon dont vous choisissez de gérer cette réponse dépend des exigences de votre application. Voici quelques considérations :

  • Envisagez de rediriger le trafic vers d’autres modèles, déploiements ou expériences. Cette option est la solution à latence la plus faible, car l’action peut être effectuée 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 community post.
  • 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 donne 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 sa taille d’invite, de sa taille de génération attendue et du modèle pour déterminer son utilisation attendue. 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 provisionnés, nous utilisons une variante de l'algorithme du seau percé pour garder l'utilisation en dessous de 100%, tout en permettant une certaine variabilité du 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 demande est effectuée :

    Un. 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 l'augmentation incrémentielle de l'utilisation requise pour traiter la requête en combinant les jetons d'invite, en soustrayant les jetons mis en cache, ainsi que le paramètre spécifié max_tokens dans l'appel. Un client peut recevoir jusqu’à 100% remise sur ses jetons d’invite en fonction de 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 plus faible que prévu lorsque le nombre de jetons générés réels est petit. Pour maximiser la concurrence, vérifiez que la valeur max_tokens est aussi proche que possible de la taille réelle de génération.

  3. Une fois une demande terminée, nous connaissons maintenant 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 :

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

    B. Si la valeur 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.

Note

Les appels sont acceptés jusqu’à ce que l’utilisation atteigne 100%. Les rafales juste au-dessus de 100% peuvent être autorisées pendant de courtes périodes, mais au fil du temps, votre trafic est limité à une utilisation de 100%.

Diagramme de l’algorithme du compartiment percé pour l’utilisation du débit alloué, montrant comment les requêtes entrantes augmentent 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 les appels jusqu’à ce que l’utilisation atteigne 100%. Pour déterminer le nombre approximatif d’appels simultanés, vous pouvez modéliser les requêtes maximales par minute pour une forme d’appel particulière dans la calculatrice de capacité. Si le système génère moins que le nombre de jetons de sortie définis pour le max_tokens paramètre, le déploiement approvisionné accepte plus de demandes.

Capacité 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 provisionné 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 approvisionné global en premier. L’option provisionnée de zone de données est disponible ultérieurement.

  • Les PTUs sont gérés par région et par type d’offre. Le quota PTU et toutes les réservations doivent être situés dans la région et la catégorie (Global, Data zone, Regional) que vous souhaitez utiliser.

  • La capacité de débordement est une option facultative qui gère les fluctuations du trafic sur les déploiements provisionnés. Pour plus d’informations sur le débordement, consultez Gérer le trafic avec un débordement pour les déploiements provisionnés.

Famille de modèles Nom du modèle Global provisionné Zone de données provisionnée Provisionné régional Fonctionnalité de débordement
Azure OpenAI Gpt 5.5 ✅ ✅ ✅ ✅
Gpt 5.4 ✅ ✅ ✅ ✅
Gpt 5.3 codex ✅ ✅
Gpt 5.2 ✅ ✅ ✅ ✅
Gpt 5.2 codex ✅ ✅
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 ✅
Meta Llama Llama-3.3-70B-Instruct ✅

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.5, 2026-04-24 gpt-5.4, 2026-03-05 gpt-5.3-codex, 2026-02-24 gpt-5.2-codex, 2026-01-14 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-mini, 2025-04-14 gpt-4.1-nano, 2025-04-14 o3-mini, 2025-01-31 o1, 2024-12-17 gpt-4o, 2024-11-20 gpt-4o, 2024-08-06 gpt-4o, 2024-05-13 gpt-4o-mini, 2024-07-18
australiaeast - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
brésilsud - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
canadacentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
canadaeast - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centralus - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
allemagnewestcentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
italynorth - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norvège-Est - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
polognecentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
south africanorth - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sud-estasia - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
sud de l'Inde - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
swedencentral - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
suisse-nord - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Suisse Ouest - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uaenorth - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westeurope - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Note

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

Contenu connexe

  • Last updated on