Modelli di multi-tenancy e Foundry

Foundry Models fornisce l'accesso ai modelli fondazionali e alle funzionalità di intelligenza artificiale agentic per la creazione di applicazioni basate sull'intelligenza artificiale. Questa guida descrive le principali funzionalità dei modelli Foundry che supportano applicazioni multi-tenant, inclusi molti tipi di soluzioni SaaS (Software as a Service). L'articolo illustra come pianificare un appropriato approccio di implementazione multi-tenant in base a isolamento, scalabilità e vincoli operativi.

Approcci all’isolamento

Per progettare un sistema multi-tenant che usa Foundry Models, è necessario innanzitutto determinare il livello di isolamento richiesto dai tenant. Le decisioni di isolamento influiscono direttamente sullo stato di sicurezza, sulla complessità operativa, sull'utilizzo delle quote e sull'efficienza dei costi. Nelle architetture basate su Microsoft Foundry, configurare l'isolamento usando i limiti della sottoscrizione Azure e del gruppo di risorse e strutturando le risorse, i progetti e le distribuzioni di modelli Foundry.

Molti casi d'uso considerano i modelli di intelligenza artificiale come componenti senza stato ed è possibile usare i modelli Foundry senza un livello di persistenza. La persistenza introduce complessità aggiuntive per le soluzioni multi-tenant, ad esempio la separazione dei dati di ogni tenant. Se si usano i modelli Foundry in modo senza stato, è possibile evitare alcune di queste complessità. Tuttavia, altri componenti della soluzione, ad esempio Foundry Agent Service, potrebbero introdurre uno stato che è necessario gestire.

Per Foundry Models, progettare l'approccio di isolamento in base ai fattori seguenti:

• Numero di tenant che prevedi di supportare. Se il numero di tenant è ridotto, le distribuzioni dedicate possono essere facili da gestire. Un numero elevato di tenant aumenta la complessità operativa delle soluzioni di implementazione dedicate.

• Conformità dei tenant o requisiti normativi. Requisiti di conformità rigorosi potrebbero richiedere un isolamento forte. Selezionare un tipo di distribuzione, il cui limite di elaborazione globale, zona dati o basato su area geografica soddisfa i requisiti di ogni tenant. Usare deployment di modello separati se i tenant richiedono confini di isolamento dell'elaborazione diversi.

  Una sottoscrizione dedicata o una risorsa Foundry da sola non vincola dove si verifica l'elaborazione dell'inferenza. Per tutti i tipi di distribuzione, i dati inattivi (a riposo) rimangono nell'area geografica di Azure designata.

• Requisiti dei tenant per modelli, versioni del modello o cicli di vita del modello specifici. Per semplificare i processi operativi, provare a limitare il numero di modelli in uso contemporaneamente. Tuttavia, potrebbe essere necessario distribuire più modelli se i tenant devono usare versioni di modello specifiche o modelli perfezionati specifici per tenant.

• Variazione tra tenant. Se i requisiti di scalabilità o velocità effettiva del carico di lavoro del tenant variano in modo significativo, potrebbe essere necessario raggruppare i tenant in set con caratteristiche simili.

Queste considerazioni sono particolarmente importanti per le piattaforme SaaS che servono centinaia o migliaia di clienti su infrastruttura condivisa.

Confronta gli approcci di isolamento

La tabella seguente riepiloga le caratteristiche di isolamento degli approcci comuni di distribuzione dei modelli Foundry per i sistemi SaaS multi-tenant.

Le sezioni seguenti descrivono questi approcci in modo più dettagliato.

Risorsa dedicata di Foundry per tenant (sottoscrizioni separate)

In questo approccio di isolamento, il provider di servizi assegna a ogni tenant una sottoscrizione Azure dedicata nel tenant Microsoft Entra del provider di servizi. Ogni sottoscrizione contiene una singola risorsa Microsoft Foundry per tale tenant, insieme a progetti e distribuzioni di modelli specifici del tenant.

