Multi-tenancy e servizio Azure OpenAI
Azure OpenAI consente di accedere ai potenti modelli linguistici di OpenAI. Questo articolo descrive le funzionalità principali di Azure OpenAI utili per le soluzioni multi-tenant. Esaminare le risorse consigliate per pianificare l'approccio e usare Azure OpenAI.
Modalità di isolamento
Quando si dispone di un sistema multi-tenant che usa il servizio Azure OpenAI, è necessario decidere il livello di isolamento richiesto dai tenant. È necessario determinare il modello di isolamento in base ai fattori seguenti:
- Quanti tenant si prevede di avere?
- I tenant hanno requisiti di conformità che richiedono l'isolamento della rete o dell'infrastruttura?
- I tenant richiedono modelli ottimizzati per i propri dati?
- I tenant richiedono versioni del modello o cicli di vita del modello diversi?
La tabella seguente riepiloga gli approcci di distribuzione che è possibile usare quando si usa il servizio Azure OpenAI in un sistema multi-tenant:
| Considerazioni | Servizio Azure OpenAI dedicato | Servizio OpenAI di Azure condiviso, distribuzione di modelli dedicati per tenant | Servizio Azure OpenAI condiviso, distribuzione di modelli condivisi | Servizio Azure OpenAI fornito dal tenant |
|---|---|---|---|---|
| Isolamento dei dati | Alto | Medio | Ridotto | Elevato |
| Isolamento delle prestazioni | Alto | Alta | Bassa media, a seconda dell'utilizzo del token al minuto (TPM) per ogni tenant. | Alto |
| Complessità della distribuzione | Basso medio, a seconda del numero di tenant. | Medio, è necessario gestire i nomi e le quote di distribuzione. | Basso | Non applicabile, gestito dal cliente. |
| Complessità operativa | Basso | Medium | Alto | Basso per il provider, maggiore per il tenant. |
| Scenario di esempio | Distribuzioni a tenant singolo che richiedono l'isolamento di rete da altri tenant. | Tenant con un ciclo di vita specifico del modello o requisiti di ottimizzazione. | Soluzioni multi-tenant di grandi dimensioni con un livello applicazione condiviso. | Tenant con requisiti di conformità o di ottimizzazione specifici. |
Servizio Azure OpenAI dedicato
Se si è un provider di servizi, è consigliabile distribuire un'istanza di Azure OpenAI per ogni tenant nella sottoscrizione di Azure. Questo approccio fornisce l'isolamento dei dati per ogni tenant. Richiede la distribuzione e la gestione di un numero crescente di risorse OpenAI di Azure man mano che si aumenta il numero di tenant.
Usare questo approccio se sono presenti distribuzioni di applicazioni separate per ogni tenant o se è necessario aggirare le limitazioni, ad esempio la quota o la richiesta al minuto. Per altre informazioni, vedere Quote e limiti di Azure OpenAI.
Il diagramma seguente illustra il modello per Azure OpenAI per ogni tenant nella sottoscrizione del provider.
Servizio OpenAI di Azure condiviso
È possibile scegliere di condividere un'istanza di Azure OpenAI tra più tenant. La risorsa OpenAI di Azure viene distribuita nella sottoscrizione di Azure (il provider di servizi). L'utente è responsabile della gestione. Questa soluzione è la soluzione più semplice da implementare, ma offre il minor isolamento dei dati e l'isolamento delle prestazioni.
La condivisione di una risorsa OpenAI di Azure non fornisce la segmentazione di sicurezza per ogni distribuzione del modello. Un tenant potrebbe essere in grado di usare un modello che non è autorizzato a usare. Per questo motivo, evitare di condividere un'istanza di Azure OpenAI quando si usano modelli ottimizzati, perché è possibile esporre informazioni riservate e consentire l'accesso non autorizzato a dati o risorse specifiche del tenant.
La condivisione di un'istanza di Azure OpenAI tra più tenant può causare anche un problema di Noisy Neighbor . Può causare una latenza più elevata per alcuni tenant. È anche necessario rendere il codice dell'applicazione compatibile con più tenancy. Ad esempio, se si vuole addebitare ai clienti il costo a consumo di un'istanza di Azure OpenAI condivisa, implementare la logica per tenere traccia del numero totale di token per ogni tenant nell'applicazione.
È anche possibile distribuire più istanze di Azure OpenAI condivise. Ad esempio, se si segue il modello Deployment Stamps, distribuire un'istanza di Azure OpenAI condivisa in ogni timbro. Se si distribuisce una soluzione multiregione, è necessario distribuire Azure OpenAI in ogni area in:
- Evitare la latenza del traffico tra aree.
- Supportare i requisiti di residenza dei dati.
- Abilitare l'uso di Azure OpenAI a livello di area all'interno di altri servizi che richiedono distribuzioni della stessa area.
Quando si dispone di un'istanza di Azure OpenAI condivisa, è importante considerare i limiti e gestire la quota.
Il diagramma seguente illustra il modello OpenAI di Azure condiviso.
Quando si distribuisce un servizio OpenAI di Azure condiviso, è possibile decidere se le distribuzioni del modello all'interno del servizio sono condivise o se sono dedicate a clienti specifici.
Distribuzione di modelli condivisi tra tenant
La condivisione di una distribuzione di modelli tra i tenant semplifica il carico operativo perché sono disponibili meno distribuzioni da gestire e modellare le versioni da tenere traccia. Pianificare l'uso di una distribuzione di modelli condivisi se possibile e creare distribuzioni di modelli dedicate solo se sono necessarie le funzionalità offerte.
Distribuzione di modelli dedicati per tenant
È possibile creare una distribuzione del modello per ogni tenant o per i tenant con requisiti speciali che non possono essere soddisfatti usando una distribuzione del modello condiviso. I motivi comuni per usare distribuzioni di modelli dedicati per un tenant includono quanto segue:
Gestione delle quote e dei costi: facilita l'allocazione TPM specifica del tenant monitorando il numero di token usati da ogni modello, che consente di allocare e gestire con precisione i costi di utilizzo di ogni tenant. Se si usano unità elaborate di cui è stato effettuato il provisioning, è possibile assegnare i PTU a clienti specifici e usare altri modelli di fatturazione per altri clienti.
Criteri di filtro del contenuto: a volte, un tenant specifico potrebbe richiedere criteri di filtro del contenuto univoci, ad esempio un elenco di blocchi specifico del tenant di parole non consentite. Specificare i criteri di filtro del contenuto nell'ambito di una distribuzione del modello.
Tipi di modello e versioni: potrebbe essere necessario usare modelli o versioni del modello diversi per tenant diversi. Un tenant potrebbe anche richiedere il proprio processo di gestione del ciclo di vita del modello.
Ottimizzazione specifica del tenant: se si creano modelli distinti ottimizzati per ogni tenant, è necessario creare una distribuzione di modello separata per ogni modello ottimizzato.
Tenere presente che l'ottimizzazione non è necessaria per la maggior parte dei casi d'uso. In genere, è preferibile mettere a terra il modello usando Azure OpenAI on Your Data o un altro approccio di generazione aumentata (RAG).
Residenza dei dati: questo approccio supporta requisiti di residenza dei dati distinti. Ad esempio, è possibile fornire una distribuzione del modello a livello di area per un tenant con esigenze di residenza dei dati rigorose e usare una distribuzione del modello globale per altri tenant senza esigenze rigorose.
Ogni distribuzione del modello ha un PROPRIO URL distinto, ma è importante ricordare che i modelli sottostanti vengono condivisi con altri clienti di Azure. Usano anche l'infrastruttura condivisa di Azure.
Azure OpenAI non applica il controllo di accesso per ogni distribuzione del modello, quindi l'applicazione deve controllare quale tenant può raggiungere la distribuzione del modello.
Risorsa Azure OpenAI fornita dal tenant
In alcune situazioni, i tenant potrebbero creare l'istanza di Azure OpenAI nelle proprie sottoscrizioni di Azure e concedere all'applicazione l'accesso. Questo approccio potrebbe essere appropriato nelle situazioni seguenti:
- I tenant hanno quote e autorizzazioni specifiche di Microsoft, ad esempio l'accesso a modelli diversi, criteri di filtro del contenuto specifici o l'uso della velocità effettiva con provisioning.
- Il tenant ha un modello ottimizzato da usare dalla soluzione.
- Richiedono un componente nel proprio ambiente per elaborare e inviare dati tramite l'istanza openAI di Azure gestita dal cliente per l'elaborazione.
Per accedere a un'istanza di Azure OpenAI nella sottoscrizione del tenant, il tenant deve fornire all'applicazione l'accesso. L'applicazione deve eseguire l'autenticazione tramite l'istanza di Microsoft Entra. Un approccio consiste nel pubblicare un'applicazione Microsoft Entra multi-tenant. Il flusso di lavoro seguente illustra i passaggi di questo approccio:
- Il tenant registra l'applicazione Microsoft Entra multi-tenant nel proprio tenant di Microsoft Entra.
- Il tenant concede all'applicazione Microsoft Entra multi-tenant il livello di accesso appropriato alla risorsa OpenAI di Azure. Ad esempio, il tenant potrebbe assegnare l'applicazione al ruolo utente dei servizi di intelligenza artificiale di Azure usando il controllo degli accessi in base al ruolo.
- Il tenant fornisce l'ID risorsa della risorsa OpenAI di Azure creata.
- Il codice dell'applicazione può usare un'entità servizio associata all'applicazione Microsoft Entra multi-tenant nella propria istanza di Microsoft Entra per accedere all'istanza di Azure OpenAI del tenant.
In alternativa, è possibile chiedere a ogni tenant di creare un'entità servizio da usare per il servizio e di specificarne le credenziali. Questo approccio richiede di archiviare e gestire in modo sicuro le credenziali per ogni tenant, che rappresenta una potenziale responsabilità in termini di sicurezza.
Se i tenant configurano i controlli di accesso alla rete nell'istanza di Azure OpenAI, assicurarsi di potervi accedere.
Il diagramma seguente illustra il modello per Azure OpenAI per ogni tenant nella sottoscrizione del tenant.
Funzionalità del servizio OpenAI di Azure che supportano la multi-tenancy
API Assistenti
L'API Assistants aggiunge funzionalità al servizio Azure OpenAI che lo rende adatto per la creazione di assistenti di intelligenza artificiale. Include la possibilità di chiamare strumenti e API, nonché i file di ricerca per individuare le risposte generate dal modello. Consente di gestire i thread conversazionali persistenti dal servizio e di generare ed eseguire codice all'interno di un ambiente in modalità sandbox. Per supportare queste funzionalità, l'API Assistants deve archiviare alcuni dati.
Quando si usa l'API Assistants in una soluzione multi-tenant, è possibile scegliere di creare assistenti dedicati a un singolo tenant oppure condividere un assistente tra più tenant. È importante considerare l'isolamento del tenant in tutti i dati archiviati, soprattutto per gli assistenti condivisi. Ad esempio, è necessario assicurarsi che i thread conversazionali vengano archiviati separatamente per ogni tenant.
L'API Assistants supporta la chiamata di funzione, che invia le istruzioni dell'applicazione sulle funzioni da richiamare e gli argomenti da includere. Assicurarsi che tutte le chiamate di funzioni effettuate siano in grado di essere consapevoli del multi-tenant, ad esempio includendo l'ID tenant nella chiamata al sistema downstream. Verificare l'ID tenant all'interno dell'applicazione e non basarsi sul modello linguistico per propagare l'ID tenant.
Azure OpenAI On Your Data
Azure OpenAI On Your Data consente al modello linguistico di grandi dimensioni di eseguire direttamente query sulle origini delle informazioni, ad esempio indici e database, come parte della generazione di una risposta dal modello linguistico.
Quando si effettua una richiesta, è possibile specificare le origini dati su cui eseguire query. In una soluzione multi-tenant assicurarsi che le origini dati siano in grado di supportare la multi-tenancy e che sia possibile specificare i filtri tenant nelle richieste. Propagare l'ID tenant all'origine dati in modo appropriato. Si supponga, ad esempio, di eseguire query su Ricerca di intelligenza artificiale di Azure. Se si dispone di dati per più tenant in un singolo indice, specificare un filtro per limitare i risultati recuperati all'ID del tenant corrente. In alternativa, se è stato creato un indice per ogni tenant, assicurarsi di specificare l'indice corretto per il tenant corrente.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Sofia Ferreira | Software Engineer, ISV & DN CoE
Altri contributori:
- John Downs | Principal Software Engineer
- Landon Pierce | Customer Engineer, ISV & DN CoE
- Paolo Salvatori | Principal Customer Engineer, ISV & DN CoE
- Daniel Scott-Raynsford | Progettista di soluzioni partner
- Arsen Vladimirintune | Principal Customer Engineer, ISV & DN CoE
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.