Calcul managé dans Microsoft Foundry (préversion)

Note

Le calcul managé dans Foundry est actuellement en préversion publique et l’inscription est nécessaire pour l’utiliser. Cette version préliminaire est fournie sans contrat de niveau de service, et nous la déconseillons pour les charges de travail en production. Certaines fonctionnalités peuvent ne pas être prises en charge ou avoir des fonctionnalités contraintes. Pour plus d’informations, consultez Conditions d'utilisation supplémentaires pour les versions préliminaires de Microsoft Azure.

Le calcul managé (préversion) est un type de déploiement dans Microsoft Foundry qui héberge des modèles open source sur une capacité GPU dédiée sans avoir à provisionner des machines virtuelles, à exploiter un cluster Kubernetes, à créer des images conteneur ou à posséder un runtime de service de modèle. Microsoft possède la topologie GPU, le runtime, l’image conteneur et la mise à jour corrective de sécurité. Vous choisissez le modèle, le modèle de déploiement, la famille d’accélérateurs et le comportement de mise à l’échelle qui correspondent à votre charge de travail.

Le calcul managé utilise la même ressource Foundry, projet, point de terminaison, authentification, configuration réseau, sdk, observabilité et surface de facturation que tout autre type de déploiement dans Foundry. Une fois que vous avez déployé un modèle avec un calcul managé, votre code d’application est identique à tout autre modèle Foundry ; seul le nom du déploiement change.

Cet article explique le type de déploiement de calcul managé dans Foundry, les concepts que vous utilisez (instances de modèle, modèles de déploiement, familles d’accélérateurs, runtimes), le catalogue à partir duquel vous pouvez déployer à partir des points de terminaison d’inférence, la mise à l’échelle, la facturation et le quota, le contrôle d’accès et les limitations actuelles. Pour obtenir des instructions de déploiement pas à pas, consultez Déployer des modèles open source avec un calcul managé.

Où le calcul managé s’adapte à Foundry

Foundry propose trois types de déploiement. Le calcul managé est le type de déploiement à utiliser pour les modèles open source sur la capacité GPU dédiée.

Type de déploiement Ce qu’il sert Billing Idéal pour
Paiement par jeton standard Modèles Foundry vendus par Azure Par jeton d’entrée et de sortie Chemin de friction le plus bas pour commencer ; trafic en rafale sur des modèles hébergés sans planification de capacité.
Capacité de traitement provisionnée Modèles Foundry vendus par Azure Unités de débit réservées Charge prévisible et soutenue sur les modèles Foundry sélectionnés vendus par Azure avec une latence cohérente.
Calcul managé Modèles de communauté et open source à partir du catalogue Foundry Par heure, par famille d’accélérateurs Hébergement de modèles open source sur des GPU dédiés avec des runtimes gérés par Foundry, une mise en réseau privée et les mêmes Kits de développement logiciel (SDK) que les autres types de déploiement.

Les trois types de déploiement partagent un point de terminaison Foundry unique, les mêmes modèles d’authentification (Microsoft Entra ID et clé), les mêmes KITS SDK, la même surface d’observabilité et une seule facture. Vous pouvez combiner les trois types de déploiement dans un projet Foundry unique et les appeler à partir du même code client.

Concepts clés

Cette section décrit les concepts clés à comprendre avant d’utiliser le déploiement de calcul managé dans Foundry.

Instance de modèle

Une instance de modèle est l’unité de déploiement dans le calcul managé. Vous ne choisissez pas de référence SKU de machine virtuelle ou de taille d’un nœud ; Au lieu de cela, vous décrivez la charge de travail en termes de modèle, et Foundry choisit la topologie GPU en dessous. Une instance peut utiliser un accélérateur ou plusieurs, selon le modèle et le modèle de déploiement que vous choisissez. Vous redimensionnez un déploiement en modifiant le nombre d’instances du modèle (la valeur capacity dans le SKU de déploiement).

Modèle de déploiement

Un modèle de déploiement est une ressource nommée avec version qui encode la façon dont un modèle spécifique doit s’exécuter. Épingles de modèle :

  • Runtime de service (par exemple, vLLM ou SGLang).
  • La famille d’accélérateurs et le nombre par instance (par exemple, un H100 80 Go ou deux A100 80 Go).
  • Longueur du contexte prise en charge et choix de quantisation.
  • Paramétrage spécifique à l’environnement d’exécution, tel que les analyseurs des appels d’outils et du raisonnement, la chaîne de notation, les sondes de santé, la concurrence des requêtes et tous les paramètres d’extension du contexte propres au modèle.