Questo approccio offre l'isolamento più sicuro perché i confini amministrativi, le quote e il monitoraggio sono completamente separati tra i tenant. Riduce al minimo il rischio di interferenza tra tenant e semplifica la conformità per i clienti che richiedono una separazione rigorosa. Poiché molte quote di Azure si applicano all'ambito della sottoscrizione Azure, questo approccio garantisce che ogni tenant estrae dalle proprie quote.

Tuttavia, il sovraccarico operativo per questo approccio aumenta significativamente man mano che aumenta il numero di tenant. Ogni tenant richiede il provisioning di sottoscrizioni indipendenti, il provisioning delle risorse Foundry, la gestione delle quote, il monitoraggio e la gestione del ciclo di vita. La distribuzione può essere complessa, soprattutto se si usano pipeline di integrazione continua e consegna continua (CI/CD) anziché la distribuzione dinamica tramite un control plane personalizzato. Questo approccio è difficile da usare in modo efficiente su scala SaaS.

Le sottoscrizioni separate sono più appropriate per i tenant strettamente regolamentati che richiedono risorse isolate. A causa della complessità operativa, questo approccio funziona meglio con un numero ridotto di tenant di grandi dimensioni che richiedono esplicitamente un'infrastruttura dedicata e sono disposti ad accettare costi operativi e onboarding più elevati per ottenere un isolamento più forte.

Risorsa dedicata Foundry per tenant (sottoscrizione condivisa)

In questo approccio più tenant condividono una singola sottoscrizione Azure e ogni tenant ottiene una risorsa Microsoft Foundry dedicata all'interno di tale sottoscrizione.

Questo approccio riduce il numero di sottoscrizioni Azure mantenendo un isolamento logico sicuro a livello di risorsa Foundry e abilita sia l'isolamento a livello di autorizzazione che di rete per ogni risorsa Foundry.

Questo approccio di isolamento riduce significativamente il numero di sottoscrizioni che è necessario gestire, ma a seconda del modo in cui si applica la capacità Foundry, i tenant potrebbero ancora competere per quote condivise a livello di sottoscrizione. Anche l'allocazione e la governance dei costi sono complesse, perché è necessario ripartire l'utilizzo tra più risorse Foundry all'interno della stessa sottoscrizione.

I limiti delle risorse Foundry si applicano per ogni sottoscrizione e area geografica di Azure. Se potresti superare questi limiti, valutare la possibilità di distribuire tra più sottoscrizioni o aree usando il bin packing.

Questo approccio viene comunemente usato per le piattaforme SaaS che richiedono una forte separazione logica, ma non richiedono l'isolamento completo della sottoscrizione per ogni tenant.

Risorsa Foundry condivisa con un progetto e un deployment dedicati per tenant

In questo approccio di isolamento, molti tenant condividono una singola risorsa Foundry. Assegni a ogni tenant un progetto Foundry dedicato e una distribuzione del modello dedicata all'interno della risorsa condivisa. I progetti definiscono la configurazione, gli strumenti e le connessioni, mentre le distribuzioni consentono il controllo per tenant sulle versioni del modello, i criteri e la velocità effettiva.

Questo approccio riduce significativamente il sovraccarico della distribuzione delle risorse e consente la gestione centralizzata mantenendo una forte separazione logica. Tuttavia, tutti i tenant condividono in definitiva la stessa risorsa Foundry e la capacità sottostante.

Se si usa questo approccio, è necessario progettare routing, limitazione e monitoraggio sensibili ai tenant. Tutte le garanzie di isolamento sono una tua responsabilità e si basano principalmente sulla configurazione corretta e dalla rigorosa applicazione a livello applicativo. Non è possibile fornire l'isolamento a livello di rete usando questo approccio.

Project e i limiti di distribuzione del modello si applicano per ogni risorsa Foundry. Esaminare le quote e i limiti correnti di Foundry Models quando si calcola la densità del tenant e si distribuiscono i tenant tra risorse o sottoscrizioni Foundry aggiuntive prima di avvicinarsi a un limite.

