Använda en gateway framför flera Azure OpenAI-distributioner eller instanser

Arbetsbelastningsarkitekturer som omfattar Azure OpenAI Service kan vara lika enkla som ett eller flera klientprogram som direkt förbrukar en enskild Azure OpenAI-modelldistribution direkt, men inte alla arbetsbelastningar kan utformas med sådan enkelhet. Mer komplexa scenarier är topologier med flera klienter, flera Azure OpenAI-distributioner eller flera Azure OpenAI-instanser. I sådana situationer kan det vara fördelaktigt att introducera en gateway framför Azure OpenAI för arbetsbelastningens utformning.

Flera Azure OpenAI-instanser eller modelldistributioner löser specifika krav i en arbetsbelastningsarkitektur. De kan klassificeras i fyra viktiga topologier.

• Flera modelldistributioner i en enda Azure OpenAI-instans
• Flera Azure OpenAI-instanser i en enda region och en enda prenumeration
• Flera Azure OpenAI-instanser i en enda region i flera prenumerationer
• Flera Azure OpenAI-instanser i flera regioner

Dessa topologier på egen hand kräver inte användning av en gateway. Valet av en gateway beror på om arbetsbelastningen drar nytta av dess inkludering i arkitekturen. Den här artikeln beskriver de utmaningar som var och en av de fyra topologierna hanterar och fördelarna och kostnaderna med att inkludera en gateway i varje topologi.

Flera modelldistributioner i en enda Azure OpenAI-instans

Topologiinformation för flera modelldistributioner

• Azure OpenAI-modelldistributioner: flera
• Azure OpenAI-instanser: en
• Prenumerationer: en
• Regioner: en

Användningsfall för topologi för flera modelldistributioner

En topologi som innehåller en enda Azure OpenAI-instans men som innehåller mer än en samtidigt distribuerad modell stöder följande användningsfall:

• Exponera olika modellfunktioner, till exempel gpt-35-turbo, gpt-4och anpassade finjusterade modeller.

• Exponera olika modellversioner, till exempel 0613, 1106och anpassade finjusterade modeller för att stödja arbetsbelastningsutveckling eller blågröna distributioner.

• Exponera olika tilldelade kvoter (30 000 token per minut (TPM), 60 000 TPM) för att stödja förbrukningsbegränsning för flera klienter.

Introducera en gateway för flera modelldistributioner

Att introducera en gateway i den här topologin är främst avsett att abstrahera klienter från att själv välja en specifik modellinstans bland de tillgängliga distributionerna på instansen. En gateway gör det möjligt för kontroll på serversidan att dirigera en klientbegäran till en specifik modell utan att behöva distribuera om klientkoden eller ändra klientkonfigurationen.

En gateway är särskilt fördelaktig när du inte styr klientkoden. Det är också fördelaktigt när du distribuerar klientkonfiguration är mer komplext eller riskabelt än att distribuera ändringar till en gateway-routningskonfiguration. Du kan ändra vilken modell en klient pekar på baserat på en blågrön distributionsstrategi för dina modellversioner, till exempel att lansera en ny finjusterad modell eller gå från version X till X+1 av samma modell.

Gatewayen kan också användas som en enda API-startpunkt som gör det möjligt för gatewayen att identifiera klienten. Den kan sedan avgöra vilken modelldistribution som används för att hantera prompten baserat på klientens identitet eller annan information i HTTP-begäran. I en lösning med flera klienter kan klientorganisationer till exempel begränsas till specifikt dataflöde, och implementeringen av arkitekturen är en modelldistribution per klientorganisation med specifika kvoter. I det här fallet skulle routningen till klientorganisationens modell vara gatewayens ansvar baserat på information i HTTP-begäran.

Om du använder en gateway i den här topologin kan du använda klientbaserad användningsspårning. Om inte klienter använder distinkta Microsoft Entra-tjänsthuvudnamn skulle åtkomstloggarna för Azure OpenAI inte kunna skilja mellan flera klienter. Att ha en gateway framför distributionen ger din arbetsbelastning en möjlighet att spåra användningen per klient i olika tillgängliga modelldistributioner för att stödja återbetalnings- eller showback-modeller.

Tips för topologin för flera modelldistributioner

• Även om gatewayen kan helt ändra vilken modell som används, till exempel till gpt-4, skulle den ändringen sannolikt betraktas som gpt-35-turbo en icke-bakåtkompatibel ändring av klienten. Låt inte nya funktionella funktioner i gatewayen distrahera från att alltid utföra säkra distributionsmetoder för den här arbetsbelastningen.

• Den här topologin är vanligtvis tillräckligt enkel för att implementeras via Azure API Management-principen i stället för en anpassad kodlösning.