Lorsque vous scriptez un déploiement, vous référencez l’ID de modèle et Foundry gère le reste. Chaque modèle du catalogue est généralement livré avec plusieurs gabarits qui impliquent des arbitrages entre le type d’accélérateurs, la longueur du contexte, ainsi que la latence et le débit. Par exemple, le qwen3-32b modèle expose quatre modèles côte à côte :

Template Runtime Accélérateur Contexte
qwen--qwen3-32b--40k-nvidia-a100 vLLM 1 × A100 80 Go 40 K
qwen--qwen3-32b--40k-nvidia-h100 vLLM 1 × H100 80 Go 40 K
qwen--qwen3-32b--128k-nvidia-2xa100 vLLM 2 × A100 80 Go 128 K
qwen--qwen3-32b--128k-nvidia-2xh100 vLLM 2 × H100 80 Go 128 K

Choisir un modèle est le seul paramètre que vous ajustez pour déterminer comment un modèle s’exécute.

Familles d’accélérateurs

Les déploiements de calcul managés ciblent une famille d’accélérateurs, et non une référence SKU de machine virtuelle spécifique. Les familles prises en charge sont les suivantes :

  • NVIDIA A100 80 Go (A100_80GB)
  • NVIDIA H100 80 Go (H100_80GB)
  • AMD MI300X 192 Go (MI_300_192GB)

Le quota est accordé par famille d’accélérateurs par région.

Runtimes de modèle

Le calcul géré exécute chaque modèle dans un environnement d’exécution de service que Microsoft crée, analyse, signe et met à jour. Vous n’exploitez pas et ne reconstruisez pas de conteneurs. Le portefeuille d’exécution est sélectionné par architecture de modèle :

Runtime Utiliser pour Remarques
vLLM Service LLM à débit élevé Traitement par lots continu, PagedAttention, parallélisme tensoriel, permutation à chaud LoRA. Valeur par défaut pour la plupart des modèles de langage volumineux.
SGLang Déploiement de LLM à sortie structurée Génération de JSON, par expressions régulières et sous contrainte grammaticale pour les charges de travail agentiques et utilisant des outils.
TensorRT-LLM Service LLM optimisé pour NVIDIA Inférence NVIDIA à faible latence pour les familles de modèles où TRT-LLM gagne sur la latence ou le débit.
NVIDIA NIM Microservices d’inférence NVIDIA TensorRT-LLM back-end avec compatibilité des API NIM pour les modèles publiés par NVIDIA.
Inférence d’intégration de texte (TEI) Intégrations, réordonnanceurs, classifieurs Noyaux spécifiques à l’accélérateur pour l’incorporation et la récupération des chemins chauds.
llama.cpp Utilisation du processeur et du petit GPU Modèles quantifiés par GGUF derrière la même API compatible OpenAI.
hf-serve Vision, audio, segmentation, autres pipelines natifs de Transformers Le serveur multimodèle de Hugging Face pour les modalités hors des voies rapides LLM et d’embeddings.

Les mises à niveau du runtime et les correctifs CVE sont appliqués automatiquement aux déploiements des clients en direct. Vous ne redéployez pas votre modèle pour récupérer une mise à jour du runtime.

Modèles pris en charge

Vous pouvez utiliser le calcul géré dans Foundry pour déployer des modèles à partir de la collection Hugging Face dans le catalogue de modèles Foundry, servis depuis le registre azure-huggingface. Ces modèles ont les attributs suivants :

  • Organisé et actualisé toutes les semaines. Les modèles tendances de l’écosystème Hugging Face sont ajoutés en continu à mesure que la communauté les publie. Le catalogue couvre le texte, la vision, l’audio et les modèles modals (LLMs et modèles de langage de vision pour les conversations et les agents), la reconnaissance vocale automatique (ASR), la traduction vocale, les incorporations, la segmentation et la génération d’images.
  • SafeTensors uniquement, aucun code non approuvé. Chaque modèle de la collection est filtré. Les dépôts qui nécessitent l’exécution de Python tiers au moment du chargement (modèles trust_remote_code) sont corrigés ou exclus.
  • Poids préchargés. Les poids du modèle sont récupérés depuis Hugging Face une seule fois, validés, puis stockés dans le stockage Azure géré par Microsoft, dans les régions où le modèle est déployé. Les images de conteneur se trouvent dans un registre géré par Microsoft. Par conséquent, les déploiements de calcul managés n’ont pas besoin d’un accès réseau sortant à Hugging Face Hub . Vous pouvez le déployer dans un réseau entièrement privé sans sortie.
  • Métadonnées de licence conservées. Chaque carte de modèle de catalogue capture et expose la licence en amont. La révision de licence par rapport à la stratégie de distribution d'entreprise de Microsoft se produit lors de la curation.

Chaîne de sélection des modèles