Questo approccio offre un buon equilibrio per le distribuzioni SaaS di media scala se si usano rigorosamente l'automazione, la governance, le mitigazioni dei vicini rumorosi e gli approcci di isolamento dei tenant. Per le distribuzioni su larga scala, valutare la possibilità di distribuire tra più risorse Foundry o sottoscrizioni Azure usando il bin packing.

Risorsa Foundry condivisa con un deployment condiviso

Nell'approccio più centralizzato, tutti i tenant condividono una singola risorsa Foundry e un'unica distribuzione del modello.

Questo approccio riduce al minimo la complessità e i costi dell'infrastruttura, ma offre le garanzie di isolamento più deboli.

Tutte le richieste del tenant vengono instradate attraverso lo stesso endpoint di distribuzione e il livello applicativo deve applicare completamente qualsiasi isolamento. I requisiti di isolamento possono includere l'autorizzazione tenant-aware, l'ambito delle richieste, la separazione dei dati e la limitazione del tasso. Poiché tutti i tenant condividono la stessa pipeline di inferenza, questo approccio potrebbe non essere adatto per i carichi di lavoro che coinvolgono dati sensibili o requisiti di conformità rigorosi.

I deployment di modelli appartengono alla risorsa Foundry, non ai singoli progetti, e i progetti possono riutilizzare i deployment di tale risorsa. I tenant possono avere progetti Foundry dedicati, come illustrato nel diagramma precedente, oppure possono usare un singolo progetto condiviso se non devono distribuire asset di progetto specifici del tenant in Foundry.

Questo approccio è adatto alle applicazioni SaaS business-to-business (B2B) e business-to-consumer (B2C) in cui i tenant condividono la stessa distribuzione del modello, la configurazione della distribuzione e i requisiti di conformità e l'applicazione applica l'isolamento del tenant. Si adatta anche agli strumenti interni, alle soluzioni proof-of-concept e alle applicazioni i cui utenti condividono un confine di attendibilità organizzativo. Usare un approccio più isolato quando i tenant richiedono versioni separate del modello, guardrail, throughput, limiti di rete, residenza dei dati o controlli di conformità.

Risorsa Foundry fornita dal tenant

In questo approccio, ogni tenant fornisce la propria risorsa Foundry e il proprio ambiente Azure. Il tenant effettua il provisioning e gestisce direttamente la risorsa. Il provider di servizi può anche distribuire la risorsa dopo aver ottenuto l'accesso alla sottoscrizione del tenant.

Si consideri questo approccio quando si applica una delle situazioni seguenti:

• I tenant richiedono accesso a modelli specifici, allocazioni di quote, configurazioni di guardrail o throughput con provisioning che devono rimanere sotto il proprio controllo.
• I tenant devono usare modelli ottimizzati ospitati nei propri ambienti.
• I tenant richiedono che i dati rimangano all'interno del proprio ambiente, consentendo comunque all'applicazione del provider di richiamare le distribuzioni del modello Foundry del tenant o altri componenti Foundry.

Questo approccio offre un forte isolamento dei dati e delle prestazioni, perché ogni tenant usa la propria risorsa Foundry e la quota assegnata. Tuttavia, crea anche un accordo operativo condiviso tra il provider e il tenant. Per evitare lacune nelle responsabilità, entrambe le parti devono definire chiaramente le responsabilità per il provisioning, il monitoraggio, il supporto, la sicurezza e la gestione dei costi.

Il provider di servizi deve inoltre progettare l'applicazione per accedere alla risorsa Foundry nell'ambiente del tenant. Un'opzione consiste nel pubblicare un'applicazione Microsoft Entra multi-tenant. Un'altra opzione consiste nel creare un service principal che il provider può usare.

Quest'ultimo approccio aumenta il carico di gestione delle credenziali del provider. Se si usano credenziali specifiche del tenant, assicurarsi di implementare in modo sicuro l'archiviazione, la rotazione e la revoca delle credenziali.

Verificare l'isolamento del tenant

