Een gateway gebruiken vóór meerdere Azure OpenAI-implementaties of -exemplaren

Workloadarchitecturen die betrekking hebben op De Azure OpenAI-service, kunnen net zo eenvoudig zijn als een of meer clienttoepassingen die rechtstreeks één Azure OpenAI-modelimplementatie gebruiken, maar niet alle workloads kunnen met een dergelijke eenvoud worden ontworpen. Complexere scenario's omvatten topologieën met meerdere clients, meerdere Azure OpenAI-implementaties of meerdere Azure OpenAI-exemplaren. In dergelijke situaties kan het introduceren van een gateway voor Azure OpenAI nuttig zijn voor het ontwerp van de workload als programmeerbare routeringsmechanisme.

Meerdere Azure OpenAI-exemplaren of modelimplementaties lossen specifieke vereisten op in een workloadarchitectuur. Ze kunnen worden geclassificeerd in vier belangrijke topologieën.

• Meerdere modelimplementaties in één Azure OpenAI-exemplaar
• Meerdere Azure OpenAI-exemplaren in één regio en één abonnement
• Meerdere Azure OpenAI-exemplaren in één regio in meerdere abonnementen
• Meerdere Azure OpenAI-exemplaren in meerdere regio's

Deze topologieën zelf maken het gebruik van een gateway niet noodzakelijk. De keuze van een gateway is afhankelijk van of de workload profiteert van de opname in de architectuur. In dit artikel worden de uitdagingen beschreven die elk van de vier topologieën aanpakken en de voordelen en kosten van het opnemen van een gateway in elke topologie.

Meerdere modelimplementaties in één Azure OpenAI-exemplaar

Topologiedetails voor meerdere modelimplementaties

• Azure OpenAI-modelimplementaties: meerdere
• Azure OpenAI-exemplaren: één
• Abonnementen: één
• Regio's: één

Topologiegebruiksvoorbeelden voor meerdere modelimplementaties

Een topologie die één Azure OpenAI-exemplaar bevat, maar meerdere gelijktijdig geïmplementeerde modellen bevat, ondersteunt de volgende use cases:

• Maak verschillende modelmogelijkheden beschikbaar, zoals gpt-35-turbo, gpt-4en aangepaste, afgestemde modellen.

• Maak verschillende modelversies beschikbaar, zoals 0613, 1106en aangepaste, afgestemde modellen ter ondersteuning van de evolutie van workloads of blauwgroene implementaties.

