Bearbeiten

Freigeben über

Zugriff auf Azure OpenAI und andere große Sprachmodelle über ein Gateway

Azure KI Services
Azure OpenAI Service
Azure API Management

Azure OpenAI Service stellt HTTP-APIs zur Verfügung, mit denen Ihre Anwendungen Einbettungen oder Completions unter Verwendung der Sprachmodelle von Azure OpenAI durchführen können. Intelligente Anwendungen rufen diese HTTP-APIs direkt von Clients oder Orchestratoren aus auf. Beispiele für Clients sind Chat UI Code und angepasste Datenverarbeitungs-Pipelines. Beispiele für Orchestratoren sind LangChain, Semantic Kernel und Azure Machine Learning Prompt Flow. Wenn Ihr Workload eine Verbindung zu einer oder mehreren Azure OpenAI-Instanzen herstellt, müssen Sie entscheiden, ob sich diese Consumer direkt oder über ein Reverse-Proxy-API-Gateway verbinden.

In dieser Anleitung erfahren Sie mehr über die wichtigsten Herausforderungen, die sich aus den fünf Säulen des Azure Well-Architected Framework ergeben, wenn Ihr Workload-Design einen direkten Zugriff Ihrer Consumer auf die Azure OpenAI Data Plane APIs vorsieht. Außerdem erfahren Sie, wie die Einführung eines Gateways in Ihre Architektur dazu beitragen kann, diese Herausforderungen des direkten Zugriffs zu lösen und gleichzeitig neue Herausforderungen zu schaffen. Dieser Artikel beschreibt das architektonische Muster, aber nicht, wie das Gateway implementiert wird.

Da ein Gateway zur Lösung spezifischer Szenarien verwendet werden kann, die nicht in jedem Workload vorkommen, sollten Sie sich die Anleitung Spezifische Szenarien ansehen, in der dieser spezielle Anwendungsfall eines Gateways näher erläutert wird.

Wichtige Herausforderungen

Ohne ein API-Gateway oder die Möglichkeit, den Azure OpenAI HTTP-APIs Logik hinzuzufügen, muss der Client die API-Client-Logik übernehmen, die Wiederholungsmechanismen oder Circuit-Breaker enthält. Diese Situation kann in Szenarien, in denen Sie den Client-Code nicht direkt kontrollieren, oder wenn der Code auf eine bestimmte SDK-Nutzung beschränkt ist, eine Herausforderung darstellen. Das Vorhandensein mehrerer Clients oder mehrerer Azure OpenAI-Instanzen und -Bereitstellungen stellt weitere Herausforderungen dar, z. B. in Bezug auf die Koordination sicherer Bereitstellungen und auf die Beobachtbarkeit.

In diesem Abschnitt finden Sie Beispiele für die wichtigsten architektonischen Herausforderungen, mit denen Sie konfrontiert werden könnten, wenn Ihre Architektur nur den direkten Zugriff auf Azure OpenAI von Consumern aus unterstützt. Die Herausforderungen sind anhand der Säulen des Azure Well-Architected Framework organisiert.

Herausforderungen bei der Zuverlässigkeit

Die Zuverlässigkeit des Workloads hängt von mehreren Faktoren ab, einschließlich seiner Fähigkeit zur Selbsterhaltung und Selbstwiederherstellung, die häufig durch Replikation und Failover-Mechanismen implementiert werden. Ohne ein Gateway müssen alle Zuverlässigkeitsanforderungen ausschließlich über die Client-Logik und die Funktionen von Azure OpenAI Service erfüllt werden. Die Zuverlässigkeit des Workloads ist kompromittiert, wenn in einer dieser beiden Bereiche nicht genügend Zuverlässigkeitskontrolle vorhanden ist.

  • Redundanz: Die Verantwortung für das Failover zwischen mehreren Azure OpenAI-Instanzen basierend auf der Dienstverfügbarkeit unterliegt dem Client. Sie können dies mithilfe der geeigneten Konfiguration und der benutzerdefinierten Logik steuern.

  • Spitzen bewältigen durch Skalieren: Das Failover zu Azure OpenAI-Instanzen mit gedrosselter Kapazität ist ein weiterer Aspekt, der der Verantwortung des Client unterliegt und der mithilfe der geeigneten Konfiguration und mithilfe der benutzerdefinierten Logik gesteuert werden kann. Die Aktualisierung mehrerer Client-Konfigurationen für neue Azure OpenAI-Instanzen stellt ein größeres Risiko dar und ist mit Zeitproblemen verbunden. Das gleiche gilt für das Aktualisieren von Clientcode, wenn Änderungen in die Logik implementiert werden sollen, wie z. B. das Weiterleiten von Anforderungen mit niedriger Priorität in eine Warteschlange während Zeiträumen mit hohem Bedarf.

  • Load-Balancing oder Drosselung: Azure OpenAI-APIs drosseln Anfragen, indem sie einen HTTP-429-Fehlerantwortcode für Anfragen zurückgeben, die den Token-Per-Minute (TPM) oder Requests-Per-Minute (RPM) im Pay-as-you-go-Modell überschreiten. Azure OpenAI-APIs drosseln auch Anfragen, die die Kapazität der bereitgestellten Throughput Units (PTU) für das Pre-Provisioned-Billing-Modell überschreiten. Die Handhabung einer geeigneten Backoff- und Wiederholungslogik bleibt ausschließlich Clientimplementierungen überlassen.