• Om du vill stödja intern SDK:er-användning med publicerade Azure OpenAI API:er-specifikationer kan du upprätthålla API-kompatibilitet med Azure OpenAI-API:et. Den här situationen är ett större problem när ditt team inte redigerar all kod för dina arbetsbelastningsklienter. När du bestämmer dig för att utforma HTTP-API:et för gatewayen bör du överväga fördelarna med att upprätthålla Azure OpenAI HTTP API-kompatibilitet.

• Den här topologin har tekniskt stöd för autentiseringsuppgifter för direktklienter (åtkomsttoken eller API-nyckel) för Azure OpenAI-instansen, men överväg starkt att implementera avslutning och återupprättande av autentiseringsuppgifter. På så sätt auktoriseras klienten vid gatewayen och sedan auktoriseras gatewayen via Azure RBAC till Azure OpenAI-instansen.

• Om gatewayen är utformad för att använda direktautentiseringsuppgifter kontrollerar du att klienterna inte kan kringgå gatewayen eller några modellbegränsningar som baseras på klienten.

• Distribuera din gateway i samma region som Azure OpenAI-instansen.

• Distribuera gatewayen till en dedikerad resursgrupp i prenumerationen som är separat från Azure OpenAI-instansen. Att isolera prenumerationen från serverdelarna kan hjälpa dig att driva en APIOps-metod genom separationer av problem.

• Distribuera gatewayen till ett virtuellt nätverk som innehåller ett undernät för azure OpenAI-instansens privata Azure Private Link-slutpunkt. Tillämpa regler för nätverkssäkerhetsgrupp (NSG) på det undernätet för att endast tillåta gatewayåtkomst till den privata slutpunkten. All annan dataplansåtkomst till Azure OpenAI-instanserna bör inte tillåtas.

Orsaker till att undvika en gateway för flera modelldistributioner

Om det är lika enkelt eller enklare att kontrollera dina klienters konfiguration än att styra routningen på gatewaynivå kanske gatewayens extra tillförlitlighet, säkerhet, kostnad, underhåll och prestanda inte är värd den tillagda arkitekturkomponenten.

Vissa arbetsbelastningsscenarier kan också ha nytta av att migrera från en distributionsmetod för flera modeller till en distributionsmetod för flera Azure OpenAI-instanser. Överväg till exempel flera Azure OpenAI-instanser om du har flera klienter som ska använda olika RBAC- eller åtkomstnycklar för att komma åt deras modell. Det är möjligt att använda flera distributioner i en enda Azure OpenAI-instans och hantera logisk identitetssegmentering på gatewaynivå, men kan vara överdrivet när en fysisk RBAC-segmenteringsmetod är tillgänglig med hjälp av distinkta Azure OpenAI-instanser.

Flera Azure OpenAI-instanser i en enda region och en enda prenumeration

Topologiinformation för flera instanser i en enda region och en enskild prenumeration

• Azure OpenAI-modelldistributioner: en eller flera
• Azure OpenAI-instanser: flera
• Prenumerationer: en
• Regioner: en

Användningsfall för topologi för flera instanser i en enda region och en enskild prenumeration

En topologi som innehåller flera Azure OpenAI-instanser i en enda region och en enda prenumeration stöder följande användningsfall:

• Aktiverar gränser för säkerhetssegmentering, till exempel nyckel eller RBAC per klient

• Möjliggör en enkel återbetalningsmodell för olika klienter

• Aktiverar en redundansstrategi för Azure OpenAI-tillgänglighet, till exempel ett plattformsfel som påverkar en specifik instans, felkonfiguration av nätverk eller en distribution som tagits bort av misstag

• Aktiverar en redundansstrategi för Azure OpenAI-kvottillgänglighet, till exempel parkoppling av både en PTU-baserad instans och en förbrukningsbaserad instans för spillover

Introducera en gateway för flera instanser i en enda region och prenumeration

En modell kanske inte är tillgänglig för en klient av flera skäl. Dessa orsaker är bland annat avbrott i Azure OpenAI-tjänsten, Azure OpenAI-begränsningsbegäranden eller problem som rör arbetsbelastningsåtgärder som felkonfiguration av nätverket eller oavsiktlig borttagning av en modelldistribution. För att hantera dessa utmaningar bör du implementera logik för återförsök och kretsbrytning.

Den här logiken kan implementeras på klienter eller på serversidan i en gateway. Genom att implementera logiken i en gateway abstraheras logiken bort från klienter, vilket resulterar i ingen upprepad kod och en enda plats för att testa logiken. Oavsett om du äger klientkoden eller inte kan det här skiftet öka arbetsbelastningens tillförlitlighet.

