Bewerken

Delen via

Toegang tot Azure OpenAI en andere taalmodellen via een gateway

Azure AI services
Azure OpenAI Service
Azure API Management

Azure OpenAI Service biedt HTTP-API's waarmee uw toepassingen insluitingen of voltooiingen kunnen uitvoeren met behulp van de taalmodellen van OpenAI. Intelligente toepassingen roepen deze HTTP-API's rechtstreeks aan bij clients of orchestrators. Voorbeelden van clients zijn chat-UI-code en aangepaste pijplijnen voor gegevensverwerking. Voorbeelden van orchestrators zijn LangChain, Semantic Kernel en promptstroom in Azure AI Foundry. Wanneer uw workload verbinding maakt met een of meer Azure OpenAI-exemplaren, moet u beslissen of deze consumenten rechtstreeks verbinding maken of via een gateway voor een omgekeerde proxy-API.

Gebruik deze handleiding voor meer informatie over de belangrijkste uitdagingen in de vijf pijlers van het Azure Well-Architected Framework dat u tegenkomt als uw workloadontwerp directe toegang van uw consumenten tot de Azure OpenAI-gegevensvlak-API's omvat. Leer vervolgens hoe u een gateway in uw architectuur kunt introduceren om deze directe toegangsproblemen op te lossen, terwijl u nieuwe uitdagingen introduceert. In dit artikel wordt het architectuurpatroon beschreven, maar niet hoe u de gateway implementeert.

Omdat een gateway kan worden gebruikt om specifieke scenario's op te lossen die mogelijk niet aanwezig zijn in elke workload, raadpleegt u de richtlijnen voor specifieke scenario's, waarin wordt gekeken naar die specifieke use case van een gateway in meer detail.

Belangrijke uitdagingen

Zonder een API-gateway of de mogelijkheid om logica toe te voegen aan de HTTP-API's van Azure OpenAI, moet de client de API-clientlogica verwerken, waaronder mechanismen voor opnieuw proberen of circuitonderbrekers. Deze situatie kan lastig zijn in scenario's waarin u de clientcode niet rechtstreeks kunt beheren of wanneer de code is beperkt tot specifiek SDK-gebruik. Meerdere clients of meerdere Azure OpenAI-exemplaren en -implementaties bieden verdere uitdagingen, zoals coördinatie van veilige implementaties en waarneembaarheid.

Deze sectie bevat voorbeelden van specifieke belangrijke architecturale uitdagingen waarmee u te maken krijgt als uw architectuur alleen directe toegang tot Azure OpenAI van consumenten ondersteunt. De uitdagingen worden georganiseerd met behulp van de pijlers van het Azure Well-Architected Framework.

Problemen met betrouwbaarheid

De betrouwbaarheid van de workload is afhankelijk van verschillende factoren, waaronder de capaciteit voor zelfbehoud en zelfherstel, die vaak worden geïmplementeerd via replicatie- en failovermechanismen. Zonder een gateway moeten alle betrouwbaarheidsproblemen uitsluitend worden aangepakt met behulp van clientlogica en Azure OpenAI Service-functies. De betrouwbaarheid van de werkbelasting wordt aangetast wanneer er onvoldoende betrouwbaarheidscontrole beschikbaar is in een van deze twee oppervlakken.

  • taakverdeling of redundantie: Failover uitvoeren tussen meerdere Azure OpenAI-exemplaren op basis van de beschikbaarheid van de service is een clientverantwoordelijkheid die u moet beheren via configuratie en aangepaste logica.

    Globale, standaard of ingericht en gegevenszone, standaard of ingericht, heeft geen invloed op de beschikbaarheid van de Azure OpenAI-service vanuit het perspectief van regionale eindpunten. U hebt nog steeds de verantwoordelijkheid om zelf failoverlogica te implementeren.

  • Uitschalen om pieken te verwerken: failover naar Azure OpenAI-exemplaren met capaciteit wanneer de beperking een andere clientverantwoordelijkheid is die u moet beheren via configuratie en aangepaste logica. Het bijwerken van meerdere clientconfiguraties voor nieuwe Azure OpenAI-exemplaren vormt een groter risico en heeft problemen met tijd. Hetzelfde geldt voor het bijwerken van clientcode voor het implementeren van wijzigingen in logica, zoals het doorsturen van aanvragen met lage prioriteit naar een wachtrij tijdens perioden met hoge vraag.

  • beperking: Azure OpenAI-API's beperken aanvragen door een HTTP 429-foutcode te retourneren voor aanvragen die groter zijn dan de token-Per-Minute (TPM) of aanvragen-Per-Minute (RPM) in het standaardmodel. Azure OpenAI-API's beperken ook aanvragen die de ingerichte capaciteit voor het vooraf ingerichte factureringsmodel overschrijden. Het afhandelen van de juiste back-off en logica voor opnieuw proberen wordt uitsluitend overgelaten aan client-implementaties.

    De meeste workloads moeten dit specifieke probleem oplossen met behulp van globale en gegevenszone implementaties van Azure OpenAI. Deze implementaties voor het gebruik van modelcapaciteit van datacenters met de voldoende capaciteit voor elke aanvraag. Het gebruik van globale implementaties en gegevenszones vermindert de servicebeperking aanzienlijk zonder extra complexiteit van aangepaste gateways. De implementaties van globale en gegevenszones zijn zelf een gatewayimplementatie.

