Używanie bramy przed wieloma wdrożeniami lub wystąpieniami usługi Azure OpenAI

Architektury obciążeń, które obejmują usługę Azure OpenAI Service, mogą być proste, ponieważ co najmniej jedna aplikacja kliencka bezpośrednio korzysta z jednego wdrożenia modelu Usługi Azure OpenAI, ale nie wszystkie obciążenia można zaprojektować z taką prostotą. Bardziej złożone scenariusze obejmują topologie z wieloma klientami, wieloma wdrożeniami usługi Azure OpenAI lub wieloma wystąpieniami usługi Azure OpenAI. W takich sytuacjach wprowadzenie bramy przed usługą Azure OpenAI może być korzystne dla projektu obciążenia jako programowalnego mechanizmu routingu.

Wiele wystąpień usługi Azure OpenAI lub wdrożeń modeli rozwiązuje określone wymagania w architekturze obciążenia. Można je sklasyfikować w czterech kluczowych topologiach.

• Wiele wdrożeń modelu w jednym wystąpieniu usługi Azure OpenAI
• Wiele wystąpień usługi Azure OpenAI w jednym regionie i jednej subskrypcji
• Wiele wystąpień usługi Azure OpenAI w jednym regionie w wielu subskrypcjach
• Wiele wystąpień usługi Azure OpenAI w wielu regionach

Te topologie samodzielnie nie wymagają użycia bramy. Wybór bramy zależy od tego, czy obciążenie korzysta z jego włączenia do architektury. W tym artykule opisano wyzwania, z którymi borykają się poszczególne topologie, oraz korzyści i koszty związane z dołączeniem bramy w każdej topologii.

Wiele wdrożeń modelu w jednym wystąpieniu usługi Azure OpenAI

Szczegóły topologii dla wielu wdrożeń modelu

• Wdrożenia modeli usługi Azure OpenAI: wiele
• Wystąpienia usługi Azure OpenAI: jeden
• Subskrypcje: jedna
• Regiony: jeden

Przypadki użycia topologii dla wielu wdrożeń modelu

Topologia obejmująca jedno wystąpienie usługi Azure OpenAI, ale zawiera więcej niż jeden model wdrożony współbieżnie, obsługuje następujące przypadki użycia:

• Uwidacznianie różnych możliwości modelu, takich jak gpt-35-turbo, gpt-4i niestandardowe modele dostosowane.

• Uwidacznianie różnych wersji modeli, takich jak 0613, 1106i niestandardowych dostosowanych modeli w celu obsługi ewolucji obciążeń lub wdrożeń blue-green.

• Uwidacznianie różnych przydziałów przypisanych (30 000 tokenów na minutę ), 60 000 modułów TPM) w celu obsługi ograniczania zużycia w wielu klientach.

Wprowadzenie bramy dla wielu wdrożeń modelu

Wprowadzenie bramy do tej topologii ma przede wszystkim na celu abstrakcja klientów od samodzielnego wybierania określonego wystąpienia modelu wśród dostępnych wdrożeń w wystąpieniu. Brama umożliwia kontroli po stronie serwera kierowanie żądania klienta do określonego modelu bez konieczności ponownego wdrażania kodu klienta lub zmiany konfiguracji klienta.

Brama jest szczególnie przydatna, gdy nie kontrolujesz kodu klienta. Korzystne jest również wdrożenie konfiguracji klienta jest bardziej złożone lub ryzykowne niż wdrażanie zmian w konfiguracji routingu bramy. Możesz zmienić model, na który wskazuje klient, w oparciu o strategię niebieskiego zielonego wdrażania wersji modelu, taką jak wdrożenie nowego modelu dostosowanego lub przejście z wersji X do X+1 tego samego modelu.

Brama może być również używana jako pojedynczy punkt wejścia interfejsu API, który umożliwia bramie identyfikację klienta. Następnie może określić, które wdrożenie modelu jest używane do obsługi monitu na podstawie tożsamości tego klienta lub innych informacji w żądaniu HTTP. Na przykład w rozwiązaniu wielodostępnym dzierżawy mogą być ograniczone do określonej przepływności, a implementacja architektury jest wdrożeniem modelu na dzierżawę z określonymi limitami przydziału. W takim przypadku routing do modelu dzierżawy będzie odpowiedzialny za bramę na podstawie informacji w żądaniu HTTP.

Użycie bramy w tej topologii umożliwia śledzenie użycia oparte na kliencie. Jeśli klienci nie używają unikatowych jednostek usługi Microsoft Entra, dzienniki dostępu dla usługi Azure OpenAI nie będą mogły odróżnić wielu klientów. Posiadanie bramy przed wdrożeniem daje obciążeniu możliwość śledzenia użycia poszczególnych klientów w różnych dostępnych wdrożeniach modelu w celu obsługi modeli obciążenia zwrotnego lub pokazu zwrotnego.

Porady dotyczące topologii wielu wdrożeń modeli

• Chociaż brama jest w stanie całkowicie zmienić używany model, taki jak gpt-35-turbogpt-4, ta zmiana prawdopodobnie zostanie uznana za zmianę powodującą niezgodność w kliencie. Nie pozwól, aby nowe funkcje bramy odwracały uwagę od zawsze bezpiecznych praktyk wdrażania dla tego obciążenia.

• Ta topologia jest zwykle wystarczająco prosta, aby zaimplementować za pomocą zasad usługi Azure API Management zamiast niestandardowego rozwiązania kodu.

• Aby obsługiwać natywne użycie zestawów SDK przy użyciu opublikowanych specyfikacji interfejsów API usługi Azure OpenAI, zachowaj zgodność interfejsu API z interfejsem API usługi Azure OpenAI. Taka sytuacja jest większym problemem, gdy zespół nie jest autorem kodu wszystkich klientów obciążeń. Podczas podejmowania decyzji o projektowaniu interfejsu API HTTP dla bramy należy wziąć pod uwagę zalety zachowania zgodności interfejsu API HTTP usługi Azure OpenAI.