Genom att använda en gateway med flera Azure OpenAI-instanser i en enda region och prenumeration kan du behandla alla serverdelar som aktiva-aktiva distributioner och inte bara använda dem i aktiv-passiva redundansväxlingar. Du kan distribuera samma PTU-baserade modell över flera Azure OpenAI-instanser och använda gatewayen för att belastningsutjäxla dem.

Ett alternativ som ett arbetsbelastningsteam har när de etablerar Azure OpenAI är att avgöra om fakturerings- och dataflödesmodellen är PTU-baserad eller förbrukningsbaserad. En strategi för kostnadsoptimering för att undvika slöseri via oanvänd PTU är att något underetablera PTU-instansen och även distribuera en förbrukningsbaserad instans bredvid den. Målet med den här topologin är att klienter först ska använda all tillgänglig PTU och sedan "burst" över till den förbrukningsbaserade distributionen för överförbrukning. Den här typen av planerad redundans drar nytta av samma orsak som i det inledande stycket i det här avsnittet: att hålla den här komplexiteten borta från klientkoden.

När en gateway är involverad är den i en unik position för att samla in information om alla modelldistributioner som klienter interagerar med. Varje instans av Azure OpenAI kan samla in sin egen telemetri, men genom att göra det i gatewayen kan arbetsbelastningsteamet publicera telemetri- och felsvar i alla förbrukade modeller till ett enda lager, vilket gör enhetlig instrumentpanel och aviseringar enklare.

Tips för flera instanser i en enda region och prenumerationstopologi

• Se till att gatewayen använder den Retry-After information som är tillgänglig i HTTP-svaret från Azure OpenAI när du stöder redundansscenarier på gatewayen. Använd den auktoritativa informationen för att styra implementeringen av kretsbrytaren. Tryck inte kontinuerligt på en slutpunkt som returnerar en 429 Too Many Requests. Bryt i stället kretsen för den modellinstansen.

• Det är möjligt att försöka förutsäga begränsningshändelser innan de inträffar genom att spåra modellförbrukning via tidigare begäranden i gatewayen, men det är fullt av gränsfall. I de flesta fall är det bäst att inte försöka förutsäga, utan använda HTTP-svarskoder för att driva framtida routningsbeslut.

• När resursallokering eller redundansväxling till en annan slutpunkt, inklusive PTU som spiller över i förbrukning, ska du alltid se till att slutpunkterna använder samma modell i samma version. Redundansväxla till exempel inte från gpt-4 till gpt-35-turbo eller från version X till version X+1 eller belastningsutjämning mellan dem. Den här versionsändringen kan orsaka oväntat beteende i klienterna.

• Belastningsutjämning och redundanslogik kan implementeras i Azure API Management-principer. Du kanske kan tillhandahålla en mer avancerad metod med hjälp av en kodbaserad gatewaylösning, men API Management räcker för det här användningsfallet.

• Distribuera din gateway i samma region som Azure OpenAI-instansen.

• Distribuera gatewayen till en dedikerad resursgrupp i prenumerationen som är separat från Azure OpenAI-instanserna. Att ha gatewayen isolerad från serverdelarna kan hjälpa till att driva en APIOps-metod genom separationer av problem.

• Samla alla privata Slutpunkter för Azure OpenAI-instansen Private Link i ett enda undernät i gatewayens virtuella nätverk. Tillämpa NSG-regler på det undernätet för att endast tillåta gatewayåtkomst till dessa privata slutpunkter. All annan dataplansåtkomst till Azure OpenAI-instanserna bör inte tillåtas.

• Om du vill förenkla logiken i gateway-routningskoden använder du samma modelldistributionsnamn för att minimera skillnaden mellan HTTP-vägarna. Modellnamnet gpt4-v1 kan till exempel användas på alla belastningsutjäxlade eller spillover-instanser, oavsett om det är förbrukningsbaserat eller PTU-baserat.

Orsaker till att undvika en gateway för flera instanser i en enda region och prenumeration

En gateway i sig förbättrar inte möjligheten att debitera modeller mot olika klienter för den här specifika topologin. I den här topologin kan klienter beviljas åtkomst till sina egna dedikerade Azure OpenAI-instanser, vilket skulle stödja ditt arbetsbelastningsteams möjlighet att utföra återbetalning eller showback. Den här modellen stöder unika identitets- och nätverksperimeter, så en gateway behöver inte introduceras specifikt för segmentering.

Om du har några klienter i området där du styr koden, och klienterna är enkla att hantera, kan logiken som du måste bygga in i gatewayen läggas till direkt i koden. Överväg att använda gatewaymetoden för redundans eller belastningsutjämning främst när du inte äger klientkoden eller komplexiteten är för mycket för klienterna att hantera.

