Redigera

Dela via

Få åtkomst till Azure OpenAI och andra språkmodeller via en gateway

Azure AI services
Azure OpenAI Service
Azure API Management

Azure OpenAI Service exponerar HTTP-API:er som gör att dina program kan utföra inbäddningar eller slutföranden med hjälp av OpenAI:s språkmodeller. Intelligenta program anropar dessa HTTP-API:er direkt från klienter eller orkestrerare. Exempel på klienter är chattgränssnittskod och anpassade databearbetningspipelines. Exempel på orchestrators är LangChain, Semantic Kernel och Azure Machine Learning prompt flow. När din arbetsbelastning ansluter till en eller flera Azure OpenAI-instanser måste du bestämma om dessa konsumenter ansluter direkt eller via en omvänd proxy-API-gateway.

Använd den här guiden om du vill lära dig mer om de viktigaste utmaningarna i de fem grundpelarna i Azure Well-Architected Framework som du stöter på om din arbetsbelastningsdesign innehåller direkt åtkomst från dina konsumenter till Azure OpenAI-dataplanets API:er. Lär dig sedan hur introduktionen av en gateway i din arkitektur kan hjälpa dig att lösa dessa direktåtkomstutmaningar, samtidigt som nya utmaningar införs. Den här artikeln beskriver arkitekturmönstret men inte hur du implementerar gatewayen.

Eftersom en gateway kan användas för att lösa specifika scenarier som kanske inte finns i varje arbetsbelastning kan du se vägledningen för specifika scenarion, som tittar närmare på det specifika användningsfallet för en gateway.

Viktiga utmaningar

Utan en API-gateway eller möjligheten att lägga till logik i HTTP-API:erna för Azure OpenAI måste klienten hantera API-klientlogik, som omfattar återförsöksmekanismer eller kretsbrytare. Den här situationen kan vara utmanande i scenarier där du inte direkt styr klientkoden eller när koden är begränsad till specifik SDK-användning. Flera klienter eller flera Azure OpenAI-instanser och distributioner medför ytterligare utmaningar, till exempel samordning av säkra distributioner och observerbarhet.

Det här avsnittet innehåller exempel på specifika viktiga arkitekturutmaningar som du kan stöta på om din arkitektur bara stöder direkt åtkomst till Azure OpenAI från konsumenter. Utmaningarna organiseras med hjälp av grundpelarna i Azure Well-Architected Framework.

Tillförlitlighetsutmaningar

Arbetsbelastningens tillförlitlighet beror på flera faktorer, inklusive dess kapacitet för självbevarelsedrift och självåterställning, som ofta implementeras via replikerings- och redundansmekanismer. Utan en gateway måste alla tillförlitlighetsproblem endast åtgärdas med hjälp av klientlogik och Azure OpenAI Service-funktioner. Arbetsbelastningens tillförlitlighet äventyras när det inte finns tillräckligt med tillförlitlighetskontroll på någon av dessa två ytor.

  • Redundans: Redundansväxling mellan flera Azure OpenAI-instanser baserat på tjänsttillgänglighet är ett klientansvar som du behöver styra via konfiguration och anpassad logik.

  • Skala ut för att hantera toppar: Växla över till Azure OpenAI-instanser med kapacitet när begränsningen är ett annat klientansvar som du behöver styra via konfiguration och anpassad logik. Att uppdatera flera klientkonfigurationer för nya Azure OpenAI-instanser innebär större risk och har problem med aktualitet. Detsamma gäller för uppdatering av klientkod för att implementera ändringar i logiken, till exempel att dirigera begäranden med låg prioritet till en kö under perioder med hög efterfrågan.

  • Belastningsutjämning eller begränsning: Azure OpenAI API:er begränsar begäranden genom att returnera en HTTP 429-felsvarskod till begäranden som överskrider TPM (Token per minut) eller Requests-Per-Minute (RPM) i modellen betala per användning. Azure OpenAI-API:er begränsar också begäranden som överskrider PTU-kapaciteten (etablerade dataflödesenheter) för den företablerade faktureringsmodellen. Hantering av lämplig back-off- och återförsökslogik lämnas uteslutande till klientimplementeringar.

