Multitenancy i Azure OpenAI w Modelach Foundry

Usługa Azure OpenAI in Foundry Models zapewnia dostęp do zaawansowanych modeli językowych interfejsu OpenAI. W tym artykule opisano kluczowe funkcje usługi Azure OpenAI, które są korzystne dla rozwiązań wielodostępnych. Zapoznaj się z zalecanymi zasobami, aby ułatwić planowanie podejścia i korzystanie z usługi Azure OpenAI.

Modele izolacji

Jeśli masz system wielodostępny korzystający z usługi Azure OpenAI, musisz określić poziom izolacji wymaganej przez dzierżawców. Model izolacji należy zaprojektować na podstawie następujących czynników:

• Liczba planowanych najemców
• Czy dzierżawcy mają wymagania dotyczące zgodności, które wymagają izolacji sieci lub infrastruktury
• Czy najemcy potrzebują modeli dopasowanych przy użyciu własnych danych
• Niezależnie od tego, czy najemcy wymagają różnych wersji modeli, czy cykli życia modeli

W poniższej tabeli przedstawiono podsumowanie metod wdrażania, które można wykonać podczas korzystania z usługi Azure OpenAI w systemie wielodostępnym:

Dedykowana usługa Azure OpenAI

Jeśli jesteś dostawcą usług, rozważ wdrożenie instancji Azure OpenAI dla każdej dzierżawy w Twojej subskrypcji Azure. Takie podejście zapewnia izolację danych dla każdej dzierżawy. Wymaga to wdrożenia coraz większej liczby zasobów usługi Azure OpenAI i zarządzania nimi w miarę zwiększania liczby dzierżaw.

Użyj tego podejścia, jeśli masz oddzielne wdrożenia aplikacji dla każdego dzierżawcy lub jeśli musisz obejść ograniczenia, takie jak limit kwoty lub żądania na minutę. Aby uzyskać więcej informacji, zobacz Limity przydziału i limity usługi Azure OpenAI.

Na poniższym diagramie przedstawiono model usługi Azure OpenAI dla każdej dzierżawy w subskrypcji dostawcy.

Udostępniona usługa Azure OpenAI

Możesz udostępnić wystąpienie usługi Azure OpenAI wśród wielu dzierżawców. Zasób Azure OpenAI jest wdrażany w ramach subskrypcji platformy Azure (dostawcy usług). Odpowiadasz za zarządzanie nim. To rozwiązanie jest najłatwiejsze do zaimplementowania, ale zapewnia najmniejszą izolację danych i izolację wydajności.

Udostępnianie zasobu usługi Azure OpenAI nie zapewnia segmentacji zabezpieczeń dla każdego wdrożenia modelu. Najemca może być w stanie użyć modelu, do którego nie ma uprawnień. Z tego powodu należy unikać udostępniania wystąpienia usługi Azure OpenAI w przypadku używania wytrenowanych modeli. Możesz ujawnić poufne informacje i zezwolić na nieautoryzowany dostęp do danych lub zasobów związanych z dzierżawcą.

Udostępnianie wystąpienia usługi Azure OpenAI przez wiele dzierżaw może również prowadzić do problemu hałaśliwego sąsiada. Może to spowodować większe opóźnienie dla niektórych najemców. Należy również uwzględnić wielodostępność kodu aplikacji. Na przykład, jeśli chcesz obciążyć klientów kosztem zużycia współdzielonego wystąpienia usługi Azure OpenAI, zaimplementuj logikę śledzenia łącznej liczby tokenów dla każdego wystąpienia najemcy w aplikacji.

Można również wdrożyć wiele udostępnionych wystąpień usługi Azure OpenAI. Na przykład, jeśli zastosujesz wzorzec stempeli wdrażania, w każdym stemplu wdrożone jest udostępnione wystąpienie usługi Azure OpenAI. W przypadku wdrażania rozwiązania w wielu regionach należy wdrożyć usługę Azure OpenAI w każdym regionie w następujących regionach:

• Unikaj opóźnienia ruchu między regionami.
• Obsługa wymagań dotyczących rezydencji danych.
• Włącz korzystanie z regionalnej usługi Azure OpenAI w innych usługach, które wymagają wdrożeń w tym samym regionie.

Jeśli masz udostępnione wystąpienie usługi Azure OpenAI, ważne jest, aby wziąć pod uwagę jego limity i zarządzać swoim przydziałem.

Na poniższym diagramie przedstawiono udostępniony model usługi Azure OpenAI.

Podczas wdrażania udostępnionej usługi Azure OpenAI możesz zdecydować, czy wdrożenia modelu w usłudze są również współużytkowane, czy dedykowane dla określonych klientów.

Wdrażanie modelu udostępnionego między najemcami

Udostępnianie wdrożenia modelu między dzierżawami upraszcza obciążenie operacyjne, ponieważ masz mniej wdrożeń do zarządzania i mniej wersji modelu do śledzenia. Zaplanuj użycie współdzielonego wdrożenia modelu, jeśli możliwe, i twórz dedykowane wdrożenia modeli tylko wtedy, gdy potrzebujesz możliwości, które one oferują.

Wdrożenie dedykowanego modelu dla każdego najemcy

Możesz utworzyć wdrażanie modelu dla każdej dzierżawy lub tych dzierżaw, które mają specjalne wymagania, których nie można spełnić za pomocą współdzielonego wdrażania modelu. Typowe przyczyny korzystania z wdrożeń dedykowanych modeli dla dzierżawy obejmują:

• Limit przydziału i zarządzanie kosztami. Wdrożenia modeli dedykowanych ułatwiają alokację TPM dla poszczególnych najemców poprzez śledzenie liczby tokenów używanych przez każdy model. Możesz użyć tej liczby, aby precyzyjnie przydzielić koszty i zarządzać użyciem każdego najemcy. Jeśli używasz aprowizowanych jednostek przepływności (PTU), możesz przypisać jednostki PTU do określonych klientów i użyć innych modeli rozliczeń dla innych klientów.

• Zasady filtrowania zawartości. Czasami określony najemca może wymagać unikatowej polityki filtrowania treści, takiej jak lista słów zabronionych specyficzna dla najemcy. Należy określić zasady filtrowania zawartości w zakresie wdrożenia modelu.

• Typy i wersje modelu. Może być konieczne użycie różnych modeli lub wersji modelu dla różnych najemców. Najemca może również wymagać własnego zarządzania cyklem życia modelu.

• Dostosowywanie specyficzne dla najemcy. W przypadku tworzenia odrębnych precyzyjnie dostrojonych modeli dla każdej dzierżawy należy utworzyć oddzielne wdrożenie dla każdego modelu.

  Pamiętaj, że dostrajanie nie jest wymagane w większości przypadków użycia. Zazwyczaj lepiej jest osadzić model przy użyciu usługi Azure OpenAI On Your Data lub innego podejścia do generowania wzbogaconego wyszukiwaniem (RAG).

• Miejsce przechowywania danych. Takie podejście obsługuje odrębne wymagania dotyczące przechowywania danych. Na przykład można podać wdrożenie modelu regionalnego dla najemcy, który ma rygorystyczne wymagania dotyczące przechowywania danych, i używać globalnego wdrożenia modelu dla innych najemców.

Każde wdrożenie modelu ma unikatowy adres URL, ale należy pamiętać, że podstawowe modele są udostępniane innym klientom platformy Azure. Modele współdzielą również infrastrukturę platformy Azure.

Usługa Azure OpenAI nie wymusza kontroli dostępu dla każdego wdrożenia modelu, dlatego aplikacja musi kontrolować, który najmca może uzyskać dostęp do wdrożenia modelu.

Zasób usługi Azure OpenAI udostępniany przez dzierżawę

