Uzyskiwanie dostępu do usługi Azure OpenAI i innych modeli językowych za pośrednictwem bramy

Usługa Azure OpenAI udostępnia interfejsy API HTTP, które umożliwiają aplikacjom osadzanie lub uzupełnianie przy użyciu modeli językowych openAI. Inteligentne aplikacje nazywają te interfejsy API HTTP bezpośrednio z klientów lub koordynatorów. Przykłady klientów obejmują kod interfejsu użytkownika czatu i niestandardowe potoki przetwarzania danych. Przykłady orkiestratorów to LangChain, Semantic Kernel i przepływ monitów w narzędziu Azure AI Foundry. Gdy obciążenie łączy się z co najmniej jednym wystąpieniem usługi Azure OpenAI, musisz zdecydować, czy ci użytkownicy łączą się bezpośrednio, czy za pośrednictwem bramy odwrotnego interfejsu API serwera proxy.

Skorzystaj z tego przewodnika, aby dowiedzieć się więcej na temat najważniejszych wyzwań w pięciu filarach struktury Azure Well-Architected Framework , które napotykasz, jeśli projekt obciążenia obejmuje bezpośredni dostęp od konsumentów do interfejsów API płaszczyzny danych usługi Azure OpenAI. Następnie dowiedz się, jak wprowadzenie bramy do architektury może pomóc rozwiązać te problemy z bezpośrednim dostępem, wprowadzając nowe wyzwania. W tym artykule opisano wzorzec architektury, ale nie sposób implementowania bramy.

Ponieważ brama może służyć do rozwiązywania konkretnych scenariuszy, które mogą nie być obecne w każdym obciążeniu, zobacz szczegółowe wskazówki dotyczące konkretnego scenariusza, w którym bardziej szczegółowo przedstawiono ten konkretny przypadek użycia bramy.

Kluczowe wyzwania

Bez bramy interfejsu API lub możliwości dodawania logiki do interfejsów API HTTP usługi Azure OpenAI klient musi obsługiwać logikę klienta interfejsu API, która obejmuje mechanizmy ponawiania prób lub wyłączniki. Taka sytuacja może być trudna w scenariuszach, w których nie kontrolujesz bezpośrednio kodu klienta lub gdy kod jest ograniczony do określonego użycia zestawu SDK. Wielu klientów lub wielu wystąpień i wdrożeń usługi Azure OpenAI stwarza dodatkowe wyzwania, takie jak koordynacja bezpiecznych wdrożeń i obserwowanie.

Ta sekcja zawiera przykłady konkretnych kluczowych wyzwań związanych z architekturą, które mogą wystąpić, jeśli twoja architektura obsługuje tylko bezpośredni dostęp do usługi Azure OpenAI od użytkowników. Wyzwania są zorganizowane przy użyciu filarów platformy Azure Well-Architected Framework.

Wyzwania związane z niezawodnością

Niezawodność obciążenia zależy od kilku czynników, w tym jego pojemności do samodzielnego zachowania i samoodzyskiwania, które są często implementowane za pomocą mechanizmów replikacji i trybu failover. Bez bramy wszystkie problemy dotyczące niezawodności muszą być rozwiązane wyłącznie przy użyciu logiki klienta i funkcji usługi Azure OpenAI Service. Niezawodność obciążenia jest zagrożona, gdy nie ma wystarczającej kontroli niezawodności dostępnej na jednej z tych dwóch powierzchni.

• równoważenia obciążenia lub nadmiarowości: przełączanie w tryb failover między wieloma wystąpieniami usługi Azure OpenAI na podstawie dostępności usługi jest klientem odpowiedzialnym za kontrolę za pośrednictwem konfiguracji i logiki niestandardowej.

  globalna, standardowa lub aprowizowana, a strefy danych, standardowej lub aprowizowanej, nie mają wpływu na dostępność usługi Azure OpenAI z perspektywy dostępności regionalnego punktu końcowego. Nadal ponosisz odpowiedzialność za samodzielne zaimplementowanie logiki trybu failover.

• Skalowanie w poziomie w celu obsługi skoków: przechodzenie w tryb failover do wystąpień usługi Azure OpenAI z pojemnością w przypadku ograniczenia jest kolejnym klientem odpowiedzialnym za kontrolę za pośrednictwem konfiguracji i logiki niestandardowej. Aktualizowanie wielu konfiguracji klienta dla nowych wystąpień usługi Azure OpenAI stwarza większe ryzyko i ma obawy dotyczące osi czasu. To samo dotyczy aktualizowania kodu klienta w celu implementowania zmian w logice, takich jak kierowanie żądań o niskim priorytcie do kolejki w okresach wysokiego zapotrzebowania.