Herausforderungen bei der Sicherheit

Sicherheitskontrollen müssen dazu beitragen, die Vertraulichkeit, Integrität und Verfügbarkeit des Workloads zu schützen. Ohne ein Gateway müssen alle Sicherheitsbelange ausschließlich in der Client-Logik und den Funktionen von Azure OpenAI Service berücksichtigt werden. Workload-Anforderungen erfordern möglicherweise mehr als nur das, was für die Clientsegmentierung, Clientsteuerung oder für Dienstsicherheitsfeatures für die direkte Kommunikation zur Verfügung gestellt wird.

  • Identitätsmanagement - Authentifizierungsbereich: Die von Azure OpenAI bereitgestellten APIs der Datenebene können auf zwei Arten gesichert werden: API-Schlüssel oder rollenbasierte Zugriffssteuerung (RBAC) von Azure. In beiden Fällen erfolgt die Authentifizierung auf der Ebene der Azure OpenAI-Instanz und nicht auf der Ebene der einzelnen Bereitstellungen, was die Bereitstellung des am wenigsten privilegierten Zugriffs und die Identitätssegmentierung für bestimmte Bereitstellungsmodelle komplexer macht.

  • Identitätsmanagement - Identitätsanbieter: Clients, die keine Identitäten verwenden können, die sich in dem Microsoft Entra-Mandanten befinden, der hinter der Azure OpenAI-Instanz steht, müssen einen einheitlichen API-Schlüssel für den vollen Zugriff verwenden. API-Schlüssel haben nur begrenzten Sicherheitsnutzen und sind problematisch, wenn mehrere Clients beteiligt sind und alle dieselbe Identität verwenden.

  • Netzwerksicherheit: Je nachdem, wo sich der Client in Bezug auf Ihre Azure OpenAI-Instanzen befindet, kann ein öffentlicher Internetzugriff auf die Sprachmodelle erforderlich sein.

  • Datenhoheit: Die Datenhoheit im Azure OpenAI-Kontext betrifft die gesetzlichen und behördlichen Anforderungen hinsichtlich der Speicherung und Verarbeitung von Daten innerhalb der geografischen Grenzen eines bestimmten Landes oder einer bestimmten Region. Ihr Workload muss eine regionale Affinität gewährleisten, damit die Clients die Bestimmungen zur Datenresidenz und -souveränität einhalten können. Dieser Prozess umfasst mehrere Bereitstellungen von Azure OpenAI.

Herausforderungen bei der Kostenoptimierung

Workloads profitieren davon, wenn die Architekturen Verschwendung minimieren und den Nutzen maximieren. Eine starke Kostenmodellierung und -überwachung ist eine wichtige Voraussetzung für jeden Workload. Ohne eines Gateways kann PTU (Nachverfolgung von Durchsatzeinheiten) oder die Nachverfolgung der Kosten pro Client autoritativ ausschließlich durch die Aggregierung der Nutzungstelemetriedaten der Azure OpenAI-Instanzen genutzt werden.

  • Kostennachverfolgung: Eine finanzielle Vorausschau zur Azure OpenAI-Nutzung kann nur auf der Grundlage aggregierter Nutzungstelemtriedaten der Azure OpenAI-Instanzen bereitgestellt werden. Wenn Sie Charge-Back oder Show-Back durchführen müssen, müssen Sie diese Nutzungstelemetrie verschiedenen Clients in verschiedenen Abteilungen oder sogar Kunden für mandantenfähige Szenarien zuordnen.

  • Auslastung des bereitgestellten Durchsatzes: Ihr Workload möchte Verschwendung vermeiden, indem er den bereitgestellten Durchsatz, für den Sie bezahlt haben, vollständig ausnutzt. Das bedeutet, dass Clients als vertrauenswürdig eingestuft und koordiniert sein müssen, um PTU-basierte Modellimplementierungen verwenden zu können, bevor sie auf verbrauchsbasierte Modellimplementierungen übergehen.

