Multitenancy och Azure OpenAI Service
Med Azure OpenAI får du åtkomst till OpenAI:s kraftfulla språkmodeller. Den här artikeln beskriver viktiga funktioner i Azure OpenAI som är bra för lösningar med flera klientorganisationer. Granska de rekommenderade resurserna som hjälper dig att planera din metod och använda Azure OpenAI.
Isoleringsmodeller
När du har ett system med flera klienter som använder Azure OpenAI-tjänsten måste du bestämma vilken isoleringsnivå som dina klienter behöver. Du bör fastställa din isoleringsmodell baserat på följande faktorer:
- Hur många klienter planerar du att ha?
- Har dina klienter efterlevnadskrav som kräver nätverks- eller infrastrukturisolering?
- Kräver dina klienter modeller som är finjusterade på sina egna data?
- Kräver dina klienter olika modellversioner eller modelllivscykler?
I följande tabell sammanfattas de distributionsmetoder som du kan använda när du använder Azure OpenAI Service i ett system med flera klientorganisationer:
| Att tänka på | Dedikerad Azure OpenAI-tjänst | Delad Azure OpenAI-tjänst, dedikerad modelldistribution per klientorganisation | Delad Azure OpenAI-tjänst, distribution av delad modell | Azure OpenAI-tjänst som tillhandahålls av klientorganisationen |
|---|---|---|---|---|
| Dataisolering | Högt | Medel | Låg | Hög |
| Prestandaisolering | Högt | Högt | Låg-medel, beroende på token per minut (TPM) användning för varje klientorganisation. | Högt |
| Distributionskomplexitet | Låg medelhög, beroende på antalet klienter. | Medel, behöver hantera distributionsnamn och kvoter. | Låg | Ej tillämpligt, hanteras av kunden. |
| Driftkomplexitet | Låg | Medium | Högt | Låg för providern, högre för klientorganisationen. |
| Exempelscenario | Distributioner av en enskild klientorganisation som kräver nätverksisolering från andra klienter. | Klienter med specifik modelllivscykel eller finjusteringskrav. | Stora lösningar för flera klientorganisationer med delad programnivå. | Klienter med specifika krav på efterlevnad eller finjustering. |
Dedikerad Azure OpenAI-tjänst
Om du är en tjänstleverantör kan du överväga att distribuera en Azure OpenAI-instans för varje klientorganisation i din Azure-prenumeration. Den här metoden tillhandahåller dataisolering för varje klientorganisation. Det kräver att du distribuerar och hanterar ett ökande antal Azure OpenAI-resurser när du ökar antalet klienter.
Använd den här metoden om du har separata programdistributioner för varje klientorganisation, eller om du behöver kringgå begränsningar, till exempel kvoten eller begäran per minut. Mer information finns i Azure OpenAI-kvoter och -gränser.
Följande diagram illustrerar modellen för Azure OpenAI för varje klientorganisation i providerns prenumeration.
Delad Azure OpenAI-tjänst
Du kan välja att dela en instans av Azure OpenAI mellan flera klienter. Azure OpenAI-resursen distribueras i din (tjänstleverantörens) Azure-prenumeration. Du ansvarar för att hantera det. Den här lösningen är den enklaste att implementera, men den ger minst dataisolering och prestandaisolering.
Att dela en Azure OpenAI-resurs ger inte säkerhetssegmentering för varje modelldistribution. En klient kan kanske använda en modell som de inte har behörighet att använda. Undvik därför att dela en Azure OpenAI-instans när du använder finjusterade modeller, eftersom du kan exponera känslig information och tillåta obehörig åtkomst till klientspecifika data eller resurser.
Att dela en instans av Azure OpenAI mellan flera klienter kan också leda till ett problem med en bullrig granne . Det kan orsaka högre svarstid för vissa klienter. Du måste också göra programkoden multitenancy-medveten. Om du till exempel vill debitera dina kunder för förbrukningskostnaden för en delad Azure OpenAI-instans implementerar du logiken för att hålla reda på det totala antalet token för varje klientorganisation i ditt program.
Du kan också distribuera flera delade Azure OpenAI-instanser. Om du till exempel följer mönstret Distributionsstämplar distribuerar du en delad Azure OpenAI-instans i varje stämpel. Om du distribuerar en lösning för flera regioner bör du distribuera Azure OpenAI i varje region för att:
- Undvik trafikfördröjning mellan regioner.
- Stöd för krav på datahemvist.
- Aktivera användningen av regionala Azure OpenAI inom andra tjänster som kräver distributioner i samma region.
När du har en delad Azure OpenAI-instans är det viktigt att överväga dess gränser och hantera din kvot.
Följande diagram illustrerar den delade Azure OpenAI-modellen.
När du distribuerar en delad Azure OpenAI-tjänst kan du bestämma om modelldistributionerna i tjänsten också delas eller om de är dedikerade till specifika kunder.
Distribution av delad modell mellan klientorganisationer
Att dela en modelldistribution mellan klienter förenklar driftbelastningen eftersom du har färre distributioner att hantera och modellversioner att spåra. Planera att använda en distribution av delad modell om du kan och skapa endast dedikerade modelldistributioner om du behöver de funktioner som de erbjuder.
Dedikerad modelldistribution per klientorganisation
Du kan skapa en modelldistribution för varje klientorganisation eller för klienter som har särskilda krav som inte kan uppfyllas med hjälp av en distribution av en delad modell. Vanliga orsaker till att använda dedikerade modelldistributioner för en klientorganisation är följande:
Kvot- och kostnadshantering: Det underlättar klientspecifik TPM-allokering genom att spåra antalet token som varje modell använder, vilket gör att du exakt kan kostnadsallokera och hantera varje klientorganisations användning. Om du använder etablerade dataflödesenheter (PTUs) kan du tilldela PTUs till specifika kunder och använda andra faktureringsmodeller för andra kunder.
Principer för innehållsfiltrering: Ibland kan en specifik klientorganisation kräva en unik innehållsfiltreringsprincip, till exempel en klientspecifik blocklista med otillåtna ord. Du anger innehållsfiltreringsprincipen i omfånget för en modelldistribution.
Modelltyper och versioner: Du kan behöva använda olika modeller eller modellversioner för olika klientorganisationer. En klientorganisation kan också kräva en egen livscykelhanteringsprocess för modellen.
Klientspecifik finjustering: Om du skapar distinkta finjusterade modeller för varje klientorganisation måste du skapa en separat modelldistribution för varje finjusterad modell.
Kom ihåg att finjustering inte krävs för de flesta användningsfall. Vanligtvis är det bättre att jorda din modell med hjälp av Azure OpenAI På dina data eller en annan rag-metod (hämtningsförhöjd generation).
Datahemvist: Den här metoden stöder distinkta krav på datahemvist. Du kan till exempel tillhandahålla en regional modelldistribution för en klientorganisation med strikta datahemvistbehov och använda en global modelldistribution för andra klienter utan strikta behov.
Varje modelldistribution har en egen distinkt URL, men det är viktigt att komma ihåg att de underliggande modellerna delas med andra Azure-kunder. De använder också delad Azure-infrastruktur.
Azure OpenAI tillämpar inte åtkomstkontroll för varje modelldistribution, så ditt program måste styra vilken klientorganisation som kan nå vilken modelldistribution.
Azure OpenAI-resurs som tillhandahålls av klientorganisationen
I vissa situationer kan dina klienter skapa Azure OpenAI-instansen i sina egna Azure-prenumerationer och ge programmet åtkomst till den. Den här metoden kan vara lämplig i följande situationer:
- Klientorganisationer har specifika kvoter och behörigheter från Microsoft, till exempel åtkomst till olika modeller, specifika principer för innehållsfiltrering eller användning av etablerat dataflöde.
- Klientorganisationen har en finjusterad modell som de behöver använda från din lösning.
- De behöver en komponent i sin miljö för att bearbeta och skicka data via sin kundhanterade Azure OpenAI-instans för bearbetning.
För att få åtkomst till en Azure OpenAI-instans i klientorganisationens prenumeration måste klientorganisationen ge ditt program åtkomst. Programmet måste autentiseras via sin Microsoft Entra-instans. En metod är att publicera ett Microsoft Entra-program med flera klientorganisationer. Följande arbetsflöde beskriver stegen i den här metoden:
- Klientorganisationen registrerar Microsoft Entra-programmet för flera klienter i sin egen Microsoft Entra-klientorganisation.
- Klientorganisationen ger microsoft Entra-programmet för flera klienter rätt åtkomstnivå till deras Azure OpenAI-resurs. Klientorganisationen kan till exempel tilldela programmet till Användarrollen för Azure AI-tjänster med hjälp av rollbaserad åtkomstkontroll (RBAC).
- Klientorganisationen tillhandahåller resurs-ID:t för den Azure OpenAI-resurs som de skapar.
- Programkoden kan använda ett huvudnamn för tjänsten som är associerat med microsoft Entra-programmet för flera klienter i din egen Microsoft Entra-instans för att få åtkomst till klientorganisationens Azure OpenAI-instans.
Alternativt kan du be varje klientorganisation att skapa ett huvudnamn för tjänsten som tjänsten ska använda och att ge dig dess autentiseringsuppgifter. Den här metoden kräver att du lagrar och hanterar autentiseringsuppgifter på ett säkert sätt för varje klientorganisation, vilket är ett potentiellt säkerhetsansvar.
Om dina klienter konfigurerar nätverksåtkomstkontroller på sin Azure OpenAI-instans kontrollerar du att du kan komma åt dem.
Följande diagram illustrerar modellen för Azure OpenAI för varje klientorganisation i klientorganisationens prenumeration.
Funktioner i Azure OpenAI Service som stöder flera klientorganisationer
API för assistenter
Assistent-API:et lägger till funktioner i din Azure OpenAI-tjänst som gör den lämplig för att skapa AI-assistenter. Den innehåller möjligheten att anropa verktyg och API:er samt sökfiler för att grunda de svar som modellen genererar. Det gör att beständiga konversationstrådar kan hanteras av tjänsten och kan generera och köra kod i en sandbox-miljö. För att stödja dessa funktioner måste assistent-API:et lagra vissa data.
När du använder API:et Assistenter i en lösning med flera klienter kan du välja att skapa assistenter som är dedikerade till en enda klientorganisation, eller så kan du dela en assistent mellan flera klienter. Det är viktigt att du överväger klientisolering i alla data som lagras, särskilt för delade assistenter. Du bör till exempel se till att konversationstrådar lagras separat för varje klientorganisation.
Api:et Assistants stöder funktionsanrop, som skickar programinstruktioner för funktioner som ska anropas och argument som ska inkluderas. Se till att alla funktioner som du gör är multitenantmedvetna, till exempel genom att inkludera klientorganisations-ID:t i anropet till det underordnade systemet. Verifiera klientorganisations-ID:t i ditt program och använd inte språkmodellen för att sprida klientorganisations-ID:t åt dig.
Azure OpenAI på dina data
Med Azure OpenAI On Your Data kan den stora språkmodellen fråga kunskapskällor direkt, till exempel index och databaser, som en del av genereringen av ett svar från språkmodellen.
När du gör en begäran kan du ange de datakällor som ska efterfrågas. I en lösning med flera klienter kontrollerar du att dina datakällor är multitenancy-medvetna och att du kan ange klientfilter för dina begäranden. Sprid klientorganisations-ID:t till datakällan på rätt sätt. Anta till exempel att du kör frågor mot Azure AI Search. Om du har data för flera klienter i ett enda index anger du ett filter för att begränsa det hämtade resultatet till den aktuella klientorganisationens ID. Om du har skapat ett index för varje klientorganisation kontrollerar du att du anger rätt index för den aktuella klientorganisationen.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Sofia Ferreira | Programvarutekniker, ISV och DN Coe
Övriga medarbetare:
- John Downs | Huvudprogramtekniker
- Landon Pierce | Kundtekniker, ISV och DN CoE
- Paolo Salvatori | Huvudkundtekniker, ISV och DN CoE
- Daniel Scott-Raynsford | Partnerlösningsarkitekt
- Arsen Vladimirskiy | Huvudkundtekniker, ISV och DN CoE
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.