W niektórych scenariuszach Twoi najemcy mogą utworzyć wystąpienie usługi Azure OpenAI we własnych subskrypcjach Azure i przyznać Twojej aplikacji dostęp do niej. Takie podejście może być odpowiednie w następujących scenariuszach:

• Najemcy mają określone limity kwot i uprawnienia od firmy Microsoft, w tym dostęp do różnych modeli, zdefiniowane zasady filtrowania zawartości i zapewnione wykorzystanie przepustowości.

• Dzierżawcy mają dopracowany model, którego muszą użyć w ramach rozwiązania.

• Najemcy wymagają składnika w swoim środowisku do przetwarzania i wysyłania danych za pośrednictwem instancji Azure OpenAI zarządzanej przez klienta.

Aby uzyskać dostęp do wystąpienia Azure OpenAI w subskrypcji twojej dzierżawy, dzierżawca musi zapewnić dostęp twojej aplikacji. Aplikacja musi uwierzytelniać się za pośrednictwem wystąpienia Microsoft Entra. Jedną z metod jest opublikowanie wielodostępnej aplikacji Firmy Microsoft Entra. Poniższy przepływ pracy przedstawia to podejście:

1. Dzierżawca rejestruje aplikację Microsoft Entra przeznaczoną dla wielu dzierżawców we własnej dzierżawie Microsoft Entra.

2. Najemca przyznaje multitenantowej aplikacji Microsoft Entra odpowiedni poziom dostępu do zasobu Azure OpenAI. Na przykład dzierżawca może przypisać aplikację do roli użytkownika usług Azure AI za pomocą kontroli dostępu opartej na rolach.

3. Najemca udostępnia identyfikator zasobu usługi Azure OpenAI, który tworzy.

4. Kod aplikacji może użyć zasobu usługi, który jest powiązany z aplikacją wielodostępową Microsoft Entra w Twoim własnym środowisku Microsoft Entra, aby uzyskać dostęp do wystąpienia Azure OpenAI w dzierżawie.

Alternatywnie możesz poprosić każdego dzierżawcę o utworzenie jednostki usługi dla Twojej usługi i podanie jej poświadczeń. Takie podejście wymaga bezpiecznego przechowywania poświadczeń i zarządzania nimi dla każdej dzierżawy, co stanowi potencjalną odpowiedzialność za zabezpieczenia.

Jeśli najemcy skonfigurują mechanizmy kontroli dostępu do sieci w swojej instancji Azure OpenAI, upewnij się, że masz zapewniony do niej dostęp.

Na poniższym diagramie przedstawiono model usługi Azure OpenAI dla każdej dzierżawy w ramach subskrypcji dzierżawy.

Funkcje usługi Azure OpenAI, które obsługują wielodostępność

Usługa Azure OpenAI udostępnia następujące funkcje, które obsługują wielodostępność.

Odpowiedzi API

API odpowiedzi to API zachowujące stan, które łączy zarządzanie konwersacjami, wywoływanie narzędzi, wyszukiwanie plików, przetwarzanie zadań w tle i ustrukturyzowane dane wyjściowe w jednym interfejsie.

W przypadku korzystania z interfejsu API odpowiedzi może być trudno odizolować dane między najemcami. Identyfikatory klientów nie mogą być dołączone do wszystkich narzędzi i możliwości.

Jeśli jednak zdecydujesz się użyć API odpowiedzi dla rozwiązania wielonajemnego, należy rozważyć izolację danych najemcy we wszystkich przechowywanych danych i operacjach, które kontrolujesz. Interfejs API przechowuje historię konwersacji przy użyciu identyfikatorów odpowiedzi, które łączą kolejne żądania z poprzednim kontekstem. Upewnij się, że identyfikatory odpowiedzi są przechowywane z kluczami o zakresie dzierżawy w aplikacji. Takie podejście gwarantuje, że żądanie może odwoływać się tylko do identyfikatorów odpowiedzi skojarzonych z tym samym dzierżawcą.