Herausforderungen beim optimalen Betrieb

Ohne ein Gateway sind Beobachtbarkeit, Änderungskontrolle und Entwicklungsprozesse auf das beschränkt, was die direkte Client-zu-Server-Kommunikation bietet.

  • Kontingentkontrolle: Clients erhalten 429-Antwortcodes direkt von Azure OpenAI, wenn die HTTP-APIs gedrosselt werden. Die Workload-Betreiber sind dafür verantwortlich, dass genügend Kontingente für die legitime Nutzung zur Verfügung stehen und dass sich falsch verhaltende Clients nicht mehr verbrauchen. Wenn Ihr Workload aus mehreren Bereitstellungsmodellen besteht, kann das Verständnis der Kontingentnutzung und der Kontingentverfügbarkeit schwierig zu visualisieren sein.

  • Überwachung und Beobachtbarkeit: Azure OpenAI-Standardmetriken sind über Azure Monitor verfügbar. Allerdings gibt es eine Latenz bei der Verfügbarkeit der Daten, und es bietet keine Echtzeitüberwachung.

  • Sichere Bereitstellungspraktiken: Ihr GenAIOps-Prozess erfordert die Koordination zwischen Clients und den Modellen, die in Azure OpenAI bereitgestellt werden. Bei fortgeschrittenen Bereitstellungsansätzen, wie Blue-Green oder Canary, muss die Logik auf der Client-Seite gehandhabt werden.

Herausforderungen bei der Leistungseffizienz

Ohne ein Gateway liegt die Verantwortung für Ihren Workload bei den Clients, sich individuell korrekt zu verhalten und mit anderen Clients bei begrenzter Kapazität fair umzugehen.

  • Performance-Optimierung - vorrangiger Datenverkehr: Die Priorisierung von Client-Anfragen, sodass Clients mit hoher Priorität einen bevorzugten Zugriff gegenüber Clients mit niedriger Priorität erhalten, würde eine umfangreiche und wahrscheinlich unangemessene Koordination zwischen den Clients erfordern. Einige Workloads könnten davon profitieren, dass Anfragen mit niedriger Priorität in eine Warteschlange gestellt werden, um sie auszuführen, wenn die Modellauslastung niedrig ist.

  • Performance-Optimierung - Compliance der Clients: Um Kapazitäten gemeinsam zu nutzen, müssen sich die Clients korrekt verhalten. Ein Beispiel dafür ist, wenn Clients sicherstellen, dass max_tokens und best_of auf genehmigte Werte festgelegt sind. Ohne ein Gateway müssen Sie darauf vertrauen, dass die Clients im besten Interesse der Erhaltung der Kapazität Ihrer Azure OpenAI-Instanz handeln.

  • Minimieren der Latenz: Auch wenn die Netzwerklatenz in der Regel nur eine kleine Komponente des gesamten Flows der Prompt- und Completion-Anfragen ist, kann es von Vorteil sein, dafür zu sorgen, dass die Clients zu einem Endpunkt des Netzwerks und einem Modell in ihrer Nähe geleitet werden. Ohne ein Gateway müssten die Clients selbst entscheiden, welche Endpunkte für die Bereitstellung des Modells verwendet werden sollen und welche Anmeldeinformationen für die jeweilige Azure OpenAI Data Plane-API erforderlich sind.

Lösung

Diagramm, das eine Architektur zeigt, in der zwischen einer intelligenten Anwendung und Azure OpenAI ein Gateway implementiert ist.

Abbildung 1: Konzeptionelle Architektur des Zugriffs auf Azure OpenAI über ein Gateway

Um die vielen Herausforderungen zu bewältigen, die in Zentrale Herausforderungen aufgeführt sind, können Sie ein Reverse-Proxy-Gateway einfügen, um die intelligente Anwendung von Azure OpenAI zu entkoppeln. Mit diesem Offloading des Gateways können Sie die Verantwortung, Komplexität und Beobachtbarkeit von den Clients weg verlagern und haben die Gelegenheit, Azure OpenAI durch andere Funktionalitäten zu erweitern, die nicht integriert sind. Beispiele:

Für einige spezifische Szenarien gibt es weitere Anleitungen, die sich direkt an ein API-Gateway und Azure OpenAI-Instanzen richten. Diese Szenarien sind im Abschnitt Weitere Schritte aufgeführt.

Überlegungen

Wenn Sie in Ihre Architektur eine neue Komponente implementieren, müssen Sie auswerten, welche neuen Vor- und Nachteile dies mit sich bringt. Wenn Sie ein API-Gateway zwischen Ihren Clients und der Azure OpenAI-Datenebene einfügen, um eine der wichtigen Herausforderungen zu bewältigen, bringt dies neue Überlegungen für Ihre Architektur mit sich. Werten Sie genau aus, ob der sich aus der Integration eines Gateways in die Architektur ergebende Mehrwert oder Nutzen die Auswirkungen auf die Workload rechtfertigt.

Zuverlässigkeit

Die Zuverlässigkeit stellt sicher, dass Ihre Anwendung die Verpflichtungen erfüllt, die Sie gegenüber Ihren Kunden eingegangen sind. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

  • Die Gateway-Lösung kann einen Single Point of Failure darstellen. Ein Ausfall könnte seinen Ursprung in der Dienstverfügbarkeit der Gateway-Plattform, Unterbrechungen aufgrund von Code- oder Konfigurationsbereitstellungen oder sogar falsch konfigurierten kritischen API-Endpunkten in Ihrem Gateway haben. Stellen Sie sicher, dass Sie Ihre Implementierung so gestalten, dass sie den Verfügbarkeitsanforderungen Ihres Workloads gerecht wird. Berücksichtigen Sie bei der Implementierung die Aspekte Resilienz und Fehlertoleranz, indem Sie das Gateway in die Fehlermodusanalyse der Workload einschließen.

  • Ihre Lösung erfordert möglicherweise Funktionen für das globale Routing, wenn Ihre Architektur Azure OpenAI-Instanzen in mehreren Regionen erfordert. Diese Situation kann die Topologie durch die Verwaltung zusätzlicher Fully Qualified Domain Names, TLS-Zertifikate und weiterer globaler Routing-Komponenten weiter verkomplizieren.

Wichtig

Implementieren Sie kein Gateway, wenn dies die Fähigkeit Ihres Workloads gefährden würde, die vereinbarten Service-Level-Ziele (SLOs) zu erfüllen.

Sicherheit

Wenn Sie Überlegen dazu anstellen, welche Vorteile ein API-Gateway für Ihre Architektur mit sich bringt, verwenden Sie die Checkliste zur Überprüfung der Sicherheit, um Ihren Entwurf zu bewerten. Sie müssen Sicherheitsüberlegungen anstellen, wie z. B. die folgenden:

  • Durch Hinzufügen des Gateways wird die Oberfläche der Workload vergrößert. Aufgrund der Vergrößerung der Oberfläche müssen Sie einige zusätzliche Überlegungen hinsichtlich der Identitäts- und Zugriffsverwaltung (IAM) im Zusammenhang mit den Azure-Ressourcen, hinsichtlich zusätzlicher Härtungsmaßnahmen und zahlreicher anderer Faktoren anstellen.

  • Das Gateway kann als Übergang für die Netzwerkgrenzen zwischen dem Netzwerkraum des Clients und dem privaten Netzwerkraum von Azure OpenAI fungieren. Auch wenn das Gateway einen zuvor dem Internet zugewandten Azure OpenAI-Endpunkt durch die Verwendung von Azure Private Link privat macht, wird er nun zum neuen Einstiegspunkt und muss angemessen gesichert werden.

  • Ein Gateway befindet sich in einer einzigartigen Position, um die Rohdaten von Anfragen und die formulierten Antworten des Sprachmodells zu sehen, die vertrauliche Daten aus beiden Quellen enthalten können. Der Bereich der Daten-Compliance und des rechtlichen Rahmens wird nun auf diese andere Komponente ausgedehnt.

  • Ein Gateway kann den Bereich der Client-Autorisierung und -Authentifizierung über die Microsoft Entra ID- und API-Schlüssel-Authentifizierung hinaus erweitern, und zwar möglicherweise über mehrere Identitätsanbieter (IdP) hinweg.

  • Bei Implementierungen in mehreren Regionen muss die Datenhoheit in Ihrer Implementierung berücksichtigt werden. Stellen Sie sicher, dass die Datenverarbeitung und Routing-Logik Ihres Gateways den Anforderungen an die Souveränität Ihres Workloads entspricht.

Wichtig

