Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Visualizzazione attuale:Versione del portale Foundry (versione classica) - Passa alla versione per il nuovo portale Foundry
Nota
I collegamenti in questo articolo potrebbero aprire contenuto nella nuova documentazione di Microsoft Foundry anziché nella documentazione di Foundry (versione classica) visualizzata.
Microsoft i modelli Foundry passano attraverso un ciclo di vita prevedibile, dall'anteprima alla disponibilità generale (GA) al ritiro finale, offrendo il tempo necessario per valutare le sostituzioni ed eseguire la migrazione dei carichi di lavoro. Questo articolo illustra ogni fase del ciclo di vita, gli impegni di sovrapposizione Microsoft quando un modello viene ritirato e come si riceve una notifica. Per date di ritiro specifiche, vedere Pianificazione del ritiro del modello.
Funzionamento del ciclo di vita del modello
Microsoft Foundry aggiorna continuamente il catalogo dei modelli con modelli più recenti e più compatibili. Quando un modello viene sostituito, passa attraverso un ciclo di vita prevedibile che consente ai clienti di valutare le sostituzioni ed eseguire la migrazione. Il ciclo di vita si applica in modo uniforme ai modelli Foundry venduti direttamente da Azure e da partner e comunità, sebbene i tempi di notifica differiscano leggermente in base all'origine del modello.
Fasi del ciclo di vita
Ogni modello nel catalogo Foundry appartiene esattamente a una di queste cinque fasi:
| Fase | Cosa significa | È possibile creare nuove distribuzioni? | Le implementazioni esistenti funzionano? |
|---|---|---|---|
| Anteprima | Sperimentale. I pesi, il runtime e lo schema dell'API possono cambiare. Non è garantito che diventi Disponibilità Generale. Etichettato "Anteprima" nel catalogo. | Sì | Sì |
| Disponibile a livello generale | Pronto per la produzione. I pesi e le API sono fissi. Le patch di runtime per le vulnerabilità di sicurezza non influiscono sugli output. Nessuna etichetta visualizzata (stato predefinito). | Sì | Sì |
| Legacy | Esistono modelli più recenti e più compatibili. È consigliabile pianificare la migrazione dei carichi di lavoro. Questa fase è facoltativa: i modelli potrebbero passare direttamente dalla disponibilità generale alla versione deprecata. | Sì (fino alla deprecazione) | Sì |
| Deprecato | I clienti esistenti possono continuare a creare e gestire le distribuzioni. Non più disponibile per i nuovi clienti: i nuovi clienti non possono creare distribuzioni o accedere al modello. Il "cliente esistente" viene determinato a livello di sottoscrizione: se tale sottoscrizione Azure abbia mai distribuito la versione specifica del modello. Una nuova sottoscrizione nello stesso tenant non eredita l'accesso. | - Clienti esistenti: Sì. - Nuovi clienti: No |
Sì |
| Pensionati | Rimosso dal servizio. Tutte le richieste di inferenza restituiscono 410 Gone. |
No | No |
Nota
- I modelli ottimizzati seguono una pianificazione separata per il ritiro per il training e la distribuzione. Per informazioni dettagliate, vedere Modelli ottimizzati finemente.
- Foundry Models (catalogo): alcuni provider di modelli definiscono un ciclo di vita GA più breve, ad esempio 12 mesi anziché 18. Quando si applica un ciclo di vita più breve, viene indicato direttamente nel modello nella pianificazione del ritiro del modello.
Avvio e disponibilità del modello
I nuovi modelli diventano disponibili tramite i tipi di distribuzione in questo ordine:
| Ordine | Tipo di distribuzione | Quando disponibile |
|---|---|---|
| 1 | Standard globale | All'avvio: disponibilità più ampia e latenza più bassa tra aree |
| 2 | Configurazione Globale | Segue direttamente lo standard globale, offre una capacità riservata con routing globale |
| 3 | Zona Dati Standard e Zona Dati Provisionata | Dopo il "Global Provisioned", l'elaborazione dei dati rimane entro un confine geografico definito |
| 4 | Standard e Provisionato | Ultima: solo a livello regionale, poiché i modelli meno recenti vengono ritirati e la capacità viene riallocata |
Suggerimento
Per un confronto completo dei tipi di distribuzione, vedere Confronto tra tipi di distribuzione.
Variazioni del ciclo di vita e della disponibilità
Diversi fattori influiscono sul modo in cui il ciclo di vita standard si applica alle distribuzioni, tra cui l'area in cui si opera, l'ambiente cloud usato e i requisiti di sicurezza.
Disponibilità regionale
- Non tutte le combinazioni di modelli e versioni sono disponibili in tutte le aree.
- In genere, i modelli più specializzati, ad esempio la generazione di audio, immagini e video, sono disponibili solo come zona dati o tipi di distribuzione globali.
- Le versioni successive del modello potrebbero non essere disponibili nelle stesse aree. Una versione più recente può essere visualizzata in alcune aree prima che gli aggiornamenti vengano pianificati in altri.
- Microsoft può limitare i nuovi clienti in determinate regioni per mantenere la qualità del servizio per i clienti esistenti.
Azure per enti pubblici cloud
- Le distribuzioni Standard Globali non sono disponibili nei cloud per enti pubblici.
- Non tutti i modelli o le versioni disponibili nei cloud commerciali sono disponibili nei cloud per enti pubblici.
- I cloud per enti pubblici supportano in genere una sola versione di un determinato modello alla volta, con una sovrapposizione di 30 giorni quando diventa disponibile una nuova versione.
Per ulteriori informazioni, consultare Foundry Models venduti direttamente da Azure (versione Governativa), Versioni dei modelli e Tipi di distribuzione in Azure (versione Governativa).
Ritiri basati sulla sicurezza
Se viene rilevato un problema di conformità o di sicurezza, Microsoft si riserva il diritto di invocare un ritiro d'emergenza con un preavviso ridotto. Per informazioni dettagliate, vedere le Azure condizioni per il servizio.
Vincoli della cronologia del ciclo di vita
Microsoft prende impegni specifici sulla durata della disponibilità delle versioni del modello e sulla visualizzazione delle sostituzioni, in modo da poter pianificare le migrazioni con sicurezza.
I modelli di sostituzione disponibili a livello generale si sovrappongono agli impegni
Ci impegniamo a una sovrapposizione significativa tra un modello di disponibilità generale ritirato e la relativa sostituzione in modo che i clienti possano testare, valutare ed eseguire la migrazione con sicurezza.
| Fase | Modello |
|---|---|
| Lancio a livello generale | Ogni modello viene avviato in base al proprio tipo di distribuzione e alla matrice di disponibilità dell'area. La data di ritiro (18 mesi) viene impostata a livello di codice e disponibile tramite l'API Models. |
| Deprecato (solo clienti esistenti) | A 12 mesi dall'avvio, i clienti esistenti possono continuare a creare e gestire le distribuzioni. I nuovi clienti non possono accedere al modello. |
| Sostituzione disponibile nello standard globale | I clienti possono usare e testare il modello di sostituzione nello standard globale circa 90 giorni prima del ritiro. |
| Sostituzione disponibile nelle regioni provisionate | Il modello di sostituzione diventa disponibile per il test nelle aree con provisioning in cui il predecessore si ritira circa 30 giorni prima del ritiro, offrendo ai clienti con provisioning una finestra di migrazione manuale. |
| Versione del modello ritirata | A 18 mesi dall'avvio, l'inferenza restituisce 410 Gone. |
Suggerimento
Perché 90-120 giorni? Il modello di sostituzione ufficiale viene selezionato e dichiarato circa 90-120 giorni prima della data di ritiro del modello in pensione, non prima. Dato il rapido ritmo di miglioramento dell'IA generativa, dichiarando una sostituzione troppo precoce rischi indirizzando i clienti a un modello che non è più l'opzione migliore disponibile entro il momento in cui è necessario eseguire la migrazione.
Anteprima del ciclo di vita del modello
I modelli di anteprima hanno un ciclo di vita fondamentalmente diverso rispetto ai modelli ga. Vengono avviate con una data di ritiro "non prima di" (tipicamente 90 giorni dalla data di annuncio), ma a volte vengono estese oltre tale finestra iniziale, fino a quando non è disponibile un'anteprima di sostituzione appropriata o una versione del modello generale disponibile. Quando viene presa una decisione di ritiro, i clienti vengono aggiornati forzatamente a una sostituzione (una versione di anteprima più recente o il modello ga) o il modello viene ritirato senza sostituzione. Non c'è opzione per rimanere su un modello di anteprima in fase di ritiro; tutte le distribuzioni di anteprima vengono aggiornate o terminate.
Nota
I modelli di anteprima non sono consigliati per i carichi di lavoro di produzione.
| Risultato | Che succede |
|---|---|
| Eseguire l'aggiornamento alla versione di anteprima più recente | Le distribuzioni di anteprima esistenti vengono aggiornate forzatamente a una versione di anteprima più recente. I clienti ricevono almeno 30 giorni di preavviso. Il ciclo viene ripetuto fino a quando non è disponibile una versione disponibile a livello generale. |
| Aggiorna a GA | All'avvio del Modello GA, le distribuzioni in anteprima vengono aggiornate automaticamente alla versione GA. I clienti ricevono almeno 30 giorni di preavviso. Il modello GA segue quindi il ciclo di vita standard di 18 mesi di Disponibilità Generale. |
| Nessuna sostituzione (rara) | Se non esiste alcuna sostituzione, i clienti ricevono un preavviso di 30 giorni prima del ritiro del modello e l'inferenza restituisce 410 Gone. |
Aggiornamenti automatici
Per Global Standard, Data Zone Standard e Standard, Microsoft gestisce gli aggiornamenti automatici quando viene ritirata una versione del modello:
- Gli aggiornamenti automatici vengono pianificati progressivamente, regione per regione.
- La pianificazione dell'aggiornamento viene pubblicata in anticipo nel programma di ritiro dei modelli.
- Gli aggiornamenti possono verificarsi anche se la nuova versione del modello non è ancora disponibile separatamente in tale area o per tale SKU, il processo di aggiornamento lo renderà disponibile.
Importante
Le distribuzioni con provisioning non vengono aggiornate automaticamente. I clienti forniti devono eseguire manualmente la migrazione al nuovo modello.
Usare l'API Models per controllare, a livello di codice, lifecycleStatus, deprecation e per SKU deprecationDate qualsiasi modello in qualsiasi momento.
Esempio: aggiornamento di gpt-4o → gpt-5.1
Quando le versioni 2024-05-13 gpt-4o e 2024-08-06 sono state ritirate il 31 marzo 2026, sono state aggiornate automaticamente a gpt-5.1 nello SKU Standard. Prima dell'aggiornamento, gpt-5.1 non aveva alcuna presenza Standard. Dopo l'aggiornamento, gpt-5.1 Standard è stato aggiunto a tutte e otto le aree che in precedenza avevano le versioni gpt-4o (centralus, eastus, eastus2, northcentralus, southcentralus, swedencentral, westus, westus3). La versione 2024-11-20 non è stata modificata (viene ritirata il 2026-10-01).
Migrazione a un modello di sostituzione
Quando un modello usato entra nella fase legacy o deprecata, controllare la colonna "Sostituzione suggerita" nella pianificazione ritiro del modello e seguire i passaggi descritti in Uso dei modelli per distribuire, testare ed eseguire la migrazione alla sostituzione.
Notifiche
I modelli GA hanno la data di ritiro impostata automaticamente a 18 mesi dal lancio, senza un "annuncio" separato. Le transizioni Eredità e Sconsigliato seguono la sequenza temporale pubblicata e sono visibili in tempo reale tramite l'API Models.
Quando si ricevono notifiche attive
| Evento | Tempi | Si applica a |
|---|---|---|
| Avviso di ritiro del modello ga | Almeno 60 giorni prima del ritiro | Tutti i modelli GA. Inviati ai proprietari degli abbonamenti con distribuzioni attive. |
| Avviso di ritiro del modello di anteprima | Almeno 30 giorni prima del ritiro | Visualizzare in anteprima i modelli. Le distribuzioni in anteprima possono essere aggiornate automaticamente alla sostituzione se un modello di sostituzione è disponibile e applicabile (ad esempio, non richiede un contratto API diverso). |
Modalità di notifica
| Canale | Dettagli |
|---|---|
| Inviati automaticamente ai titolari delle sottoscrizioni con distribuzioni attive. | |
| integrità dei servizi di Azure | Gli avvisi di salute vengono visualizzati per gli abbonamenti interessati. Passare a Service Health > Health advisories, filtrare in base a Servizio Azure OpenAI e creare una regola di avviso per le notifiche tramite posta elettronica, SMS o webhook. |
Metodi programmatici per controllare il ciclo di vita del modello e la deprecazione
I clienti possono controllare i campi relativi al ciclo di vita e alla deprecazione in qualsiasi modello usando l'API Models (con ambito sottoscrizione, tutti i modelli in un'area):
GET https://management.azure.com/subscriptions/{sub}/providers/Microsoft.CognitiveServices/locations/{location}/models?api-version=2024-10-01
Campi chiave: lifecycleStatus, deprecation.inference, deprecation.fineTune, per SKU deprecationDate (date ISO).
Importante
L'API usa terminologia diversa rispetto alla documentazione e al portale. La tabella seguente esegue il mapping dei nomi delle fasi rivolte ai clienti usati in questo documento e nel portale Foundry ai valori dei campi API corrispondenti.
| Fase (documentazione e portale) | Campo Stato API (lifecycleStatus) |
Campo data API (deprecation.inference) |
Cosa significa |
|---|---|---|---|
| Anteprima | Preview |
Data futura o non impostata | Sperimentale. Può cambiare o essere rimosso. |
| Disponibile a livello generale | GenerallyAvailable |
Data futura (impostata al lancio) | Pronto per la produzione. Pesi fissi e API. |
| Deprecato | Deprecating |
Data futura | Serve comunque l'inferenza. Bloccato per i nuovi clienti. |
| Pensionati | Deprecated |
Data precedente | Completamente ritirato. L'inferenza restituisce 410 Gone. |
Ad esempio, un modello che l'elenco dei documenti è "Deprecato" (ancora funziona, bloccato per i nuovi clienti) viene visualizzato nell'API come lifecycleStatus: "Deprecating", non "Deprecated". Il valore "Deprecated" dell'API indica che il modello viene ritirato e non serve più l'inferenza.
Per determinare la fase di un modello a livello di codice, controllare entrambi i campi insieme:
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
Modelli ottimizzati
I modelli ottimizzati sono ritirati in due fasi: addestramento e distribuzione.
Se non specificato in modo esplicito, la formazione non viene ritirata prima della data di ritiro del modello base. Dopo che un modello è stato ritirato per il training, non è più disponibile per l'ottimizzazione, ma tutti i modelli sottoposti a training in precedenza rimangono disponibili per la distribuzione.
Alla fase di ritiro del deployment, l'inferenza e il deployment restituiscono risposte di errore.
| Modello | Versione | Data di disattivazione del training | Data di fine implementazione |
|---|---|---|---|
| gpt-4o | 2024-08-06 | Non precedente al 2027-04-011 | 01-10-2027 |
| gpt-4o-mini | 2024-07-18 | Non precedente al 2027-04-011 | 01-10-2027 |
| gpt-4.1 | 2025-04-14 | Non prima del 2027-04-141 | 14-10-2027 |
| gpt-4.1-mini | 2025-04-14 | Non prima del 2027-04-141 | 14-10-2027 |
| gpt-4.1-nano | 2025-04-14 | Non prima del 2027-04-141 | 14-10-2027 |
| o4-mini | 2025-04-16 | Ritiro del modello di base | Un anno dopo il ritiro del modello addestrato |
1 Solo per i clienti esistenti. In caso contrario, il pensionamento del training avviene al pensionamento del modello di base.
Domande frequenti
| Domanda | Risposta | Ulteriori informazioni |
|---|---|---|
| Qual è la differenza tra una famiglia di modelli, una versione e una variante? | Una famiglia di modelli è una generazione di modelli (ad esempio, GPT-4o, GPT-5). Una versione di modello è una versione datata all'interno di una famiglia (ad esempio, gpt-4o 2024-05-13 contro 2024-08-06). Una variante di modello è un livello di dimensioni/funzionalità all'interno della stessa famiglia (ad esempio, GPT-5, GPT-5-mini, GPT-5-nano). | Versioni del modello |
| È possibile controllare quando viene eseguito l'aggiornamento automatico della distribuzione Standard? | Sì. Impostare la proprietà nella versionUpgradeOption distribuzione su uno dei tre valori seguenti: OnceNewDefaultVersionAvailable (aggiornamento quando è impostato un nuovo valore predefinito), OnceCurrentVersionExpired (aggiornamento solo al ritiro) o NoAutoUpgrade (mai aggiornamento automatico, la distribuzione smette di funzionare al ritiro). È possibile configurare questa impostazione tramite l'API REST, Azure PowerShell o il portale foundry. |
Uso dei modelli: configurazione di aggiornamento |
| Come si esegue la migrazione di una distribuzione provisionata? | Le implementazioni con provisioning non vengono aggiornate automaticamente. Sono disponibili due opzioni: Migrazione sul posto (Azure gestisce la migrazione del traffico in una finestra di 20-30 minuti senza tempi di inattività) o Migrazione side-by-side (multi-distribuzione (si crea una nuova distribuzione, si testa, si passa al traffico e si elimina quella precedente). | Gestione dei modelli nei tipi di distribuzione provisionata |
| La mia quota sarà conservata nel modello di sostituzione? | Per gli aggiornamenti automatici Standard, sì, la quota viene gestita automaticamente. Per le distribuzioni provisionate, è necessario assicurarsi che la quota sia disponibile per il modello di destinazione prima della migrazione. La capacità PTU è indipendente dal modello e fungibile nei deployment gestiti e sottoposti a provisioning. | Capacità di elaborazione con provisioning: limite |
| È possibile ottenere un'eccezione per estendere la data di ritiro di un modello? | No. Le date di ritiro non sono estendibili. Pianificare la migrazione usando le sequenze temporali pubblicate nella pianificazione del ritiro del modello e nell'API Modelli. | N/D |
| Quali strumenti possono essere utili per valutare un modello di sostituzione? | Usare la classifica del modello nel Portale Foundry per confrontare i benchmark, la funzionalità di confronto dei modelli durante la distribuzione e Valutazioni per i test personalizzati del carico di lavoro. Applicare la progettazione dei prompt e l'ottimizzazione in base alle esigenze per trovare una corrispondenza con l'accuratezza precedente. | Preparazione per i ritiri del modello |
| I modelli di incorporamento seguono lo stesso ciclo di vita? | I modelli di incorporamento (text-embedding-3-large, text-embedding-3-small, text-embedding-ada-002) hanno sequenze temporali estese e vengono gestite in modo diverso dai modelli di inferenza. Controllare il Piano di Disattivazione del Modello per le date specifiche. | Ritiri del modello: incorporamenti |
| Come si aggiornano l'elaborazione prioritaria e le distribuzioni batch? | L'elaborazione della priorità segue lo stesso processo di aggiornamento delle distribuzioni Standard (aggiornamento automatico supportato). Le distribuzioni batch seguono l'approccio di migrazione side-by-side (multi-deployment), distribuire il nuovo modello, inviare di nuovo i processi e quindi ritirare la distribuzione precedente. | Uso dei modelli |
| Non riesco a trovare "Microsoft Foundry" in integrità dei servizi di Azure: come posso configurare gli avvisi? | Selezionare Servizio Azure OpenAI come nome del servizio durante la configurazione degli avvisi di integrità dei servizi. Non esiste un servizio "Microsoft Foundry" separato in Integrità dei servizi. |
Configurare gli avvisi di integrità dei servizi |
Contenuto correlato
- Pianificazione ritiro modello per date specifiche per tutti i modelli correnti, deprecati e ritirati
-
Riferimento API dei modelli per eseguire query a livello di codice su
lifecycleStatus,deprecation, e su SKUdeprecationDatedi qualsiasi modello - Versioni dei modelli in Microsoft Foundry Models su come funzionano gli aggiornamenti delle versioni
- Introduzione alla valutazione del modello
- Gestione dei modelli nei tipi di distribuzione provisionata
- Configurare gli avvisi di integrità dei servizi