Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Affichage actuel :
Version du portail - Passer à la version du nouveau portail Foundry
Note
Les liens de cet article peuvent ouvrir du contenu dans la nouvelle documentation Microsoft Foundry au lieu de la documentation Foundry (classique) que vous affichez maintenant.
Les Modèles Foundry de Microsoft parcourent un cycle de vie prévisible, allant de la phase d’aperçu à la disponibilité générale (GA), puis à l'éventuelle mise hors service, vous donnant ainsi le temps d’évaluer les remplacements et de migrer des charges de travail. Cet article explique chaque étape du cycle de vie, les engagements de transition que Microsoft prend lorsqu'un modèle est retiré, et comment vous êtes averti. Pour connaître des dates de mise hors service spécifiques, consultez la planification de mise hors service du modèle.
Fonctionnement du cycle de vie du modèle
Microsoft Foundry actualise en permanence son catalogue de modèles avec des modèles plus récents et plus compatibles. Lorsqu’un modèle est remplacé, il passe par un cycle de vie prévisible qui donne aux clients le temps d’évaluer les remplacements et de migrer. Le cycle de vie s’applique uniformément aux modèles foundry vendus directement par Azure et des partenaires et de la communauté, bien que les chronologies de notification diffèrent légèrement par l’origine du modèle.
Phases de cycle de vie
Chaque modèle du catalogue Foundry appartient exactement à l’une des cinq étapes suivantes :
| Étape | Ce qu’il signifie | Est-il possible de créer de nouveaux déploiements ? | Les déploiements existants fonctionnent ? |
|---|---|---|---|
| Aperçu | Expérimental. Les pondérations, le runtime et le schéma d’API peuvent changer. Il n'est pas garanti que cela devienne disponible en disponibilité générale. Intitulé « Aperçu » dans le catalogue. | Oui | Oui |
| Disponibilité générale | Prêt pour la production. Les pondérations et les API sont fixes. Les correctifs d’exécution pour les vulnérabilités de sécurité n’affectent pas les sorties. Aucune étiquette affichée (état par défaut). | Oui | Oui |
| Héritage | Des modèles plus récents et plus compatibles existent. Vous devez planifier la migration des charges de travail. Cette étape est facultative : les modèles peuvent passer directement de la disponibilité générale à l'obsolescence. | Oui (jusqu’à la dépréciation) | Oui |
| Déconseillée | Les clients existants peuvent continuer à créer et gérer des déploiements. Plus disponible pour les nouveaux clients : les nouveaux clients ne peuvent pas créer de déploiements ni accéder au modèle. « Client existant » est déterminé au niveau de l’abonnement : indique si cet abonnement Azure a déjà déployé la version spécifique du modèle. Un nouvel abonnement sous le même locataire n’hérite pas de l’accès. | - Clients existants : Oui. - Nouveaux clients : Non |
Oui |
| Retraite | Supprimé du service. Toutes les demandes d’inférence retournent 410 Gone. |
Non | Non |
Note
- Les modèles affinés suivent un calendrier de mise hors service distinct pour la formation et le déploiement. Pour plus d’informations, consultez les modèles affinés .
- Modèles Foundry (catalogue) : Certains fournisseurs de modèles définissent un cycle de vie de disponibilité générale plus court, par exemple, 12 mois au lieu de 18. Lorsqu’un cycle de vie plus court s’applique, il est indiqué directement sur le modèle dans le calendrier de mise hors service du modèle.
Lancement et disponibilité du modèle
Les nouveaux modèles deviennent disponibles via les types de déploiement dans cet ordre :
| Commande | Type de déploiement | Lorsqu’il est disponible |
|---|---|---|
| 1 | Global Standard | Au lancement : disponibilité la plus étendue et latence la plus faible entre les régions |
| 2 | Global Provisioned | Suit étroitement après Global Standard : fournit un débit réservé avec le routage global |
| 3 | Data Zone Standard et Zone de données provisionnée | Après l’approvisionnement global : le traitement des données reste dans une limite géographique définie |
| 4 | Standard et Provisionné | Dernier — uniquement au niveau régional, au fur et à mesure que les modèles plus anciens sont retirés et que la capacité est réattribuée |
Conseil
Pour obtenir une comparaison complète des types de déploiement, consultez comparaison des types de déploiement.
Variations de cycle de vie et de disponibilité
Plusieurs facteurs affectent la façon dont le cycle de vie standard s’applique à vos déploiements, notamment la région dans laquelle vous travaillez, l’environnement cloud que vous utilisez et les exigences de sécurité.
Disponibilité régionale
- Toutes les combinaisons de modèles et de versions ne sont pas disponibles dans toutes les régions.
- En règle générale, des modèles plus spécialisés (par exemple, audio, image et génération vidéo) sont disponibles uniquement en tant que types de déploiement de zone de données ou global.
- Les versions de modèle successives peuvent ne pas être disponibles dans les mêmes régions. Une version plus récente peut apparaître dans certaines régions avant que les mises à niveau ne soient planifiées dans d’autres.
- Microsoft pouvez limiter les nouveaux clients dans des régions spécifiques afin de maintenir la qualité des services pour les clients existants.
Azure Government dans le cloud
- Les déploiements standard globaux ne sont pas disponibles dans les clouds gouvernementaux.
- Tous les modèles ou versions disponibles dans les clouds commerciaux ne sont pas disponibles dans les clouds gouvernementaux.
- Les clouds gouvernementaux prennent généralement en charge une seule version d’un modèle donné à la fois, avec un chevauchement de 30 jours lorsqu’une nouvelle version devient disponible.
Pour plus d’informations, consultez Foundry Models vendus directement par Azure (government), Model versions et Types de déploiement dans Azure Government.
Retraits pilotés par la sécurité
Si un modèle a des problèmes de conformité ou de sécurité, Microsoft se réserve le droit d’appeler une mise hors service d'urgence avec un avis raccourci. Pour plus d’informations, reportez-vous aux Azure conditions d’utilisation.
Engagements de chronologie du cycle de vie
Microsoft prend des engagements spécifiques sur la durée pendant laquelle les versions de modèle restent disponibles et lorsque les remplacements apparaissent, afin de planifier les migrations en toute confiance.
Engagements de chevauchement de modèle de remplacement en disponibilité générale (GA)
Nous nous engageons à effectuer un chevauchement significatif entre un modèle de disponibilité générale mis hors service et son remplacement afin que les clients puissent tester, évaluer et migrer en toute confiance.
| Étape | Modèle |
|---|---|
| Lancement en disponibilité générale | Chaque modèle démarre selon son propre type de déploiement et sa propre matrice de disponibilité de région. La date de mise hors service (18 mois) est définie par programme et disponible via l’API Models. |
| Déconseillé (clients existants uniquement) | À 12 mois de lancement, les clients existants peuvent continuer à créer et gérer des déploiements. Les nouveaux clients ne peuvent pas accéder au modèle. |
| Remplacement disponible selon le standard mondial | Les clients peuvent utiliser et tester le modèle de remplacement selon une norme mondiale pour une période d'environ 90 jours avant la mise hors service du modèle actuel. |
| Remplacement disponible dans les régions approvisionnées | Le modèle de remplacement devient disponible pour les tests dans les régions approvisionnées où le prédécesseur prend sa retraite environ 30 jours avant la mise hors service, ce qui donne aux clients approvisionnés une fenêtre de migration manuelle. |
| Version du modèle supprimée | À 18 mois de lancement, toutes les inférences retournent 410 Gone. |
Conseil
Pourquoi 90 à 120 jours ? Le modèle de remplacement officiel est déterminé environ 90 à 120 jours avant la date de mise hors service du modèle en retraite, pas plus tôt. Compte tenu du rythme rapide d’amélioration de l’IA générative, déclarer un remplacement trop tôt risque de diriger les clients vers un modèle qui n’est plus la meilleure option disponible au moment où ils doivent migrer.
Cycle de vie du modèle en aperçu
Les modèles en prévisualisation ont un cycle de vie fondamentalement différent de celui des modèles en disponibilité générale. Ils sont lancés avec une date de retrait « pas avant » (généralement prévue à 90 jours), mais cela peut parfois être prolongé au-delà de cette période initiale, jusqu'à ce qu'une préversion de remplacement appropriée ou une version de disponibilité générale soit disponible. Lorsqu’une décision de mise hors service est prise, les clients sont forcés de mettre à niveau vers un remplacement (une version préliminaire plus récente ou le modèle GA) ou le modèle est mis hors service sans remplacement. Il n’existe aucune option permettant de rester sur un modèle de préversion en voie de retrait, donc tous les déploiements en préversion sont mis à niveau ou arrêtés.
Note
Les modèles en préversion ne sont pas recommandés pour les charges de travail de production.
| Résultat | Que se passe-t-il ? |
|---|---|
| Mettre à niveau vers une préversion plus récente | Les déploiements en préversion existants sont mis à niveau par force vers une version plus récente. Les clients reçoivent au moins 30 jours d’avis. Le cycle se répète jusqu’à ce qu’une version en disponibilité générale soit disponible. |
| Mise à niveau vers GA | Lorsque le modèle en disponibilité générale démarre, les déploiements en préversion sont mis à niveau forcé vers la version en disponibilité générale. Les clients reçoivent au moins 30 jours d’avis. Le modèle GA suit par la suite le cycle de vie GA standard de 18 mois. |
| Aucun remplacement (rare) | Si aucun remplacement n’existe, les clients reçoivent une notification de 30 jours avant la mise hors service du modèle et l’inférence retourne 410 Gone. |
Mises à niveau automatiques
Pour Global Standard, Data Zone Standard et Standard, Microsoft gère les mises à niveau automatiques lorsqu’une version du modèle est supprimée :
- Les mises à niveau automatiques sont planifiées sur la base d'un déploiement progressif par région.
- La planification de mise à niveau est publiée à l’avance dans la planification de mise hors service du modèle.
- Les mises à niveau peuvent se produire même si la nouvelle version du modèle n’est pas encore disponible séparément dans cette région, ou pour cette référence SKU, le processus de mise à niveau le rend disponible.
Important
Les déploiements provisionnés ne sont PAS mis à niveau automatiquement. Les clients approvisionnés doivent migrer manuellement vers le modèle de remplacement.
Utilisez l'API Models pour vérifier lifecycleStatus, deprecation et par SKU deprecationDate par programmation pour n'importe quel modèle à tout moment.
Exemple : mise à niveau de gpt-4o → gpt-5.1
Lorsque les versions 2024-05-13 gpt-4o et 2024-08-06 ont été mises hors service le 2026-03-31, elles ont été automatiquement mises à niveau vers gpt-5.1 sur la référence SKU Standard. Avant la mise à niveau, gpt-5.1 n’avait pas de présence Standard du tout. Après la mise à niveau, gpt-5.1 Standard a été ajouté à toutes les huit régions qui avaient précédemment ces versions gpt-4o (centralus, eastus, eastus2, northcentralus, southcentralus, swedencentral, westus3). La version 2024-11-20 n’a pas été affectée (mise hors service 2026-10-01).
Migration vers un modèle de remplacement
Lorsqu’un modèle que vous utilisez entre l’étape héritée ou déconseillée, cochez la colonne « Remplacement suggéré » dans la planification de mise hors service du modèle et suivez les étapes de l’utilisation des modèles pour déployer, tester et migrer vers le remplacement.
Notifications
Les modèles GA ont leur date de mise hors service fixée automatiquement au lancement à 18 mois, il n’y a pas d'« annonce » distincte. Les transitions héritées et obsolètes suivent la chronologie publiée et sont visibles en temps réel via l’API Models.
Lorsque vous recevez des notifications actives
| Événement | Synchronisation | S’applique à |
|---|---|---|
| Avis de mise hors service du modèle ga | Au moins 60 jours avant la retraite | Tous les modèles en disponibilité générale. Envoyé aux propriétaires d’abonnements dotés de déploiements actifs. |
| Avis de retrait du modèle en prévisualisation | Au moins 30 jours avant la retraite | Aperçu des modèles. Les déploiements en préversion peuvent être mis à niveau automatiquement vers le remplacement si un modèle de remplacement est disponible et applicable (par exemple, ne nécessite pas de contrat d’API différent). |
Comment vous êtes averti
| Canal | Détails |
|---|---|
| Envoyé automatiquement aux propriétaires d’abonnements avec des déploiements actifs. | |
| Azure Service Health | Les avis de santé s'affichent pour les abonnements affectés. Accédez aux avis d’intégrité du > service, filtrez par Azure OpenAI Service et créez une règle d’alerte pour les notifications par e-mail, SMS ou webhook. |
Méthodes programmatiques pour vérifier le cycle de vie et l'obsolescence du modèle
Les clients peuvent vérifier les champs de cycle de vie et d'obsolescence sur n’importe quel modèle en utilisant l’API Modèles (limité à l'abonnement, tous les modèles d’une région) :
GET https://management.azure.com/subscriptions/{sub}/providers/Microsoft.CognitiveServices/locations/{location}/models?api-version=2024-10-01
Champs clés : lifecycleStatus, deprecation.inference, deprecation.fineTune, par référence SKU deprecationDate (dates ISO).
Important
L’API utilise une terminologie différente de la documentation et du portail. Le tableau ci-dessous mappe les noms d’étape côté client utilisés dans ce document et le portail Foundry aux valeurs de champ d’API correspondantes.
| Étape (docs et portail) | Champ d’état de l’API (lifecycleStatus) |
Champ de date de l’API (deprecation.inference) |
Ce qu’il signifie |
|---|---|---|---|
| Aperçu | Preview |
Date future ou non définie | Expérimental. Peut changer ou être supprimé. |
| Disponibilité générale | GenerallyAvailable |
Date future (définie au lancement) | Prêt pour la production. Pondérations fixes et API. |
| Déconseillée | Deprecating |
Date future | Continue de servir à l'inférence. Bloqué pour les nouveaux clients. |
| Retraite | Deprecated |
Date passée | Entièrement mis hors service. L’inférence retourne 410 Gone. |
Par exemple, un modèle que la documentation répertorie comme « Déconseillé » (fonctionne toujours, bloqué pour les nouveaux clients) apparaît dans l'API comme lifecycleStatus: "Deprecating"—pas comme "Deprecated". La valeur "Deprecated" de l’API signifie que le modèle est mis hors service et ne sert plus l’inférence.
Pour déterminer l’étape d’un modèle par programmation, vérifiez les deux champs ensemble :
if lifecycleStatus == "Deprecated" → Retired (410 Gone)
if lifecycleStatus == "Deprecating" → Deprecated (existing customers only)
if deprecation.inference < today → Retired (regardless of lifecycleStatus lag)
if lifecycleStatus == "GenerallyAvailable" → GA
if lifecycleStatus == "Preview" → Preview
Modèles affinés
Les modèles affinés sont retirés en deux phases : entraînement et déploiement.
Sauf indication explicite, la formation prend sa retraite avant la date de mise hors service du modèle de base. Une fois qu’un modèle est mis hors service pour l’entraînement, il n’est plus disponible pour le réglage précis, mais tous les modèles précédemment formés restent disponibles pour le déploiement.
Lors du retrait du déploiement, l’inférence et le déploiement génèrent des réponses d’erreur.
| Modèle | Version | Date de mise hors service de formation | Date de retrait du déploiement |
|---|---|---|---|
| gpt-4o | 2024-08-06 | Pas plus tôt que 2027-04-011 | 01/10/2027 |
| gpt-4o-mini | 18/07/2024 | Pas plus tôt que 2027-04-011 | 01/10/2027 |
| gpt-4.1 | 2025-04-14 | Pas plus tôt que 2027-04-141 | 14/10/2027 |
| gpt-4.1-mini | 2025-04-14 | Pas plus tôt que 2027-04-141 | 14/10/2027 |
| gpt-4.1-nano | 2025-04-14 | Pas plus tôt que 2027-04-141 | 14/10/2027 |
| o4-mini | 2025-04-16 | Mise hors service du modèle de base | Un an après la retraite de la formation |
1 Pour les clients existants uniquement. Sinon, la mise hors service de la formation se produit lors de la mise hors service du modèle de base.
Questions fréquemment posées
| Question | Réponse | Pour en savoir plus |
|---|---|---|
| Quelle est la différence entre une famille de modèles, une version et une variante ? | Une famille de modèles est une génération de modèles (par exemple, GPT-4o, GPT-5). Une version de modèle est une version datée dans une famille (par exemple, gpt-4o 2024-05-13 vs. 2024-08-06). Une variante de modèle est un niveau taille/capacité au sein de la même famille (par exemple, GPT-5, GPT-5-mini, GPT-5-nano). | Versions de modèle |
| Puis-je contrôler le moment auquel mes déploiements Standard se mettent à jour automatiquement ? | Oui. Définissez la versionUpgradeOption propriété sur votre déploiement sur l’une des trois valeurs suivantes : OnceNewDefaultVersionAvailable (mise à niveau lorsqu’une nouvelle valeur par défaut est définie), OnceCurrentVersionExpired (mise à niveau uniquement à la mise hors service) ou NoAutoUpgrade (jamais mise à niveau automatique : le déploiement cesse de fonctionner à la mise hors service). Vous pouvez configurer ce paramètre via l’API REST, Azure PowerShell ou le portail Foundry. |
Utilisation de modèles : configuration de mise à niveau |
| Comment migrer un déploiement provisionné ? | Les déploiements provisionnés ne sont pas mis à niveau automatiquement. Vous avez deux options : Migration sur place (Azure gère la migration du trafic sur une fenêtre de 20 à 30 minutes sans temps d’arrêt) ou Migration côte à côte (multidéploiement) (vous créez un déploiement, testez, basculez le trafic et supprimez l’ancien). | Gestion des modèles sur les types de déploiement provisionnés |
| Mon quota sera-t-il reporté sur le modèle de remplacement ? | Pour les mises à niveau automatiques standard, oui : le quota est géré automatiquement. Pour les déploiements provisionnés, vous devez vous assurer que le quota est disponible pour le modèle cible avant la migration. La capacité PTU est indépendante de tout modèle et est interchangeable dans les déploiements gérés approuvés. | Débit provisionné : quota |
| Puis-je obtenir une exception pour étendre la date de mise hors service d’un modèle ? | Non. Les dates de mise hors service ne sont pas extensibles. Planifiez votre migration à l’aide des chronologies publiées dans la planification de mise hors service du modèle et l’API Modèles. | N/A |
| Quels outils peuvent m’aider à évaluer un modèle de remplacement ? | Utilisez le classement du modèle dans le portail Foundry pour comparer les benchmarks, la fonctionnalité de comparaison des modèles lors du déploiement et des évaluations pour les tests de charge de travail personnalisés. Appliquez l’ingénierie d’invite et le réglage précis si nécessaire pour correspondre à la précision préalable. | Préparation des retraits de modèles |
| Les modèles incorporés suivent-ils le même cycle de vie ? | Les modèles d’incorporation (text-embedding-3-large, text-embedding-3-small, text-embedding-ada-002) ont des chronologies étendues et sont gérés différemment des modèles d’inférence. Vérifiez la planification de mise hors service du modèle pour connaître des dates spécifiques. | Mises hors service de modèles — embeddings |
| Comment procéder à la mise à niveau des déploiements de traitement de priorité et de traitement par lots ? | Le traitement prioritaire suit le même processus de mise à niveau que les déploiements Standard (mise à niveau automatique prise en charge). Les déploiements batch suivent l'approche de migration en parallèle (multi-déploiement) : déployez le nouveau modèle, soumettez à nouveau des tâches, puis retirez l'ancien déploiement. | Utilisation de modèles |
| Je ne trouve pas "Microsoft Foundry" dans Azure Service Health—comment configurer des alertes ? | Sélectionnez Azure OpenAI Service comme nom de service lors de la configuration des alertes Service Health. Il n'existe aucun service « Microsoft Foundry » distinct dans Service Health. |
Configurer des alertes d’intégrité du service |
Contenu connexe
- Planification de mise hors service du modèle pour des dates spécifiques pour tous les modèles actuels, déconseillés et supprimés
-
Référence de l’API modèles pour interroger par programmation
lifecycleStatus,deprecation, et par SKUdeprecationDatepour n'importe quel modèle - Versions du modèle dans Microsoft Foundry Models pour savoir comment fonctionnent les mises à niveau des versions
- Prise en main de l’évaluation du modèle
- Gestion des modèles sur les types de déploiement provisionnés
- Configurer des alertes d’intégrité du service