Implementieren Sie kein Gateway, wenn Ihr Workload dadurch nicht in der Lage wäre, die Vertraulichkeit, Integrität oder Verfügbarkeit seiner Daten oder der Daten seiner Benutzenden zu schützen.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

Alle implementierten API-Gateways haben Runtime-Kosten, die Sie einplanen und berücksichtigen müssen. Diese Kosten steigen in der Regel mit zusätzlichen Funktionen, die die Zuverlässigkeit, Sicherheit und Leistung des Gateways selbst betreffen, sowie mit den Betriebskosten, die durch das zusätzliche APIOps-Management entstehen. Diese zusätzlichen Kosten müssen gegen den neuen Mehrwert aufgerechnet werden, den das System mit dem Gateway generiert. Sie möchten einen Punkt erreichen, an dem die neuen Funktionalitäten, die durch den Einsatz eines Gateways eingeführt werden, die Kosten für die Implementierung und Wartung des Gateways aufwiegen. In Abhängigkeit von der Beziehung Ihrer Workload zu ihren Benutzern werden Sie die Nutzung möglicherweise in Rechnung stellen können.

Um Kosten beim Entwickeln und Testen eines Gateways zu verwalten, sollten Sie einen simulierten Endpunkt für Azure OpenAI verwenden. Verwenden Sie beispielsweise die Lösung im GitHub-Repository des Azure OpenAI-API-Simulators .

Optimaler Betrieb

Wenn Sie überlegen, welche Vorteile ein API-Gateway für Ihre Architektur mit sich bringt, verwenden Sie die Checkliste zur Überprüfung des optimalen Betriebs, um Ihren Entwurf zu bewerten. Sie müssen sich mit folgenden Vorgängen auseinandersetzen:

  • Das Gateway muss von der Überwachungslösung Ihrer Workload und potenziell von Clients überwacht werden. Dies bedeutet, dass das Gateway-Computing und der Gateway-Betrieb in die Modellierung der Integrität der Workload einbezogen werden müssen.

  • Ihre Methoden zur sicheren Bereitstellung müssen jetzt die Bereitstellung der API-Gateway-Infrastruktur und Code oder die Konfiguration des Gateway-Routings mit einbeziehen. Ihre Lösung für Infrastrukturautomatisierung und Infrastructure-as-Code (IaC) muss berücksichtigen, wie Sie Ihr Gateway als langlebige Ressource im Workload behandeln.

  • Sie müssen Ihren APIOps-Ansatz erstellen oder erweitern, um die im Gateway bereitgestellten APIs abzudecken.

Effiziente Leistung

Wenn Sie überlegen, welche Vorteile ein API-Gateway für Ihre Architektur mit sich bringt, verwenden Sie die Checkliste zur Überprüfung der Leistungseffizienz, um Ihren Entwurf zu bewerten. Sie müssen Überlegungen zur Performance-Effizienz anstellen, wie z. B. die folgenden:

  • Der Gateway-Dienst kann zu einem Engpass beim Durchsatz führen. Stellen Sie sicher, dass das Gateway leistungsfähig genug ist, um die Last zu verarbeiten, und dass es sich problemlos gemäß Ihren Wachstumserwartungen skalieren lässt. Sorgen Sie für Flexibilität in der Lösung, sodass das Gateway das Angebot reduzieren oder vertikal herunterskalieren kann, wenn der Bedarf gering ist, wie z. B. bei der Nutzung an einem Werktag.

  • Der Gateway-Dienst muss pro Anfrage eine Verarbeitung durchführen, was zu einer zusätzlichen Latenzzeit pro API-Aufruf führt. Sie sollten Ihre Routinglogik optimieren, um eine hohe Leistung zu gewährleisten.

  • In den meisten Fällen sollte sich das Gateway geografisch in der Nähe der Benutzer- und der Azure OpenAI-Instanzen befinden, um die Latenzzeit zu verringern. Obwohl die Netzwerklatenz in der Regel nur einen geringen Anteil an der Gesamtzeit der API-Aufrufe zu Sprachmodellen ausmacht, könnte sie für Ihren Workload ein Wettbewerbsfaktor sein.

  • Evaluieren Sie die Auswirkungen des Gateways auf Azure OpenAI-Funktionen, wie Streaming-Antworten oder Instanz-Pinning für statusbasierte Interaktionen, wie z. B. die Assistents-API.

Wichtig

Implementieren Sie kein Gateway, wenn dies das Erreichen der ausgehandelten Leistungsziele unmöglich macht oder zu viele Kompromisse mit sich bringt.