Indipendentemente dall'approccio di isolamento selezionato, verifica il confine di isolamento con test che non dipendono dal comportamento del modello. Ad esempio, verificare gli scenari seguenti usando una combinazione di valutazioni del modello e test deterministici.

Se un test tra tenant viene superato solo perché il modello ha rifiutato di rispondere, consideralo un fallimento, perché i dati dell'altro tenant hanno già raggiunto il modello. Poiché il comportamento del modello non è deterministico, eseguire questi test ripetutamente e includerli nel processo di rilascio.

Funzionalità dei modelli Foundry che supportano la multi-tenancy

È importante pianificare l'isolamento del tenant quando si usano funzionalità specifiche di Foundry Models.

API delle Risposte

Azure OpenAI Responses API all'interno di Foundry Models unifica diversi aspetti separati dietro una singola interfaccia. Questi problemi includono la cronologia delle conversazioni, la chiamata allo strumento, la ricerca di file, gli output strutturati e le attività in background a esecuzione prolungata. L'API Responses supporta operazioni archiviate e senza stato. L'API conserva i dati di risposta archiviati per un periodo definito ed è anche possibile eliminare i dati in modo esplicito.

Ogni chiamata restituisce un identificatore di risposta e si concatenano i turni passando tale identificatore di risposta alla richiesta successiva o allegando risposte a un oggetto conversazione con stato gestito dal servizio per conto dell'utente. Poiché lo stato si trova nel servizio anziché nell'applicazione, si ottiene la continuità tra turni, ma si ereditano anche gli obblighi di multi-tenancy che derivano da archiviazione con stato condiviso.

Quando si usa la Responses API in una soluzione multi-tenant, l'applicazione è responsabile dell'isolamento del tenant. Il servizio non partiziona lo stato archiviato per tenant per conto tuo, quindi è necessario definire l'ambito e convalidare ogni riferimento a risposte e conversazioni archiviate. Per i tenant che operano su larga scala o che hanno requisiti rigorosi di isolamento o residenza dei dati, spostare lo stato della conversazione in un archivio dati esterno controllato anziché basarsi sullo stato gestito dal servizio.

Copiare lo stato nel proprio archivio non impedisce al servizio di conservarne una copia, quindi disabilitare l'archiviazione dello stato in queste richieste e passare la cronologia delle conversazioni dal proprio archivio a ogni turno. La modalità in background richiede l'archiviazione con stato, quindi non è possibile usarla con questo approccio. Per i carichi di lavoro multi-tenant con stato che richiedono controlli di isolamento più avanzati, valutare il Foundry Agent Service.

Se si usa Responses API nei modelli Foundry all'interno di una soluzione multi-tenant, applicare le procedure consigliate seguenti:

• Archiviare le risposte e gli ID di conversazione con chiavi con ambito tenant nel proprio database e verificare rigorosamente che una richiesta dal tenant A non possa mai fare riferimento a un ID creato per il tenant B.

• Assicurarsi che le chiamate di funzione dall'applicazione includano l'ID tenant. Convalida l'ID tenant lato server. Non fare affidamento sul modello per propagarlo.

• Code Interpreter viene eseguito in un'infrastruttura gestita da Microsoft, quindi, dove l'isolamento è importante, usare contenitori Code Interpreter dedicati per ogni tenant.

• Le chiamate MCP (Remote Model Context Protocol) si collegano al server MCP remoto configurato, quindi, dove l'isolamento è importante, usare configurazioni degli strumenti MCP remoti dedicate per ogni tenant.

• Limitare gli strumenti di recupero a un singolo tenant per archivio vettoriale, oppure applicare un filtro tenant verificato a ogni query di archivio condiviso.

Servizio agente Foundry

Foundry Agent Service è affiancato a Foundry Models per la creazione di carichi di lavoro agentici con stato. Aggiunge un livello di persistenza per agenti, conversazioni e risposte e supporta funzionalità come routine e flussi di lavoro autonomi a esecuzione prolungata. Queste caratteristiche con stato e a esecuzione prolungata aggiungono complessità alla multitenancy al di là della semplice inferenza di modelli senza stato.