• Chociaż ta topologia technicznie obsługuje poświadczenia przekazywane klienta (tokeny dostępu lub klucz interfejsu API) dla wystąpienia usługi Azure OpenAI, zdecydowanie należy rozważyć zaimplementowanie zakończenia poświadczeń i ponowne opublikowanie. W ten sposób klient jest autoryzowany w bramie, a następnie brama jest autoryzowana za pośrednictwem kontroli dostępu opartej na rolach platformy Azure do wystąpienia usługi Azure OpenAI.

• Jeśli brama została zaprojektowana tak, aby korzystała z poświadczeń przekazywania, upewnij się, że klienci nie mogą pominąć bramy ani żadnych ograniczeń modelu opartych na kliencie.

• Wdróż bramę w tym samym regionie co wystąpienie usługi Azure OpenAI.

• Wdróż bramę w dedykowanej grupie zasobów w subskrypcji, która jest oddzielona od wystąpienia usługi Azure OpenAI. Izolowanie subskrypcji z zaplecza może pomóc w kierowania podejściem APIOps poprzez rozdzielenie obaw.

• Wdróż bramę w sieci wirtualnej, która zawiera podsieć dla prywatnego punktu końcowego usługi Azure Private Link wystąpienia usługi Azure OpenAI. Zastosuj reguły sieciowej grupy zabezpieczeń do tej podsieci, aby zezwolić na dostęp bramy tylko do tego prywatnego punktu końcowego. Wszystkie inne płaszczyzny danych dostępu do wystąpień usługi Azure OpenAI powinny być niedozwolone.

Przyczyny uniknięcia bramy dla wielu wdrożeń modelu

Jeśli kontrolowanie konfiguracji klientów jest tak proste, jak i łatwiejsze niż kontrolowanie routingu na poziomie bramy, dodatkowa niezawodność, bezpieczeństwo, koszty, konserwacja i wpływ bramy na wydajność mogą nie być warte dodania składnika architektury.

Ponadto niektóre scenariusze obciążeń mogą skorzystać z migracji z wielu metod wdrażania modelu do wielu metod wdrażania wystąpień usługi Azure OpenAI. Rozważmy na przykład wiele wystąpień usługi Azure OpenAI, jeśli masz wielu klientów, którzy powinni używać innej kontroli dostępu opartej na rolach lub kluczy dostępu w celu uzyskania dostępu do modelu. Użycie wielu wdrożeń w jednym wystąpieniu usługi Azure OpenAI i obsługa segmentacji tożsamości logicznej na poziomie bramy jest możliwe, ale może być nadmierne, gdy fizyczne podejście segmentacji RBAC jest dostępne przy użyciu odrębnych wystąpień usługi Azure OpenAI.

Wiele wystąpień usługi Azure OpenAI w jednym regionie i jednej subskrypcji

Szczegóły topologii dla wielu wystąpień w jednym regionie i jednej subskrypcji

• Wdrożenia modeli usługi Azure OpenAI: co najmniej jeden
• Wystąpienia usługi Azure OpenAI: wiele
• Subskrypcje: jedna
• Regiony: jeden

Przypadki użycia topologii dla wielu wystąpień w jednym regionie i jednej subskrypcji

Topologia obejmująca wiele wystąpień usługi Azure OpenAI w jednym regionie i pojedyncza subskrypcja obsługuje następujące przypadki użycia:

• Włącza granice segmentacji zabezpieczeń, takie jak klucz lub kontrola dostępu oparta na rolach na klienta

• Umożliwia łatwy model obciążenia zwrotnego dla różnych klientów

• Włącza strategię trybu failover dla dostępności usługi Azure OpenAI, taką jak awaria platformy, która ma wpływ na określone wystąpienie, błędną konfigurację sieci lub przypadkowo usunięte wdrożenie

• Umożliwia strategię trybu failover dla dostępności przydziału usługi Azure OpenAI, na przykład parowanie zarówno aprowizowanego wystąpienia, jak i wystąpienia standardowego na potrzeby przekazywania danych

Wprowadzenie bramy dla wielu wystąpień w jednym regionie i subskrypcji

Model może nie być dostępny dla klienta z kilku powodów. Przyczyny te obejmują zakłócenia w usłudze Azure OpenAI Service, żądania ograniczania usługi Azure OpenAI lub problemy związane z operacjami obciążeń, takimi jak błędna konfiguracja sieci lub przypadkowe usunięcie wdrożenia modelu. Aby sprostać tym wyzwaniom, należy zaimplementować logikę ponawiania prób i przerywania obwodu.

Tę logikę można zaimplementować po stronie klientów lub serwera w bramie. Implementowanie logiki w bramie powoduje abstrakcje logiki od klientów, co nie powoduje powtórzonego kodu i jednego miejsca do testowania logiki. Niezależnie od tego, czy jesteś właścicielem kodu klienta, czy nie, ta zmiana może zwiększyć niezawodność obciążenia.

Użycie bramy z wieloma wystąpieniami usługi Azure OpenAI w jednym regionie i subskrypcji pozwala traktować wszystkie zaplecza jako wdrożenia aktywne-aktywne, a nie tylko używać ich w trybie failover aktywny-pasywny. Możesz wdrożyć ten sam aprowizowany model w wielu wystąpieniach usługi Azure OpenAI i użyć bramy do równoważenia obciążenia między nimi.