Beveiligingsuitdagingen

Beveiligingscontroles moeten helpen bij het beschermen van de vertrouwelijkheid, integriteit en beschikbaarheid van workloads. Zonder een gateway moeten alle beveiligingsproblemen uitsluitend worden aangepakt in clientlogica en Azure OpenAI-servicefuncties. Workloadvereisten kunnen meer vragen dan beschikbaar is voor clientsegmentatie-, clientbeheer- of servicebeveiligingsfuncties voor directe communicatie.

  • Identiteitsbeheer- verificatiebereik: de gegevensvlak-API's die worden weergegeven door Azure OpenAI, kunnen op twee manieren worden beveiligd: API-sleutel of op rollen gebaseerd toegangsbeheer van Azure (RBAC). In beide gevallen vindt verificatie plaats op het niveau van het Azure OpenAI-exemplaar, niet op het afzonderlijke implementatieniveau, wat complexiteit introduceert voor het bieden van minst bevoegde toegang en identiteitssegmentatie voor specifieke implementatiemodellen.

  • Identiteitsbeheer - id-providers: clients die geen identiteiten kunnen gebruiken die zich in de Microsoft Entra-tenant bevinden die de back-up van het Azure OpenAI-exemplaar maken, moeten één API-sleutel voor volledige toegang delen. API-sleutels hebben beperkingen voor de bruikbaarheid van de beveiliging en zijn problematisch wanneer meerdere clients betrokken zijn en allemaal dezelfde identiteit delen.

  • Netwerkbeveiliging: afhankelijk van de clientlocatie ten opzichte van uw Azure OpenAI-exemplaren, is openbare internettoegang tot taalmodellen mogelijk nodig.

  • Gegevenssoevereine: Gegevenssoevereine in de context van Azure OpenAI verwijst naar de wettelijke en wettelijke vereisten met betrekking tot de opslag en verwerking van gegevens binnen de geografische grenzen van een specifiek land of een specifieke regio. Uw workload moet zorgen voor regionale affiniteit, zodat clients kunnen voldoen aan de wetgeving inzake gegevenslocatie en soevereiniteit. Dit proces omvat meerdere Azure OpenAI-implementaties.

    Houd er rekening mee dat wanneer u globale of gegevenszone gebruikt implementaties van Azure OpenAI, gegevens-at-rest in de aangewezen Azure-geografie blijven staan, maar gegevens kunnen worden verzonden en verwerkt voor deductie op een Azure OpenAI-locatie.

Uitdagingen voor kostenoptimalisatie