Interfejs API odpowiedzi obsługuje wywoływanie funkcji i wbudowane narzędzia. W przypadku wywoływania funkcji, gdy kod aplikacji obsługuje wywołanie funkcji, należy upewnić się, że wszystkie wywołania funkcji są przystosowane do wielu najemców. Jednym z podejść jest uwzględnienie identyfikatora dzierżawy w wywołaniu podrzędnego interfejsu API lub funkcji. W przypadku wbudowanych narzędzi, takich jak interpreter kodu i wszelkie zdalne wywołania serwera MCP, infrastruktura modelu wykonuje te operacje. Nie można niezawodnie wprowadzać kontekstu dzierżawy do tych wbudowanych wywołań narzędzi, dlatego podczas korzystania z tych funkcji należy używać dedykowanych kontenerów lub oddzielnych konfiguracji narzędzi dla każdej dzierżawy.

W przypadku korzystania z funkcji wyszukiwania plików lub generowania z rozszerzonym pobieraniem (RAG), należy upewnić się, że repozytoria plików i indeksy wektorów są przypisane do odpowiedniego klienta. Jeśli używasz indeksów udostępnionych, zastosuj filtry najemcy do wszystkich zapytań. Jeśli wdrażasz indeksy przypisane do najemcy, przyporządkuj każde żądanie do prawidłowego indeksu na podstawie identyfikatora najemcy. Aby uzyskać więcej informacji, zobacz Projektowanie bezpiecznego wielodostępnego rozwiązania wnioskowania RAG.

Interfejs API odpowiedzi obsługuje tryb w tle dla długotrwałych operacji. Identyfikatory zadań należy przechowywać w kontekście dzierżawcy i sprawdzać dzierżawcę podczas sondowania wyników. Upewnij się, że kolejki zadań i magazyn wyników uniemożliwiają jednemu najemcy uzyskiwanie dostępu do zadań w tle oraz danych wyjściowych innego najemcy.

Interfejs API asystentów

Interfejs API Asystentów wzbogaca usługę Azure OpenAI, czyniąc ją odpowiednią do tworzenia asystentów sztucznej inteligencji. Obejmuje możliwość wywoływania narzędzi i interfejsów API oraz przeszukiwania plików w celu uzasadnienia odpowiedzi generowanych przez model. Umożliwia usłudze zarządzanie trwałymi wątkami konwersacyjnymi. Interfejs API może również generować i uruchamiać kod w izolowanym środowisku. Aby obsługiwać te możliwości, interfejs API Asystentów musi przechowywać pewne dane.

Jeśli używasz API Asystentów w rozwiązaniu wieloznacznikowym, możesz utworzyć asystentów dedykowanych jednemu najemcy lub udostępnić asystenta między wieloma najemcami. Ważne jest, aby rozważyć izolację najemców we wszystkich przechowywanych danych, szczególnie w przypadku asystentów współdzielonych. Na przykład należy zadbać o to, aby rozmowy były przechowywane oddzielnie dla każdego najemcy.

Interfejs API Asystentów obsługuje wywołanie funkcji, które wysyła instrukcje aplikacji dotyczące funkcji do wywołania i argumentów do uwzględnienia. Upewnij się, że wszystkie wywołania funkcji, które zostały utworzone, są obsługujące wiele dzierżaw. Jednym z podejść jest uwzględnienie identyfikatora najemcy w wywołaniu do systemu docelowego. Zweryfikuj identyfikator najemcy w aplikacji i nie polegaj na modelu językowym, żeby propagować identyfikator najemcy.

Azure OpenAI na Twoich Danych

Funkcja Azure OpenAI On Your Data umożliwia dużemu modelowi językowemu bezpośrednie wykonywanie zapytań dotyczących źródeł wiedzy, takich jak indeksy i bazy danych, w ramach generowania odpowiedzi na podstawie modelu językowego.

