Multitenancy e servizio di Azure OpenAI

Il servizio OpenAI di Azure 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 Azure OpenAI, è necessario determinare il livello di isolamento richiesto dai tenant. È consigliabile progettare il modello di isolamento in base ai fattori seguenti:

• Numero di tenant che si prevede di avere
• Se i loro inquilini hanno requisiti di conformità che richiedono l'isolamento della rete o dell'infrastruttura
• Indica se i tenant richiedono modelli ottimizzati usando i propri dati
• Indica se i tenant richiedono versioni del modello o cicli di vita del modello diversi

La tabella seguente riepiloga gli approcci di distribuzione che è possibile adottare quando si usa Azure OpenAI in un sistema multi-tenant:

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. È necessario distribuire e gestire 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 vostra sottoscrizione di Azure (del provider di servizi). Sei 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. È possibile esporre informazioni riservate e consentire l'accesso non autorizzato a dati o risorse specifici del tenant.

La condivisione di un'istanza di Azure OpenAI tra più tenant può causare anche un problema di vicino rumoroso. Può causare una latenza più elevata per alcuni clienti. È anche necessario rendere il codice dell'applicazione consapevole della multitenancy. 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 lo schema Deployment Stamps, distribuire un'istanza di Azure OpenAI condivisa in ciascun gruppo. Se si distribuisce una soluzione in più aree, è 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 Azure OpenAI condiviso, è possibile decidere se le distribuzioni del modello all'interno del servizio sono condivise o dedicate a clienti specifici.

Distribuzione di modelli condivisi tra utenti

La condivisione di una distribuzione di modelli tra i tenant semplifica il carico operativo perché sono disponibili meno distribuzioni per gestire e ridurre il numero di versioni del modello 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à fornite.

Implementazione di modelli dedicati per ogni cliente

È possibile creare una distribuzione del modello per ogni tenant o per i tenant con requisiti speciali che non è possibile soddisfare usando una distribuzione del modello condiviso. I motivi comuni per usare distribuzioni di modelli dedicati per un tenant includono:

• Gestione delle quote e dei costi. Le distribuzioni di modelli dedicati facilitano l'allocazione TPM specifica del tenant monitorando il numero di token usati da ogni modello. È possibile usare questo numero per allocare con precisione i costi e gestire l'utilizzo di ogni tenant. Se si utilizzano unità di throughput fornite (PTU), è possibile assegnare i PTU a clienti specifici e usare altri modelli di fatturazione per altri clienti.

• Criteri di filtro del contenuto. In alcuni casi, 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 di modelli diversi per inquilini diversi. Un tenant potrebbe anche richiedere il proprio processo di gestione del ciclo di vita del modello.

• Messa a punto specifica per l'inquilino. Se si creano modelli distinti ottimizzati per ogni tenant, è necessario creare una distribuzione di modelli separata per ogni modello ottimizzato.

  Tenere presente che l'ottimizzazione non è necessaria per la maggior parte dei casi d'uso. In genere, è preferibile basare il modello utilizzando Azure OpenAI sui tuoi dati o un altro approccio di generazione aumentata dal recupero (RAG).

• Residenza dei dati. Questo approccio supporta distinti requisiti di residenza dei dati. 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.

Ogni distribuzione del modello ha un URL univoco, ma è importante ricordare che i modelli sottostanti vengono condivisi con altri clienti di Azure. I modelli condividono anche l'infrastruttura 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 alcuni scenari, 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 negli scenari seguenti:

• I tenant hanno quote e autorizzazioni specifiche da Microsoft, inclusi l'accesso a modelli diversi, i criteri di filtro dei contenuti definiti e l'utilizzo della velocità di trasmissione fornita.

• Gli inquilini hanno un modello ottimizzato che devono utilizzare dalla tua soluzione.

• I tenant 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 questo approccio:

1. Il tenant registra l'applicazione Microsoft Entra multi-tenant nel proprio tenant Microsoft Entra.

2. 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.

3. Il tenant fornisce l'ID della risorsa Azure OpenAI che crea.