• ograniczanie przepustowości: żądania ograniczania przepływności interfejsów API usługi Azure OpenAI przez zwrócenie kodu odpowiedzi http 429 na żądania przekraczające token-Per-Minute (TPM) lub żądania —Per-Minute (RPM) w modelu standardowym. Interfejsy API usługi Azure OpenAI ograniczają również żądania, które przekraczają aprowizowaną pojemność dla wstępnie aprowizowanego modelu rozliczeń. Obsługa odpowiedniego wycofywania i logiki ponawiania prób jest pozostawiona wyłącznie do implementacji klienta.

  Większość obciążeń powinna rozwiązać ten konkretny problem przy użyciu globalnej i wdrożenia strefy danych wdrożeń usługi Azure OpenAI. Te wdrożenia umożliwiają korzystanie z pojemności modelu z centrów danych z wystarczającą pojemnością dla każdego żądania. Korzystanie z wdrożeń globalnych i stref danych znacznie zmniejszy ograniczanie przepustowości usługi bez dodatkowej złożoności bram niestandardowych. Wdrożenia stref globalnych i danych są implementacją bramy.

Wyzwania związane z zabezpieczeniami

Mechanizmy kontroli zabezpieczeń muszą pomóc chronić poufność, integralność i dostępność obciążeń. Bez bramy wszystkie obawy dotyczące zabezpieczeń muszą być rozwiązane wyłącznie w logice klienta i funkcjach usługi Azure OpenAI Service. Wymagania dotyczące obciążeń mogą wymagać więcej niż to, co jest dostępne dla segmentacji klienta, kontroli klienta lub funkcji zabezpieczeń usługi na potrzeby bezpośredniej komunikacji.

• Zarządzanie tożsamościami — zakres uwierzytelniania: interfejsy API płaszczyzny danych uwidocznione przez usługę Azure OpenAI można zabezpieczyć na jeden z dwóch sposobów: klucz interfejsu API lub kontrolę dostępu opartą na rolach (RBAC) platformy Azure. W obu przypadkach uwierzytelnianie odbywa się na poziomie wystąpienia usługi Azure OpenAI, a nie na poziomie poszczególnych wdrożeń, co wprowadza złożoność zapewniania najmniej uprzywilejowanego dostępu i segmentacji tożsamości dla określonych modeli wdrażania.

• Zarządzanie tożsamościami — dostawcy tożsamości: klienci, którzy nie mogą używać tożsamości znajdujących się w dzierżawie usługi Microsoft Entra, która wspiera wystąpienie usługi Azure OpenAI, muszą współużytkować pojedynczy klucz interfejsu API pełnego dostępu. Klucze interfejsu API mają ograniczenia użyteczności zabezpieczeń i są problematyczne, gdy wielu klientów jest zaangażowanych i wszystkich współużytkuje tę samą tożsamość.

• Zabezpieczenia sieci: w zależności od lokalizacji klienta względem wystąpień usługi Azure OpenAI może być konieczny publiczny dostęp do Internetu do modeli językowych.

• Niezależność danych: Niezależność danych w kontekście usługi Azure OpenAI odnosi się do wymagań prawnych i regulacyjnych związanych z przechowywaniem i przetwarzaniem danych w granicach geograficznych określonego kraju lub regionu. Obciążenie musi zapewnić koligację regionalną, aby klienci mogli zachować zgodność z przepisami dotyczącymi rezydencji danych i niezależności. Ten proces obejmuje wiele wdrożeń usługi Azure OpenAI.

  Należy pamiętać, że jeśli używasz globalnej lub strefy danych wdrożeniach usługi Azure OpenAI, dane magazynowane pozostają w wyznaczonej lokalizacji geograficznej platformy Azure, ale dane mogą być przesyłane i przetwarzane do wnioskowania w dowolnej lokalizacji usługi Azure OpenAI.

Wyzwania związane z optymalizacją kosztów

Obciążenia korzystają, gdy architektury minimalizują straty i maksymalizuj narzędzia. Silne modelowanie kosztów i monitorowanie są ważnym wymaganiem dla dowolnego obciążenia. Bez bramy wykorzystanie aprowizowanego lub śledzenia kosztów poszczególnych klientów może być autorytatywne osiągane wyłącznie na podstawie agregacji danych telemetrycznych użycia wystąpienia usługi Azure OpenAI.