Podczas wykonywania żądania można określić źródła danych, które mają być odpytywane. W rozwiązaniu wielodostępnym upewnij się, że źródła danych są świadome wielodostępności i że można określić filtry tenantów dla żądań. Odpowiednio rozpropaguj identyfikator dzierżawy do źródła danych. Załóżmy na przykład, że wykonasz zapytanie dotyczące usługi Azure AI Search. Jeśli masz dane dla wielu dzierżaw w jednym indeksie, określ filtr, aby ograniczyć pobrane wyniki do identyfikatora bieżącej dzierżawy. Lub jeśli tworzysz indeks dla każdej dzierżawy, upewnij się, że określono prawidłowy indeks dla bieżącej dzierżawy.

Wdrożenia grupowe

Niektóre modele można wdrożyć w usłudze Azure OpenAI przy użyciu wdrożenia wsadowego. Wdrożenia wsadowe umożliwiają asynchroniczne przetwarzanie grupowych żądań przy użyciu oddzielnego przydziału wsadowego. Żądania wysyłane do wdrożeń wsadowych mają docelowy czas realizacji wynoszący 24 godziny i kosztują mniej niż standardowe wdrożenia. W przeciwieństwie do wdrożeń standardowych przydziały wsadowe ograniczają liczbę tokenów w kolejce zamiast modułu TPM.

Ten typ wdrożenia jest idealny w scenariuszach, w których natychmiastowe odpowiedzi nie są wymagane, a przetwarzanie dużych ilości żądań nie może zakłócać odpowiedzi w czasie rzeczywistym.

Na przykład system, który analizuje nastroje opinii użytkowników, może użyć wdrożenia wsadowego, aby uniknąć ograniczania przepustowości standardowego przydziału potrzebnego do prowadzenia interakcji w czasie rzeczywistym w innych aplikacjach. Takie podejście zmniejsza również koszty przetwarzania.

W rozwiązaniu typu multitenant wdrożenia wsadowe mogą być dzielone między wszystkich najemców lub tworzone osobno dla każdego najemcy.

• Oddzielne wdrożenia wsadowe dla każdego najemcy:

  Przypisując limity tokenów do każdego wdrożenia wsadowego dla danego najemcy, można zapobiec monopolizowaniu zasobów przez pojedynczego najemcę. Takie podejście umożliwia również śledzenie użycia tokenu dla każdego najemcy, co jest przydatne w przypadku przypisania kosztów.

• Wdrażanie wsadowe udostępnione:

  Wspólne wdrożenie wsadowe może przetwarzać żądania z wielu dzierżawców w połączonych lub oddzielnych zadaniach wsadowych. Jeśli połączysz żądania od wielu najemców w jedno zadanie wsadowe, upewnij się, że można poprawnie przypisać odpowiedzi do odpowiedniego najemcy.

  Zadania usługi Batch są zarządzane na poziomie zadania, dlatego dobrym pomysłem jest ich rozdzielenie według dzierżawcy. Takie podejście umożliwia anulowanie lub usunięcie zadań dla każdego właściciela zasobów. Nie można anulować ani usunąć pojedynczych żądań w grupie.

Starannie zarządzając wdrożeniami wsadowymi, można umożliwiać równoważenie efektywności kosztowej i alokacji zasobów przy zachowaniu izolacji najemców oraz elastyczności operacyjnej.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Sofia Ferreira | Inżynier oprogramowania, ISV i DN CoE

Inni współautorzy:

• John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• Landon Pierce | Inżynier klienta, ISV i DN CoE
• Paolo Salvatori | Główny inżynier klienta, ISV i DN CoE
• Daniel Scott-Raynsford | Architekt rozwiązań partnerskich
• Arsen Vladimirskiy | Główny inżynier ds. klientów, ISV i DN CoE

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Powiązane zasoby

• Podejścia architektury do wdrażania i konfigurowania rozwiązań wielodostępnych
• Podejścia architektoniczne do zarządzania kosztami i alokacji w rozwiązaniu wielodostępnym
• Lista kontrolna dotycząca projektowania architektury i budowania rozwiązań multitenantowych na platformie Azure