Flera Azure OpenAI-instanser i en enda region i flera prenumerationer

Topologiinformation för flera Azure OpenAI-instanser i en enda region i flera prenumerationer

• Azure OpenAI-modelldistributioner: en eller flera
• Azure OpenAI-instanser: flera
• Prenumerationer: flera
• Regioner: en

Användningsfall för topologi för flera Azure OpenAI-instanser i en enda region i flera prenumerationer

En topologi som innehåller flera Azure OpenAI-instanser i en enda region i flera prenumerationer stöder följande användningsfall:

• Innehåller alla användningsfall som anges för flera Azure OpenAI-instanser i en enda region och en enda prenumeration.

• Gör att du kan få fler förbrukningsbaserade kvoter eftersom prenumerationsgränsen är en tillgänglig faktor för förbrukningsmodellen. Du kan använda den här extra kvoten för att stödja hög samtidig förbrukning.

Introducera en gateway för flera instanser i en enda region och flera prenumerationer

Samma orsaker som beskrivs i Introduktion till en gateway för flera instanser i en enda region och prenumeration gäller för den här topologin.

Förutom dessa orsaker stöder tillägg av en gateway i den här topologin även ett centraliserat team som tillhandahåller en "Azure OpenAI som en tjänst"-modell för organisationen. Eftersom en förbrukningsbaserad kvot är prenumerationsbunden måste ett centraliserat team som tillhandahåller Azure OpenAI-tjänster som använder den förbrukningsbaserade modellen distribuera Azure OpenAI-instanser över flera prenumerationer för att få den kvot som krävs. Gatewaylogik är fortfarande i stort sett densamma.

Tips för flera instanser i en enda region och topologi för flera prenumerationer

• Helst bör alla prenumerationer säkerhetskopieras med samma Microsoft Entra-klientorganisation för att stödja konsekvens i Azure RBAC och Azure Policy.

• Distribuera din gateway i samma region som Azure OpenAI-instansen.

• Distribuera gatewayen till en dedikerad prenumeration som är separat från Azure OpenAI-instanserna. Detta bidrar till att upprätthålla en konsekvens när det gäller att hantera Azure OpenAI-instanser och ger en logisk segmentering av uppgifter mellan Azure OpenAI-distributioner och deras routning.

• När du dirigerar begäranden från din gateway mellan prenumerationer kontrollerar du att privata slutpunkter kan nås. Du kan använda transitiv routning via en hubb till privata slutpunkter för serverdelarna i respektive ekrar. Du kanske kan exponera privata slutpunkter för Azure OpenAI-tjänsterna direkt i gatewayprenumerationen med hjälp av Private Link-anslutningar mellan prenumerationer. Private Link-anslutningar mellan prenumerationer rekommenderas om din arkitektur och organisation stöder den här metoden.

Orsaker till att undvika en gateway för flera instanser i en enda region och flera prenumerationer

Alla orsaker till att undvika en gateway för flera instanser i en enda region och prenumeration gäller för den här topologin.

Flera Azure OpenAI-instanser i flera regioner

Topologiinformation för flera Azure OpenAI-instanser i flera regioner

• Azure OpenAI-modelldistributioner: flera
• Azure OpenAI-instanser: flera
• Prenumerationer: en eller flera
• Regioner: flera

Användningsfall för topologi för flera Azure OpenAI-instanser i flera regioner

En topologi som innehåller flera Azure OpenAI-instanser spridda över två eller flera Azure-regioner stöder följande användningsfall:

• Innehåller alla användningsfall som anges för flera Azure OpenAI-instanser i en enda region i flera prenumerationer.

• Aktiverar en redundansstrategi för tjänsttillgänglighet, till exempel att använda par mellan regioner.

• Aktiverar en design för datahemvist och efterlevnad.

• Aktiverar tillgänglighet för blandade modeller. Vissa regioner har olika modeller och olika kvoter tillgängliga för modellerna.

Även om det tekniskt sett inte är olika Azure-regioner gäller även den här topologin när du har en AI-modell som exponeras i en situation som är korsförberedskap, till exempel lokalt eller i ett annat moln.

Introducera en gateway för flera instanser i flera regioner

För affärskritiska arkitekturer som måste överleva ett fullständigt regionalt avbrott hjälper en global, enhetlig gateway till att eliminera redundanslogik från klientkoden. Den här implementeringen kräver att gatewayen inte påverkas av ett regionalt avbrott.