Säkerhetsutmaningar

Säkerhetskontroller måste hjälpa till att skydda arbetsbelastningens konfidentialitet, integritet och tillgänglighet. Utan en gateway måste alla säkerhetsproblem endast åtgärdas i klientlogik och Azure OpenAI Service-funktioner. Arbetsbelastningskrav kan kräva mer än vad som är tillgängligt för klientsegmentering, klientkontroll eller tjänstsäkerhetsfunktioner för direkt kommunikation.

  • Identitetshantering – autentiseringsomfång: Api:er för dataplanet som exponeras av Azure OpenAI kan skyddas på något av två sätt: API-nyckel eller Rollbaserad åtkomstkontroll i Azure (RBAC). I båda fallen sker autentisering på Azure OpenAI-instansnivå, inte på den enskilda distributionsnivån, vilket ger komplexitet för att tillhandahålla minst privilegierad åtkomst och identitetssegmentering för specifika distributionsmodeller.

  • Identitetshantering – identitetsprovidrar: Klienter som inte kan använda identiteter som finns i Microsoft Entra-klientorganisationen som stöder Azure OpenAI-instansen måste dela en enda API-nyckel med fullständig åtkomst. API-nycklar har begränsningar för säkerhetsnyttighet och är problematiska när flera klienter är inblandade och alla delar samma identitet.

  • Nätverkssäkerhet: Beroende på klientplats i förhållande till dina Azure OpenAI-instanser kan offentlig Internetåtkomst till språkmodeller vara nödvändig.

  • Datasuveränitet: Datasuveränitet i samband med Azure OpenAI avser de juridiska och regelmässiga krav som gäller lagring och bearbetning av data inom de geografiska gränserna för ett visst land eller en viss region. Din arbetsbelastning måste säkerställa regional tillhörighet så att klienterna kan följa lagarna om datahemvist och suveränitet. Den här processen omfattar flera Azure OpenAI-distributioner.

Utmaningar med kostnadsoptimering

Arbetsbelastningar är till nytta när arkitekturer minimerar slöseri och maximerar nyttan. Stark kostnadsmodellering och övervakning är ett viktigt krav för alla arbetsbelastningar. Utan en gateway kan användningen av PTU- eller per-klientkostnadsspårning auktoritativt uppnås uteslutande från aggregering av användningstelemetri för Azure OpenAI-instanser.

  • Kostnadsspårning: Att kunna tillhandahålla en budgetplan för Azure OpenAI-användning är begränsat till data aggregerade från användningstelemetri för Azure OpenAI-instanser. När det krävs för att göra återbetalning eller showback måste du tillskriva den användningstelemetrin med olika klienter på olika avdelningar eller till och med kunder för scenarier med flera klienter.

  • Etablerad dataflödesanvändning: Din arbetsbelastning vill undvika slöseri genom att fullt ut utnyttja det etablerade dataflödet som du betalade för. Det innebär att klienter måste vara betrodda och koordinerade för att kunna använda PTU-baserade modelldistributioner innan de sprids till förbrukningsbaserade modelldistributioner.

Utmaningar för driftskvalitet

Utan en gateway är observerbarhet, ändringskontroll och utvecklingsprocesser begränsade till vad som tillhandahålls av direkt kommunikation från klient till server.

  • Kvotkontroll: Klienter får 429 svarskoder direkt från Azure OpenAI när HTTP-API:erna begränsas. Arbetsbelastningsoperatorer ansvarar för att säkerställa att tillräckligt med kvoter är tillgängliga för legitim användning och att felaktiga klienter inte förbrukar mer än så. När din arbetsbelastning består av flera modelldistributioner kan det vara svårt att visualisera kvotanvändning och kvottillgänglighet.

  • Övervakning och observerbarhet: Standardmått för Azure OpenAI är tillgängliga via Azure Monitor. Det finns dock svarstider med tillgängligheten för data och det ger inte realtidsövervakning.

  • Säkra distributionsmetoder: GenAIOps-processen kräver samordning mellan klienter och de modeller som distribueras i Azure OpenAI. För avancerade distributionsmetoder, till exempel blågrön eller kanariefågel, måste logiken hanteras på klientsidan.