Optionen für die Implementierung

Azure bietet keine schlüsselfertige Lösung an, die speziell für den Proxy der HTTP-API von Azure OpenAI oder anderer angepasster Sprachmodell-Inferencing-APIs entwickelt wurde. Aber es gibt immer noch mehrere Optionen, die Ihr Workload-Team implementieren kann, wie z. B. ein Gateway in Azure.

Verwenden von Azure API Management

Azure API Management ist ein von der Plattform verwalteter Dienst, der für das Offloading von HTTP-basierten APIs konzipiert wurde. Er ist konfigurationsgesteuert und unterstützt Anpassungen durch das Richtliniensystem für eingehende und ausgehende Anforderungen. Er unterstützt hochverfügbare, zonenredundante und sogar multiregionale Repliken durch die Verwendung einer einzigen Steuerungsebene.

Die Gateway-Routing- und Anforderungsverarbeitungslogik muss größtenteils im Richtliniensystem von API Management implementiert werden. Sie können integrierte Richtlinien wie Einschränken der Azure OpenAI-API-Tokennutzung oder Ausgeben von Metriken für den Verbrauch von Azure OpenAI-Tokens und Ihre eigenen benutzerdefinierten Richtlinien nutzen. Das GitHub-Repository des GenAI-Gateway-Toolkits enthält eine Reihe von benutzerdefinierten API-Verwaltungsrichtlinien sowie ein Ladetestset zum Testen des Verhaltens der Richtlinien.

Verwenden Sie die Well-Architected Framework Service Anleitung für API Management, wenn Sie eine Lösung entwerfen, die Azure API Management beinhaltet. Wenn Ihre Workload als Teil einer Anwendungslandzone vorhanden ist, lesen Sie die Anleitungen, die im Cloud Adoption Framework für Azure zur Implementierung einer Azure API Management-Zielzone verfügbar sind.

Die Verwendung von Azure API Management für Ihre Gateway-Implementierung ist im Allgemeinen der bevorzugte Ansatz zum Erstellen und Betreiben eines Azure OpenAI-Gateways. Der Dienst ist ein Platform-as-a-Service (PaaS)-Angebot mit umfangreichen integrierten Funktionalitäten, hoher Verfügbarkeit und Networking-Optionen. Außerdem verfügt er über robuste APIOps-Ansätze für die Verwaltung Ihrer Completion-APIs.

Benutzerdefinierten Code verwenden

Der Ansatz mit angepasstem Code erfordert, dass Entwickler*innen eine angepasste Code-Lösung erstellen und diese Lösung auf einer Azure-Anwendungsplattform ihrer Wahl bereitstellen. Das Erstellen einer selbstverwalteten Lösung zur Verwaltung der Gateway-Logik kann eine gute Grundlage für Workload-Teams darstellen, die sich mit der Verwaltung von Netzwerk- und Routingcode auskennen.

Der Workload kann in der Regel auf Datenverarbeitungskapazität zurückgreifen, mit dem sie vertraut sind, z. B. das Hosten des Gateway-Codes auf Azure App Service, Azure Container Apps oder Azure Kubernetes Service.

Die Bereitstellung von angepasstem Code kann auch mit API Management erfolgen, wenn API Management ausschließlich für seine Core-HTTP-API-Gateway-Funktionalitäten zwischen Ihren Clients und Ihrem angepassten Code verwendet wird. Auf diese Weise wird Ihr angepasster Code ausschließlich mit Ihren Azure OpenAI HTTP-APIs auf der Grundlage der erforderlichen Geschäftslogik verbunden.

Die Verwendung von Nicht-Microsoft-Gateway-Technologien, d. h. von Produkten oder Diensten, die nicht nativ von Azure bereitgestellt werden, kann als Teil dieses Ansatzes betrachtet werden.

Beispiel Architektur

Diagramm, das ein Beipsiel einer Architektur zeigt, in der zwischen einer intelligenten Anwendung und Azure OpenAI ein Gateway implementiert ist.

Abbildung 2: Beispielarchitektur für den Zugriff auf Azure OpenAI über ein auf Azure API Management basierendes Gateway

Nächste Schritte

Erfahren Sie mehr über ein bestimmtes Szenario, in dem ein Gateway zwischen einer intelligenten Anwendung und Azure OpenAI-Bereitstellungen integriert wird, um Workloadanforderungen zu erfüllen:

Lernen Sie, wie Sie die Protokollierung und Überwachung für Azure OpenAI-Modelle implementieren.