Workloads profiteren wanneer architecturen verspilling minimaliseren en het hulpprogramma maximaliseren. Sterke kostenmodellering en -bewaking zijn een belangrijke vereiste voor elke workload. Zonder een gateway kan het gebruik van ingerichte of kostentracering per client uitsluitend worden bereikt door gebruikstelemetrie van Azure OpenAI-exemplaren te aggregeren.

  • Kosten bijhouden: het kunnen bieden van een financieel perspectief op Het gebruik van Azure OpenAI is beperkt tot gegevens die zijn geaggregeerd vanuit de gebruikstelemetrie van azure OpenAI-exemplaren. Wanneer dat nodig is om terugstorting of showback uit te voeren, moet u die gebruikstelemetrie toewijzen aan verschillende clients in verschillende afdelingen of zelfs klanten voor scenario's met meerdere tenants.

  • Ingerichte doorvoergebruik: uw workload wil verspilling voorkomen door de ingerichte doorvoer waarvoor u hebt betaald, volledig te gebruiken. Dit betekent dat clients moeten worden vertrouwd en gecoördineerd voor het gebruik van ingerichte modelimplementaties voordat ze overlopen in standaardmodelimplementaties.

Uitdagingen met operationele uitmuntendheid

Zonder een gateway zijn waarneembaarheid, wijzigingsbeheer en ontwikkelingsprocessen beperkt tot wat wordt geleverd door directe client-naar-server-communicatie.

  • Quotumbeheer: clients ontvangen rechtstreeks vanuit Azure OpenAI 429-antwoordcodes wanneer de HTTP-API's worden beperkt. Workloadoperators zijn verantwoordelijk voor het garanderen dat er voldoende quotum beschikbaar is voor legitiem gebruik en dat onjuiste naleving van clients niet te veel verbruikt. Wanneer uw workload bestaat uit meerdere modelimplementaties of meerdere gegevenszones, kan het lastig zijn om het quotumgebruik en de beschikbaarheid van quota te begrijpen.

  • Bewaking en waarneembaarheid: standaardgegevens van Azure OpenAI zijn beschikbaar via Azure Monitor. Er is echter latentie met de beschikbaarheid van de gegevens en biedt geen realtime bewaking.

  • Veilige implementatieprocedures: Uw GenAIOps-proces vereist coördinatie tussen clients en de modellen die zijn geïmplementeerd in Azure OpenAI. Voor geavanceerde implementatiemethoden, zoals blauwgroen of kanarie, moet logica aan de clientzijde worden verwerkt.

Prestatie-efficiëntieproblemen

Zonder een gateway zorgt uw workload ervoor dat clients afzonderlijk goed werken en zich eerlijk gedragen met andere clients tegen beperkte capaciteit.

  • Optimalisatie van prestaties - prioriteitsverkeer: clientaanvragen prioriteren, zodat clients met een hoge prioriteit voorkeurstoegang hebben boven clients met een lage prioriteit, zouden uitgebreide en waarschijnlijk onredelijke client-naar-client-coördinatie vereisen. Sommige workloads kunnen profiteren van aanvragen met een lage prioriteit die in de wachtrij worden geplaatst om uit te voeren wanneer het modelgebruik laag is.

  • Prestatieoptimalisatie : clientcompatibiliteit: om capaciteit te delen, moeten clients goed werken. Een voorbeeld hiervan is wanneer clients ervoor zorgen dat max_tokens en best_of worden ingesteld op goedgekeurde waarden. Zonder een gateway moet u clients vertrouwen om te handelen in het belang van het behoud van de capaciteit van uw Azure OpenAI-exemplaar.

  • Minimale latentie: hoewel netwerklatentie meestal een klein onderdeel is van de algemene aanvraagstroom voor prompts en voltooiingsaanvragen, kan het nuttig zijn om ervoor te zorgen dat clients worden doorgestuurd naar een netwerkeindpunt en dat het model dicht bij hen ligt. Zonder een gateway moeten clients zelf selecteren welke eindpunten voor modelimplementatie moeten worden gebruikt en welke referenties nodig zijn voor die specifieke Azure OpenAI-gegevensvlak-API.

Oplossing

Diagram met een conceptuele architectuur voor het injecteren van een gateway tussen een intelligente toepassing en Azure OpenAI.

Afbeelding 1: Conceptuele architectuur voor toegang tot Azure OpenAI via een gateway