• Stel verschillende quota beschikbaar die zijn toegewezen (30.000 Token-Per-Minuut (TPM), 60.000 TPM ter ondersteuning van verbruiksbeperking voor meerdere clients.

Een gateway introduceren voor meerdere modelimplementaties

Introductie van een gateway in deze topologie is voornamelijk bedoeld om clients te abstraheren van het zelf selecteren van een specifiek modelexemplaren onder de beschikbare implementaties op het exemplaar. Met een gateway kan aan de serverzijde een clientaanvraag worden omleiden naar een specifiek model zonder clientcode opnieuw te hoeven implementeren of clientconfiguratie te wijzigen.

Een gateway is vooral nuttig wanneer u de clientcode niet bepaalt. Het is ook nuttig bij het implementeren van clientconfiguraties is complexer of riskanter dan het implementeren van wijzigingen in een gatewayrouteringsconfiguratie. U kunt wijzigen naar welk model een client verwijst op basis van een blauwgroene implementatiestrategie van uw modelversies, zoals het uitrollen van een nieuw afgestemd model of van versie X naar X+1 van hetzelfde model.

De gateway kan ook worden gebruikt als één API-toegangspunt waarmee de gateway de client kan identificeren. Vervolgens kan worden bepaald welke modelimplementatie wordt gebruikt om de prompt te verwerken op basis van de identiteit van die client of andere informatie in de HTTP-aanvraag. In een multitenant-oplossing kunnen tenants bijvoorbeeld worden beperkt tot specifieke doorvoer en is de implementatie van de architectuur een modelimplementatie per tenant met specifieke quota. In dit geval is de routering naar het model van de tenant de verantwoordelijkheid van de gateway op basis van informatie in de HTTP-aanvraag.

Door een gateway in deze topologie te gebruiken, kunnen op clients gebaseerde gebruiksgegevens worden bijgehouden. Tenzij clients afzonderlijke Microsoft Entra-service-principals gebruiken, kunnen de toegangslogboeken voor Azure OpenAI niet meerdere clients onderscheiden. Als u een gateway voor de implementatie hebt, biedt uw workload de mogelijkheid om het gebruik per client bij te houden in verschillende beschikbare modelimplementaties ter ondersteuning van terugstortings- of showbackmodellen.

Tips voor de topologie voor meerdere modelimplementaties

• Hoewel de gateway in staat is om volledig te wijzigen welk model wordt gebruikt, bijvoorbeeld gpt-35-turbogpt-4, wordt die wijziging waarschijnlijk beschouwd als een belangrijke wijziging voor de client. Laat nieuwe functionele mogelijkheden van de gateway niet afleiden van het altijd uitvoeren van veilige implementatieprocedures voor deze workload.

• Deze topologie is doorgaans eenvoudig genoeg om te implementeren via Azure API Management-beleid in plaats van een aangepaste codeoplossing.

• Om systeemeigen SDK's te ondersteunen met gepubliceerde Azure OpenAI API-specificaties, onderhoudt u API-compatibiliteit met de Azure OpenAI-API. Deze situatie is een grotere zorg wanneer uw team niet alle code van uw workloadclients ontwerpt. Overweeg bij het ontwerpen van de HTTP-API voor de gateway de voordelen van het onderhouden van azure OpenAI HTTP API-compatibiliteit.

• Hoewel deze topologie technisch gezien ondersteuning biedt voor passthrough-clientreferenties (toegangstokens of API-sleutel) voor het Azure OpenAI-exemplaar, is het raadzaam om referentie-beëindiging en herstel te implementeren. Op deze manier wordt de client geautoriseerd bij de gateway en wordt de gateway geautoriseerd via Azure RBAC naar het Azure OpenAI-exemplaar.

• Als de gateway is ontworpen voor het gebruik van passthrough-referenties, moet u ervoor zorgen dat clients de gateway of modelbeperkingen niet kunnen omzeilen op basis van de client.

• Implementeer uw gateway in dezelfde regio als het Azure OpenAI-exemplaar.

• Implementeer de gateway in een toegewezen resourcegroep in het abonnement dat losstaat van het Azure OpenAI-exemplaar. Het isoleren van het abonnement van de back-ends kan helpen bij het stimuleren van een APIOps-benadering door middel van scheidingen van zorg.

• Implementeer de gateway in een virtueel netwerk dat een subnet bevat voor het Privé-eindpunt van Azure OpenAI van het Azure OpenAI-exemplaar. Pas NSG-regels (netwerkbeveiligingsgroep) toe op dat subnet om alleen de gatewaytoegang tot dat privé-eindpunt toe te staan. Alle andere gegevenslaagtoegang tot de Azure OpenAI-exemplaren moet niet zijn toegestaan.

Redenen om een gateway voor meerdere modelimplementaties te voorkomen

Als het beheren van de configuratie van uw clients net zo eenvoudig is als of eenvoudiger is dan het beheren van de routering op gatewayniveau, is de toegevoegde betrouwbaarheid, beveiliging, kosten, onderhoud en prestatie-impact van de gateway mogelijk niet de moeite waard voor het toegevoegde architectuuronderdeel.

Sommige workloadscenario's kunnen ook baat hebben bij het migreren van een implementatiebenadering met meerdere modellen naar een implementatiebenadering van meerdere Azure OpenAI-exemplaren. Denk bijvoorbeeld aan meerdere Azure OpenAI-exemplaren als u meerdere clients hebt die verschillende RBAC- of toegangssleutels moeten gebruiken om toegang te krijgen tot hun model. Het gebruik van meerdere implementaties in één Azure OpenAI-exemplaar en het verwerken van logische identiteitssegmentatie op gatewayniveau is mogelijk, maar kan overmatig zijn wanneer een fysieke RBAC-segmentatiebenadering beschikbaar is met behulp van afzonderlijke Azure OpenAI-exemplaren.

Meerdere Azure OpenAI-exemplaren in één regio en één abonnement

Topologiedetails voor meerdere exemplaren in één regio en één abonnement

• Azure OpenAI-modelimplementaties: een of meer
• Azure OpenAI-exemplaren: meerdere
• Abonnementen: één
• Regio's: één

Topologiegebruiksvoorbeelden voor meerdere exemplaren in één regio en één abonnement

Een topologie met meerdere Azure OpenAI-exemplaren in één regio en één abonnement ondersteunt de volgende use cases:

• Maakt beveiligingssegmentatiegrenzen mogelijk, zoals sleutel of RBAC per client

• Maakt een eenvoudig terugstortingsmodel mogelijk voor verschillende clients

• Maakt een failoverstrategie mogelijk voor azure OpenAI-beschikbaarheid, zoals een platformstoring die van invloed is op een specifiek exemplaar, een onjuiste configuratie van netwerken of een per ongeluk verwijderde implementatie

• Maakt een failoverstrategie mogelijk voor beschikbaarheid van Azure OpenAI-quota, zoals het koppelen van zowel een ingericht exemplaar als een standaardexemplaren voor overloop

Een gateway introduceren voor meerdere exemplaren in één regio en een abonnement

Een model is mogelijk om verschillende redenen niet toegankelijk voor een client. Deze redenen omvatten onderbrekingen in De Azure OpenAI-service, Azure OpenAI-beperkingsaanvragen of problemen met betrekking tot workloadbewerkingen, zoals onjuiste netwerkconfiguratie of onbedoeld verwijderen van een modelimplementatie. Om deze uitdagingen aan te pakken, moet u logica voor opnieuw proberen en circuitonderbreking implementeren.

Deze logica kan worden geïmplementeerd in clients of serverzijde in een gateway. Het implementeren van de logica in een gateway abstraheert de logica weg van clients, wat resulteert in geen herhaalde code en één plaats om de logica te testen. Ongeacht of u de clientcode bezit of niet, kan deze verschuiving de betrouwbaarheid van de workload verhogen.

Als u een gateway gebruikt met meerdere Azure OpenAI-exemplaren in één regio en een abonnement, kunt u alle back-ends behandelen als actief-actieve implementaties en niet alleen gebruiken in actief-passieve failovers. U kunt hetzelfde ingerichte model implementeren in meerdere Azure OpenAI-exemplaren en de gateway gebruiken om de taakverdeling tussen deze exemplaren te verdelen.

Een optie die een workloadteam heeft bij het inrichten van Azure OpenAI, is bepalen of het facturerings- en doorvoermodel is ingericht of standaard. Een strategie voor kostenoptimalisatie om afval te voorkomen door ongebruikte ingerichte capaciteit is door het inrichten van het ingerichte exemplaar enigszins te onderbouwen en er ook een standaardexemplaren naast te implementeren. Het doel van deze topologie is dat clients eerst alle beschikbare vooraf toegewezen doorvoer verbruiken en vervolgens 'burst' naar de standaardimplementatie voor overschrijdingen. Deze vorm van geplande failover profiteert van dezelfde reden als vermeld in de openingsalinea van deze sectie: deze complexiteit buiten clientcode houden.

Wanneer een gateway betrokken is, bevindt deze zich op een unieke positie om details vast te leggen over alle modelimplementaties waarmee clients werken. Hoewel elk exemplaar van Azure OpenAI zijn eigen telemetrie kan vastleggen, kan het workloadteam in de gateway telemetrie en foutreacties publiceren voor alle verbruikte modellen naar één archief, waardoor geïntegreerde dashboarding en waarschuwingen eenvoudiger worden.

Tips voor de meerdere exemplaren in één regio en abonnementstopologie

• Zorg ervoor dat de gateway gebruikmaakt van de Retry-After informatie die beschikbaar is in het HTTP-antwoord van Azure OpenAI bij het ondersteunen van failoverscenario's op de gateway. Gebruik deze gezaghebbende informatie om de implementatie van uw circuitonderbreker te beheren. Raak niet continu een eindpunt dat een 429 Too Many Requestsretourneert. In plaats daarvan moet u het circuit voor dat modelexemplaren verbreken.

• Het voorspellen van beperkingsevenementen voordat ze plaatsvinden door het bijhouden van modelverbruik via eerdere aanvragen is mogelijk in de gateway, maar is beladen met edge-zaken. In de meeste gevallen kunt u het beste niet proberen te voorspellen, maar HTTP-antwoordcodes gebruiken om toekomstige routeringsbeslissingen te nemen.

• Wanneer round robin wordt uitgevoerd of een failover naar een ander eindpunt uitvoert, inclusief ingerichte overloop naar standaardimplementaties, moet u er altijd voor zorgen dat deze eindpunten hetzelfde model in dezelfde versie gebruiken. Voer bijvoorbeeld geen failover uit van of gpt-4 van gpt-35-turbo versie X naar versie X+1 of taakverdeling tussen deze. Deze versiewijziging kan onverwacht gedrag in de clients veroorzaken.

• Taakverdeling en failoverlogica kunnen worden geïmplementeerd binnen Azure API Management-beleid. Mogelijk kunt u een geavanceerdere benadering bieden met behulp van een gatewayoplossing op basis van code, maar API Management is voldoende voor deze use-case.

• Implementeer uw gateway in dezelfde regio als het Azure OpenAI-exemplaar.

• Implementeer de gateway in een toegewezen resourcegroep in het abonnement dat gescheiden is van de Azure OpenAI-exemplaren. Als de gateway is geïsoleerd van de back-ends, kan dit helpen bij het stimuleren van een APIOps-benadering door middel van scheidingen van zorg.

• Plaats alle privé-eindpunten van het Azure OpenAI-exemplaar van Private Link op één subnet in het virtuele netwerk van de gateway. Pas NSG-regels toe op dat subnet om alleen de gatewaytoegang tot deze privé-eindpunten toe te staan. Alle andere gegevenslaagtoegang tot de Azure OpenAI-exemplaren moet niet zijn toegestaan.

• Gebruik dezelfde modelimplementatienaam om het verschil tussen de HTTP-routes te minimaliseren om de logica in uw gatewayrouteringscode te vereenvoudigen. De modelnaam gpt4-v1 kan bijvoorbeeld worden gebruikt voor alle exemplaren met gelijke taakverdeling of overloop, ongeacht of deze standaard of ingericht is.

Redenen om een gateway te voorkomen voor meerdere exemplaren in één regio en abonnement

Een gateway zelf verbetert niet de mogelijkheid om modellen terug te rekenen op verschillende clients voor deze specifieke topologie. In deze topologie kunnen clients toegang krijgen tot hun eigen toegewezen Azure OpenAI-exemplaren, die ondersteuning bieden voor de mogelijkheid van uw workloadteam om terugstorting of showback uit te voeren. Dit model ondersteunt unieke identiteits- en netwerkperimeters, zodat een gateway niet specifiek hoeft te worden geïntroduceerd voor segmentatie.

Als u een paar clients in het gebied hebt waar u de code bepaalt en de clients eenvoudig kunnen worden bijgewerkt, kan de logica die u in de gateway moet inbouwen rechtstreeks in de code worden toegevoegd. Overweeg om de gatewaybenadering voor failover of taakverdeling voornamelijk te gebruiken wanneer u niet de eigenaar bent van de clientcode of de complexiteit te veel is voor de clients die moeten worden verwerkt.

Als u een gateway gebruikt om capaciteitsbeperkingen aan te pakken, moet u evalueren of capaciteitsfuncties op basis van een gegevenszone voldoende zijn voor uw workload.

Meerdere Azure OpenAI-exemplaren in één regio in meerdere abonnementen

Topologiedetails voor meerdere Azure OpenAI-exemplaren in één regio voor meerdere abonnementen

• Azure OpenAI-modelimplementaties: een of meer
• Azure OpenAI-exemplaren: meerdere
• Abonnementen: meerdere
• Regio's: één

Topologiegebruiksvoorbeelden voor meerdere Azure OpenAI-exemplaren in één regio voor meerdere abonnementen

Een topologie met meerdere Azure OpenAI-exemplaren in één regio in meerdere abonnementen ondersteunt de volgende use cases:

• Bevat alle gebruiksvoorbeelden die worden vermeld voor meerdere Azure OpenAI-exemplaren in één regio en één abonnement.

• U wilt meer quotum verkrijgen in een standaardimplementatie en u moet het gebruik van modellen beperken tot één specifieke regio.

  Notitie

  Als u het gebruik van modellen niet hoeft te beperken tot een specifieke regio, moet u globale of gegevenszone gebruiken implementaties van Azure OpenAI die gebruikmaken van de globale infrastructuur van Azure om de deductieaanvragen dynamisch te routeren naar datacenters met de beschikbare capaciteit.

Een gateway introduceren voor meerdere exemplaren in één regio en meerdere abonnementen

Dezelfde redenen die worden behandeld in Een gateway introduceren voor meerdere exemplaren in één regio en een abonnement zijn van toepassing op deze topologie.

Naast deze redenen biedt het toevoegen van een gateway in deze topologie ook ondersteuning voor een gecentraliseerd team dat een 'Azure OpenAI as a service'-model biedt voor hun organisatie. Omdat het quotum in een standaardimplementatie abonnementsgebonden is, moet een gecentraliseerd team dat Azure OpenAI-services biedt die gebruikmaken van de standaardimplementatie Azure OpenAI-exemplaren implementeren voor meerdere abonnementen om het vereiste quotum te verkrijgen. De gatewaylogica blijft nog steeds grotendeels hetzelfde.

Tips voor de topologie van meerdere exemplaren in één regio en meerdere abonnementen

• In het ideale geval moeten alle abonnementen worden ondersteund met dezelfde Microsoft Entra-tenant ter ondersteuning van consistentie in Azure RBAC en Azure Policy.

• Implementeer uw gateway in dezelfde regio als het Azure OpenAI-exemplaar.

• Implementeer de gateway in een toegewezen abonnement dat losstaat van de Azure OpenAI-exemplaren. Dit helpt bij het afdwingen van consistentie bij het aanpakken van de Azure OpenAI-exemplaren en biedt een logische segmentatie van taken tussen Azure OpenAI-implementaties en hun routering.

• Zorg ervoor dat privé-eindpunten bereikbaar zijn wanneer aanvragen van uw gateway tussen abonnementen worden gerouteerd. U kunt transitieve routering via een hub gebruiken naar privé-eindpunten voor de back-ends in hun respectieve spokes. Mogelijk kunt u privé-eindpunten beschikbaar maken voor de Azure OpenAI-services rechtstreeks in het gatewayabonnement met behulp van Private Link-verbindingen tussen abonnementen. Private Link-verbindingen tussen abonnementen hebben de voorkeur als uw architectuur en organisatie deze benadering ondersteunen.

Redenen om een gateway te voorkomen voor meerdere exemplaren in één regio en meerdere abonnementen

Alle redenen om een gateway voor meerdere exemplaren in één regio en abonnement te voorkomen, zijn van toepassing op deze topologie.

Meerdere Azure OpenAI-exemplaren in meerdere regio's

Topologiedetails voor meerdere Azure OpenAI-exemplaren in meerdere regio's

• Azure OpenAI-modelimplementaties: meerdere
• Azure OpenAI-exemplaren: meerdere
• Abonnementen: een of meer
• Regio's: meerdere

Topologiegebruiksvoorbeelden voor meerdere Azure OpenAI-exemplaren in meerdere regio's

Een topologie met meerdere Azure OpenAI-exemplaren verspreid over twee of meer Azure-regio's ondersteunt de volgende use cases:

• Bevat alle gebruiksvoorbeelden die worden vermeld voor meerdere Azure OpenAI-exemplaren in één regio in meerdere abonnementen.

• Maakt een failoverstrategie mogelijk voor servicebeschikbaarheid, zoals het gebruik van paren tussen regio's.

• Hiermee kunt u een ontwerp voor gegevenslocatie en naleving inschakelen.

• Maakt beschikbaarheid van gemengde modellen mogelijk. Sommige regio's hebben verschillende modellen en verschillende quota's die beschikbaar zijn voor de modellen.

Hoewel technisch geen verschillende Azure-regio's zijn, is deze topologie ook van toepassing wanneer u een AI-model beschikbaar hebt gemaakt in een situatie tussen meerdere locaties, zoals on-premises of in een andere cloud.

Een gateway introduceren voor meerdere exemplaren in meerdere regio's

Voor bedrijfskritieke architecturen die een volledige regionale storing moeten overleven, helpt een wereldwijde, geïntegreerde gateway om failoverlogica uit clientcode te elimineren. Deze implementatie vereist dat de gateway niet wordt beïnvloed door een regionale storing.

Azure API Management gebruiken (implementatie met één regio)

In deze topologie wordt Azure API Management specifiek gebruikt voor de gatewaytechnologie. Hier wordt API Management geïmplementeerd in één regio. Vanuit dat gateway-exemplaar voert u actief-actief taakverdeling uit tussen regio's. Het beleid in uw gateway verwijst naar al uw Azure OpenAI-exemplaren. Voor de gateway is een netwerklijn vereist voor elke back-end tussen regio's, via peering tussen regio's of privé-eindpunten. Bij aanroepen van deze gateway naar een Azure OpenAI-exemplaar in een andere regio worden meer netwerklatentie- en uitgaande kosten in rekening gebracht.

Uw gateway moet de beperkings- en beschikbaarheidssignalen van de Azure OpenAI-exemplaren respecteren en back-ends uit de pool verwijderen totdat de defecte of beperkte Azure OpenAI-instantie veilig is gelezen. De gateway moet de huidige aanvraag opnieuw proberen tegen een ander back-endexemplaren in de pool na een fout, voordat u terugvalt op het retourneren van een gatewayfout. De statuscontrole van de gateway moet niet in orde zijn wanneer er geen back-end Azure OpenAI-exemplaren beschikbaar zijn.

Omdat deze topologie een single point of failure (de gateway) introduceert, is het hulpprogramma van deze specifieke architectuur redelijk beperkt: bescherming tegen regionale Azure OpenAI-eindpuntstoringen.

Actief-passieve variant

Dit model kan ook worden gebruikt om een actief-passieve benadering te bieden om specifiek regionale fouten van alleen Azure OpenAI af te handelen. In deze modus stroomt verkeer normaal gesproken van de gateway naar het Azure OpenAI-exemplaar in dezelfde regio als de API Management-service. Dit exemplaar van Azure OpenAI verwerkt alle verwachte verkeersstroom zonder regionale storingen. Het kan worden ingericht of standaard, afhankelijk van uw voorkeursfactureringsmodel. In het geval van een regionale fout van alleen Azure OpenAI kan de gateway verkeer omleiden naar een andere regio met Azure OpenAI die al in een standaardimplementatie is geïmplementeerd.

Azure API Management gebruiken (implementatie in meerdere regio's)

Api Management biedt ondersteuning voor het implementeren van een exemplaar in meerdere Azure-regio's om de betrouwbaarheid van de eerdere architectuur op basis van Azure API Management te verbeteren. Deze implementatieoptie biedt u één besturingsvlak via één API Management-exemplaar, maar biedt gerepliceerde gateways in de regio's van uw keuze. In deze topologie implementeert u gatewayonderdelen in elke regio met Azure OpenAI-exemplaren die een actief-actief-gatewayarchitectuur bieden.

Beleidsregels zoals routerings- en aanvraagafhandelingslogica worden gerepliceerd naar elke afzonderlijke gateway. Alle beleidslogica moet voorwaardelijke logica in het beleid hebben om ervoor te zorgen dat u Azure OpenAI-exemplaren aanroept in dezelfde regio als de huidige gateway. Zie Route-API-aanroepen naar regionale back-endservices voor meer informatie. Het gatewayonderdeel vereist vervolgens alleen netwerklijn voor Azure OpenAI-exemplaren in een eigen regio, meestal via privé-eindpunten.

API Management biedt kant-en-klare wereldwijde FQDN-routering (Fully Qualified Domain Name) op basis van de laagste latentie. Gebruik deze ingebouwde functionaliteit op basis van prestaties voor actieve-actieve gatewayimplementaties. Deze ingebouwde functionaliteit helpt bij het oplossen van prestaties en het afhandelen van een regionale gatewaystoring. De ingebouwde globale router biedt ook ondersteuning voor het testen van herstel na noodgevallen, omdat regio's kunnen worden gesimuleerd door afzonderlijke gateways uit te schakelen. Zorg ervoor dat clients de time to live (TTL) op de FQDN respecteren en de juiste logica voor opnieuw proberen hebben om een recente DNS-failover af te handelen.

Als u een webtoepassingsfirewall in deze architectuur moet introduceren, kunt u nog steeds de ingebouwde FQDN-routeringsoplossing gebruiken als de back-end-oorsprong voor uw globale router die een web application firewall implementeert. De globale router zou failoververantwoordelijkheid delegeren aan API Management. U kunt ook de FQDN's van de regionale gateway gebruiken als leden van de back-endpool. In deze laatste architectuur gebruikt u het ingebouwde /status-0123456789abcdef eindpunt op elke regionale gateway of een ander aangepast api-eindpunt voor de status om regionale failover te ondersteunen. Als u het niet zeker weet, begint u met de FQDN-benadering van één oorspronkelijke back-end.

Deze architectuur werkt het beste als u regio's kunt behandelen als volledig beschikbaar of volledig niet beschikbaar. Dit betekent dat als de API Management-gateway of het Azure OpenAI-exemplaar niet beschikbaar is, het clientverkeer niet meer naar de API Management-gateway in die regio moet worden gerouteerd. Tenzij er een andere inrichting wordt gemaakt, moet de fout worden doorgegeven aan de client als de regionale gateway nog steeds verkeer accepteert terwijl Azure OpenAI niet beschikbaar is. Als u de clientfout wilt voorkomen, raadpleegt u een verbeterde benadering in active-active gateway plus actief-passieve Azure OpenAI-variant.

Als een regio een storing in de API Management-gateway ondervindt of als beschadigd wordt gemarkeerd, moeten de resterende beschikbare regio's 100% van het verkeer van die andere regio's absorberen. Dit betekent dat u over-ingerichte Azure OpenAI-exemplaren moet inrichten om de nieuwe burst van verkeer af te handelen of een actief-passieve benadering voor failover-te gebruiken. Gebruik de Azure OpenAI-capaciteitscalculator voor capaciteitsplanning.

Zorg ervoor dat de resourcegroep die Azure API Management bevat, dezelfde locatie is als het API Management-exemplaar zelf om de straal van een gerelateerde regionale storing te verminderen die van invloed is op de mogelijkheid om toegang te krijgen tot de resourceprovider voor uw gateways.

Actief-actieve gateway plus actief-passieve Azure OpenAI-variant

In de vorige sectie wordt de beschikbaarheid van de gateway opgelost door een actief-actief-gatewaytopologie op te geven. Deze topologie combineert de actief-actieve gateway met een rendabele actief-passieve Azure OpenAI-topologie. Door actief-passieve logica toe te voegen aan de gateway om een failover uit te voeren naar een standaard Azure OpenAI-implementatie vanuit een ingerichte implementatie, kan de betrouwbaarheid van de workload aanzienlijk toenemen. Met dit model kunnen clients nog steeds de ingebouwde FQDN-routeringsoplossing van API Management gebruiken voor routering op basis van prestaties.

Een aangepaste, gecodeerde gateway gebruiken

Als uw regels voor routering per gateway te complex zijn voor uw team om redelijk te overwegen als Azure API Management-beleid, moet u uw eigen oplossing implementeren en beheren. Deze architectuur moet een implementatie met meerdere regio's van uw gateway zijn, met één maximaal beschikbare schaaleenheid per regio. U moet deze implementaties fronteren met Azure Front Door (Anycast) of Azure Traffic Manager (DNS), meestal met behulp van routering op basis van latentie en de juiste statuscontroles van de beschikbaarheid van de gateway.

Gebruik Azure Front Door als u een firewall voor webtoepassingen en openbare internettoegang nodig hebt. Gebruik Traffic Manager als u geen firewall voor webtoepassingen nodig hebt en DNS TTL voldoende is. Zorg ervoor dat de gateway niet kan worden omzeild wanneer u uw gatewayexemplaren fronteert met Azure Front Door (of een omgekeerde proxy). Maak de gateway-exemplaren alleen beschikbaar via een privé-eindpunt wanneer u Azure Front Door gebruikt en voeg validatie van de X_AZURE_FDID HTTP-header toe in uw gateway-implementatie.

Plaats resources per regio die worden gebruikt in uw aangepaste gateway in resourcegroepen per regio. Dit vermindert de straalstraal van een gerelateerde regionale storing die van invloed is op uw mogelijkheid om toegang te krijgen tot de resourceprovider voor uw gatewayresources in die regio.

U kunt ook overwegen om uw gatewaylogica-implementatie te fronten met Azure API Management, voor de andere voordelen van API Management, zoals TLS, verificatie, statuscontrole of round robin-taakverdeling. Dit verschuift veelvoorkomende API-problemen uit aangepaste code in uw gateway en stelt uw gateway in staat om specifiek de routering van azure OpenAI-exemplaar en modelimplementatie aan te pakken.

Voor naleving van gegevenslocatie moet u ervoor zorgen dat elke geopolitieke grens een eigen geïsoleerde implementatie van deze architectuur heeft en dat clients alleen hun geautoriseerde eindpunt kunnen bereiken.

Redenen om een gateway te voorkomen voor meerdere exemplaren in meerdere regio's

Implementeer geen geïntegreerde gateway in geopolitieke regio's wanneer gegevenslocatie en naleving vereist zijn. Dit zou in strijd zijn met de vereisten voor gegevenslocatie. Gebruik afzonderlijk adresseerbare gateways per regio en volg de richtlijnen in een van de vorige secties.

Implementeer niet alleen een uniforme gateway voor het verhogen van het quotum. Gebruik Wereldwijde-implementaties van Azure OpenAI gebruikmaken van de globale infrastructuur van Azure om aanvragen dynamisch naar datacenters te routeren met de beste capaciteit voor elke aanvraag.

Als clients geen failover tussen regio's verwachten en u clients de mogelijkheid hebt om clients een specifieke gateway te geven om te gebruiken, gebruikt u in plaats daarvan meerdere gateways, één per regio en volgt u de richtlijnen in een van de vorige secties. Koppel de beschikbaarheid van andere regio's niet aan de regio met uw gateway als één storingspunt.

Implementeer geen geïntegreerde gateway als uw model en versie niet beschikbaar zijn in alle regio's die door de gateway worden weergegeven. Clients moeten worden gerouteerd naar hetzelfde model en dezelfde modelversie. Voor gateways met gelijke taakverdeling en failover voor meerdere regio's moet u een gemeenschappelijk model en modelversie kiezen die beschikbaar is in alle betrokken regio's. Zie De beschikbaarheid van modellen voor meer informatie. Als u model- en modelversie niet kunt standaardiseren, is het voordeel van de gateway beperkt.

Algemene aanbevelingen

Ongeacht welke topologie uw workload nodig heeft, zijn er enkele aanbevelingen die u moet overwegen bij het bouwen van uw gatewayoplossing.

Stateful interacties

Wanneer clients stateful functies van Azure OpenAI gebruiken, zoals de Api voor assistenten, moet u uw gateway configureren om een client vast te maken aan een specifieke back-end tijdens die interactie. U kunt dit doen door instantiegegevens op te slaan in een cookie. In deze scenario's kunt u overwegen om een API-antwoord te retourneren, zoals een 429 naar een vastgemaakte client in plaats van deze om te leiden naar een ander Azure OpenAI-exemplaar. Hierdoor kan de client plotselinge onbeschikbaarheid expliciet afhandelen en deze verbergen en worden doorgestuurd naar een modelinstantie die geen geschiedenis heeft.

Gatewaystatuscontroles

Er zijn twee perspectieven voor statuscontrole, ongeacht de topologie.

Als uw gateway is gebouwd rond round robining of strikt presterende failover van servicebeschikbaarheid, wilt u een manier om een Azure OpenAI-exemplaar (of model) uit de beschikbaarheidsstatus te halen. Azure OpenAI biedt geen statuscontrole-eindpunt om preventief te weten of het beschikbaar is voor het verwerken van aanvragen. U kunt synthetische overgangen verzenden, maar dat verbruikt modelcapaciteit. Tenzij u een andere betrouwbare signaalbron voor azure OpenAI-exemplaar en modelbeschikbaarheid hebt, moet uw gateway er waarschijnlijk van uitgaan dat het Azure OpenAI-exemplaar up is en vervolgens http-statuscodes verwerkt 429500503 als signaal voor circuitonderbreking voor toekomstige aanvragen op dat exemplaar of model. Voor beperkingssituaties moet u altijd de gegevens in de header in de Retry-After Azure OpenAI API-antwoorden respecteren voor 429 antwoordcodes in uw circuitonderbrekingslogica. Als u Azure API Management gebruikt, evalueert u met behulp van de ingebouwde circuitonderbrekerfunctionaliteit .

Uw klanten of uw workloadbewerkingsteam willen mogelijk een statuscontrole op uw gateway laten zien voor hun eigen routerings- of introspectiedoeleinden. Als u API Management gebruikt, is de standaardinstelling /status-0123456789abcdef mogelijk niet gedetailleerd genoeg omdat deze meestal het API Management-gatewayexemplaren adresseren, niet uw back-ends. Overweeg om een toegewezen statuscontrole-API toe te voegen die zinvolle gegevens kan retourneren aan clients of waarneembaarheidssystemen op de beschikbaarheid van de gateway of specifieke routes in de gateway.

Veilige implementatiemethoden

U kunt gatewayimplementaties gebruiken om blauwgroene implementaties van bijgewerkte modellen te organiseren. Azure OpenAI-modellen worden bijgewerkt met nieuwe modelversies en nieuwe modellen, en mogelijk hebt u nieuwe aangepaste modellen.

Nadat u de effecten van een wijziging in de preproductie hebt getest, moet u evalueren of productieclients moeten worden 'overgesneden' naar de nieuwe modelversie of in plaats daarvan verkeer moeten verschuiven. Met het eerder beschreven gatewaypatroon kan de back-end beide modellen gelijktijdig implementeren. Het gelijktijdig implementeren van modellen biedt de gateway de kracht om verkeer om te leiden op basis van de veilige implementatiepraktijk van het workloadteam van incrementele implementatie.

Zelfs als u geen blauwgroene implementaties gebruikt, moet de APIOps-benadering van uw workload worden gedefinieerd en voldoende geautomatiseerd worden met de snelheid van wijziging van uw back-endexemplementatie en modelimplementaties.

Net genoeg implementatie

Veel van de scenario's die in dit artikel zijn geïntroduceerd, helpen de potentiële SLO (Service Level Objective) van uw workload te verhogen door de complexiteit van de client te verminderen en betrouwbare technieken voor zelfbehoud te implementeren. Anderen verbeteren de beveiliging van de workload door toegangsbeheer naar specifieke modellen weg te verplaatsen van Azure OpenAI. Zorg ervoor dat de introductie van de gateway geen teller voor deze doelen is. Inzicht in de risico's van het toevoegen van een nieuw single point of failure via servicefouten of door mensen veroorzaakte configuratieproblemen in de gateway, complexe routeringslogica of de risico's van het blootstellen van meer modellen aan onbevoegde clients dan bedoeld is.

Gegevenssoevereiniteit

De verschillende actief-actief- en actief-passieve benaderingen moeten worden geëvalueerd vanuit het perspectief van naleving van gegevenslocatie voor uw workload. Veel van deze patronen zijn van toepassing op de architectuur van uw workload als de betrokken regio's binnen de geopolitieke grenzen blijven. Ter ondersteuning van dit scenario moet u geopolitieke grenzen behandelen als geïsoleerde stempels en de actief-actief- of actief-passieve verwerking uitsluitend binnen die stempel toepassen.

In het bijzonder moet elke routering op basis van prestaties sterk worden gecontroleerd op naleving van gegevenssoevereiniteit. In scenario's voor gegevenssoevereine kunt u clients met een andere geografie niet onderhouden en compatibel blijven. Alle gatewayarchitecturen die betrekking hebben op gegevenslocatie, moeten afdwingen dat clients alleen eindpunten gebruiken in hun geopolitieke regio. De clients moeten worden geblokkeerd voor het gebruik van andere gateway-eindpunten en de gateway zelf schendt de vertrouwensrelatie van de client niet door een geopolitieke aanvraag te maken. De meest betrouwbare manier om deze segmentatie te implementeren, is door uw architectuur te bouwen rond een volledig onafhankelijke, maximaal beschikbare gateway per geopolitieke regio.

Wanneer u overweegt om te profiteren van een verhoogde capaciteit via globale of gegevenszone implementaties van Azure OpenAI, moet u begrijpen hoe deze implementaties van invloed zijn op de gegevenslocatie. Gegevens die in rust zijn opgeslagen, blijven in de aangewezen Azure-geografie voor implementaties van wereldwijde en gegevenszones. Deze gegevens kunnen worden verzonden en verwerkt voor deductie op elke Azure OpenAI-locatie voor globale implementaties of op een Azure OpenAI-locatie binnen de door Microsoft opgegeven gegevenszone voor implementaties van gegevenszones.

Azure OpenAI-autorisatie

De gateway moet worden geverifieerd met alle Azure OpenAI-exemplaren waarmee deze wordt geinterfaced. Tenzij u de gateway hebt ontworpen voor passthrough-verificatie, moet de gateway een beheerde identiteit gebruiken voor de referenties. Elk Azure OpenAI-exemplaar moet dus RBAC met minimale bevoegdheden configureren voor de beheerde identiteiten van de gateways. Zorg ervoor dat de identiteit van de gateway gelijkwaardige machtigingen heeft voor alle betrokken Azure OpenAI-exemplaren voor actief-actief- en failoverarchitecturen.

Azure Policy

Consistentie tussen modelimplementaties en Azure OpenAI-exemplaren is belangrijk in zowel actief-actief- als actief-passieve situaties. Gebruik Azure Policy om consistentie af te dwingen tussen de verschillende Azure OpenAI-exemplaren of modelimplementaties. Als het ingebouwde beleid voor Azure OpenAI niet voldoende is om consistentie tussen deze beleidsregels te garanderen, kunt u overwegen aangepaste beleidsregels te maken of te gebruiken.

Gatewayredundantie

Hoewel dit niet specifiek is voor meerdere back-ends, moet de gateway-implementatie van elke regio altijd worden gebouwd met redundantie en maximaal beschikbaar zijn binnen de schaaleenheid. Kies regio's met beschikbaarheidszones en zorg ervoor dat uw gateway over deze regio's is verdeeld. Implementeer meerdere exemplaren van de gateway, zodat single point of failure beperkt is tot een volledige regionale storing en niet de fout van één rekenproces in uw gateway. Implementeer voor Azure API Management twee of meer eenheden in twee of meer zones. Voor aangepaste code-implementaties implementeert u ten minste drie exemplaren met best effort-distributie in beschikbaarheidszones.

Gateway-implementaties

Azure biedt geen volledige kant-en-klare oplossing of referentiearchitectuur voor het bouwen van een dergelijke gateway die zich richt op het routeren van verkeer over meerdere back-ends. Azure API Management heeft echter de voorkeur omdat de service u een PaaS-oplossing biedt met behulp van ingebouwde functies zoals back-endpools, circuitonderbrekingsbeleid en aangepaste beleidsregels, indien nodig. Zie Overzicht van generatieve AI-gatewaymogelijkheden in Azure API Management om te evalueren wat er beschikbaar is in die service voor de multi-back-endbehoeften van uw workload.

Ongeacht of u API Management gebruikt of een aangepaste oplossing bouwt, zoals vermeld in het inleidingsartikel, moet uw workloadteam deze gateway bouwen en gebruiken. Hieronder volgen voorbeelden van enkele van de eerder genoemde gebruiksvoorbeelden. U kunt deze voorbeelden raadplegen wanneer u uw eigen proof-of-concept bouwt met API Management of aangepaste code.

Implementatie	Opmerking
Azure API Management	Slimme taakverdeling voor Azure OpenAI met behulp van Azure API Management : deze GitHub-opslagplaats bevat voorbeeldbeleidscode en instructies voor implementatie in uw abonnement. Azure OpenAI schalen met behulp van Azure API Management: deze GitHub-opslagplaats bevat voorbeeldbeleidscode en instructies voor ingerichte en standaardoverloop. De GenAI-gateway-toolkit bevat voorbeelden van API Management-beleidsregels, samen met een installatie voor het testen van het gedrag van het beleid.
Aangepaste code	Slimme taakverdeling voor Azure OpenAI met behulp van Azure Container Apps Deze GitHub-opslagplaats bevat voorbeeldcode en instructies voor het bouwen van de container en het implementeren in uw abonnement.

Het Cloud Adoption Framework voor Azure bevat ook richtlijnen voor het implementeren van een Azure API Management-landingszone voor generatieve AI-scenario's, waaronder dit scenario met meerdere back-ends. Als uw workload bestaat in een landingszone van een toepassing, raadpleegt u deze richtlijnen voor overwegingen en aanbevelingen voor de implementatie.

Volgende stappen

Het hebben van een gatewayimplementatie voor uw workload biedt voordelen buiten het tactische voordeel van meerdere back-endroutering dat in dit artikel wordt beschreven. Meer informatie over de andere belangrijke uitdagingen die een gateway kan oplossen.

Verwante resources

• Azure OpenAI-service
• Een goed ontworpen AI-workload ontwerpen
• API-gateway in Azure API Management