Belastningsutjämning mellan regioner är inte typiskt, men kan användas strategiskt för att kombinera tillgängliga kvoter i förbrukningsbaserade distributioner mellan regioner. Det här scenariot kräver inte att gatewayen förblir opåverkad av ett regionalt avbrott, men vi rekommenderar det för maximal arbetsbelastningstillförlitlighet.

Använda Azure API Management (distribution med en region)

I den här topologin används Azure API Management specifikt för gatewaytekniken. Här distribueras API Management till en enda region. Från den gatewayinstansen utför du aktiv-aktiv belastningsutjämning mellan regioner. Principerna i din gateway refererar till alla Azure OpenAI-instanser. Gatewayen kräver nätverkssynpunkt för varje serverdel mellan regioner, antingen via peering för virtuella nätverk mellan regioner eller privata slutpunkter. Anrop från den här gatewayen till en Azure OpenAI-instans i en annan region medför mer nätverksfördröjning och utgående avgifter.

Din gateway måste respektera begränsnings- och tillgänglighetssignaler från Azure OpenAI-instanserna och ta bort felaktiga serverdelar från poolen tills det är säkert att läsa den felande eller begränsade Azure OpenAI-instansen. Gatewayen bör försöka med den aktuella begäran mot en annan serverdelsinstans i poolen vid fel, innan den återgår till att returnera ett gatewayfel. Gatewayens hälsokontroll bör signalera att den inte är felfri när det inte finns några Azure OpenAI-instanser i serverdelen.

Eftersom den här topologin introducerar en enskild felpunkt (gatewayen) är verktyget för den här specifika arkitekturen ganska begränsat. Den här modellen lämpar sig väl för förbrukningsbaserad fakturering i Azure OpenAI när det kan vara för svårt att förutsäga PTU-allokering.

Aktiv-passiv variant

Den här modellen kan också användas för att tillhandahålla en aktiv-passiv metod för att specifikt hantera regionala fel för bara Azure OpenAI. I det här läget flödar trafiken normalt från gatewayen till Azure OpenAI-instansen i samma region som API-hanteringstjänsten. Den instansen av Azure OpenAI skulle hantera alla förväntade trafikflöden utan att regionala fel inträffar. Den kan vara PTU-baserad eller förbrukningsbaserad, beroende på önskad faktureringsmodell. Om det uppstår ett regionalt fel på bara Azure OpenAI kan gatewayen omdirigera trafik till en annan region med Azure OpenAI redan distribuerat i förbrukningsläge.

Använda Azure API Management (distribution i flera regioner)

För att förbättra tillförlitligheten för den tidigare Azure API Management-baserade arkitekturen har API Management stöd för distribution av en instans till flera Azure-regioner. Det här distributionsalternativet ger dig ett enda kontrollplan via en enda API Management-instans, men tillhandahåller replikerade gatewayer i valfria regioner. I den här topologin distribuerar du gatewaykomponenter till varje region som innehåller Azure OpenAI-instanser som tillhandahåller en aktiv-aktiv gatewayarkitektur.

Principer som routning och logik för hantering av begäranden replikeras till varje enskild gateway. All principlogik måste ha villkorsstyrd logik i principen för att säkerställa att du anropar Azure OpenAI-instanser i samma region som den aktuella gatewayen. Mer information finns i Dirigera API-anrop till regionala serverdelstjänster. Gatewaykomponenten kräver sedan endast nätverkslinje för Azure OpenAI-instanser i sin egen region, vanligtvis via privata slutpunkter.

API Management erbjuder out-of-the-box global fullständigt kvalificerade domännamn (FQDN) routning baserat på lägsta svarstid. Använd den här inbyggda, prestandabaserade funktionen för aktiv-aktiv gateway-distributioner. Den här inbyggda funktionen hjälper till att hantera prestanda och hanterar ett regionalt gateway-avbrott. Den inbyggda globala routern stöder också haveriberedskapstestning eftersom regioner kan simuleras nedåt genom att inaktivera enskilda gatewayer. Kontrollera att klienterna respekterar TTL (Time To Live) på det fullständiga domännamnet och har lämplig logik för återförsök för att hantera en nyligen genomförd DNS-redundansväxling.

Om du behöver introducera en brandvägg för webbprogram i den här arkitekturen kan du fortfarande använda den inbyggda FQDN-routningslösningen som backend-ursprung för den globala routern som implementerar en brandvägg för webbprogram. Den globala routern delegerar redundansansvaret till API Management. Du kan också använda de regionala gateway-FQDN:erna som medlemmar i serverdelspoolen. I den senare arkitekturen använder du den inbyggda /status-0123456789abcdef slutpunkten på varje regional gateway eller en annan anpassad hälso-API-slutpunkt för att stödja regional redundans. Om du är osäker börjar du med FQDN-metoden för enskild ursprungsserverdel.

