Multitenancy en Azure OpenAI-service
Azure OpenAI biedt u toegang tot de krachtige taalmodellen van OpenAI . In dit artikel worden de belangrijkste functies van Azure OpenAI beschreven die nuttig zijn voor multitenant-oplossingen. Bekijk de aanbevolen resources om u te helpen bij het plannen van uw aanpak en het gebruik van Azure OpenAI.
Isolatiemodellen
Wanneer u een multitenant-systeem hebt dat gebruikmaakt van de Azure OpenAI-service, moet u bepalen welk isolatieniveau uw tenants nodig hebben. U moet uw isolatiemodel bepalen op basis van de volgende factoren:
- Hoeveel tenants wilt u hebben?
- Hebben uw tenants nalevingsvereisten waarvoor netwerk- of infrastructuurisolatie is vereist?
- Vereisen uw tenants modellen die zijn afgestemd op hun eigen gegevens?
- Vereisen uw tenants verschillende modelversies of modellevenscycli?
De volgende tabel bevat een overzicht van de implementatiemethoden die u kunt gebruiken bij het gebruik van Azure OpenAI Service in een systeem met meerdere tenants:
| Overweging | Toegewezen Azure OpenAI-service | Gedeelde Azure OpenAI-service, toegewezen modelimplementatie per tenant | Gedeelde Azure OpenAI-service, implementatie van gedeeld model | Door de tenant geleverde Azure OpenAI-service |
|---|---|---|---|---|
| Gegevensisolatie | Hoog | Gemiddeld | Beperkt | Hoog |
| Isolatie van prestaties | Hoog | Hoog | Laag/gemiddeld, afhankelijk van het gebruik van het token per minuut (TPM) voor elke tenant. | Hoog |
| Implementatiecomplexiteit | Laag/gemiddeld, afhankelijk van het aantal tenants. | Gemiddeld moet u implementatienamen en quota beheren. | Beperkt | Niet van toepassing, beheerd door de klant. |
| Operationele complexiteit | Beperkt | Gemiddeld | Hoog | Laag voor de provider, hoger voor de tenant. |
| Voorbeeldscenario | Implementaties van één tenant die netwerkisolatie van andere tenants vereisen. | Tenants met specifieke modellevenscyclus of vereisten voor afstemming. | Grote multitenant-oplossingen met een gedeelde toepassingslaag. | Tenants met specifieke nalevings- of afstemmingsvereisten. |
Toegewezen Azure OpenAI-service
Als u een serviceprovider bent, kunt u overwegen om een Azure OpenAI-exemplaar te implementeren voor elke tenant in uw Azure-abonnement. Deze benadering biedt gegevensisolatie voor elke tenant. Hiervoor moet u een toenemend aantal Azure OpenAI-resources implementeren en beheren wanneer u het aantal tenants verhoogt.
Gebruik deze methode als u afzonderlijke toepassingsimplementaties voor elke tenant hebt of als u beperkingen moet omzeilen, zoals het quotum of de aanvraag per minuut. Zie Azure OpenAI-quota en -limieten voor meer informatie.
In het volgende diagram ziet u het model voor Azure OpenAI voor elke tenant in het abonnement van de provider.
Gedeelde Azure OpenAI-service
U kunt ervoor kiezen om een exemplaar van Azure OpenAI te delen tussen meerdere tenants. De Azure OpenAI-resource wordt geïmplementeerd in uw Azure-abonnement (de serviceprovider). U bent verantwoordelijk voor het beheren ervan. Deze oplossing is het eenvoudigst te implementeren, maar biedt de minste gegevensisolatie en prestatie-isolatie.
Het delen van een Azure OpenAI-resource biedt geen beveiligingssegmentatie voor elke modelimplementatie. Een tenant kan mogelijk een model gebruiken dat ze niet mogen gebruiken. Vermijd daarom het delen van een Azure OpenAI-exemplaar wanneer u nauwkeurig afgestemde modellen gebruikt, omdat u mogelijk gevoelige informatie beschikbaar maakt en onbevoegde toegang tot tenantspecifieke gegevens of resources toestaat.
Het delen van een exemplaar van Azure OpenAI tussen meerdere tenants kan ook leiden tot een probleem met Noisy Neighbor . Dit kan leiden tot een hogere latentie voor sommige tenants. U moet uw toepassingscode ook multitenancybewust maken. Als u bijvoorbeeld uw klanten wilt opladen voor de verbruikskosten van een gedeeld Azure OpenAI-exemplaar, implementeert u de logica om het totale aantal tokens voor elke tenant in uw toepassing bij te houden.
U kunt ook meerdere gedeelde Azure OpenAI-exemplaren implementeren. Als u bijvoorbeeld het patroon Implementatiestempels volgt, implementeert u een gedeeld Azure OpenAI-exemplaar in elke stempel. Als u een oplossing voor meerdere regio's implementeert, moet u Azure OpenAI in elke regio implementeren in:
- Vermijd latentie van verkeer tussen regio's.
- Ondersteuning voor vereisten voor gegevenslocatie.
- Schakel het gebruik van regionale Azure OpenAI in binnen andere services waarvoor implementaties in dezelfde regio zijn vereist.
Wanneer u een gedeeld Azure OpenAI-exemplaar hebt, is het belangrijk om rekening te houden met de limieten en om uw quotum te beheren.
In het volgende diagram ziet u het gedeelde Azure OpenAI-model.
Wanneer u een gedeelde Azure OpenAI-service implementeert, kunt u bepalen of de modelimplementaties binnen de service ook worden gedeeld of dat ze zijn toegewezen aan specifieke klanten.
Gedeelde modelimplementatie tussen tenants
Het delen van een modelimplementatie tussen tenants vereenvoudigt uw operationele last, omdat u minder implementaties hebt om te beheren en modelversies om bij te houden. Plan indien mogelijk een gedeelde modelimplementatie te gebruiken en maak alleen toegewezen modelimplementaties als u de mogelijkheden nodig hebt die ze bieden.
Implementatie van toegewezen modellen per tenant
U kunt een modelimplementatie maken voor elke tenant of voor tenants die speciale vereisten hebben waaraan niet kan worden voldaan met behulp van een gedeelde modelimplementatie. Veelvoorkomende redenen voor het gebruik van toegewezen modelimplementaties voor een tenant zijn onder andere:
Quotum- en kostenbeheer: Het vereenvoudigt tenantspecifieke TPM-toewijzing door het aantal tokens bij te houden dat door elk model wordt gebruikt, zodat u het gebruik van elke tenant nauwkeurig kunt toewijzen en beheren. Als u ingerichte doorvoereenheden (PPU's) gebruikt, kunt u de PKU's toewijzen aan specifieke klanten en andere factureringsmodellen gebruiken voor andere klanten.
Beleid voor inhoudsfiltering: Soms vereist een specifieke tenant mogelijk een uniek beleid voor inhoudsfiltering, zoals een tenantspecifieke blokkeringslijst met niet-toegestane woorden. U geeft het beleid voor inhoudsfilters op voor het bereik van een modelimplementatie.
Modeltypen en -versies: mogelijk moet u verschillende modellen of modelversies voor verschillende tenants gebruiken. Een tenant vereist mogelijk ook een eigen proces voor levenscyclusbeheer van modellen.
Tenantspecifieke afstemming: als u afzonderlijke, nauwkeurig afgestemde modellen voor elke tenant maakt, moet u een afzonderlijke modelimplementatie maken voor elk nauwkeurig afgestemd model.
Houd er rekening mee dat het afstemmen niet vereist is voor de meeste gebruiksvoorbeelden. Normaal gesproken is het beter om uw model te grondleren met behulp van Azure OpenAI On Your Data of een andere rag-benadering (retrieval-augmented generation).
Gegevenslocatie: Deze benadering ondersteunt afzonderlijke vereisten voor gegevenslocatie. U kunt bijvoorbeeld een regionale modelimplementatie bieden voor een tenant met strikte behoeften voor gegevenslocatie en een globale modelimplementatie gebruiken voor andere tenants zonder strikte behoeften.
Elke modelimplementatie heeft een eigen afzonderlijke URL, maar het is belangrijk om te onthouden dat de onderliggende modellen worden gedeeld met andere Azure-klanten. Ze maken ook gebruik van een gedeelde Azure-infrastructuur.
Azure OpenAI dwingt geen toegangsbeheer af voor elke modelimplementatie, dus uw toepassing moet bepalen welke tenant welke modelimplementatie kan bereiken.
Door de tenant geleverde Azure OpenAI-resource
In sommige gevallen kunnen uw tenants het Azure OpenAI-exemplaar maken in hun eigen Azure-abonnementen en uw toepassing toegang verlenen. Deze aanpak kan geschikt zijn in de volgende situaties:
- Tenants hebben specifieke quota en machtigingen van Microsoft, zoals toegang tot verschillende modellen, specifiek beleid voor inhoudsfiltering of het gebruik van ingerichte doorvoer.
- De tenant heeft een nauwkeurig afgestemd model dat ze moeten gebruiken vanuit uw oplossing.
- Ze hebben een onderdeel in hun omgeving nodig om gegevens te verwerken en te verzenden via hun door de klant beheerde Azure OpenAI-exemplaar voor verwerking.
Als u toegang wilt krijgen tot een Azure OpenAI-exemplaar in het abonnement van uw tenant, moet de tenant uw toepassing toegang geven. Uw toepassing moet worden geverifieerd via hun Microsoft Entra-exemplaar. Eén benadering is het publiceren van een Multitenant Microsoft Entra-toepassing. In de volgende werkstroom worden de stappen van deze aanpak beschreven:
- De tenant registreert de multitenant Microsoft Entra-toepassing in hun eigen Microsoft Entra-tenant.
- De tenant verleent de multitenant Microsoft Entra-toepassing het juiste toegangsniveau tot hun Azure OpenAI-resource. De tenant kan bijvoorbeeld de toepassing toewijzen aan de gebruikersrol azure AI-services met behulp van op rollen gebaseerd toegangsbeheer (RBAC).
- De tenant biedt de resource-id van de Azure OpenAI-resource die ze maken.
- Uw toepassingscode kan een service-principal gebruiken die is gekoppeld aan de multitenant Microsoft Entra-toepassing in uw eigen Microsoft Entra-exemplaar voor toegang tot het Azure OpenAI-exemplaar van de tenant.
U kunt ook elke tenant vragen om een service-principal te maken voor uw service die moet worden gebruikt en om u de referenties ervan te geven. Deze aanpak vereist dat u referenties veilig opslaat en beheert voor elke tenant, wat een mogelijke beveiligingsaansprakelijkheid is.
Als uw tenants besturingselementen voor netwerktoegang configureren op hun Azure OpenAI-exemplaar, moet u ervoor zorgen dat u er toegang toe hebt.
In het volgende diagram ziet u het model voor Azure OpenAI voor elke tenant in het abonnement van de tenant.
Functies van De Azure OpenAI-service die ondersteuning bieden voor multitenancy
Api voor assistenten
De Assistants-API voegt functionaliteit toe aan uw Azure OpenAI-service, waardoor deze geschikt is voor het maken van AI-assistenten. Het bevat de mogelijkheid om hulpprogramma's en API's aan te roepen, evenals zoekbestanden om de antwoorden te vinden die door het model worden gegenereerd. Hiermee kunnen permanente gespreksthreads worden beheerd door de service en kunnen code worden gegenereerd en uitgevoerd in een sandboxomgeving. Ter ondersteuning van deze mogelijkheden moet de Assistent-API enkele gegevens opslaan.
Wanneer u de Assistent-API in een multitenant-oplossing gebruikt, kunt u ervoor kiezen om assistenten te maken die zijn toegewezen aan één tenant, of u kunt een assistent delen tussen meerdere tenants. Het is belangrijk dat u rekening houdt met tenantisolatie in alle gegevens die zijn opgeslagen, met name voor gedeelde assistenten. U moet er bijvoorbeeld voor zorgen dat gespreksthreads afzonderlijk worden opgeslagen voor elke tenant.
De Assistenten-API ondersteunt functie-aanroep, waarmee uw toepassingsinstructies voor functies worden verzonden om aan te roepen en argumenten op te nemen. Zorg ervoor dat alle functies die u aanroept multitenant-bewust zijn, zoals door de tenant-id in de aanroep naar het downstreamsysteem op te geven. Controleer de tenant-id in uw toepassing en vertrouw niet op het taalmodel om de tenant-id voor u door te geven.
Azure OpenAI op uw gegevens
Met Azure OpenAI op uw gegevens kan het grote taalmodel rechtstreeks query's uitvoeren op kennisbronnen, zoals indexen en databases, als onderdeel van het genereren van een antwoord van het taalmodel.
Wanneer u een aanvraag indient, kunt u de gegevensbronnen opgeven waarop een query moet worden uitgevoerd. Zorg er in een multitenant-oplossing voor dat uw gegevensbronnen multitenancybewust zijn en dat u tenantfilters voor uw aanvragen kunt opgeven. De tenant-id op de juiste manier doorgeven aan de gegevensbron. Stel dat u een query uitvoert op Azure AI Search. Als u gegevens voor meerdere tenants in één index hebt, geeft u een filter op om de opgehaalde resultaten te beperken tot de id van de huidige tenant. Als u voor elke tenant een index hebt gemaakt, controleert u of u de juiste index voor de huidige tenant opgeeft.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Sofia Microsoft | Software Engineer, ISV & DN CoE
Andere Inzenders:
- John Downs | Principal Software Engineer
- Landon Pierce | Klanttechnicus, ISV & DN CoE
- Paulo Salvatori | Principal Customer Engineer, ISV & DN CoE
- Daniel Scott-Raynsford | Partner Solution Architect
- Arsen Vladimirskiy | Principal Customer Engineer, ISV & DN CoE
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.