Per gli agenti ospitati, il servizio Agent isola le conversazioni, le sessioni e i dati archiviati in base all'identità Microsoft Entra del chiamante. Se l'applicazione autentica i propri utenti, un livello intermedio attendibile può passare un identificatore utente stabile, derivato dal server e con ambito tenant. Il servizio associa le sessioni a questa identità delegata, ma l'applicazione è interamente responsabile della gestione della separazione degli utenti.

Mantenere gli identificatori di sessione limitati al tenant e all'utente corretti e applicare l'autorizzazione basata sul tenant per gli strumenti, gli archivi dati e le azioni dell'agente. Per altre informazioni, vedere Isolare le sessioni dell'agente ospitato per utente.

Gli agenti ospitati hanno una copertura limitata delle chiavi gestite dal cliente (CMK) per le chiavi di crittografia. Prima di usare agenti ospitati per i tenant che richiedono chiavi di crittografia controllate dal cliente, esaminare la copertura CMK corrente per Microsoft Foundry.

Gateway di intelligenza artificiale in Gestione API di Azure

Un gateway di intelligenza artificiale è un intermediario tra l'applicazione e gli endpoint dei modelli foundry. In una soluzione multi-tenant, può centralizzare le problematiche trasversali, ad esempio l'autenticazione, la limitazione della frequenza, il routing, la memorizzazione nella cache e l'osservabilità. Il traffico di ogni tenant viene regolato in modo coerente prima che raggiunga una distribuzione di un modello. Il gateway è un luogo naturale per applicare limiti per tenant, attribuire l'utilizzo e i costi a ciascun tenant e impedire a qualsiasi tenant di consumare capacità necessaria ad altri tenant.

Gestione API di Azure offre funzionalità del gateway di intelligenza artificiale tramite il sistema di criteri in ingresso e in uscita, inclusi i criteri compatibili con i modelli linguistici di grandi dimensioni (LLM), il controllo dei token, la memorizzazione nella cache semantica e il routing back-end. Questi criteri vengono usati per trasformare un endpoint condiviso dei modelli Foundry in un'interfaccia API gestita, a consumo e consapevole del tenant.

Quando si progetta una distribuzione di Gestione API multi-tenant con i modelli Foundry, la considerazione più importante consiste nell'identificare il tenant. Usare l'identificatore del tenant in modo coerente in tutti i criteri per definire l'ambito di ogni limite, metrica e voce della cache in un singolo tenant. Deriva l'identificatore del tenant da un'origine attendibile, ad esempio:

• Un claim JWT (JSON Web Token) convalidato.
• ID sottoscrizione di Gestione API, se ogni sottoscrizione corrisponde a un singolo tenant. Non usare il valore della chiave di sottoscrizione, perché è una credenziale segreta che cambia quando si ruotano le chiavi.

Non accettare un identificatore del tenant che il client fornisce direttamente.

Applicare l'identificatore del tenant nei criteri seguenti:

• Limite di token: Usare l'identificatore del tenant come counter-key nel criterio llm-token-limit per applicare limiti di token al minuto per tenant e quote di token. Il criterio può precalcolare i token del prompt nel gateway e rifiutare le richieste che superano il limite di un tenant prima di raggiungere il back-end. Questo approccio riduce il noisy neighbor problem.

  I contatori dei token non vengono aggregati a livello dell'intera istanza. Ogni gateway, area o area di lavoro tiene traccia dell'utilizzo in modo indipendente. Se è necessario un limite coerente di richieste per tenant o di larghezza di banda tra aree in un'istanza di Gestione API, usare i criteri quota o quota-by-key. Per limiti di token coerenti a livello globale, applicare il limite a un singolo gateway upstream che riceve tutto il traffico o instradare ogni tenant a un singolo gateway o regione designata.