• Śledzenie kosztów: możliwość zapewnienia perspektywy finansowej użycia usługi Azure OpenAI jest ograniczona do danych zagregowanych z danych telemetrycznych użycia wystąpienia usługi Azure OpenAI. W razie potrzeby obciążenia zwrotnego lub powrotu należy przypisać te dane telemetryczne użycia z różnymi klientami w różnych działach, a nawet klientów w scenariuszach wielodostępnych.

• Wykorzystanie aprowizowanej przepływności: Obciążenie chce uniknąć strat dzięki pełnemu wykorzystaniu aprowizowanej przepływności, za którą zapłaciłeś. Oznacza to, że klienci muszą być zaufani i skoordynowani w celu korzystania z wdrożeń modelu aprowizowania przed rozlaniem do wszystkich wdrożeń modelu standardowego.

Wyzwania związane z doskonałością operacyjną

Bez bramy można obserwować, kontrolować zmiany i procesy programistyczne są ograniczone do tego, co zapewnia bezpośrednia komunikacja między klientem a serwerem.

• Kontrola limitu przydziału: klienci otrzymują kody odpowiedzi 429 bezpośrednio z usługi Azure OpenAI, gdy interfejsy API HTTP są ograniczane. Operatorzy obciążeń są odpowiedzialni za zapewnienie, że wystarczający limit przydziału jest dostępny dla prawidłowego użycia i że nieprawidłowo zachowujący się klienci nie zużywają nadmiaru. Jeśli obciążenie składa się z wielu wdrożeń modelu lub wielu stref danych, zrozumienie użycia przydziału i dostępności przydziału może być trudne do wizualizacji.

• Monitorowanie i obserwowanie: domyślne metryki usługi Azure OpenAI są dostępne za pośrednictwem usługi Azure Monitor. Istnieje jednak opóźnienie z dostępnością danych i nie zapewnia monitorowania w czasie rzeczywistym.

• Bezpieczne praktyki wdrażania: proces GenAIOps wymaga koordynacji między klientami a modelami wdrożonym w usłudze Azure OpenAI. W przypadku zaawansowanych metod wdrażania, takich jak niebieski-zielony lub kanary, logika musi być obsługiwana po stronie klienta.

Wyzwania związane z wydajnością

Bez bramy obciążenie ponosi odpowiedzialność za indywidualne zachowanie klientów i zachowanie się sprawiedliwie z innymi klientami w odniesieniu do ograniczonej pojemności.

• Optymalizacja wydajności — ruch priorytetowy: ustalanie priorytetów żądań klientów tak, aby klienci o wysokim priorytcie mieli preferencyjny dostęp do klientów o niskim priorytetach, wymagałoby rozległych i prawdopodobnie nieuzasadnionych koordynacji między klientami. Niektóre obciążenia mogą korzystać z obsługi żądań o niskim priorytcie w kolejce do uruchomienia, gdy wykorzystanie modelu jest niskie.

• Optymalizacja wydajności — zgodność klienta: aby udostępnić pojemność, klienci muszą być dobrze zachowywani. Przykładem jest to, że klienci zapewniają, że max_tokens i best_of są ustawione na zatwierdzone wartości. Bez bramy należy ufać klientom, aby działali w najlepszym interesie zachowania pojemności wystąpienia usługi Azure OpenAI.

• Minimalizuj opóźnienie: chociaż opóźnienie sieci jest zwykle małym składnikiem ogólnego przepływu żądań monitu i ukończenia, zapewnienie, że klienci są kierowani do punktu końcowego sieci i modelu blisko nich mogą być korzystne. Bez bramy klienci musieliby samodzielnie wybrać punkty końcowe wdrożenia modelu do użycia i jakie poświadczenia są niezbędne dla tego konkretnego interfejsu API płaszczyzny danych usługi Azure OpenAI.

Rozwiązanie

Rysunek 1. Koncepcyjna architektura uzyskiwania dostępu do usługi Azure OpenAI za pośrednictwem bramy

Aby sprostać wielu wyzwaniom wymienionym w sekcji Kluczowe wyzwania, możesz wstrzyknąć bramę zwrotnego serwera proxy, aby rozdzielić inteligentną aplikację z usługi Azure OpenAI. Ta brama odciążająca umożliwia przesunięcie odpowiedzialności, złożoności i możliwości obserwacji od klientów oraz możliwość rozszerzenia usługi Azure OpenAI przez udostępnienie innych funkcji, które nie są wbudowane. Niektóre przykłady:

• Możliwość zaimplementowania uwierzytelniania federacyjnego.

• Możliwość kontrolowania nacisku na modele poprzez ograniczanie szybkości.

• Monitorowanie krzyżowe i krzyżowe.

• Możliwość wprowadzenia agregacji bramy i zaawansowanego routingu do wielu usług, takich jak routing komunikatów o niskim priorytecie do kolejki na potrzeby bilansowania obciążenia opartego na kolejce lub obliczania w celu wykonywania zadań.

• Równoważenie obciążenia, które używa monitorowania punktu końcowego kondycji do kierowania tylko do punktów końcowych w dobrej kondycji przez wyłącznik w przypadku niedostępnych lub przeciążonych wdrożeń modelu.

Niektóre konkretne scenariusze zawierają więcej wskazówek, które bezpośrednio dotyczą bramy interfejsu API i wystąpień usługi Azure OpenAI. Te scenariusze są wymienione w sekcji Następne kroki .

Kwestie wymagające rozważenia

Podczas wprowadzania nowego składnika do architektury należy ocenić nowo wprowadzone kompromisy. W przypadku wstrzykiwania bramy interfejsu API między klientami i płaszczyzną danych usługi Azure OpenAI w celu rozwiązania dowolnego z kluczowych wyzwań należy wprowadzić nowe kwestie do architektury. Dokładnie oceń, czy wpływ obciążenia na te zagadnienia dotyczące architektury uzasadnia wartość dodaną lub narzędzie bramy.

Niezawodność

Niezawodność gwarantuje, że aplikacja spełnia zobowiązania wobec klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.

• Rozwiązanie bramy może wprowadzić pojedynczy punkt awarii. Ten błąd może mieć swoje źródło w dostępności usługi platformy bramy, przerwy z powodu wdrożeń kodu lub konfiguracji, a nawet nieprawidłowo skonfigurowanych krytycznych punktów końcowych interfejsu API w bramie. Upewnij się, że projektujesz implementację w celu spełnienia wymagań dotyczących dostępności obciążenia. Rozważ możliwości odporności i odporności na uszkodzenia w implementacji, uwzględniając bramę w analizie trybu awarii obciążenia.

• Rozwiązanie może wymagać globalnych możliwości routingu, jeśli architektura wymaga wystąpień usługi Azure OpenAI w wielu regionach w celu zwiększenia dostępności punktów końcowych usługi Azure OpenAI, takich jak możliwość kontynuowania obsługi żądań w przypadku awarii regionalnej. Taka sytuacja może jeszcze bardziej skomplikować topologię dzięki zarządzaniu dodatkowymi w pełni kwalifikowaną nazwami domen, certyfikatami TLS i bardziej globalnymi składnikami routingu.

Zabezpieczenia

Rozważając, w jaki sposób brama interfejsu API korzysta z architektury, użyj listy kontrolnej Przegląd projektu dla opcji Zabezpieczenia , aby ocenić projekt. Należy uwzględnić zagadnienia dotyczące zabezpieczeń, takie jak:

• Obszar powierzchni obciążenia jest zwiększany wraz z dodatkami bramy. Obszar powierzchni zapewnia dodatkowe zagadnienia związane z zarządzaniem tożsamościami i dostępem (IAM) zasobów platformy Azure, zwiększone wysiłki związane z wzmacnianiem zabezpieczeń i nie tylko.

• Brama może pełnić rolę przejścia granicy sieci między przestrzenią sieciową klienta a prywatną przestrzenią sieciową usługi Azure OpenAI. Mimo że brama sprawia, że wcześniej dostępny z Internetu punkt końcowy usługi Azure OpenAI jest prywatny za pośrednictwem usługi Azure Private Link, teraz staje się nowym punktem wejścia i musi być odpowiednio zabezpieczony.

• Brama jest w unikatowej sytuacji, aby wyświetlić nieprzetworzone dane żądania i sformułować odpowiedzi z modelu językowego, które mogą zawierać poufne dane z dowolnego źródła. Zgodność danych i zakres regulacyjny są teraz rozszerzone do tego innego składnika.

• Brama może rozszerzyć zakres autoryzacji i uwierzytelniania klienta poza uwierzytelnianiem identyfikatora i klucza interfejsu API firmy Microsoft oraz potencjalnie między wieloma dostawcami tożsamości (IdP).