Prestandaeffektivitetsutmaningar

Utan en gateway lägger din arbetsbelastning ansvaret på klienter att vara individuellt väluppfostrade och att bete sig rättvist med andra klienter mot begränsad kapacitet.

  • Prestandaoptimering – prioritetstrafik: Prioritering av klientbegäranden så att klienter med hög prioritet har prioriterad åtkomst framför klienter med låg prioritet skulle kräva omfattande och sannolikt orimlig samordning mellan klienter. Vissa arbetsbelastningar kan ha nytta av att ha lågprioriterade begäranden i kö för att köras när modellanvändningen är låg.

  • Prestandaoptimering – klientefterlevnad: För att kunna dela kapacitet måste klienterna vara väluppfostrade. Ett exempel på detta är när klienterna ser till att max_tokens och best_of är inställda på godkända värden. Utan en gateway måste du lita på att klienterna agerar för att bevara kapaciteten för din Azure OpenAI-instans.

  • Minimera svarstiden: Även om nätverksfördröjning vanligtvis är en liten komponent i det övergripande flödet för fråga och slutförandebegäran kan det vara fördelaktigt att se till att klienter dirigeras till en nätverksslutpunkt och en modell nära dem. Utan en gateway måste klienterna själv välja vilka modelldistributionsslutpunkter som ska användas och vilka autentiseringsuppgifter som krävs för det specifika Azure OpenAI-dataplanets API.

Lösning

Diagram som visar en konceptuell arkitektur för att mata in en gateway mellan ett intelligent program och Azure OpenAI.

Bild 1: Konceptuell arkitektur för åtkomst till Azure OpenAI via en gateway

För att hantera de många utmaningar som anges i Viktiga utmaningar kan du mata in en omvänd proxygateway för att frikoppla det intelligenta programmet från Azure OpenAI. Med den här gateway-avlastningen kan du flytta ansvar, komplexitet och observerbarhet från klienter och ger dig möjlighet att utöka Azure OpenAI genom att tillhandahålla andra funktioner som inte är inbyggda. Några exempel är:

Vissa specifika scenarier har mer vägledning som direkt adresserar en API-gateway och Azure OpenAI-instanser. Dessa scenarier visas i avsnittet Nästa steg .

Att tänka på

När du introducerar en ny komponent i arkitekturen måste du utvärdera de nyligen introducerade kompromisserna. När du matar in en API-gateway mellan dina klienter och Azure OpenAI-dataplanet för att hantera några av de viktigaste utmaningarna introducerar du nya överväganden i din arkitektur. Utvärdera noggrant om arbetsbelastningens påverkan i dessa arkitekturöverväganden motiverar gatewayens mervärde eller verktyg.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program uppfyller de åtaganden du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

  • Gatewaylösningen kan introducera en enskild felpunkt. Det här felet kan ha sitt ursprung i gatewayplattformens tjänsttillgänglighet, avbrott på grund av kod- eller konfigurationsdistributioner eller till och med felkonfigurerade kritiska API-slutpunkter i din gateway. Se till att du utformar implementeringen så att den uppfyller arbetsbelastningens tillgänglighetskrav. Överväg återhämtnings- och feltoleransfunktioner i implementeringen genom att inkludera gatewayen i fellägesanalysen av arbetsbelastningen.

  • Din lösning kan kräva globala routningsfunktioner om din arkitektur kräver Azure OpenAI-instanser i flera regioner. Den här situationen kan ytterligare komplicera topologin genom hantering av extra fullständigt kvalificerade domännamn, TLS-certifikat och fler globala routningskomponenter.

Viktigt!

Implementera inte en gateway om det skulle äventyra arbetsbelastningens förmåga att uppfylla överenskomna servicenivåmål (SLO).

Säkerhet