Als u de vele uitdagingen in belangrijke uitdagingen wilt oplossen, kunt u een omgekeerde proxygateway injecteren om de intelligente toepassing los te koppelen van Azure OpenAI. Met deze offloading van gateways kunt u de verantwoordelijkheid, complexiteit en waarneembaarheid van clients verschuiven en krijgt u de mogelijkheid om Azure OpenAI te verbeteren door andere mogelijkheden te bieden die niet zijn ingebouwd. Enkele voorbeelden:

Sommige specifieke scenario's hebben meer richtlijnen die rechtstreeks betrekking hebben op een API-gateway en Azure OpenAI-exemplaren. Deze scenario's worden weergegeven in de sectie Volgende stappen .

Overwegingen

Wanneer u een nieuw onderdeel in uw architectuur introduceert, moet u de nieuw geïntroduceerde compromissen evalueren. Wanneer u een API-gateway tussen uw clients en het Azure OpenAI-gegevensvlak injecteert om een van de belangrijkste uitdagingen aan te pakken, introduceert u nieuwe overwegingen in uw architectuur. Evalueer zorgvuldig of de workload van invloed is op deze architectuuroverwegingen die de toegevoegde waarde of het hulpprogramma van de gateway rechtvaardigt.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing voldoet aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

  • De gatewayoplossing kan een single point of failure veroorzaken. Deze fout kan de oorsprong hebben van de beschikbaarheid van de service van het gatewayplatform, onderbrekingen vanwege code- of configuratie-implementaties of zelfs onjuist geconfigureerde kritieke API-eindpunten in uw gateway. Zorg ervoor dat u uw implementatie ontwerpt om te voldoen aan de beschikbaarheidsvereisten van uw workload. Overweeg tolerantie- en fouttolerantiemogelijkheden in de implementatie door de gateway op te nemen in de analyse van de foutmodus van de workload.

  • Uw oplossing vereist mogelijk globale routeringsmogelijkheden als voor uw architectuur Azure OpenAI-exemplaren in meerdere regio's nodig zijn om de beschikbaarheid van uw Azure OpenAI-eindpunten te vergroten, zoals de mogelijkheid om aanvragen te blijven verwerken in het geval van een regionale storing. Deze situatie kan de topologie verder bemoeilijken door het beheer van extra volledig gekwalificeerde domeinnamen, TLS-certificaten en meer globale routeringsonderdelen.

Belangrijk