• Niezależność danych musi być uwzględniana w implementacji w implementacji w wielu regionach. Upewnij się, że logika obliczeniowa i routingu bramy jest zgodna z wymaganiami dotyczącymi niezależności umieszczonymi w obciążeniu.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

Wszystkie zaimplementowane bramy interfejsu API mają koszty środowiska uruchomieniowego, które muszą być budżetowane i uwzględniane. Koszty te zwykle zwiększają się wraz z dodanymi funkcjami, aby rozwiązać problem z niezawodnością, bezpieczeństwem i wydajnością samej bramy wraz z kosztami operacyjnymi wprowadzonymi w ramach dodanego zarządzania interfejsem APIOps. Te dodatkowe koszty muszą być mierzone względem nowej wartości dostarczonej z systemu za pomocą bramy. Chcesz osiągnąć punkt, w którym nowe możliwości wprowadzone przy użyciu bramy przewyższają koszt implementacji i utrzymania bramy. W zależności od relacji obciążenia z użytkownikami może być możliwe obciążenie zwrotne.

Aby ułatwić zarządzanie kosztami podczas opracowywania i testowania bramy, rozważ użycie symulowanego punktu końcowego dla usługi Azure OpenAI. Na przykład użyj rozwiązania w repozytorium GitHub symulatora interfejsu API platformy Azure OpenAI.

Sprawność operacyjna

Rozważając, w jaki sposób brama interfejsu API korzysta z architektury, użyj listy kontrolnej przeglądu projektu dla doskonałości operacyjnej , aby ocenić projekt. Należy uwzględnić zagadnienia dotyczące doskonałości operacyjnej, takie jak:

• Brama musi być monitorowana przez rozwiązanie do monitorowania obciążenia i potencjalnie przez klientów. Oznacza to, że obliczenia i operacje bramy muszą być uwzględnione w modelowaniu kondycji obciążenia.

• Twoje bezpieczne praktyki wdrażania muszą teraz dotyczyć wdrażania infrastruktury bramy interfejsu API oraz kodu lub konfiguracji routingu bramy. Rozwiązanie automatyzacji infrastruktury i infrastruktury jako kodu (IaC) musi rozważyć sposób traktowania bramy jako długotrwałego zasobu w obciążeniu.

• Musisz utworzyć lub rozszerzyć podejście apiOps, aby uwzględnić interfejsy API uwidocznione w bramie.

• Zduplikowane możliwości, które są dostępne za pośrednictwem rozwiązań, takich jak zasób usługi Azure AI Service lub funkcja dystrybucji obciążenia strefy danych Usługi Azure OpenAI.

Efektywność wydajności

Rozważając, w jaki sposób brama interfejsu API korzysta z architektury, użyj listy kontrolnej Przegląd projektu, aby ocenić swój projekt. Należy uwzględnić zagadnienia dotyczące wydajności, takie jak:

• Usługa bramy może wprowadzić wąskie gardło przepływności. Upewnij się, że brama ma odpowiednią wydajność do obsługi pełnego obciążenia współbieżnego i można ją łatwo skalować zgodnie z oczekiwaniami dotyczącymi wzrostu. Zapewnij elastyczność rozwiązania, aby brama mogła zmniejszyć podaż lub skalować w dół, gdy zapotrzebowanie jest niskie, na przykład przy użyciu dnia roboczego.

• Usługa bramy ma przetwarzanie, które musi wykonać na żądanie, i wprowadza dodatkowe opóźnienie dla wywołania interfejsu API. Należy zoptymalizować logikę routingu, aby zapewnić prawidłowe działanie żądań.

• W większości przypadków brama powinna być geograficznie zbliżona zarówno do użytkowników, jak i wystąpień usługi Azure OpenAI, aby zmniejszyć opóźnienie. Chociaż opóźnienie sieci jest zwykle niewielkim procentem czasu w ogólnych wywołaniach interfejsu API do modeli językowych, może to być czynnik konkurencyjny dla obciążenia.

• Oceń wpływ bramy na funkcje usługi Azure OpenAI, takie jak odpowiedzi przesyłania strumieniowego lub przypinanie wystąpień na potrzeby interakcji stanowych, takich jak interfejs API Asystentów.

Opcje implementacji

Platforma Azure nie oferuje gotowego rozwiązania przeznaczonego specjalnie do serwera proxy interfejsu API HTTP usługi Azure OpenAI ani innych niestandardowych interfejsów API wnioskowania modeli językowych w celu pokrycia wszystkich tych scenariuszy. Istnieje jednak jeszcze kilka opcji implementacji zespołu ds. obciążeń, takich jak brama na platformie Azure.