När du överväger hur en API-gateway gynnar din arkitektur använder du checklistan Designgranskning för Säkerhet för att utvärdera din design. Du måste ta itu med säkerhetsöverväganden, till exempel följande:

  • Arbetsbelastningens yta ökas med tillägg av gatewayen. Den ytan ger extra överväganden för identitets- och åtkomsthantering (IAM) för Azure-resurserna, ökad härdning med mera.

  • Gatewayen kan fungera som en nätverksgränsövergång mellan klientnätverksutrymme och privat Azure OpenAI-nätverksutrymme. Även om gatewayen gör en tidigare Internetuppkopplad Azure OpenAI-slutpunkt privat med hjälp av Azure Private Link, blir den nu den nya startpunkten och måste vara tillräckligt säker.

  • En gateway är i en unik position för att se rådata och formulerade svar från språkmodellen, som kan innehålla konfidentiella data från någon av källorna. Dataefterlevnad och regelomfång utökas nu till den andra komponenten.

  • En gateway kan utöka omfånget för klientauktorisering och autentisering utöver Microsoft Entra-ID och API-nyckelautentisering, och eventuellt över flera identitetsprovidrar (IdP).

  • Datasuveränitet måste beaktas i implementeringen i implementeringar i flera regioner. Se till att gatewayens beräknings- och routningslogik följer de suveränitetskrav som ställs på din arbetsbelastning.

Viktigt!

Implementera inte en gateway om det skulle göra att din arbetsbelastning inte kan skydda sekretess, integritet eller tillgänglighet för sig själv eller sina användares data.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

Alla implementerade API-gatewayer har körningskostnader som måste budgeteras och redovisas. Dessa kostnader ökar vanligtvis med extra funktioner för att hantera tillförlitlighet, säkerhet och prestanda för själva gatewayen tillsammans med driftskostnader som introduceras med extra APIOps-hantering. Dessa extra kostnader måste mätas mot det nya värdet som levereras från systemet med gatewayen. Du vill nå en punkt där de nya funktionerna som introduceras med hjälp av en gateway uppväger kostnaden för att implementera och underhålla gatewayen. Beroende på din arbetsbelastnings relation till användarna kanske du kan debitera tillbaka användning.

Överväg att använda en simulerad slutpunkt för Azure OpenAI för att hantera kostnader när du utvecklar och testar en gateway. Du kan till exempel använda lösningen i GitHub-lagringsplatsen för Azure OpenAI API-simulatorn .

Driftseffektivitet

När du funderar på hur en API-gateway gynnar din arkitektur använder du checklistan Designgranskning för Operational Excellence för att utvärdera din design. Du måste ta itu med överväganden för driftskvalitet, till exempel följande:

  • Själva gatewayen måste övervakas av din arbetsbelastnings övervakningslösning och eventuellt av klienter. Det innebär att gatewayberäkning och -åtgärder måste ingå i arbetsbelastningens hälsomodellering.

  • Dina säkra distributionsmetoder måste nu hantera distributionen av API Gateway-infrastrukturen och koden eller konfigurationen av gateway-routningen. Din lösning för infrastrukturautomatisering och infrastruktur som kod (IaC) måste överväga hur gatewayen ska hanteras som en långvarig resurs i arbetsbelastningen.

  • Du måste skapa eller utöka din APIOps-metod för att täcka de API:er som exponeras i gatewayen.

Prestandaeffektivitet

När du överväger hur en API-gateway gynnar din arkitektur använder du checklistan Designgranskning för prestandaeffektivitet för att utvärdera din design. Du måste ta itu med prestandaeffektivitetsöverväganden, till exempel följande:

  • Gatewaytjänsten kan introducera en flaskhals i dataflödet. Se till att gatewayen har tillräcklig prestanda för att hantera fullständig samtidig belastning och enkelt kan skalas i enlighet med dina tillväxtförväntningar. Se till att lösningen är elastisk så att gatewayen kan minska tillgången eller skala ned när efterfrågan är låg, till exempel med användning på arbetsdagen.

  • Gatewaytjänsten har bearbetat den måste utföra per begäran och introducerar ökad svarstid per API-anrop. Du bör optimera routningslogik så att begäranden fungerar bra.

  • I de flesta fall bör gatewayen vara geografiskt nära både användarna och Azure OpenAI-instanserna för att minska svarstiden. Nätverksfördröjning är vanligtvis en liten procentandel av tiden i övergripande API-anrop till språkmodeller, men det kan vara en konkurrensfaktor för din arbetsbelastning.

  • Utvärdera gatewayens inverkan på Azure OpenAI-funktioner, till exempel strömningssvar eller instansens fästning för tillståndskänsliga interaktioner, till exempel API:et Assistenter.