Chaque modèle de la collection Hugging Face passe par un pipeline de curation à cinq étapes avant d’apparaître dans le catalogue :

  1. Identifier les modèles tendance : Microsoft identifie les modèles tendance en fonction des signaux de la communauté, des demandes des partenaires et de la demande des clients.
  2. Écran de conformité et de sécurité : chaque modèle subit une révision de licence et une inspection pour trust_remote_code les modèles et le code exécutable personnalisé.
  3. Créez, analysez et publiez des images de conteneur d’exécution : créées par Microsoft, analysées à la recherche de CVE, signées et publiées sur un registre géré par Microsoft.
  4. Pondérations de chargement pour sécuriser le stockage Azure : validé par rapport à la carte de modèle et stocké dans les régions où le modèle est servi.
  5. Valider et publier : chaque combinaison de modèles, d’exécution et d’accélérateurs est testée pour la conformité et les performances de l’API, puis publiée dans le catalogue avec un chemin de déploiement en un clic.

Points de terminaison d’inférence

Le déploiement d’un modèle sur une capacité de calcul managée rend le modèle disponible pour l’inférence via le même point de terminaison unifié du projet Foundry que celui utilisé par les déploiements avec facturation au jeton et avec débit approvisionné. Le point de terminaison de base a le modèle https://<account>.services.ai.azure.com.

Itinéraires de point de terminaison

Un déploiement de calcul managé peut être appelé sur deux familles de routes sur le point de terminaison unifié. L’itinéraire que vous choisissez varie selon que le modèle sous-jacent et le runtime exposent une API compatible OpenAI.

Itinéraire Chemin S’applique à Comportement
Itinéraire des déploiements managés (OSS) <endpoint>/managed-deployments/<deployment-name>/ Tous les déploiements de calcul managés Fonctionne pour chaque modèle déployé sur le calcul managé, y compris les modèles sur mesure fournis avec leur propre SDK. Les modèles qui exposent /chat/completions peuvent également être appelés sur cette route avec le Kit de développement logiciel (SDK) OpenAI en pointant le client base_url sur ce chemin d’accès.
Route compatible avec OpenAI <endpoint>/openai/v1/ Déploiements de calcul managés dont le runtime expose une API compatible OpenAI (par exemple, vLLM, SGLang, TensorRT-LLM, llama.cpp service de conversation ou d’incorporations) Le Kit de développement logiciel (SDK) OpenAI peut appeler le déploiement en définissant base_url ce chemin d’accès et en transmettant le nom du déploiement dans le model champ de la charge utile de la requête. Si une requête cible cet itinéraire avec un nom de déploiement dont le modèle ou le runtime sous-jacent ne prend pas en charge la surface compatible OpenAI, le runtime retourne HTTP 404.

Points clés à retenir :

  • Chaque déploiement de calcul managé est accessible sur l’itinéraire https://<account>.services.ai.azure.com/managed-deployments/<deployment-name>/
  • Tout déploiement dont le runtime est compatible avec OpenAI est également accessible sur l’itinéraire https://<account>.services.ai.azure.com/openai/v1/ .
  • Utilisez l’itinéraire OpenAI lorsque vous souhaitez partager du code client avec d’autres déploiements Foundry.
  • Utilisez l’itinéraire des déploiements managés pour les modèles qui expédient un SDK personnalisé ou une API non OpenAI.

Tip

Un déploiement de calcul managé pour les complétions de conversation peut également être ajouté à un agent Foundry en tant que modèle connecté par un administrateur et appelé via l’API Foundry Responses avec le même SDK OpenAI, en utilisant la même authentification, le même point de terminaison et la même observabilité que pour tout autre modèle Foundry.

Authentification du point de terminaison

Les déploiements de calcul managés utilisent les mêmes modèles d’authentification que le reste du point de terminaison Foundry :

  • Microsoft Entra ID (recommandé). Obtenez un jeton pour la portée https://ai.azure.com/.default et envoyez-le comme jeton Bearer dans l’en-tête Authorization. Pour appeler un déploiement de calcul managé avec Entra ID, l’identité appelante a besoin du rôle Foundry User sur l’étendue du compte Foundry. Le Kit de développement logiciel (SDK) OpenAI en mode basé sur les jetons et DefaultAzureCredential fonctionne sans configuration spécifique au calcul managé.
  • Clé API de compte. Transmettez la clé de compte Foundry comme Authorization: Bearer <key>. Le Kit de développement logiciel (SDK) OpenAI envoie automatiquement la clé dans ce formulaire lorsque vous définissez l’argument api_key . Les clés accordent le même accès sur les déploiements de calcul managés que sur les déploiements de paiement par jeton et de PTU sur le même compte.