Jedną z opcji, które zespół ds. obciążeń ma podczas aprowizacji usługi Azure OpenAI, jest decyzja, czy model rozliczeń i przepływności jest aprowizowany, czy standardowy. Strategia optymalizacji kosztów, która pozwala uniknąć strat za pośrednictwem nieużywanej aprowizowanej pojemności, jest nieco w ramach aprowizowania aprowizowanego wystąpienia, a także wdrożenia wystąpienia standardowego obok niego. Celem tej topologii jest, aby klienci najpierw zużywali całą dostępną wstępnie przydzieloną przepływność, a następnie "zwiększali się" do standardowego wdrożenia dla nadwyżki. Ta forma planowanego przejścia w tryb failover korzysta z tego samego powodu, jak wspomniano w akapicie początkowym tej sekcji: utrzymanie tej złożoności poza kodem klienta.

Gdy brama jest zaangażowana, jest to unikatowa pozycja do przechwytywania szczegółów dotyczących wszystkich klientów wdrożeń modelu, z którymi korzystają klienci. Chociaż każde wystąpienie usługi Azure OpenAI może przechwytywać własne dane telemetryczne, dzięki temu zespół obciążenia może publikować dane telemetryczne i odpowiedzi na błędy we wszystkich używanych modelach w jednym magazynie, co ułatwia ujednolicone pulpity nawigacyjne i alerty.

Porady dotyczące wielu wystąpień w jednym regionie i topologii subskrypcji

• Upewnij się, że brama korzysta z Retry-After informacji dostępnych w odpowiedzi HTTP z usługi Azure OpenAI podczas obsługi scenariuszy trybu failover w bramie. Użyj tych autorytatywnych informacji, aby kontrolować implementację wyłącznika. Nie należy stale osiągać punktu końcowego zwracającego wartość 429 Too Many Requests. Zamiast tego należy przerwać obwód dla tego wystąpienia modelu.

• Próba przewidywania zdarzeń ograniczania przepustowości przed ich wykonaniem przez śledzenie użycia modelu za pośrednictwem wcześniejszych żądań jest możliwa w bramie, ale jest obarczona przypadkami brzegowymi. W większości przypadków najlepiej nie próbować przewidywać, ale używać kodów odpowiedzi HTTP do podejmowania przyszłych decyzji dotyczących routingu.

• W przypadku przechodzenia okrężnego lub przełączania w tryb failover do innego punktu końcowego, w tym aprowizowanego rozlania do standardowych wdrożeń, zawsze upewnij się, że te punkty końcowe korzystają z tego samego modelu w tej samej wersji. Na przykład nie przejmij trybu failover z gpt-4 do gpt-35-turbo lub z wersji X do wersji X+1 ani równoważenia obciążenia między nimi. Ta zmiana wersji może spowodować nieoczekiwane zachowanie klientów.

• Równoważenie obciążenia i logika trybu failover można zaimplementować w ramach zasad usługi Azure API Management. Możesz zapewnić bardziej zaawansowane podejście przy użyciu rozwiązania bramy opartego na kodzie, ale usługa API Management jest wystarczająca dla tego przypadku użycia.

• Wdróż bramę w tym samym regionie co wystąpienie usługi Azure OpenAI.

• Wdróż bramę w dedykowanej grupie zasobów w subskrypcji, która jest oddzielona od wystąpień usługi Azure OpenAI. Odizolowanie bramy od zaplecza może pomóc w uzyskaniu podejścia APIOps dzięki separacjom problemów.

• Kolokuj wszystkie prywatne punkty końcowe usługi Private Link wystąpienia usługi Azure OpenAI w jedną podsieć w sieci wirtualnej bramy. Zastosuj reguły sieciowej grupy zabezpieczeń do tej podsieci, aby zezwolić na dostęp bramy tylko do tych prywatnych punktów końcowych. Wszystkie inne płaszczyzny danych dostępu do wystąpień usługi Azure OpenAI powinny być niedozwolone.

• Aby uprościć logikę w kodzie routingu bramy, użyj tej samej nazwy wdrożenia modelu, aby zminimalizować różnicę między trasami HTTP. Na przykład nazwa modelu gpt4-v1 może być używana we wszystkich wystąpieniach o zrównoważonym obciążeniu lub rozlaniu, niezależnie od tego, czy jest to standardowa, czy aprowizowana.

Przyczyny uniknięcia bramy dla wielu wystąpień w jednym regionie i subskrypcji

Sama brama nie zwiększa możliwości ładowania zwrotnego modeli dla różnych klientów dla tej konkretnej topologii. W tej topologii klienci mogą mieć dostęp do własnych dedykowanych wystąpień usługi Azure OpenAI, które będą obsługiwać możliwość wykonywania obciążeń zwrotnych lub pokazowych. Ten model obsługuje unikatowe obwody tożsamości i sieci, więc brama nie musi być wprowadzana specjalnie na potrzeby segmentacji.

Jeśli masz kilku klientów w obszarze, w którym kontrolujesz kod, a klienci są łatwo aktualizowani, logika, którą trzeba będzie zbudować w bramie, można dodać bezpośrednio do kodu. Rozważ użycie podejścia bramy do trybu failover lub równoważenia obciążenia głównie wtedy, gdy nie jesteś właścicielem kodu klienta lub złożoność jest zbyt duża, aby klienci obsługiwali.

Jeśli używasz bramy specjalnie do rozwiązywania ograniczeń pojemności, sprawdź, czy funkcje pojemności oparte na strefie danych są wystarczające dla obciążenia.

Wiele wystąpień usługi Azure OpenAI w jednym regionie w wielu subskrypcjach

Szczegóły topologii dla wielu wystąpień usługi Azure OpenAI w jednym regionie w wielu subskrypcjach

• Wdrożenia modeli usługi Azure OpenAI: co najmniej jeden
• Wystąpienia usługi Azure OpenAI: wiele
• Subskrypcje: wiele
• Regiony: jeden