Viktigt!

Implementera inte en gateway om det gör det omöjligt eller för komprometterande för andra kompromisser att uppnå förhandlade prestandamål.

Implementeringsalternativ

Azure erbjuder inte en nyckelfärdig lösning som utformats specifikt för proxy för Azure OpenAI:s HTTP-API eller andra API:er för inferens av anpassad språkmodell. Men det finns fortfarande flera alternativ för ditt arbetsbelastningsteam att implementera, till exempel en gateway i Azure.

Använda Azure API Management

Azure API Management är en plattformshanterad tjänst som är utformad för att avlasta övergripande problem för HTTP-baserade API:er. Den är konfigurationsdriven och har stöd för anpassning via dess principsystem för inkommande och utgående begärandebearbetning. Den stöder repliker med hög tillgänglighet, zonredundant och till och med repliker i flera regioner med hjälp av ett enda kontrollplan.

Merparten av gatewayens routnings- och begärandehanteringslogik måste implementeras i principsystemet för API Management. Du kan kombinera inbyggda principer, till exempel Begränsa användning av Azure OpenAI API-token eller Generera mått för förbrukning av Azure OpenAI-token och dina egna anpassade principer. GitHub-lagringsplatsen för GenAI-gatewayverktyg innehåller ett antal anpassade API Management-principer tillsammans med en konfiguration av belastningstestning för testning av principernas beteende.

Använd tjänstguiden Well-Architected Framework för API Management när du utformar en lösning som omfattar Azure API Management. Om din arbetsbelastning finns som en del av en programlandningszon kan du läsa vägledningen i Cloud Adoption Framework för Azure om hur du implementerar en Azure API Management-landningszon.

Att använda Azure API Management för gatewayimplementeringen är vanligtvis den bästa metoden för att skapa och driva en Azure OpenAI-gateway. Det är att föredra eftersom tjänsten är en paaS-tjänst (plattform som en tjänst) med omfattande inbyggda funktioner, hög tillgänglighet och nätverksalternativ. Den har också robusta APIOps-metoder för att hantera dina slutförande-API:er.

Använda anpassad kod

Den anpassade kodmetoden kräver att ett programvaruutvecklingsteam skapar en anpassad kodad lösning och distribuerar den lösningen till valfri Azure-programplattform. Att skapa en självhanterad lösning för att hantera gatewaylogik kan passa bra för arbetsbelastningsteam som är skickliga på att hantera nätverks- och routningskod.

Arbetsbelastningen kan vanligtvis använda beräkning som de är bekanta med, till exempel värd för gatewaykoden i Azure App Service, Azure Container Apps eller Azure Kubernetes Service.

Anpassade koddistributioner kan också frontas med API Management när API Management endast används för dess grundläggande HTTP API-gatewayfunktioner mellan dina klienter och din anpassade kod. På så sätt kan du använda anpassade kodgränssnitt uteslutande med dina AZURE OpenAI HTTP-API:er baserat på nödvändig affärslogik.

Användningen av gatewayteknik som inte kommer från Microsoft, som är en produkt eller tjänst som inte tillhandahålls internt av Azure, kan betraktas som en del av den här metoden.

Exempelarkitektur

Diagram som visar en exempelarkitektur för att mata in en gateway mellan ett intelligent program och Azure OpenAI.

Bild 2: Exempelarkitektur för åtkomst till Azure OpenAI via en Azure API Management-baserad gateway

Nästa steg

Lär dig mer om ett specifikt scenario där distribution av en gateway mellan ett intelligent program och Azure OpenAI-distributioner används för att hantera arbetsbelastningskrav:

Lär dig hur du implementerar loggning och övervakning för Azure OpenAI-modeller.