Den här arkitekturen fungerar bäst om du kan behandla regioner som helt tillgängliga eller helt otillgängliga. Det innebär att om antingen API Management-gatewayen eller Azure OpenAI-instansen inte är tillgänglig vill du att klienttrafiken inte längre ska dirigeras till API Management-gatewayen i den regionen. Om inte en annan etablering görs måste felet spridas till klienten om den regionala gatewayen fortfarande accepterar trafik medan Azure OpenAI inte är tillgängligt. För att undvika klientfelet kan du se en förbättrad metod i Aktiv-aktiv gateway plus aktiv-passiv Azure OpenAI-variant.

Om en region drabbas av ett AVBROTT i API Management-gatewayen eller flaggas som inte felfri, måste de återstående tillgängliga regionerna absorbera 100 % av trafiken från dessa andra regioner. Det innebär att du måste överetablera PTU-baserade Azure OpenAI-instanser för att hantera den nya trafikmängden eller använda en aktiv-passiv metod för redundansväxling. Använd Kapacitetskalkylatorn för Azure OpenAI för kapacitetsplanering.

Se till att resursgruppen som innehåller Azure API Management är samma plats som själva API Management-instansen för att minska explosionsradien för ett relaterat regionalt avbrott som påverkar din möjlighet att komma åt resursprovidern för dina gatewayer.

Aktiv-aktiv gateway plus aktiv-passiv Azure OpenAI-variant

I föregående avsnitt beskrivs gatewayens tillgänglighet genom att tillhandahålla en aktiv-aktiv gatewaytopologi. Den här topologin kombinerar den aktiva-aktiva gatewayen med en kostnadseffektiv aktiv-passiv Azure OpenAI-topologi. Att lägga till aktiv-passiv logik i gatewayen för redundansväxling till en förbrukningsbaserad Azure OpenAI-distribution från en PTU-baserad distribution kan avsevärt öka arbetsbelastningens tillförlitlighet. Den här modellen tillåter fortfarande klienter att använda den inbyggda FQDN-routningslösningen för API Management för prestandabaserad routning.

Använda en anpassad kodad gateway

Om dina routningsregler per gateway är för komplexa för att ditt team ska kunna betrakta dem som rimliga som API Management-principer måste du distribuera och hantera din egen lösning. Den här arkitekturen måste vara en distribution i flera regioner av din gateway med en skalningsenhet med hög tillgänglighet per region. Du måste fronta dessa distributioner med Azure Front Door (Anycast) eller Azure Traffic Manager (DNS), vanligtvis med hjälp av svarstidsbaserad routning och lämpliga hälsokontroller av gatewaytillgänglighet.

Använd Azure Front Door om du behöver en brandvägg för webbprogram och offentlig Internetåtkomst. Använd Traffic Manager om du inte behöver en brandvägg för webbprogram och DNS TTL räcker. När du frontar dina gatewayinstanser med Azure Front Door (eller någon omvänd proxyserver) kontrollerar du att gatewayen inte kan kringgås. Gör gatewayinstanserna endast tillgängliga via privat slutpunkt när du använder Azure Front Door och lägg till verifiering av X_AZURE_FDID HTTP-huvudet i gatewayimplementeringen.

Placera resurser per region som används i din anpassade gateway i resursgrupper per region. Detta minskar explosionsradien för ett relaterat regionalt avbrott som påverkar din möjlighet att komma åt resursprovidern för dina gatewayresurser i den regionen.

Du kan också överväga att fronta din gatewaylogikimplementering med API Management för de andra fördelarna med API Management, till exempel TLS, autentisering, hälsokontroll eller resursallokeringsbelastningsutjämning. Detta flyttar vanliga API-problem från anpassad kod i din gateway och gör att din gateway specifikt kan hantera Azure OpenAI-instans- och modelldistributionsroutning.

För efterlevnad av datahemvist kontrollerar du att varje geopolitisk gräns har en egen isolerad distribution av den här arkitekturen och att klienter bara kan nå sin auktoriserade slutpunkt.

Orsaker till att undvika en gateway för flera instanser i flera regioner

Implementera inte en enhetlig gateway i geopolitiska regioner när datahemvist och efterlevnad krävs. Detta skulle strida mot kraven på datahemvist. Använd individuellt adresserbara gatewayer per region och följ riktlinjerna i något av föregående avsnitt.

Om klienter inte förväntas redundansväxla mellan regioner och du har möjlighet att ge klienter en specifik gateway att använda, använder du i stället flera gatewayer, en per region, och följer riktlinjerna i något av föregående avsnitt. Koppla inte tillgängligheten för andra regioner till den region som innehåller din gateway som en enskild felpunkt.