Przypadki użycia topologii dla wielu wystąpień usługi Azure OpenAI w jednym regionie w wielu subskrypcjach

Topologia obejmująca wiele wystąpień usługi Azure OpenAI w jednym regionie w wielu subskrypcjach obsługuje następujące przypadki użycia:

• Obejmuje wszystkie przypadki użycia wymienione dla wielu wystąpień usługi Azure OpenAI w jednym regionie i jednej subskrypcji.

• Chcesz uzyskać większy limit przydziału we standardowym wdrożeniu i należy ograniczyć użycie modeli do jednego, określonego regionu.

  Uwaga

  Jeśli nie musisz ograniczać używania modeli do określonego regionu, należy użyć globalnej lub strefy danych wdrożeń usługi Azure OpenAI, które wykorzystują globalną infrastrukturę platformy Azure do dynamicznego kierowania żądań wnioskowania do centrów danych z dostępną pojemnością.

Wprowadzenie bramy dla wielu wystąpień w jednym regionie i wielu subskrypcjach

Te same przyczyny, które zostały omówione w temacie Wprowadzenie bramy dla wielu wystąpień w jednym regionie i subskrypcji mają zastosowanie do tej topologii.

Oprócz tych powodów dodanie bramy w tej topologii obsługuje również scentralizowany zespół udostępniający model "Azure OpenAI jako usługa" dla swojej organizacji. Ponieważ limit przydziału we standardowym wdrożeniu jest powiązany z subskrypcją, scentralizowany zespół, który udostępnia usługi Azure OpenAI korzystające ze standardowego wdrożenia, musi wdrożyć wystąpienia usługi Azure OpenAI w wielu subskrypcjach w celu uzyskania wymaganego limitu przydziału. Logika bramy nadal pozostaje w dużej mierze taka sama.

Porady dotyczące wielu wystąpień w jednym regionie i wielu topologii subskrypcji

• W idealnym przypadku wszystkie subskrypcje powinny być objęte tą samą dzierżawą firmy Microsoft Entra w celu zapewnienia spójności w ramach kontroli dostępu opartej na rolach platformy Azure i usługi Azure Policy.

• Wdróż bramę w tym samym regionie co wystąpienie usługi Azure OpenAI.

• Wdróż bramę w dedykowanej subskrypcji, która jest oddzielona od wystąpień usługi Azure OpenAI. Pomaga to wymusić spójność w rozwiązywaniu problemów z wystąpieniami usługi Azure OpenAI i zapewnia logiczną segmentację obowiązków między wdrożeniami usługi Azure OpenAI i ich routingiem.

• Podczas routingu żądań z bramy między subskrypcjami upewnij się, że prywatne punkty końcowe są osiągalne. Możesz użyć routingu przechodniego za pośrednictwem koncentratora do prywatnych punktów końcowych zaplecza w odpowiednich szprychach. Możesz uwidocznić prywatne punkty końcowe dla usług Azure OpenAI bezpośrednio w subskrypcji bramy przy użyciu połączeń usługi Private Link między subskrypcjami. Połączenia usługi Private Link między subskrypcjami są preferowane, jeśli twoja architektura i organizacja obsługują to podejście.

Przyczyny uniknięcia bramy dla wielu wystąpień w jednym regionie i wielu subskrypcjach

Wszystkie powody, aby uniknąć bramy dla wielu wystąpień w jednym regionie i subskrypcji mają zastosowanie do tej topologii.

Wiele wystąpień usługi Azure OpenAI w wielu regionach

Szczegóły topologii dla wielu wystąpień usługi Azure OpenAI w wielu regionach

• Wdrożenia modeli usługi Azure OpenAI: wiele
• Wystąpienia usługi Azure OpenAI: wiele
• Subskrypcje: co najmniej jedna
• Regiony: wiele

Przypadki użycia topologii dla wielu wystąpień usługi Azure OpenAI w wielu regionach

Topologia obejmująca wiele wystąpień usługi Azure OpenAI rozmieszczonych w co najmniej dwóch regionach świadczenia usługi Azure obsługuje następujące przypadki użycia:

• Zawiera wszystkie przypadki użycia wymienione dla wielu wystąpień usługi Azure OpenAI w jednym regionie w wielu subskrypcjach.

• Włącza strategię przejścia w tryb failover na potrzeby dostępności usługi, na przykład przy użyciu par między regionami.

• Umożliwia projektowanie rezydencji danych i zgodności.

• Umożliwia dostępność modelu mieszanego. Niektóre regiony mają różne modele i różne limity przydziału dostępne dla modeli.

Chociaż technicznie nie ma różnych regionów świadczenia usługi Azure, ta topologia ma zastosowanie również w przypadku wystąpienia modelu sztucznej inteligencji w sytuacji obejmującej wiele lokalizacji, takich jak lokalna lub w innej chmurze.

Wprowadzenie bramy dla wielu wystąpień w wielu regionach

W przypadku architektur o znaczeniu krytycznym dla działania firmy, które muszą przetrwać kompletną awarię regionalną, globalna, ujednolicona brama pomaga wyeliminować logikę trybu failover z kodu klienta. Ta implementacja wymaga, aby brama nie miała wpływu na awarię regionalną.

Korzystanie z usługi Azure API Management (wdrażanie w jednym regionie)

W tej topologii usługa Azure API Management jest używana specjalnie dla technologii bramy. W tym miejscu usługa API Management jest wdrażana w jednym regionie. W tym wystąpieniu bramy wykonujesz równoważenie obciążenia aktywne-aktywne w różnych regionach. Zasady w bramie odwołują się do wszystkich wystąpień usługi Azure OpenAI. Brama wymaga widoku sieci do każdego zaplecza w różnych regionach za pośrednictwem komunikacji równorzędnej sieci wirtualnych między regionami lub prywatnych punktów końcowych. Wywołania z tej bramy do wystąpienia usługi Azure OpenAI w innym regionie powodują większe opóźnienie sieci i opłaty za ruch wychodzący.