• Metriche dei token: Aggiungere l'identificatore del tenant come dimensione personalizzata nel criterio llm-emit-token-metric, ma assicurarsi che il popolamento del tenant rientri nei limiti delle metriche personalizzate. La norma ignora silenziosamente i valori delle dimensioni e le serie temporali che superano il limite.

  Usare le metriche dei token per lo showback approssimativo dei costi solo quando si dispone di un numero ridotto di tenant di cui tenere traccia. Per un numero elevato di tenant, aggregare i log dell'API LLM in base all'ID sottoscrizione di API Management quando le sottoscrizioni sono associate ai tenant. In caso contrario, inviare l'utilizzo dei token e l'identificatore del tenant convalidato a un'altra pipeline di misurazione durevole.

• Cache semantica: Usare l'identificatore del tenant come vary-by valore nel criterio llm-semantic-cache-lookup, in modo che una risposta memorizzata nella cache generata per un tenant non venga servita a un altro tenant. Usare valori aggiuntivi vary-by per il modello, il prompt, lo strumento e le versioni dei criteri di sicurezza pertinenti e impostare la durata della cache in base alla velocità con cui cambiano le informazioni sottostanti. Poiché la memorizzazione nella cache semantica corrisponde in base alla somiglianza, può restituire risposte non corrette, obsolete o non sicure per la richiesta corrente. Non usarlo per interazioni altamente personalizzate, regolamentate, critiche per la sicurezza o sensibili al tempo o per interazioni che dipendono da effetti collaterali degli strumenti o delle transazioni.

  Caution

  La mancata partizione della cache in modo appropriato è un errore comune nella progettazione del gateway di intelligenza artificiale multi-tenant.

• Routing back-end: Usare l'identificatore del tenant nei criteri di routing per selezionare pool back-end che usano il bilanciamento del carico basato su priorità o peso e gli interruttori automatici per ogni back-end. Ad esempio, instradare i tenant premium alle distribuzioni con provisioning che usano unità di throughput con provisioning (PTU), instradare altri tenant alle distribuzioni con pagamento in base al consumo e instradare i tenant con requisiti di posizione di elaborazione dati a distribuzioni specifiche della zona dati o basate su area geografica.

• Sicurezza dei contenuti: Usare il criterio llm-content-safety per applicare soglie di danno appropriate al tenant e elenchi di blocchi. Abilitare l'attributo shield-prompt per controllare gli input dell'utente per gli attacchi al prompt e convalidare gli output del modello usando l'attributo enforce-on-completions o un criterio in uscita.

• Controllo: Se i tenant lo consentono, registrare prompt e completamenti in Monitoraggio di Azure e includere l'identificatore del tenant in modo che sia possibile produrre feed di controllo per tenant. I prompt e i completamenti contengono dati sensibili, quindi è preferibile usare i metadati del token e della richiesta per i feed di controllo di routine per tenant.

Il gateway regola il traffico al perimetro. Non isola i dati del tenant all'interno delle risorse foundry. Le distribuzioni per tenant, i progetti, gli indici e la costruzione del prompt rimangono parte del limite di isolamento, come descritto negli approcci di isolamento precedenti. Per altre informazioni, vedere Funzionalità del gateway di intelligenza artificiale in Gestione API di Azure e Architettura di riferimento per la chat Microsoft Foundry.

Contributors

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

Autori principali:

• Rodanthi Alexiou | Architetto delle soluzioni Partner
• Kiko de Angel Gimeno | Senior Partner Solution Architect
• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Jing Liu | Responsabile strategie tecnologiche per i partner
• Ellie Nosrat | Architetto Principale di Soluzioni per Partner

Altri contributori:

• Daphne Choong | Architetto senior di soluzioni per i partner, Soluzioni per partner enterprise
• Mamoru Kuroda | Progettista di soluzioni partner
• Kodai Sakabe | Architetto di soluzioni per i partner, Soluzioni per partner aziendali
• Daniel Scott-Raynsford | Partner Solution Architect, Data & AI

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

Passaggi successivi

• Documentazione di Foundry Models

Risorse correlate

• Approcci architetturali per intelligenza artificiale e Machine Learning in soluzioni multi-tenant