4. 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 principale del servizio per il tuo servizio e di fornirtene le credenziali. Questo approccio richiede di archiviare e gestire in modo sicuro le credenziali per ogni tenant, che rappresenta una potenziale responsabilità di sicurezza.

Se i tuoi inquilini configurano i controlli di accesso alla rete nell'istanza di Azure OpenAI, assicurati di potervi accedere.

Il diagramma seguente illustra il modello per Azure OpenAI per ogni tenant nella sottoscrizione del tenant.

Funzionalità di Azure OpenAI che supportano la multi-tenancy

Azure OpenAI offre le funzionalità seguenti che supportano la multi-tenancy.

API degli 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 e di cercare i file per individuare le risposte generate dal modello. Consente al servizio di gestire thread conversazionali persistenti. L'API può anche 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, in particolare 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 sugli argomenti da includere. Assicurarsi che tutte le chiamate di funzione effettuate supportino il multitenancy. Un approccio consiste nell'includere l'ID tenant nella chiamata al sistema downstream. Verificare l'ID del tenant all'interno dell'applicazione e non affidarsi al modello di linguaggio per propagare l'ID del tenant.

Azure OpenAI sui tuoi dati

La funzionalità 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 del tenant all'origine dati correttamente. Si supponga, ad esempio, di eseguire una query in Ricerca 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 si crea un indice per ogni tenant, assicurarsi di specificare l'indice corretto per il tenant corrente.

Distribuzioni batch

È possibile distribuire alcuni modelli in Azure OpenAI usando una distribuzione batch. Le distribuzioni batch consentono l'elaborazione asincrona delle richieste raggruppate usando una quota batch separata. Le richieste inviate a una distribuzione batch hanno un tempo di risposta previsto di 24 ore e un costo inferiore alle distribuzioni standard. A differenza delle distribuzioni standard, le quote batch limitano il numero di token accodati anziché il TPM.

Questo tipo di distribuzione è ideale per gli scenari in cui le risposte immediate non sono necessarie e l'elaborazione di grandi volumi di richieste non può interrompere le risposte in tempo reale.

Ad esempio, un sistema che analizza il sentiment dei commenti degli utenti può usare una distribuzione batch per evitare di limitare la quota di distribuzione standard necessaria per eseguire interazioni in tempo reale in altre applicazioni. Questo approccio riduce anche i costi di elaborazione.

In una soluzione multi-tenant, le distribuzioni batch possono essere condivise tra tutti i tenant o create separatamente per ogni tenant.

• Distribuzioni batch separate per ciascun tenant:

  Assegnando quote di token a ogni distribuzione batch specifica del tenant, si impedisce a qualsiasi tenant di monopolizzare le risorse. Questo approccio consente anche di tenere traccia dell'utilizzo dei token per tenant, utile per l'allocazione dei costi.

• Distribuzione in lotto condivisa:

  Una distribuzione batch condivisa può elaborare le richieste da più locatari in processi batch combinati o separati. Se si combinano le richieste da più tenant in un singolo processo batch, assicurarsi di poter eseguire correttamente il mapping delle risposte al tenant appropriato.

  I lavori batch vengono gestiti a livello di lavoro, quindi è consigliabile separarli in base al locatario. Questo approccio consente di annullare o eliminare le attività per ogni inquilino. Le singole richieste all'interno di un batch non possono essere annullate o eliminate.

Gestendo attentamente le distribuzioni batch, è possibile bilanciare l'efficienza dei costi e l'allocazione delle risorse mantenendo al tempo stesso l'isolamento del tenant e la flessibilità operativa.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

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 | Ingegnere Principale per la Clientela, ISV & DN CoE
• Daniel Scott-Raynsford | Progettista di soluzioni partner
• Arsen Vladimirskiy | Principal Customer Engineer, ISV & DN CoE

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Risorse correlate

• Approcci architetturali per la distribuzione e la configurazione di soluzioni multi-tenant
• Approcci architetturali per la gestione e l'allocazione dei costi in una soluzione multi-tenant
• Elenco di controllo per la progettazione e la creazione di soluzioni multi-tenant in Azure