Brama musi honorować sygnały ograniczania przepustowości i dostępności z wystąpień usługi Azure OpenAI i usuwać uszkodzone zaplecza z puli do momentu bezpiecznego odczytania uszkodzonego lub ograniczonego wystąpienia usługi Azure OpenAI. Brama powinna ponowić bieżące żądanie względem innego wystąpienia zaplecza w puli po awarii, zanim powróci do zwracania błędu bramy. Kontrola kondycji bramy powinna sygnalizować złą kondycję, gdy nie są dostępne żadne wystąpienia usługi Azure OpenAI zaplecza.

Ponieważ ta topologia wprowadza pojedynczy punkt awarii (bramy), narzędzie tej konkretnej architektury jest dość ograniczone — ochrona przed regionalnymi awariami punktów końcowych usługi Azure OpenAI.

Wariant aktywny-pasywny

Ten model może również służyć do zapewnienia aktywnego pasywnego podejścia do obsługi awarii regionalnej tylko usługi Azure OpenAI. W tym trybie ruch zwykle przepływa z bramy do wystąpienia usługi Azure OpenAI w tym samym regionie co usługa API Management. To wystąpienie usługi Azure OpenAI obsłuży cały oczekiwany przepływ ruchu bez wystąpienia regionalnych awarii. Może to być aprowidowane lub standardowe, w zależności od preferowanego modelu rozliczeniowego. W przypadku awarii regionalnej tylko usługi Azure OpenAI brama może przekierowywać ruch do innego regionu przy użyciu usługi Azure OpenAI już wdrożonego we standardowym wdrożeniu.

Korzystanie z usługi Azure API Management (wdrażanie w wielu regionach)

Aby zwiększyć niezawodność wcześniejszej architektury opartej na usłudze Azure API Management, usługa API Management obsługuje wdrażanie wystąpienia w wielu regionach świadczenia usługi Azure. Ta opcja wdrażania zapewnia jedną płaszczyznę sterowania za pośrednictwem pojedynczego wystąpienia usługi API Management, ale udostępnia replikowane bramy w wybranym regionie. W tej topologii wdrażasz składniki bramy w każdym regionie zawierającym wystąpienia usługi Azure OpenAI, które zapewniają architekturę bramy aktywne-aktywne.

Zasady, takie jak logika routingu i obsługi żądań, są replikowane do każdej bramy. Cała logika zasad musi mieć logikę warunkową w zasadach, aby upewnić się, że wywołujesz wystąpienia usługi Azure OpenAI w tym samym regionie co bieżąca brama. Aby uzyskać więcej informacji, zobacz Route API calls to regional back end services (Kierowanie wywołań interfejsu API do regionalnych usług zaplecza). Składnik bramy wymaga następnie połączenia sieciowego tylko z wystąpieniami usługi Azure OpenAI we własnym regionie, zwykle za pośrednictwem prywatnych punktów końcowych.

Usługa API Management oferuje gotowe do użycia routing globalnie w pełni kwalifikowanej nazwy domeny (FQDN) na podstawie najmniejszego opóźnienia. Użyj tej wbudowanej funkcji opartej na wydajności dla wdrożeń bramy aktywne-aktywne. Ta wbudowana funkcja ułatwia rozwiązywanie problemów z wydajnością i obsługą awarii bramy regionalnej. Wbudowany router globalny obsługuje również testowanie odzyskiwania po awarii, ponieważ regiony można symulować przez wyłączenie poszczególnych bram. Upewnij się, że klienci przestrzegają czasu wygaśnięcia (TTL) w nazwie FQDN i mają odpowiednią logikę ponawiania prób do obsługi ostatniego trybu failover DNS.

Jeśli musisz wprowadzić zaporę aplikacji internetowej do tej architektury, nadal możesz użyć wbudowanego rozwiązania routingu nazw FQDN jako źródła zaplecza dla routera globalnego, który implementuje zaporę aplikacji internetowej. Router globalny deleguje odpowiedzialność za przejście w tryb failover do usługi API Management. Alternatywnie można użyć regionalnych nazw FQDN bramy jako elementów członkowskich puli zaplecza. W tej drugiej architekturze użyj wbudowanego /status-0123456789abcdef punktu końcowego w każdej bramie regionalnej lub innego niestandardowego punktu końcowego interfejsu API kondycji do obsługi regionalnego trybu failover. Jeśli nie masz pewności, zacznij od podejścia FQDN pojedynczego źródła.

Ta architektura działa najlepiej, jeśli można traktować regiony jako w pełni dostępne lub w pełni niedostępne. Oznacza to, że jeśli brama usługi API Management lub wystąpienie usługi Azure OpenAI jest niedostępne, ruch klienta nie będzie już kierowany do bramy usługi API Management w tym regionie. Jeśli nie zostanie zainicjowana inna aprowizacja, jeśli brama regionalna nadal akceptuje ruch, gdy usługa Azure OpenAI jest niedostępna, należy propagować błąd do klienta. Aby uniknąć błędu klienta, zobacz ulepszone podejście w bramie Aktywne-aktywne oraz wariant active-passive Azure OpenAI.

Jeśli w regionie występuje awaria bramy usługi API Management lub jest oznaczona jako w złej kondycji, pozostałe dostępne regiony muszą absorbować 100% ruchu z tych innych regionów. Oznacza to, że musisz aprowizować aprowizowane wystąpienia usługi Azure OpenAI, aby obsługiwać nowy wzrost ruchu lub użyć podejścia aktywne-pasywne dlatrybu failover. Skorzystaj z kalkulatora pojemności usługi Azure OpenAI na potrzeby planowania pojemności.