Implementera inte en enhetlig gateway om din modell och version inte är tillgänglig i alla regioner som exponeras av gatewayen. Klienter måste dirigeras till samma modell och samma modellversion. För lastbalanserade gatewayer och redundansgatewayer i flera regioner måste du välja en gemensam modell- och modellversion som är tillgänglig i alla berörda regioner. Mer information finns i Modelltillgänglighet. Om du inte kan standardisera på modell- och modellversion är fördelen med gatewayen begränsad.

Allmänna rekommendationer

Oavsett vilken topologi dina arbetsbelastningsbehov behöver finns det några övergripande rekommendationer att tänka på när du skapar din gatewaylösning.

Tillståndskänsliga interaktioner

När klienter använder Azure OpenAI:s tillståndskänsliga funktioner, till exempel API:et Assistenter, måste du konfigurera din gateway för att fästa en klient på en specifik serverdel under interaktionen. Detta kan åstadkommas genom att lagra instansdata i en cookie. I dessa scenarier bör du överväga att returnera ett Azure OpenAI API-svar som ett 429 till en fäst klient i stället för att omdirigera dem till en annan Azure OpenAI-instans. På så sätt kan klienten uttryckligen hantera plötslig otillgänglighet jämfört med att dölja den och dirigeras till en modellinstans som inte har någon historik.

Hälsokontroller för gateway

Det finns två hälsokontrollperspektiv att tänka på, oavsett topologi.

Om din gateway bygger på resursallokering eller strikt utför redundans för tjänsttillgänglighet vill du ha ett sätt att ta bort en Azure OpenAI-instans (eller modell) från tillgänglighetsstatusen. Azure OpenAI tillhandahåller ingen typ av slutpunkt för hälsokontroll för att i förebyggande syfte veta om den är tillgänglig för att hantera begäranden. Du kan skicka syntetiska övergångar genom, men det förbrukar modellkapacitet. Om du inte har en annan tillförlitlig signalkälla för Azure OpenAI-instans och modelltillgänglighet bör din gateway förmodligen anta att Azure OpenAI-instansen är igång och sedan hanterar 429, 500, 503 HTTP-statuskoder som en signal till kretsbrytning för framtida begäranden om den instansen eller modellen under en tid. För begränsningssituationer ska du alltid respektera data i huvudet som Retry-After finns i Azure OpenAI API-svar för 429 svarskoder i din kretsbrytande logik. Om du använder Azure API Management utvärderar du med hjälp av de inbyggda kretsbrytarfunktionerna .

Dina klienter eller ditt arbetsbelastningsteam kanske vill ha en hälsokontroll tillgänglig på din gateway för sin egen routning eller introspektion. Om du använder API Management kanske standardvärdet /status-0123456789abcdef inte är tillräckligt detaljerat eftersom det främst adresserar API Management-gatewayinstansen, inte dina serverdelar. Överväg att lägga till ett dedikerade hälsokontroll-API som kan returnera meningsfulla data till klienter eller observerbarhetssystem om tillgängligheten för gatewayen eller specifika vägar i gatewayen.

Säkra distributionsmetoder

Du kan använda gatewayimplementeringar för att samordna blågröna distributioner av uppdaterade modeller. Azure OpenAI-modeller uppdateras med nya modellversioner och nya modeller, och du kan ha nya finjusterade modeller.

När du har testat effekterna av en ändring i förproduktion utvärderar du om produktionsklienter ska "skäras över" till den nya modellversionen eller i stället flytta trafik. Gatewaymönstret som beskrevs tidigare gör att serverdelen kan ha båda modellerna samtidigt distribuerade. När modeller distribueras samtidigt kan gatewayen omdirigera trafik baserat på arbetsbelastningsteamets säkra distributionspraxis för inkrementell distribution.

Även om du inte använder blågröna distributioner måste arbetsbelastningens APIOps-metod definieras och vara tillräckligt automatiserad i takt med ändringshastigheten för serverdelsinstansen och modelldistributionerna.

Precis tillräckligt med implementering

Många av scenarierna som introduceras i den här artikeln bidrar till att öka det potentiella servicenivåmålet (SLO) för din arbetsbelastning genom att minska klientkomplexiteten och implementera tillförlitliga självbevarande tekniker. Andra förbättrar säkerheten för arbetsbelastningen genom att flytta åtkomstkontroller till specifika modeller från Azure OpenAI. Se till att introduktionen av gatewayen inte slutar fungera mot dessa mål. Förstå riskerna med att lägga till en ny felpunkt, antingen genom tjänstfel eller konfigurationsproblem orsakade av människor i gatewayen, komplex routningslogik eller riskerna med att exponera fler modeller för obehöriga klienter än vad som är avsett.