Implementeer geen gateway als dit de mogelijkheid van uw workload in gevaar brengt om te voldoen aan overeengekomen serviceniveaudoelstellingen (SLO's).

Beveiliging

Wanneer u overweegt hoe een API-gateway van uw architectuur profiteert, gebruikt u de controlelijst ontwerpbeoordeling voor Beveiliging om uw ontwerp te evalueren. U moet beveiligingsoverwegingen aanpakken, zoals de volgende:

  • Het oppervlak van de werkbelasting wordt verhoogd met de toevoeging van de gateway. Dit oppervlak brengt extra overwegingen met betrekking tot identiteits- en toegangsbeheer (IAM) met zich mee voor de Azure-resources, verbeterde inspanningen voor de beveiliging en meer.

  • De gateway kan fungeren als een netwerkgrensovergang tussen de clientnetwerkruimte en de privé-Azure OpenAI-netwerkruimte. Hoewel de gateway een eerder internetgerichte Azure OpenAI-eindpunt privé maakt via het gebruik van Azure Private Link, wordt deze nu het nieuwe toegangspunt en moet deze adequaat worden beveiligd.

  • Een gateway bevindt zich in een unieke positie om onbewerkte aanvraaggegevens en geformuleerde antwoorden van het taalmodel te bekijken, die vertrouwelijke gegevens uit beide bronnen kunnen bevatten. Het bereik voor gegevensnaleving en regelgeving wordt nu uitgebreid naar dit andere onderdeel.

  • Een gateway kan het bereik van clientautorisatie en -verificatie uitbreiden buiten Microsoft Entra ID en API-sleutelverificatie, en mogelijk tussen meerdere id-providers (IdP).

  • Gegevenssoevereine moet worden meegerekend in uw implementatie in implementaties in meerdere regio's. Zorg ervoor dat uw gateway-berekenings- en routeringslogica voldoet aan de soevereiniteitsvereisten die zijn gesteld aan uw workload.

Belangrijk

Implementeer geen gateway als dit uw workload de vertrouwelijkheid, integriteit of beschikbaarheid van zichzelf of de gegevens van de gebruikers niet kan beschermen.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie.

Alle geïmplementeerde API-gateways hebben runtimekosten die moeten worden gebudgetteerd en waarvoor rekening moet worden gehouden. Deze kosten nemen meestal toe met toegevoegde functies om de betrouwbaarheid, beveiliging en prestaties van de gateway zelf aan te pakken, samen met operationele kosten die zijn geïntroduceerd met extra APIOps-beheer. Deze extra kosten moeten worden gemeten op basis van de nieuwe waarde die door het systeem wordt geleverd met de gateway. U wilt een punt bereiken waarop de nieuwe mogelijkheden die met behulp van een gateway worden geïntroduceerd, wegen op tegen de kosten voor het implementeren en onderhouden van de gateway. Afhankelijk van de relatie van uw workload met de gebruikers, kunt u mogelijk het gebruik van terugstortingen in rekening brengen.

Voor het beheren van kosten bij het ontwikkelen en testen van een gateway kunt u overwegen een gesimuleerd eindpunt te gebruiken voor Azure OpenAI. Gebruik bijvoorbeeld de oplossing in de GitHub-opslagplaats van de Azure OpenAI API-simulator .

Operationele topprestaties

Wanneer u overweegt hoe een API-gateway van uw architectuur profiteert, gebruikt u de controlelijst ontwerpbeoordeling voor Operational Excellence om uw ontwerp te evalueren. U moet rekening hebben met overwegingen voor operationele uitmuntendheid, zoals de volgende:

  • De gateway zelf moet worden bewaakt door de bewakingsoplossing van uw workload en mogelijk door clients. Dit betekent dat gateway-rekenkracht en -bewerkingen moeten worden opgenomen in de statusmodellering van de workload.

  • Uw veilige implementatieprocedures moeten nu betrekking hebben op de implementatie van de API-gatewayinfrastructuur en de code of configuratie van de gatewayroutering. Uw oplossing voor infrastructuurautomatisering en infrastructuur als code (IaC) moet overwegen hoe uw gateway moet worden behandeld als een langdurige resource in de workload.

  • U moet uw APIOps-benadering bouwen of uitbreiden om de API's te dekken die beschikbaar zijn in de gateway.

  • U dupliceerde mogelijkheden die beschikbaar zijn via oplossingen zoals de Azure AI Service-resource of de loaddistributiefunctionaliteit van de Azure OpenAI-gegevenszone.

Prestatie-efficiëntie

Wanneer u overweegt hoe een API-gateway van uw architectuur profiteert, gebruikt u de controlelijst ontwerpbeoordeling voor prestatie-efficiëntie om uw ontwerp te evalueren. U moet rekening hebben met prestatie-efficiëntieoverwegingen, zoals de volgende:

  • De gatewayservice kan een knelpunt voor doorvoer veroorzaken. Zorg ervoor dat de gateway voldoende prestaties heeft om volledige gelijktijdige belasting af te handelen en kan eenvoudig worden geschaald in overeenstemming met uw groei verwachtingen. Zorg voor elasticiteit in de oplossing, zodat de gateway het aanbod kan verminderen of omlaag kan schalen wanneer de vraag laag is, zoals bij het gebruik van de werkdag.

  • De gatewayservice verwerkt deze per aanvraag en introduceert extra latentie per API-aanroep. U moet uw routeringslogica optimaliseren om aanvragen goed te laten presteren.

  • In de meeste gevallen moet de gateway geografisch dicht bij zowel de gebruikers als de Azure OpenAI-exemplaren staan om de latentie te verminderen. Hoewel netwerklatentie meestal een klein percentage tijd is in algemene API-aanroepen naar taalmodellen, kan dit een concurrerende factor zijn voor uw workload.

  • Evalueer de impact van de gateway op Azure OpenAI-functies, zoals streamingantwoorden of het vastmaken van exemplaren voor stateful interacties, zoals de Assistent-API.

Belangrijk

Implementeer geen gateway als dit het bereiken van overeengekomen prestatiedoelen onmogelijk maakt of te veel compromissen met zich mee brengt.

Implementatie-opties

Azure biedt geen kant-en-klare oplossing die speciaal is ontworpen om de HTTP-API van Azure OpenAI of andere aangepaste taalmodeldeductie-API's te proxyn om al deze scenario's te behandelen. Er zijn echter nog steeds verschillende opties voor uw workloadteam om te implementeren, zoals een gateway in Azure.

Azure API Management gebruiken

Azure API Management is een platformbeheerde service die is ontworpen voor het offloaden van kruislingse problemen voor HTTP-API's. Het is configuratiegestuurd en biedt ondersteuning voor aanpassing via het binnenkomende en uitgaande beleidssysteem voor verwerking van aanvragen. Het ondersteunt maximaal beschikbare, zone-redundante en zelfs replica's met meerdere regio's met behulp van één besturingsvlak.

De meeste routerings- en aanvraagafhandelingslogica van de gateway moeten worden geïmplementeerd in het beleidssysteem van API Management. U kunt ingebouwde beleidsregels combineren specifiek voor Azure OpenAI, zoals het gebruik van azure OpenAI API-token beperken of metrische gegevens verzenden voor gebruik van Azure OpenAI-tokensen uw eigen aangepaste beleid. De GitHub-opslagplaats voor de GenAI-gateway-toolkit bevat een aantal aangepaste API Management-beleidsregels, samen met een installatie voor het testen van het gedrag van het beleid.

Gebruik de well-Architected Framework-servicehandleiding voor API Management bij het ontwerpen van een oplossing die betrekking heeft op Azure API Management. Als uw workload bestaat als onderdeel van een landingszone van een toepassing, bekijkt u de richtlijnen die beschikbaar zijn in het Cloud Adoption Framework voor Azure over het implementeren van een Azure API Management-landingszone.

Het gebruik van Azure API Management voor uw gatewayimplementatie is over het algemeen de voorkeursbenadering voor het bouwen en gebruiken van een Azure OpenAI-gateway. Dit heeft de voorkeur omdat de service een PaaS-aanbieding (Platform as a Service) is met uitgebreide ingebouwde mogelijkheden, hoge beschikbaarheid en netwerkopties. Het heeft ook robuuste APIOps-benaderingen voor het beheren van uw voltooiings-API's.

Aangepaste code gebruiken

Voor de aangepaste codebenadering moet een softwareontwikkelingsteam een aangepaste oplossing maken en die oplossing implementeren op een Azure-toepassingsplatform naar keuze. Het bouwen van een zelfbeheerde oplossing voor het afhandelen van de gatewaylogica kan een goede oplossing zijn voor workloadteams die goed kunnen omgaan met het beheren van netwerk- en routeringscode.

De workload kan meestal gebruikmaken van berekeningen waarmee ze bekend zijn, zoals het hosten van de gatewaycode op Azure-app Service, Azure Container Apps of Azure Kubernetes Service.

Aangepaste code-implementaties kunnen ook worden geleverd met API Management wanneer API Management uitsluitend wordt gebruikt voor de belangrijkste mogelijkheden van de HTTP API-gateway tussen uw clients en uw aangepaste code. Op deze manier worden uw aangepaste code-interfaces uitsluitend met uw HTTP-API's van Azure OpenAI op basis van de benodigde bedrijfslogica gebruikt.

Het gebruik van niet-Microsoft-gatewaytechnologie, een product of service die niet systeemeigen wordt geleverd door Azure, kan worden beschouwd als onderdeel van deze benadering.

Voorbeeldarchitectuur

Diagram met een voorbeeldarchitectuur van het injecteren van een gateway tussen een intelligente toepassing en Azure OpenAI.

Afbeelding 2: Voorbeeldarchitectuur van toegang tot Azure OpenAI via een op Azure API Management gebaseerde gateway

Volgende stappen

Meer informatie over een specifiek scenario waarbij het implementeren van een gateway tussen een intelligente toepassing en Azure OpenAI-implementaties wordt gebruikt om te voldoen aan de workloadvereisten:

Meer informatie over manieren om logboekregistratie en bewaking voor Azure OpenAI-modellen te implementeren.