Upewnij się, że grupa zasobów zawierająca usługę Azure API Management jest tą samą lokalizacją co wystąpienie usługi API Management, aby zmniejszyć promień wybuchu powiązanej regionalnej awarii wpływającej na możliwość uzyskania dostępu do dostawcy zasobów dla bram.

Brama active-active oraz wariant active-passive Azure OpenAI

W poprzedniej sekcji przedstawiono dostępność bramy, zapewniając topologię bramy aktywne-aktywne. Ta topologia łączy bramę active-active-active z ekonomiczną topologią active-passive Azure OpenAI. Dodanie logiki aktywne-pasywnej do bramy w celu przejścia w tryb failover do standardowego wdrożenia usługi Azure OpenAI z aprowizowanego wdrożenia może znacznie zwiększyć niezawodność obciążenia. Ten model nadal umożliwia klientom korzystanie z wbudowanego rozwiązania routingu FQDN usługi API Management na potrzeby routingu opartego na wydajności.

Używanie niestandardowej bramy kodowanej

Jeśli reguły routingu dla bramy są zbyt złożone, aby zespół rozważył rozsądne zasady usługi Azure API Management, musisz wdrożyć własne rozwiązanie i zarządzać nim. Ta architektura musi być wdrożeniem bramy w wielu regionach z jedną jednostką skalowania o wysokiej dostępności na region. Należy kierować te wdrożenia przy użyciu usługi Azure Front Door (Anycast) lub usługi Azure Traffic Manager (DNS), zazwyczaj przy użyciu routingu opartego na opóźnieniach i odpowiednich kontroli kondycji dostępności bramy.

Użyj usługi Azure Front Door, jeśli potrzebujesz zapory aplikacji internetowej i publicznego dostępu do Internetu. Użyj usługi Traffic Manager, jeśli nie potrzebujesz zapory aplikacji internetowej, a czas wygaśnięcia DNS jest wystarczający. Podczas frontowania wystąpień bramy za pomocą usługi Azure Front Door (lub dowolnego zwrotnego serwera proxy) upewnij się, że brama nie może zostać pominięta. Udostępnij wystąpienia bramy tylko za pośrednictwem prywatnego punktu końcowego, gdy używasz usługi Azure Front Door, i dodaj walidację nagłówka X_AZURE_FDID HTTP w implementacji bramy.

Umieść zasoby dla poszczególnych regionów, które są używane w bramie niestandardowej w grupach zasobów poszczególnych regionów. Zmniejsza to promień wybuchu powiązanej regionalnej awarii wpływające na możliwość uzyskania dostępu do dostawcy zasobów dla zasobów bramy w tym regionie.

Możesz również rozważyć fronting implementacji logiki bramy za pomocą usługi Azure API Management, aby uzyskać inne korzyści z usługi API Management, takie jak TLS, uwierzytelnianie, sprawdzanie kondycji lub równoważenie obciążenia z działaniem okrężnym. Dzięki temu typowe problemy z interfejsem API są zmieniane z kodu niestandardowego w bramie i umożliwiają bramie rozwiązanie problemu z wystąpieniem usługi Azure OpenAI i routingiem wdrażania modelu.

Aby zapewnić zgodność miejsca przechowywania danych, upewnij się, że każda granica geopolityczna ma własne izolowane wdrożenie tej architektury i że klienci mogą uzyskać dostęp tylko do autoryzowanego punktu końcowego.

Przyczyny uniknięcia bramy dla wielu wystąpień w wielu regionach

Nie implementuj ujednoliconej bramy w różnych regionach geopolitycznych, gdy jest wymagana rezydencja danych i zgodność. W ten sposób naruszałoby to wymagania dotyczące przechowywania danych. Używaj indywidualnie adresowalnych bram na region i postępuj zgodnie ze wskazówkami w jednej z poprzednich sekcji.

Nie implementuj ujednoliconej bramy wyłącznie w celu zwiększenia limitu przydziału. Użyj globalne wdrożenia usługi Azure OpenAI wykorzystują globalną infrastrukturę platformy Azure do dynamicznego kierowania żądań do centrów danych z najlepszą pojemnością dla każdego żądania.

Jeśli klienci nie mają przejść w tryb failover między regionami i masz możliwość nadania klientom określonej bramy do użycia, zamiast tego należy użyć wielu bram, jednej na region i postępować zgodnie ze wskazówkami w jednej z poprzednich sekcji. Nie należy wiązać dostępności innych regionów z regionem zawierającym bramę jako pojedynczy punkt awarii.

Nie implementuj ujednoliconej bramy, jeśli model i wersja nie są dostępne we wszystkich regionach uwidocznionych przez bramę. Klienci muszą być kierowani do tego samego modelu i tej samej wersji modelu. W przypadku bram z równoważeniem obciążenia w wielu regionach i trybu failover należy wybrać wspólny model i wersję modelu, która jest dostępna we wszystkich zaangażowanych regionach. Aby uzyskać więcej informacji, zobacz Dostępność modelu. Jeśli nie możesz standaryzacji w modelu i wersji modelu, korzyść z bramy jest ograniczona.

Zalecenia ogólne

Niezależnie od tego, której topologii wymaga obciążenie, istnieje kilka zaleceń dotyczących krzyżowego uwzględnienia podczas tworzenia rozwiązania bramy.

Interakcje stanowe

Gdy klienci korzystają z funkcji stanowych usługi Azure OpenAI, takich jak interfejs API Asystentów, należy skonfigurować bramę, aby przypiąć klienta do określonego zaplecza podczas tej interakcji. Można to zrobić, przechowując dane wystąpienia w pliku cookie. W tych scenariuszach rozważ zwrócenie odpowiedzi interfejsu API, takiej jak 429 do przypiętego klienta, zamiast przekierowywania ich do innego wystąpienia usługi Azure OpenAI. Dzięki temu klient może jawnie obsługiwać nagłe niedostępności, ukrywając je i kierowany do wystąpienia modelu, które nie ma historii.

