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.
Microsoft Foundry organizza i carichi di lavoro di intelligenza artificiale tramite un'architettura a più livelli: una risorsa Foundry di primo livello per la governance, i progetti per l'isolamento dello sviluppo e i servizi di Azure connessi per la gestione di archiviazione, ricerca e segreti.
Questo articolo fornisce ai team IT operazioni e sicurezza con informazioni dettagliate sulla risorsa Foundry e sull'architettura del servizio di Azure sottostante, sui relativi componenti e sulla relazione con altri tipi di risorse di Azure. Usare queste informazioni come guida per personalizzare la distribuzione di Foundry in base ai requisiti dell'organizzazione. Per altre informazioni su come implementare Foundry nell'organizzazione, vedere Foundry Rollout.
Quando usare questa architettura
Prendere in considerazione il modello di risorsa Foundry quando lo scenario prevede:
- Configurazione per la prima volta: si sta avviando un nuovo progetto di intelligenza artificiale e si vuole una singola risorsa che aggrega l'accesso al modello, l'hosting dell'agente e gli strumenti di valutazione.
- Accesso multi-team: più team necessitano di progetti isolati con distribuzioni di modelli condivise e governance centralizzata.
- Progettazione basata sulla conformità: l'organizzazione richiede rete privata, crittografia gestita dal cliente o definizione dell'ambito di Azure RBAC a livello di risorsa e di progetto.
- Migrazione di Azure OpenAI: stai passando da una risorsa Azure OpenAI autonoma e vuoi mantenere i criteri esistenti e RBAC mentre aggiungi funzionalità di agente e valutazione.
Per l'esplorazione a singolo sviluppatore, una risorsa Foundry con un progetto è l'impostazione predefinita consigliata. Se il carico di lavoro richiede solo completamenti OpenAI di Azure senza hosting o valutazione dell'agente, potrebbe essere sufficiente una risorsa OpenAI di Azure autonoma.
Tipi di risorse e provider di intelligenza artificiale di Azure
All'interno della famiglia di prodotti Azure per intelligenza artificiale è possibile usare questi provider di risorse di Azure che supportano le esigenze degli utenti a livelli diversi nello stack.
| Fornitore di risorse | Scopo | Servizi supportati |
|---|---|---|
| Microsoft.CognitiveServices | Supporta lo sviluppo di applicazioni Agentic e GenAI che compongono e personalizzano modelli predefiniti. | Fonderia; Azure OpenAI; Riconoscimento vocale di Azure negli strumenti della Fonderia; Linguaggio di Azure negli strumenti della Fonderia; Visione di Azure negli strumenti della Fonderia |
| Microsoft.Search | Supporta il recupero di conoscenze dai tuoi dati | Ricerca di intelligenza artificiale di Azure |
Per la maggior parte degli scenari di sviluppo di intelligenza artificiale, inclusi i flussi di lavoro di compilazione, distribuzione di modelli e valutazione dell'agente, la risorsa Foundry è il punto di partenza consigliato. Le risorse foundry condividono lo spazio dei nomi del provider Microsoft.CognitiveServices con servizi come Azure OpenAI, Speech, Vision e Language. Questo spazio dei nomi del provider condiviso consente di allineare le API di gestione, i modelli di controllo di accesso, la rete e il comportamento dei criteri tra le risorse di intelligenza artificiale correlate.
Usare la tabella seguente per identificare il tipo di risorsa corrispondente al carico di lavoro. Mostra i tipi di risorse e le funzionalità specifici all'interno del provider Microsoft.CognitiveServices:
| Tipo di risorsa | Tipo e provider di risorse | Tipologia | Funzionalità supportate |
|---|---|---|---|
| Microsoft Foundry | Microsoft.CognitiveServices/accounts |
AIServices |
Agenti, valutazioni, Azure OpenAI, riconoscimento vocale, visione artificiale, lingua e comprensione del contenuto |
| Progetto Foundry | Microsoft.CognitiveServices/accounts/projects |
AIServices |
Sottorisorsa a quanto sopra |
| Strumenti di riconoscimento vocale di Azure in Foundry | Microsoft.CognitiveServices/accounts |
Speech |
Discorso |
| Linguaggio di Azure negli strumenti Foundry | Microsoft.CognitiveServices/accounts |
Language |
Lingua |
| Azure Vision negli strumenti di fonderia | Microsoft.CognitiveServices/accounts |
Vision |
Visione |
I tipi di risorse all'interno dello stesso namespace del provider condividono le stesse API di gestione e utilizzano azioni simili del controllo degli accessi basato sui ruoli di Azure (Azure RBAC), configurazioni di rete e alias per la configurazione delle Policy di Azure. Se stai eseguendo l'aggiornamento da Azure OpenAI a Foundry, le tue politiche personalizzate di Azure esistenti e le azioni RBAC di Azure continueranno ad applicarsi.
Gerarchia delle risorse di Foundry
Il diagramma seguente mostra una risorsa Foundry con distribuzioni di modelli, impostazioni di sicurezza, connessioni e due progetti. I servizi di Azure connessi, ad esempio Archiviazione, Key Vault e Ricerca di intelligenza artificiale di Azure, sono risorse di Azure separate con i propri limiti di governance:
Importante
Le risorse connesse, ad esempio Archiviazione, Key Vault e Ricerca di intelligenza artificiale di Azure, sono risorse di Azure indipendenti con i propri limiti di governance. È possibile gestire le impostazioni di rete, criteri di accesso e conformità per queste risorse separatamente dalla risorsa Foundry.
Usare questo modello durante la pianificazione dell'architettura e dei limiti di accesso:
- Risorsa Foundry: Risorsa di Azure di primo livello in cui si gestiscono impostazioni di governance come la rete, la sicurezza e la distribuzione dei modelli.
- Progetto: limite di sviluppo all'interno della risorsa Foundry in cui i team compilano e valutano i casi d'uso. I progetti consentono ai team di creare prototipi all'interno di un ambiente preconfigurato, riutilizzando distribuzioni e connessioni di modelli esistenti senza ripetere la configurazione IT.
- Risorse di progetto: file, agenti, valutazioni e artefatti correlati con l'ambito di un progetto.
- Risorse connesse: servizi di Azure come Archiviazione, Key Vault e Ricerca di intelligenza artificiale di Azure a cui fa riferimento la risorsa Foundry tramite connessioni. Queste risorse hanno limiti di governance separati, quindi è possibile gestire i criteri di rete e di accesso in modo indipendente.
Questa separazione consente ai team IT di applicare controlli centralizzati a livello di risorsa mentre i team di sviluppo lavorano entro i limiti a livello di progetto.
Nota
La maggior parte delle nuove API è disponibile nell'ambito del progetto. Tuttavia, alcune funzionalità originariamente supportate a livello di account tramite i servizi Azure OpenAI, Speech, Vision e Language sono disponibili solo a livello di risorsa Foundry, non nell'ambito del progetto. Ad esempio, l'API Translator è disponibile solo a livello di risorsa Foundry. Pianificare la struttura di distribuzione in base agli ambiti API necessari per i carichi di lavoro.
Separazione degli ambiti guidata dalla sicurezza
Foundry applica una netta separazione tra le operazioni di gestione e sviluppo per garantire carichi di lavoro di intelligenza artificiale sicuri e scalabili.
Governance delle risorse di primo livello
Le operazioni di gestione delle risorse Foundry di primo livello includono, ad esempio, la configurazione della sicurezza, la definizione della connettività con altri servizi di Azure e la gestione delle distribuzioni. I contenitori di progetti dedicati isolano le attività di sviluppo e forniscono limiti per il controllo di accesso, i file, gli agenti e le valutazioni.
Controllo degli accessi in base al ruolo
Le azioni di controllo degli accessi in base al ruolo di Azure riflettono questa separazione dei problemi. Le azioni del livello di controllo, ad esempio la creazione di distribuzioni e progetti, sono distinte dalle azioni del livello dati, ad esempio la creazione di agenti, l'esecuzione di valutazioni e il caricamento di file. È possibile definire l'ambito delle assegnazioni del controllo degli accessi in base al ruolo sia a livello di risorsa principale sia a livello di singolo progetto. Assegnare identità gestite in entrambi gli ambiti per supportare l'automazione sicura e l'accesso al servizio. Per altre informazioni, vedere Controllo degli accessi in base al ruolo per Microsoft Foundry.
Gli incarichi iniziali comuni per l'inserimento con privilegi minimi includono:
- Utente Azure AI per ogni entità utente sviluppatore nell'ambito della risorsa Foundry.
- Utente di Intelligenza artificiale di Azure per ogni identità gestita del progetto all'interno dell'ambito delle risorse di Foundry.
Per le definizioni dei ruoli e le indicazioni sulla pianificazione dell'ambito, vedere Controllo degli accessi in base al ruolo per Microsoft Foundry.
Monitoraggio e osservabilità
Monitoraggio di Azure segmenta le metriche per ambito. È possibile visualizzare le metriche di gestione e utilizzo nella risorsa di primo livello, mentre le metriche specifiche del progetto, ad esempio le prestazioni di valutazione o l'attività dell'agente, hanno come ambito i singoli contenitori di progetto.
Le principali funzionalità di monitoraggio includono:
- Metriche a livello di risorsa: consumo di token, latenza del modello, conteggi delle richieste e percentuali di errore in tutti i progetti.
- Metriche a livello di progetto: risultati dell'esecuzione della valutazione, conteggi delle chiamate dell'agente e attività di operazione file.
- Registrazione diagnostica: abilitare le impostazioni di diagnostica per instradare i log a Log Analytics, Archiviazione o Hub eventi per l'analisi e la conservazione.
Per altre informazioni, vedere Panoramica di Monitoraggio di Azure.
Infrastruttura di calcolo
Foundry gestisce l'infrastruttura di calcolo per l'hosting del modello, l'esecuzione dell'agente e l'elaborazione batch. Questa sezione illustra i tipi di distribuzione, l'infrastruttura di valutazione e l'agente, l'integrazione della rete virtuale, l'isolamento del tenant, i controlli di sicurezza del contenuto e la disponibilità a livello di area.
Tipi di distribuzione del modello
Foundry supporta più tipi di distribuzione per l'hosting di modelli, raggruppati in base all'ambito di elaborazione dati: globale (tra aree), zona dati (entro un limite definito) e area (singola area). Ogni tipo bilancia la latenza, la velocità effettiva e la posizione di elaborazione dei dati in modo diverso:
| Tipo di distribuzione | Elaborazione dei dati | Fatturazione |
|---|---|---|
| Standard globale | Tra aree, gestione da parte di Azure | Pagamento in base al token |
| Fornito globalmente | Tra aree, gestione da parte di Azure | Capacità riservata oraria |
| Batch globale | Tra aree, gestione da parte di Azure | Prezzi dei token batch |
| Zona Dati Standard | All'interno del limite della zona dati | Pagamento in base al token |
| Zona dati provisionata | All'interno del limite della zona dati | Capacità riservata oraria |
| Batch area dati | All'interno del limite della zona dati | Prezzi dei token batch |
| Standard | Regione singola | Pagamento in base al token |
| Provisioning a livello di area | Regione singola | Capacità riservata oraria |
| Sviluppatore | Qualsiasi area di Azure (nessuna garanzia di residenza dei dati) | Pagamento per token (solo valutazione del modello ottimizzato; durata di 24 ore; nessun SLA) |
Per informazioni dettagliate su come scegliere il tipo di distribuzione corretto, vedere Tipi di distribuzione per i modelli foundry.
Agenti, valutazioni ed elaborazione batch
Gli agenti, le valutazioni e i processi batch sono completamente gestiti da Microsoft. I carichi di lavoro dell'agente vengono eseguiti all'interno dell'infrastruttura contenitore della piattaforma, che supporta l'integrazione della rete virtuale per scenari isolati dalla rete. Le valutazioni richiamano gli endpoint del modello, confrontano gli output con i criteri di classificazione e archiviano i risultati all'interno dell'ambito del progetto. Le code di elaborazione batch mettono in coda le richieste di inferenza per l'esecuzione asincrona con prezzi ridotti per token. I risultati per tutti e tre i tipi di carico di lavoro sono accessibili tramite il portale o l'SDK.
Integrazione della rete virtuale
Quando gli agenti si connettono con sistemi esterni, è possibile isolare il traffico di rete usando l'inserimento di contenitori, in cui la piattaforma inserisce una subnet nella rete virtuale, abilitando la comunicazione locale con le risorse di Azure all'interno della stessa rete virtuale.
Foundry supporta due modelli di rete per l'isolamento in uscita:
| Modello | Come funziona | Compromesso |
|---|---|---|
| Rete virtuale gestita dal cliente (BYO) | Tu fornisci la rete virtuale e una subnet dedicata delegata a Microsoft.App/environments. La piattaforma si interfaccia con la tua subnet, abilitando la comunicazione locale con le risorse private di Azure. |
Controllo completo sulla configurazione di rete; richiede una gestione di rete personalizzata. |
| Rete virtuale gestita (anteprima) | Foundry gestisce la rete virtuale per conto dell'utente. | Configurazione più semplice; limita le opzioni di personalizzazione. Per informazioni dettagliate, vedere Configurare la rete virtuale gestita. |
Nota
Alcuni scenari isolati dalla rete richiedono l'SDK o l'interfaccia della riga di comando anziché il portale. Ad esempio, le distribuzioni con endpoint privati che bloccano tutti gli accessi pubblici non sono configurabili tramite l'interfaccia utente del portale. Per informazioni dettagliate, vedere Come configurare un collegamento privato per Foundry.
Isolamento del tenant
I carichi di lavoro vengono eseguiti in ambienti isolati logicamente per ogni risorsa Foundry. Il codice del cliente non condivide i contenitori di runtime con altri tenant.
Sicurezza dei contenuti e protezioni
Foundry integra i controlli di sicurezza dei contenuti nella pipeline di inferenza del modello e dell'agente. Le guardrail definiscono i rischi da rilevare, i punti di intervento da esaminare (input utente, output, chiamate agli strumenti (anteprima) e risposte degli strumenti (anteprima)), e le azioni di risposta quando viene rilevato un rischio. I filtri contenuto vengono eseguiti in linea con le richieste di modello e possono essere configurati per ogni implementazione. Per altre informazioni, vedere Cenni preliminari su guardrail e controlli, e Livelli di gravità del filtro del contenuto.
Disponibilità regionale
Le funzionalità di calcolo variano in base all'area di Azure. Disponibilità del modello, opzioni del tipo di distribuzione e supporto delle funzionalità, ad esempio agenti o valutazioni, possono variare in diverse aree. Verificare che l'area di destinazione supporti le funzionalità necessarie prima del provisioning. Per la disponibilità corrente, vedere Disponibilità delle funzionalità tra aree cloud.
Archiviazione dei dati
Foundry offre opzioni di archiviazione dei dati flessibili e sicure per supportare un'ampia gamma di carichi di lavoro di intelligenza artificiale.
Archiviazione gestita per il caricamento di file
Nell'installazione predefinita, Foundry usa account di archiviazione gestiti da Microsoft separati logicamente e supportano i caricamenti diretti dei file per i casi d'uso selezionati, ad esempio modelli e agenti OpenAI, senza richiedere un account di archiviazione fornito dal cliente.
Porta il tuo dispositivo di archiviazione
Facoltativamente, è possibile connettere i propri account di archiviazione di Azure. Gli strumenti foundry, ad esempio le valutazioni e l'elaborazione batch, possono leggere gli input da e scrivere output in questi account. Per informazioni dettagliate sugli scenari supportati, vedere Bring-your-own resources with the Agent service.
Archiviazione dello stato dell'agente
- Con la configurazione dell'agente di base, il servizio Agent archivia thread, messaggi e file nell'archiviazione multi-tenant gestita da Microsoft, con separazione logica.
- Con la configurazione standard dell'agente, è possibile usare le proprie risorse di Azure per tutti i dati dei clienti, inclusi file, conversazioni e archivi vettoriali. In questa configurazione i dati vengono isolati dal progetto all'interno degli account di archiviazione.
Crittografia della chiave gestita dal cliente
Per impostazione predefinita, i servizi di Azure crittografano i dati inattivi e in transito usando chiavi gestite da Microsoft con crittografia AES a 256 bit conforme a FIPS 140-2. Non sono necessarie modifiche al codice.
Per usare le chiavi personalizzate, verificare invece questi prerequisiti prima di abilitare le chiavi gestite dal cliente per Foundry:
- Key Vault viene distribuito nella stessa area di Azure della risorsa Foundry.
- L'eliminazione temporanea e la protezione dalla rimozione definitiva sono abilitate in Key Vault.
- Le identità gestite dispongono delle autorizzazioni chiave necessarie, come il ruolo Utente crittografia Key Vault quando si utilizza il controllo degli accessi in base al ruolo di Azure.
Crea il tuo Key Vault
Per impostazione predefinita, Foundry archivia tutti i segreti di connessione basati su chiavi API in un Azure Key Vault gestito. Se preferite gestire i segreti manualmente, collegate il vostro Vault delle chiavi alla risorsa Foundry. Una connessione di Azure Key Vault gestisce tutti i segreti di connessione a livello di progetto e risorsa. Per altre informazioni, vedere come configurare una connessione di Azure Key Vault a Foundry.
Per altre informazioni sulla crittografia dei dati, vedere Chiavi gestite dal cliente per la crittografia con Foundry.
Residenza e conformità dei dati
Foundry archivia tutti i dati inattivi nell'area geografica di Azure designata. L'inferenza dei dati (prompt e completamenti) viene elaborata in base al tipo di distribuzione: le distribuzioni globali possono essere instradate verso qualsiasi area di Azure, le distribuzioni della zona dati rimangono all'interno della zona degli Stati Uniti o dell'UE, mentre le distribuzioni standard o a livello di area vengono elaborate nell'area di distribuzione. Per informazioni dettagliate, vedere Tipi di distribuzione. Foundry non supporta il failover automatico tra regioni. Se l'organizzazione richiede la disponibilità in più aree, distribuire risorse Foundry separate in ogni area di destinazione e gestire la sincronizzazione e il routing dei dati a livello di applicazione. Per informazioni dettagliate sulla certificazione di conformità, vedere la documentazione sulla conformità di Azure.
Convalidare le decisioni relative all'architettura
Prima dell'implementazione, convalidare quanto segue per l'ambiente di destinazione:
- Verificare che i modelli e le funzionalità necessari siano disponibili nelle aree di distribuzione. Per informazioni dettagliate, vedere Disponibilità delle funzionalità tra aree cloud.
- Verificare che l'ambito delle assegnazioni di ruolo sia corretto sia a livello di risorsa Foundry che a livello di progetto. Per informazioni dettagliate, vedere Controllo degli accessi in base al ruolo per Microsoft Foundry.
- Convalidare i requisiti di isolamento della rete e i percorsi di accesso privato. Per informazioni dettagliate, vedere Come configurare un collegamento privato per Foundry.
- Verificare i requisiti di crittografia e gestione dei segreti, incluse le chiavi gestite dal cliente e l'integrazione di Azure Key Vault. Per informazioni dettagliate, vedere Chiavi gestite dal cliente per la crittografia con Foundry e come configurare una connessione di Azure Key Vault a Foundry.
- Esaminare le quote e i limiti per le risorse di destinazione, inclusi i limiti di implementazione del modello e i limiti di frequenza. Per informazioni dettagliate, vedere Quote e limiti di Azure OpenAI e limiti del servizio agente, quote e aree geografiche.
Contenuto correlato
- Implementazione di Foundry nell'organizzazione
- Controllo degli accessi in base al ruolo per Microsoft Foundry
- Chiavi gestite dal cliente per la crittografia con Foundry
- Come configurare un collegamento privato per Foundry
- Bring-your-own Resources con il servizio agenti
- Panoramica di Monitoraggio di Azure
- Quote e limiti di Azure OpenAI
- Tipi di distribuzione per i modelli Foundry
- Panoramica delle protezioni e dei controlli
- Disponibilità delle funzionalità tra aree cloud