Datasuveränitet

De olika aktiva och aktiva passiva metoderna måste utvärderas utifrån ett efterlevnadsperspektiv för datahemvist för din arbetsbelastning. Många av dessa mönster skulle vara tillämpliga för din arbetsbelastnings arkitektur om de berörda regionerna ligger kvar inom den geopolitiska gränsen. För att stödja det här scenariot måste du behandla geopolitiska gränser som isolerade stämplar och tillämpa aktiv-aktiv eller aktiv-passiv hantering uteslutande inom den stämpeln.

I synnerhet måste prestandabaserad routning granskas mycket för datasuveränitetsefterlevnad. I scenarier med datasuveränitet kan du inte betjäna klienter med ett annat geografiskt område och förbli kompatibel. Alla gatewayarkitekturer som omfattar datahemvist måste framtvinga att klienter endast använder slutpunkter i sin geopolitiska region. Klienterna måste blockeras från att använda andra gatewayslutpunkter och själva gatewayen bryter inte mot klientens förtroende genom att göra en geopolitisk begäran. Det mest tillförlitliga sättet att implementera den här segmenteringen är att bygga din arkitektur kring en helt oberoende gateway med hög tillgänglighet per geopolitisk region.

Azure OpenAI-auktorisering

Gatewayen måste autentiseras med alla Azure OpenAI-instanser som den gränssnitt med. Om du inte har utformat gatewayen för direktautentisering bör gatewayen använda en hanterad identitet för sina autentiseringsuppgifter. Så varje Azure OpenAI-instans måste konfigurera minst privilegierad RBAC för gatewayernas hanterade identiteter. För arkitekturer för aktiv-aktiv och redundans kontrollerar du att gatewayens identitet har motsvarande behörigheter för alla berörda Azure OpenAI-instanser.

Azure Policy

Konsekvens mellan modelldistributioner och Azure OpenAI-instanser är viktigt i aktiva eller aktiva passiva situationer. Använd Azure Policy för att upprätthålla konsekvens mellan de olika Azure OpenAI-instanserna eller modelldistributionerna. Om de inbyggda principerna för Azure OpenAI inte räcker för att säkerställa konsekvens mellan dem kan du överväga att skapa eller använda anpassade principer som skapats av communityn.

Gatewayredundans

Även om den inte är specifik för flera serverdelar bör varje regions gatewayimplementering alltid skapas med redundans och ha hög tillgänglighet i skalningsenheten. Välj regioner med tillgänglighetszoner och se till att din gateway är spridd över dem. Distribuera flera instanser av gatewayen så att en enskild felpunkt begränsas till ett fullständigt regionalt avbrott och inte felet för en enda beräkningsinstans i din gateway. För API Management distribuerar du två eller flera enheter över två eller flera zoner. För anpassade kodimplementeringar distribuerar du minst tre instanser med bästa möjliga distribution mellan tillgänglighetszoner.

Gatewayimplementeringar

Azure erbjuder ingen nyckelfärdig lösning eller referensarkitektur för att skapa en sådan gateway. Som du nämnde i introduktionsartikeln måste ditt arbetsbelastningsteam skapa och använda den här gatewayen. Här följer några exempel på exempelimplementeringar som stöds av communityn och som omfattar några av de tidigare nämnda användningsfallen. Överväg att referera till dessa GitHub-exempel när du skapar ett eget konceptbevis.

Implementering	Exempel
Azure API Management	Smart belastningsutjämning för Azure OpenAI med Hjälp av Azure API Management – Den här GitHub-lagringsplatsen innehåller exempelprincipkod och instruktioner för distribution till din prenumeration. Skala Azure OpenAI med Azure API Management – Den här GitHub-lagringsplatsen innehåller exempelprincipkod och instruktioner för PTU och förbrukningsspillning. GenAI-gatewayverktyget innehåller exempel på API Management-principer tillsammans med en konfiguration av belastningstestning för att testa principernas beteende.
Anpassad kod	Smart belastningsutjämning för Azure OpenAI med Hjälp av Azure Container Apps Den här GitHub-lagringsplatsen innehåller C#-exempelkod och instruktioner för att skapa containern och distribuera den till din prenumeration.

Nästa steg

Att ha en gatewayimplementering för din arbetsbelastning ger fördelar utöver den taktiska routningsförmånen för flera serverdelsroutning som beskrivs i den här artikeln. Lär dig mer om de andra viktiga utmaningar som en gateway kan lösa.

Relaterade resurser

• Azure OpenAI-tjänsten
• API-gateway i Azure API Management