Sprawdzanie kondycji bramy

Istnieją dwie perspektywy kontroli kondycji, które należy wziąć pod uwagę, niezależnie od topologii.

Jeśli brama jest wbudowana w działanie okrężne lub ściśle wykonuje tryb failover dostępności usługi, chcesz przejąć stan dostępności wystąpienia usługi Azure OpenAI (lub modelu). Usługa Azure OpenAI nie udostępnia żadnego punktu końcowego sprawdzania kondycji, aby preemptively wiedzieć, czy jest dostępna do obsługi żądań. Możesz wysyłać syntetyczne przejścia, ale zużywa pojemność modelu. Jeśli nie masz innego niezawodnego źródła sygnału dla wystąpienia i dostępności modelu usługi Azure OpenAI, brama prawdopodobnie powinna zakładać, że wystąpienie usługi Azure OpenAI jest uruchomione, a następnie obsługuje 429500503 kody stanu HTTP jako sygnał do przerwania obwodu dla przyszłych żądań w tym wystąpieniu lub modelu przez jakiś czas. W przypadku sytuacji ograniczania zawsze należy przestrzegać danych w nagłówku znajdującym się w odpowiedziach interfejsu Retry-After API usługi Azure OpenAI dla 429 kodów odpowiedzi w logice przerywania obwodu. Jeśli używasz usługi Azure API Management, oceń użycie wbudowanej funkcji wyłącznika .

Klienci lub zespół ds. operacji obciążeń mogą chcieć mieć kontrolę kondycji uwidocznioną w bramie na potrzeby routingu lub introspekcji. Jeśli używasz usługi API Management, wartość domyślna /status-0123456789abcdef może nie być wystarczająco szczegółowa, ponieważ dotyczy głównie wystąpienia bramy usługi API Management, a nie zaplecza. Rozważ dodanie dedykowanego interfejsu API sprawdzania kondycji, który może zwracać istotne dane do klientów lub systemów obserwacji w zakresie dostępności bramy lub określonych tras w bramie.

Praktyki bezpiecznego wdrażania

Implementacje bramy umożliwiają organizowanie niebieskich zielonych wdrożeń zaktualizowanych modeli. Modele usługi Azure OpenAI są aktualizowane przy użyciu nowych wersji modelu i nowych modeli. Być może masz nowe modele dostosowane.

Po przetestowaniu skutków zmiany w przedprodukcji należy ocenić, czy klienci produkcyjni powinni być "przecięci" do nowej wersji modelu, czy zamiast tego przenieść ruch. Opisany wcześniej wzorzec bramy umożliwia zapleczu równoczesne wdrożenie obu modeli. Wdrażanie modeli jednocześnie zapewnia bramie możliwość przekierowywania ruchu na podstawie bezpiecznej praktyki wdrażania przyrostowego zespołu obciążeń.

Nawet jeśli nie używasz wdrożeń niebiesko-zielonych, podejście APIOps obciążenia musi być zdefiniowane i wystarczająco zautomatyzowane z szybkością zmian wystąpień zaplecza i wdrożeń modelu.

Wystarczająca liczba implementacji

Wiele scenariuszy wprowadzonych w tym artykule pomaga zwiększyć potencjalny cel poziomu usług (SLO) obciążenia przez zmniejszenie złożoności klienta i zaimplementowanie niezawodnych technik samozachowawczych. Inni zwiększają bezpieczeństwo obciążenia, przenosząc mechanizmy kontroli dostępu do określonych modeli z dala od usługi Azure OpenAI. Upewnij się, że wprowadzenie bramy nie kończy się licznikiem pracy dla tych celów. Zapoznaj się z ryzykiem dodawania nowego pojedynczego punktu awarii za pośrednictwem błędów usługi lub problemów z konfiguracją spowodowanych przez człowieka w bramie, złożonej logice routingu lub ryzyka ujawnienia większej liczby modeli nieautoryzowanym klientom niż jest to zamierzone.

Niezależność danych

Różne podejścia aktywne-aktywne i aktywne-pasywne należy ocenić z perspektywy zgodności rezydencji danych dla obciążenia. Wiele z tych wzorców będzie miało zastosowanie do architektury obciążenia, jeśli zaangażowane regiony pozostają w granicach geopolitycznych. Aby obsługiwać ten scenariusz, należy traktować granice geopolityczne jako izolowane sygnatury i stosować obsługę aktywne-aktywne lub aktywne-pasywne wyłącznie w ramach tej sygnatury.

W szczególności każdy routing oparty na wydajności musi być wysoce przeanalizowany pod kątem zgodności niezależności danych. W scenariuszach niezależności danych nie można obsługiwać klientów z inną lokalizacją geograficzną i zachować zgodność. Wszystkie architektury bramy, które obejmują rezydencję danych, muszą wymuszać, aby klienci używali tylko punktów końcowych w ich regionie geopolitycznym. Klienci muszą być zablokowani przy użyciu innych punktów końcowych bramy, a sama brama nie narusza zaufania klienta przez utworzenie żądania międzypolitycznego. Najbardziej niezawodnym sposobem wdrożenia tej segmentacji jest utworzenie architektury wokół w pełni niezależnej, wysoce dostępnej bramy na region geopolityczny.