Korzystanie z usługi Azure API Management

Usługa Azure API Management to usługa zarządzana przez platformę przeznaczona do odciążania zagadnień dotyczących krzyżowych interfejsów API opartych na protokole HTTP. Jest on oparty na konfiguracji i obsługuje dostosowywanie za pośrednictwem systemu zasad przetwarzania żądań przychodzących i wychodzących. Obsługuje ona repliki o wysokiej dostępności, strefowo nadmiarowej, a nawet w wielu regionach przy użyciu jednej płaszczyzny sterowania.

Większość logiki routingu i obsługi żądań bramy musi być zaimplementowana w systemie zasad usługi API Management. Możesz połączyć wbudowane zasady specyficzne dla interfejsu Azure OpenAI, takie jak ograniczyć użycie tokenów interfejsu API usługi Azure OpenAI lub Emitować metryki do użycia tokenów usługi Azure OpenAIi własnych zasad niestandardowych. Repozytorium GitHub zestawu narzędzi bramy GenAI zawiera szereg niestandardowych zasad usługi API Management wraz z konfiguracją testowania obciążenia na potrzeby testowania zachowania zasad.

Skorzystaj z przewodnika po usłudze Well-Architected Framework dla usługi API Management podczas projektowania rozwiązania obejmującego usługę Azure API Management. Jeśli obciążenie istnieje w ramach strefy docelowej aplikacji, zapoznaj się ze wskazówkami dostępnymi w przewodniku Cloud Adoption Framework dla platformy Azure w celu zaimplementowania strefy docelowej usługi Azure API Management.

Korzystanie z usługi Azure API Management na potrzeby implementacji bramy jest zazwyczaj preferowanym podejściem do tworzenia i obsługi bramy usługi Azure OpenAI. Jest to preferowane, ponieważ usługa jest ofertą typu platforma jako usługa (PaaS) z zaawansowanymi wbudowanymi możliwościami, wysoką dostępnością i opcjami sieciowymi. Oferuje również niezawodne metody apiOps do zarządzania interfejsami API uzupełniania.

Używanie kodu niestandardowego

Podejście niestandardowego kodu wymaga od zespołu deweloperów oprogramowania utworzenia niestandardowego rozwiązania kodowanego i wdrożenia tego rozwiązania na wybranej platformie aplikacji platformy Azure. Tworzenie samodzielnego rozwiązania do obsługi logiki bramy może być dobrym rozwiązaniem dla zespołów obciążeń biegłych w zarządzaniu siecią i kodem routingu.

Obciążenie zazwyczaj może używać zasobów obliczeniowych, które znają, takich jak hostowanie kodu bramy w usłudze aplikacja systemu Azure Service, Azure Container Apps lub Azure Kubernetes Service.

Niestandardowe wdrożenia kodu można również frontonować za pomocą usługi API Management, gdy usługa API Management jest używana wyłącznie dla podstawowych funkcji bramy interfejsu API HTTP między klientami a kodem niestandardowym. W ten sposób niestandardowe interfejsy kodu wyłącznie z interfejsami API HTTP usługi Azure OpenAI oparte na niezbędnej logice biznesowej.

Użycie technologii bramy innej niż Microsoft, która jest produktem lub usługą, która nie jest natywnie dostarczana przez platformę Azure, można uznać za część tego podejścia.

Przykładowa architektura

Rysunek 2. Przykładowa architektura uzyskiwania dostępu do usługi Azure OpenAI za pośrednictwem bramy opartej na usłudze Azure API Management

Następne kroki

Dowiedz się więcej o konkretnym scenariuszu, w którym wdrażanie bramy między inteligentną aplikacją a wdrożeniami usługi Azure OpenAI jest używane do spełnienia wymagań dotyczących obciążenia:

• Równoważenie obciążenia lub tryb failover między wieloma wystąpieniami zaplecza
• Uwierzytelnianie niestandardowe i autoryzacja dla aplikacji klienckich

Dowiedz się, jak zaimplementować rejestrowanie i monitorowanie modeli usługi Azure OpenAI.

Powiązane zasoby

• Azure OpenAI Service
• Brama interfejsu API w usłudze Azure API Management
• Repozytorium GitHub strefy docelowej usługi API Management obejmujące generowanie scenariuszy sztucznej inteligencji
• Zestaw narzędzi bramy usługi API Management
• Symulator interfejsu API interfejsu OpenAI