Les deux options d’authentification fonctionnent sur les deux itinéraires de point de terminaison. Pour consulter des exemples de code client de bout en bout (SDK OpenAI avec Entra ID ou une clé API), voir Envoyer une requête de test.

Scaling

Vous mettez à l’échelle un déploiement de calcul managé en modifiant le nombre d’instances de modèle. Lorsque vous définissez la capacity valeur sur la référence SKU de déploiement, Foundry ajuste le nombre de GPU en conséquence. Nombre total de GPU égales au nombre d’instances de modèle multipliées par les GPU par instance définies par le modèle de déploiement que vous avez choisi. Foundry ne vous demande pas de dimensionner un nœud ou de choisir une famille de machines virtuelles.

Étendues de facturation, de quota et de déploiement

Le calcul managé est facturé toutes les heures par accélérateur. Contrairement à une infrastructure basée sur des machines virtuelles, où vous louez des serveurs GPU entiers et payez pour chaque GPU du serveur, que votre modèle l’utilise ou non, le calcul managé est facturé par instance de modèle. Foundry taille correctement chaque modèle au nombre de GPU dont il a réellement besoin (un, deux, quatre ou huit) afin de ne pas payer pour les accélérateurs inactifs assis à côté de votre charge de travail. Le coût d’un déploiement est le suivant :

Accélérateurs par instance de modèle × instances de modèle × heures d’exécution × taux horaire

Les taux horaires varient selon la famille d’accélérateurs (A100, H100, MI300X) et par étendue de déploiement. Pour connaître la tarification actuelle, consultez la calculatrice de prix Azure.

Étendue du déploiement

Le calcul géré (préversion) prend actuellement en charge le déploiement Global, défini par le nom de SKU de déploiement GlobalManagedCompute. Le déploiement global vous offre la capacité d’accélérateur la plus large au taux le plus bas.

Quota

Le quota de calcul managé est accordé par famille d’accélérateurs par région via le processus de quota Foundry. Le quota de calcul géré est distinct du quota des machines virtuelles Azure. Bien que le quota de machines virtuelles Azure soit une allocation d’infrastructure en tant que service liée à des références SKU de VM propres à une région donnée, la capacité de calcul managée est une offre PaaS managée. Le quota de machines virtuelles Azure existant ne peut pas être appliqué à un déploiement de calcul managé.

Pour plus d’informations sur l’affichage de l’utilisation, l’attribution de coûts à un projet et la demande de quota, consultez Plan et gérer les coûts pour Microsoft Foundry et Manage et augmenter les quotas.

Contrôle d’accès

Le calcul managé utilise le modèle de contrôle d’accès en fonction du rôle (RBAC) de Foundry. L’ensemble des opérations du fournisseur de ressources Azure requises pour créer, lire, mettre à jour et supprimer un déploiement de calcul managé est documenté dans Contrôle d’accès en fonction des rôles pour Microsoft Foundry — opérations du plan de contrôle du calcul managé, ainsi que les rôles intégrés qui accordent chacune de ces opérations.

En un coup d’œil :

  • Contributeur Cognitive Services (ou Propriétaire Foundry / Propriétaire du compte Foundry) accorde tous les droits de création, lecture, mise à jour et suppression sur les déploiements de calcul gérés.
  • Cognitive Services User et Foundry User accordent un accès en lecture seule aux déploiements.
  • Foundry Project Manager accorde un accès en lecture aux déploiements et aux données d’utilisation de l’accélérateur, mais pas les autorisations de création ou de suppression.

L’inférence (plan de données) sur le point de terminaison Foundry unifié suit le modèle Foundry standard en affectant Foundry User sur l’étendue du compte Foundry pour appeler des déploiements avec Microsoft Entra ID.

Limitations

Le calcul managé est en préversion publique. Notez les points suivants avant de déployer des charges de travail de production :

  • Filtrage de contenu : les filtres intégrés Azure AI Sécurité du Contenu ne font pas partie du chemin de données de calcul managé dans la préversion publique. Si vous avez besoin d’un filtrage au niveau de la demande ou d’une réponse, appelez les API Azure AI Sécurité du Contenu directement à partir de votre application.
  • Disponibilité régionale : le calcul géré est lancé avec une portée mondiale. Les déploiements de zones de données et d’autres régions sont en cours de déploiement : consultez la matrice de disponibilité générale pour la couverture actuelle.
  • Tarification : les tarifs horaires par famille d’accélérateurs et par région, la capacité réservée et les remises liées aux engagements sont en cours d’évolution pour le déploiement de calcul géré en préversion. Pour connaître les tarifs actuels, consultez la calculatrice de prix Azure.

Contenu connexe

  • Last updated on