Rozważając, czy korzystać ze zwiększonej pojemności za pośrednictwem globalnej, czy stref danych wdrożeniach usługi Azure OpenAI, musisz zrozumieć, w jaki sposób te wdrożenia wpływają na miejsce przechowywania danych. Dane przechowywane w spoczynku pozostają w wyznaczonej lokalizacji geograficznej platformy Azure zarówno dla wdrożeń globalnych, jak i wdrożeń stref danych. Te dane mogą być przesyłane i przetwarzane do wnioskowania w dowolnej lokalizacji usługi Azure OpenAI dla wdrożeń globalnych lub w dowolnej lokalizacji usługi Azure OpenAI w określonej strefie danych firmy Microsoft na potrzeby wdrożeń stref danych.

Autoryzacja usługi Azure OpenAI

Brama musi uwierzytelniać się przy użyciu wszystkich wystąpień usługi Azure OpenAI, z którymi interfejsy. Jeśli brama nie została zaprojektowana pod kątem uwierzytelniania przekazywanego, brama powinna używać tożsamości zarządzanej dla jej poświadczeń. Dlatego każde wystąpienie usługi Azure OpenAI musi skonfigurować najmniej uprzywilejowaną kontrolę dostępu opartą na rolach dla tożsamości zarządzanych bram. W przypadku architektur aktywnych i trybu failover upewnij się, że tożsamość bramy ma równoważne uprawnienia we wszystkich zaangażowanych wystąpieniach usługi Azure OpenAI.

Azure Policy

Spójność między wdrożeniami modelu a wystąpieniami usługi Azure OpenAI jest ważna zarówno w sytuacjach aktywne-aktywne, jak i aktywne-pasywne. Użyj usługi Azure Policy, aby wymusić spójność między różnymi wystąpieniami usługi Azure OpenAI lub wdrożeniami modeli. Jeśli wbudowane zasady usługi Azure OpenAI nie są wystarczające, aby zapewnić spójność między nimi, rozważ utworzenie lub użycie zasad niestandardowych utworzonych przez społeczność.

Nadmiarowość bramy

Chociaż nie jest specyficzny dla wielu zapleczy, implementacja bramy każdego regionu powinna być zawsze kompilowana z nadmiarowością i być wysoce dostępna w ramach jednostki skalowania. Wybierz regiony ze strefami dostępności i upewnij się, że brama jest rozłożona na nich. Wdróż wiele wystąpień bramy, aby pojedynczy punkt awarii był ograniczony do całkowitej awarii regionalnej, a nie do błędu pojedynczego wystąpienia obliczeniowego w bramie. W przypadku usługi Azure API Management wdróż co najmniej dwie jednostki w co najmniej dwóch strefach. W przypadku niestandardowych implementacji kodu należy wdrożyć co najmniej trzy wystąpienia z najlepszą dystrybucją w różnych strefach dostępności.

Implementacje bramy

Platforma Azure nie oferuje kompletnego rozwiązania kluczowego ani architektury referencyjnej do tworzenia takiej bramy, która koncentruje się na routingu ruchu między wieloma zapleczami. Jednak usługa Azure API Management jest preferowana, ponieważ usługa udostępnia rozwiązanie oparte na usłudze PaaS przy użyciu wbudowanych funkcji, takich jak pule zaplecza, zasady powodujące niezgodność obwodów i niestandardowe zasady w razie potrzeby. Zobacz Omówienie możliwości bramy generowania sztucznej inteligencji w usłudze Azure API Management, aby ocenić, co jest dostępne w tej usłudze na potrzeby wielu zaplecza obciążenia.

Niezależnie od tego, czy używasz usługi API Management, czy tworzysz rozwiązanie niestandardowe, jak wspomniano w artykule dotyczącym wprowadzenia , zespół obciążenia musi skompilować i obsługiwać tę bramę. Poniżej przedstawiono przykłady obejmujące niektóre z wcześniej wymienionych przypadków użycia. Rozważ odwołanie się do tych przykładów podczas tworzenia własnego weryfikacji koncepcji przy użyciu usługi API Management lub kodu niestandardowego.

Implementacja	Przykład
Usługa Azure API Management	Inteligentne równoważenie obciążenia dla usługi Azure OpenAI przy użyciu usługi Azure API Management — to repozytorium GitHub zawiera przykładowy kod zasad i instrukcje wdrażania w ramach subskrypcji. skalowanie usługi Azure OpenAI przy użyciu usługi Azure API Management — to repozytorium GitHub zawiera przykładowy kod zasad i instrukcje dotyczące aprowizowania i standardowego przekazywania danych. Zestaw narzędzi bramy GenAI zawiera przykładowe zasady usługi API Management wraz z konfiguracją testowania obciążenia na potrzeby testowania zachowania zasad.
Kod niestandardowy	Inteligentne równoważenie obciążenia dla usługi Azure OpenAI przy użyciu usługi Azure Container Apps To repozytorium GitHub zawiera przykładowy kod języka C# i instrukcje dotyczące kompilowania kontenera i wdrażania w ramach subskrypcji.

Przewodnik Cloud Adoption Framework dla platformy Azure zawiera również wskazówki dotyczące implementowania strefy docelowej usługi Azure API Management na potrzeby scenariuszy generowania sztucznej inteligencji, w tym tego scenariusza obejmującego wiele zaplecza. Jeśli obciążenie istnieje w strefie docelowej aplikacji, zapoznaj się z tym wskazówkami dotyczącymi zagadnień i zaleceń dotyczących implementacji.

Następne kroki

Implementacja bramy dla obciążenia zapewnia korzyści wykraczające poza taktyczne korzyści z routingu wielu zaplecza opisane w tym artykule. Dowiedz się więcej o innych kluczowych wyzwaniach , jakie może rozwiązać brama.

Powiązane zasoby

• Azure OpenAI Service
• Projektowanie dobrze zaprojektowanego obciążenia sztucznej inteligencji
• Brama interfejsu API w usłudze Azure API Management