Verwenden eines vor mehreren Azure OpenAI-Bereitstellungen oder Instanzen hinzugefügten Gateways

Workload-Architekturen, die Azure OpenAI Service nutzen, können so einfach sein wie eine oder mehrere Client-Anwendungen, die direkt eine einzelne Bereitstellung des Azure OpenAI-Modells nutzen, aber nicht alle Workloads lassen sich so einfach gestalten. Zu den komplexeren Szenarien gehören Topologien mit mehreren Clients, mehreren Azure OpenAI-Bereitstellungen oder mehreren Azure OpenAI-Instanzen. In diesen Situationen kann die Einführung eines Gateways vor Azure OpenAI für das Design des Workloads von Vorteil sein.

Mehrere Azure OpenAI-Instanzen oder -Modellbereitstellungen lösen bestimmte Anforderungen in einer Workloadarchitektur. Sie können in vier Schlüsseltopologien eingeteilt werden.

• Mehrere Modellbereitstellungen in einer einzigen Azure OpenAI-Instanz
• Mehrere Azure OpenAI-Instanzen in einer einzelnen Region und einem einzelnen Abonnement
• Mehrere Azure OpenAI-Instanzen in einer einzelnen Region über mehrere Abonnements hinweg
• Mehrere Azure OpenAI-Instanzen in mehreren Regionen

Für diese Topologien ist die Verwendung eines Gateways nicht erforderlich. Die Wahl eines Gateways hängt davon ab, ob die Workload von der Integration in die Architektur profitiert. Dieser Artikel beschreibt die Herausforderungen, die jede der vier Topologien mit sich bringt, sowie die Vorteile und Kosten der Einbeziehung eines Gateways in jede Topologie.

Mehrere Modellbereitstellungen in einer einzigen Azure OpenAI-Instanz

Topologiedetails für mehrere Modellbereitstellungen

• Azure OpenAI-Modellbereitstellungen: mehrere
• Azure OpenAI-Instanzen: eine
• Abonnements: eins
• Regionen: eine

Topologie-Anwendungsfälle für mehrere Modellbereitstellungen

Eine Topologie, die eine einzelne Azure OpenAI-Instanz enthält, aber mehrere gleichzeitig bereitgestellte Modelle umfasst, unterstützt die folgenden Anwendungsfälle:

• Bereitstellen verschiedener Funktionalitäten wie gpt-35-turbo, gpt-4 und angepasste Feinabstimmungsmodelle.

• Bereitstellen verschiedener Modellversionen, z. B. 0613, 1106 und angepasste Modelle zur Unterstützung von Workload-Evolution oder Blue-Green-Bereitstellungen.

• Unterschiedliche zugewiesene Kontingente (30.000 Token-Per-Minute (TPM), 60.000 TPM) zur Unterstützung der Nutzungsdrosselung über mehrere Clients hinweg.

Einführung eines Gateways für mehrere Modellbereitstellungen

Die Einführung eines Gateways in diese Topologie dient in erster Linie dazu, die Clients davon abzuhalten, selbst eine bestimmte Instanz aus den verfügbaren Bereitstellungsmodellen auf der Instanz auszuwählen. Ein Gateway ermöglicht die serverseitige Steuerung, um eine Client-Anfrage an ein bestimmtes Modell weiterzuleiten, ohne dass Client-Code erneut bereitgestellt oder die Client-Konfiguration geändert werden muss.

Ein Gateway ist besonders dann von Vorteil, wenn Sie keine Kontrolle über den Client-Code haben. Es ist auch dann von Vorteil, wenn die Bereitstellung der Client-Konfiguration komplexer oder riskanter ist als die Bereitstellung von Änderungen an der Routing-Konfiguration eines Gateways. Sie könnten das Modell, das ein Client verwendet, auf der Grundlage einer Blue-Green-Rollout-Strategie für Ihre Modellversionen ändern, z. B. ein neues, fein abgestimmtes Modell einführen oder von Version X zu X+1 desselben Modells wechseln.

Das Gateway kann auch als einziger API-Einstiegspunkt verwendet werden, der es dem Gateway ermöglicht, den Client zu identifizieren. Es kann dann anhand der Clientidentität oder anderer Informationen in der HTTP-Anfrage bestimmen, welches Bereitstellungsmodell für den Prompt verwendet wird. In einer mandantenfähigen Lösung könnten die Mandanten beispielsweise auf einen bestimmten Durchsatz beschränkt sein, und die Implementierung der Architektur ist eine Modellbereitstellung pro Mandant mit bestimmten Kontingenten. In diesem Fall läge die Verantwortung für das Routing zum Modell des Mandanten beim Gateway auf der Grundlage der Informationen in der HTTP-Anfrage.

Die Verwendung eines Gateways in dieser Topologie ermöglicht die clientbasierte Verwendungsnachverfolgung. Sofern Clients nicht unterschiedliche Microsoft Entra-Dienstprinzipale verwenden, können die Zugriffsprotokolle für Azure OpenAI nicht zwischen mehreren Clients unterscheiden. Ein Gateway, das der Bereitstellung vorgeschaltet ist, gibt Ihrer Workload die Möglichkeit, die Nutzung pro Client über verschiedene verfügbare Modellbereitstellungen hinweg zu verfolgen, um Chargeback- oder Showback-Modelle zu unterstützen.

Tipps für die Topologie mit mehreren Modellbereitstellungen

• Das Gateway ist zwar in der Lage, das verwendete Modell vollständig zu ändern, z. B. von gpt-35-turbo auf gpt-4, aber diese Änderung würde wahrscheinlich als ein Einschnitt für den Client angesehen werden. Lassen Sie sich durch neue Funktionalitäten des Gateways nicht davon ablenken, für diesen Workload stets sichere Bereitstellungspraktiken anzuwenden.

• Diese Topologie ist in der Regel einfach genug, um die Azure API Management-Richtlinie anstelle einer benutzerdefinierten Codelösung zu implementieren.

• Um die Verwendung nativer SDKs mit veröffentlichten Spezifikationen der Azure OpenAI-APIs zu unterstützen, müssen Sie die API-Kompatibilität mit der Azure OpenAI-API aufrechterhalten. Diese Situation ist ein größeres Problem, wenn Ihr Team nicht den gesamten Code Ihrer Workload-Clients erstellt hat. Berücksichtigen Sie bei der Entscheidung, die HTTP-API für das Gateway zu konzipieren, die Vorteile der Aufrechterhaltung der HTTP-API-Kompatibilität mit Azure OpenAI.

• Auch wenn diese Topologie technisch Passthrough-Client-Anmeldeinformationen (Zugriffstoken oder API-Schlüssel) für die Azure OpenAI-Instanz unterstützt, sollten Sie unbedingt die Implementierung der Beendigung und Wiederherstellung von Anmeldeinformationen in Betracht ziehen. Auf diese Weise wird der Client am Gateway autorisiert, und dann wird das Gateway über Azure RBAC für die Azure OpenAI Instanz autorisiert.

• Wenn das Gateway für Passthrough-Anmeldeinformationen ausgelegt ist, stellen Sie sicher, dass die Clients das Gateway oder etwaige Modellbeschränkungen, die auf dem Client basieren, nicht aushebeln können.

• Stellen Sie Ihr Gateway in derselben Region wie die Azure OpenAI-Instanz bereit.

• Stellen Sie das Gateway in einer dedizierten Ressourcengruppe im Abonnement bereit, die von der Azure OpenAI-Instanz getrennt ist. Die Isolierung des Abonnements von den Back-Ends kann dazu beitragen, einen APIOps-Ansatz durch eine Trennung der Bereiche voranzutreiben.

• Stellen Sie das Gateway in einem virtuellen Netzwerk bereit, das ein Subnetz für den privaten Endpunkt der Azure OpenAI Instanz von Azure Private Link enthält. Wenden Sie Regeln für die Netzwerksicherheitsgruppe (Network Security Group, NSG) auf dieses Subnetz an, um nur den Gatewayzugriff auf diesen privaten Endpunkt zuzulassen. Alle anderen Datenebenenzugriffe auf die Azure OpenAI-Instanzen sollten unzulässig sein.

Gründe, ein Gateway für mehrere Modellbereitstellungen zu vermeiden

Wenn die Steuerung der Konfiguration Ihrer Clients genauso einfach oder einfacher ist als die Steuerung des Routings auf Gateway-Ebene, sind die zusätzlichen Auswirkungen auf Zuverlässigkeit, Sicherheit, Kosten, Wartung und Leistung des Gateways die zusätzliche Architekturkomponente möglicherweise nicht wert.

Darüber hinaus können einige Workloadszenarien von der Migration eines Bereitstellungsansatzes mit mehreren Modellen zu einem Bereitstellungsansatz für mehrere Azure OpenAI-Instanzen profitieren. Ziehen Sie beispielsweise mehrere Azure OpenAI-Instanzen in Betracht, wenn Sie über mehrere Clients verfügen, die unterschiedliche RBAC oder Zugriffsschlüssel verwenden sollten, um auf ihr Modell zuzugreifen. Die Verwendung mehrerer Bereitstellungen in einer einzelnen Azure OpenAI-Instanz und die Handhabung der logischen Identitätssegmentierung auf Gateway-Ebene ist möglich, kann jedoch überdimensioniert sein, wenn ein physischer RBAC-Segmentierungsansatz durch die Verwendung unterschiedlicher Azure OpenAI-Instanzen verfügbar ist.

Mehrere Azure OpenAI-Instanzen in einer einzelnen Region und einem einzelnen Abonnement

Topologiedetails für mehrere Instanzen in einer einzelnen Region und einem einzelnen Abonnement

• Azure OpenAI-Modellbereitstellungen: eine oder mehrere
• Azure OpenAI-Instanzen: mehrere
• Abonnements: eins
• Regionen: eine

Topologie-Anwendungsfälle für mehrere Instanzen in einer einzelnen Region und einem einzelnen Abonnement

Eine Topologie, die mehrere Azure OpenAI-Instanzen in einer einzelnen Region und ein einzelnes Abonnement umfasst, unterstützt die folgenden Anwendungsfälle:

• Aktiviert Sicherheitssegmentierungsgrenzen, z. B. Schlüssel oder RBAC pro Client

• Ermöglicht ein einfaches Chargebackmodell für verschiedene Clients

• Ermöglicht eine Failover-Strategie für die Verfügbarkeit von Azure OpenAI, z. B. bei einem Ausfall der Plattform, der eine bestimmte Instanz betrifft, bei einer Fehlkonfiguration des Netzwerks oder bei einer versehentlich gelöschten Bereitstellung.

• Ermöglicht eine Failoverstrategie für die Verfügbarkeit von Azure OpenAI-Kontingenten, z. B. das Koppeln einer PTU-basierten Instanz und einer verbrauchsbasierten Instanz für den Überlauf

Einführung eines Gateways für mehrere Instanzen in einer einzelnen Region und einem Abonnement

Ein Modell kann aus mehreren Gründen nicht für einen Client zugänglich sein. Zu diesen Gründen gehören Unterbrechungen von Azure OpenAI Service, Azure OpenAI-Drosselungsanfragen oder Probleme im Zusammenhang mit dem Betrieb des Workloads wie eine Fehlkonfiguration des Netzwerks oder ein versehentliches Löschen einer Modellbereitstellung. Um diese Herausforderungen zu bewältigen, sollten Sie Wiederholungs- und Verbindungsunterbrechungslogik implementieren.

Diese Logik könnte auf der Client- oder Serverseite in einem Gateway implementiert werden. Durch die Implementierung der Logik in einem Gateway wird die Logik von den Clients abstrahiert, was zu keinem wiederholten Code und einem einzigen Ort zum Testen der Logik führt. Unabhängig davon, ob Sie den Clientcode besitzen oder nicht, kann diese Verschiebung die Zuverlässigkeit der Workload erhöhen.

Durch die Verwendung eines Gateways mit mehreren Azure OpenAI-Instanzen in einer einzigen Region und einem einzigen Abonnement können Sie alle Back-Ends als Aktiv-Aktive-Bereitstellungen behandeln und sie nicht nur für Aktiv-Passiv-Failover verwenden. Sie können dasselbe PTU-basierte Modell über mehrere Azure OpenAI-Instanzen hinweg bereitstellen und das Gateway verwenden, um den Lastenausgleich zwischen ihnen zu ermöglichen.

Eine Option, die ein Workload-Team bei der Bereitstellung von Azure OpenAI hat, besteht darin, zu entscheiden, ob das Abrechnungs- und Durchsatzmodell PTU-basiert oder verbrauchsbasiert ist. Eine Strategie zur Kostenoptimierung, um Verschwendung durch ungenutzte PTUs zu vermeiden, besteht darin, die PTU-Instanz etwas niedriger bereitzustellen und daneben auch eine verbrauchsbasierte Instanz bereitzustellen. Das Ziel dieser Topologie besteht darin, dass Clients zunächst die gesamte verfügbare PTU verbrauchen und dann zur verbrauchsbasierten Bereitstellung für Überschreitungen übergehen. Diese Form des geplanten Failovers ist aus demselben Grund vorteilhaft, der im ersten Absatz dieses Abschnitts erwähnt wurde: keine Komplexität im Clientcode.

Wenn ein Gateway involviert ist, befindet es sich in einer einzigartigen Position, um Details zu allen Bereitstellungsmodellen zu erfassen, mit denen Clients interagieren. Während jede Instanz von Azure OpenAI ihre eigenen Telemetriedaten erfassen kann, kann das Workload-Team Telemetriedaten und Fehlerreaktionen für alle verwendeten Modelle in einem einzigen Speicher veröffentlichen, was einheitliches Dashboarding und Warnhinweise erleichtert.

Tipps für mehrere Instanzen in einer Topologie mit einer einzelnen Region und einem Abonnement

• Stellen Sie sicher, dass das Gateway die Retry-After-Informationen verwendet, die in der HTTP-Antwort von Azure OpenAI verfügbar sind, wenn Failoverszenarien am Gateway unterstützt werden. Nutzen Sie diese maßgeblichen Informationen zur Steuerung Ihrer Circuit-Breaker-Implementierung. Vermeiden Sie Endpunkte, die 429 Too Many Requests zurückgeben. Unterbrechen Sie stattdessen den Circuit für diese Modellinstanz.

• Der Versuch, Drosselungsereignisse vorherzusagen, bevor sie eintreten, indem der Modellverbrauch über vorherige Anfragen verfolgt wird, ist im Gateway zwar möglich, jedoch mit Grenzfällen verbunden. In den meisten Fällen ist es am besten, keine Vorhersagen zu treffen, sondern HTTP-Antwortcodes zu verwenden, um zukünftige Routing-Entscheidungen voranzutreiben.

• Stellen Sie bei Round-Robin oder einem Failover auf einen anderen Endpunkt, einschließlich PTU-Überlauf in den Verbrauch, immer sicher, dass diese Endpunkte dasselbe Modell mit derselben Version verwenden. Führen Sie z. B. keinen Failover von gpt-4 zu gpt-35-turbo oder von Version X zu Version X+1 und keinen Lastenausgleich zwischen beiden durch. Diese Versionsänderung kann zu unerwartetem Verhalten in den Clients führen.

• Lastenausgleich und Failoverlogik können in Azure API Management-Richtlinien implementiert werden. Möglicherweise können Sie mit einer codebasierten Gateway-Lösung einen komplexeren Ansatz bereitstellen, aber API Management ist für diesen Anwendungsfall ausreichend.

• Stellen Sie Ihr Gateway in derselben Region wie die Azure OpenAI-Instanz bereit.

• Stellen Sie das Gateway in einer dedizierten Ressourcengruppe im Abonnement bereit, die von den Azure OpenAI-Instanzen getrennt ist. Die Isolierung des Gateways von den Back-Ends kann dazu beitragen, einen APIOps-Ansatz durch die Trennung der Bereiche zu fördern.

• Platzieren Sie alle privaten Private Link-Endpunkte der Azure OpenAI-Instanz in einem einzigen Subnetz im virtuellen Netzwerk des Gateways. Wenden Sie NSG-Regeln auf dieses Subnetz an, um nur den Gatewayzugriff auf diese privaten Endpunkte zuzulassen. Alle anderen Datenebenenzugriffe auf die Azure OpenAI-Instanzen sollten unzulässig sein.

• Um die Logik im Gatewayroutingcode zu vereinfachen, verwenden Sie denselben Modellbereitstellungsnamen, um den Unterschied zwischen den HTTP-Routen zu minimieren. Der Modellname gpt4-v1 kann zum Beispiel für alle Instanzen mit Load-Balance oder Spillover verwendet werden, unabhängig davon, ob sie verbrauchsbasiert oder PTU-basiert sind.

Gründe, ein Gateway für mehrere Instanzen in einer einzelnen Region und einem Abonnement zu vermeiden

Ein Gateway selbst verbessert nicht die Möglichkeit, Modelle für verschiedene Clients für diese spezifische Topologie zurückzubuchen. In dieser Topologie könnte Clients Zugriff auf ihre eigenen dedizierten Azure OpenAI-Instanzen gewährt werden, was die Fähigkeit Ihres Workload-Teams zur Durchführung von Chargebacks oder Showbacks unterstützen würde. Dieses Modell unterstützt eindeutige Identitäten und Netzwerkperimeter, sodass kein Gateway speziell für die Segmentierung eingeführt werden muss.

Wenn Sie einige Clients in dem Bereich haben, in dem Sie den Code verwalten, und die Clients leicht aktualisierbar sind, könnte die Logik, die Sie in das Gateway integrieren müssten, direkt in den Code eingefügt werden. Ziehen Sie den Gateway-Ansatz für Failover oder Load-Balancing in erster Linie dann in Betracht, wenn Sie nicht im Besitz des Codes der Clients sind oder die Komplexität für die Clients zu groß ist.

Mehrere Azure OpenAI-Instanzen in einer einzelnen Region über mehrere Abonnements hinweg

Topologiedetails für mehrere Azure OpenAI-Instanzen in einer einzelnen Region über mehrere Abonnements hinweg

• Azure OpenAI-Modellbereitstellungen: eine oder mehrere
• Azure OpenAI-Instanzen: mehrere
• Abonnements: mehrere
• Regionen: eine

Topologie-Anwendungsfälle für mehrere Azure OpenAI-Instanzen in einer einzelnen Region über mehrere Abonnements hinweg

Eine Topologie, die mehrere Azure OpenAI-Instanzen in einer einzelnen Region in mehreren Abonnements umfasst, unterstützt die folgenden Anwendungsfälle:

• Umfasst alle Anwendungsfälle für mehrere Azure OpenAI-Instanzen in einer einzigen Region und einem einzigen Abonnement.

• Ermöglicht es Ihnen, mehr verbrauchsbasierte Kontingente zu erhalten, da die Grenze des Abonnements ein verfügbarer Faktor für das Verbrauchsmodell ist. Sie können dieses zusätzliche Kontingent nutzen, um einen hochgradig parallelen Verbrauch zu unterstützen.

Einführung eines Gateways für mehrere Instanzen in einer einzelnen Region und mehreren Abonnements

Die gleichen Gründe, die unter Einführung eines Gateways für mehrere Instanzen in einer einzelnen Region und einem Abonnement behandelt werden, gelten für diese Topologie.

Zusätzlich zu diesen Gründen unterstützt das Hinzufügen eines Gateways in dieser Topologie auch ein zentralisiertes Team, das ein Azure OpenAI-as-a-Service-Modell für seine Organisation anbietet. Da ein verbrauchsbasiertes Kontingent an ein Abonnement gebunden ist, muss ein zentralisiertes Team, das Azure OpenAI Service bereitstellt, die das verbrauchsbasierte Modell nutzen, Azure OpenAI-Instanzen über mehrere Abonnements hinweg bereitstellen, um das erforderliche Kontingent zu erhalten. Die Gateway-Logik bleibt weitgehend gleich.

Tipps für mehrere Instanzen in einer einzelnen Region und eine Topologie mit mehreren Abonnements

• Idealerweise sollten die Abonnements alle mit demselben Microsoft Entra-Mandanten verbunden sein, um die Konsistenz von Azure RBAC und Azure-Richtlinien zu unterstützen.

• Stellen Sie Ihr Gateway in derselben Region wie die Azure OpenAI-Instanz bereit.

• Stellen Sie das Gateway in einem dedizierten Abonnement bereit, das von den Azure OpenAI-Instanzen getrennt ist. Dies trägt dazu bei, eine konsistente Adressierung der Azure OpenAI-Instanzen sicherzustellen und bietet eine logische Segmentierung der Aufgaben zwischen Azure OpenAI-Bereitstellungen und deren Weiterleitung.

• Wenn Sie Anfragen von Ihrem Gateway über Abonnements hinweg routen, stellen Sie sicher, dass die privaten Endpunkte erreichbar sind. Sie können transitives Routing über einen Hub zu privaten Endpunkten für die Back-Ends in ihren jeweiligen Spokes verwenden. Möglicherweise können Sie private Endpunkte für Azure OpenAI Service direkt im Gateway-Abonnement bereitstellen, indem Sie Private Link-Verbindungen über Abonnements hinweg verwenden. Abonnementübergreifende Private Link-Verbindungen sind vorzuziehen, wenn Ihre Architektur und Organisation diesen Ansatz unterstützen.

Gründe, ein Gateway für mehrere Instanzen in einer einzelnen Region und mehrere Abonnements zu vermeiden

Alle Gründe, um ein Gateway für mehrere Instanzen in einer einzelnen Region und in einem Abonnement zu vermeiden, gelten für diese Topologie.

Mehrere Azure OpenAI-Instanzen in mehreren Regionen

Topologiedetails für mehrere Azure OpenAI-Instanzen in mehreren Regionen

• Azure OpenAI-Modellbereitstellungen: mehrere
• Azure OpenAI-Instanzen: mehrere
• Abonnements: eins oder mehrere
• Regionen: mehrere

Topologie-Anwendungsfälle für mehrere Azure OpenAI-Instanzen in mehreren Regionen

Eine Topologie, die mehrere Azure OpenAI-Instanzen umfasst, die in zwei oder mehr Azure-Regionen verteilt sind, unterstützt die folgenden Anwendungsfälle:

• Umfasst alle Nutzungsfälle für mehrere Azure OpenAI-Instanzen in einer einzigen Region über mehrere Abonnements.

• Ermöglicht eine Failover-Strategie für die Verfügbarkeit von Diensten, wie z. B. die Verwendung von regionenübergreifenden Paaren.

• Ermöglicht ein Datenresidenz- und Compliance-Design.

• Ermöglicht die Verfügbarkeit gemischter Modelle. Einige Regionen verfügen über verschiedene Modelle und unterschiedliche Kontingente für die Modelle.

Obwohl es sich technisch gesehen nicht um verschiedene Azure-Regionen handelt, ist diese Topologie auch anwendbar, wenn Sie ein KI-Modell in einer cross-premises Situation, wie z. B. lokal oder in einer anderen Cloud, exponiert haben.

Einführung eines Gateways für mehrere Instanzen in mehreren Regionen

Für geschäftskritische Architekturen, die einem vollständigen regionalen Ausfall standhalten müssen, hilft ein globales, einheitliches Gateway dabei, die Failover-Logik aus dem Client-Code zu beseitigen. Diese Implementierung setzt voraus, dass das Gateway von einem Ausfall in einer Region nicht betroffen ist.

Ein Load-Balancing über Regionen hinweg ist nicht typisch, könnte aber strategisch eingesetzt werden, um verfügbare Kontingente in verbrauchsbasierten Bereitstellungen über Regionen hinweg zu kombinieren. Bei diesem Szenario ist es nicht erforderlich, dass das Gateway von einem regionalen Ausfall unberührt bleibt, aber wir empfehlen es für maximale Zuverlässigkeit des Workloads.

Verwenden von Azure API Management (Bereitstellung in einer Region)

In dieser Topologie wird Azure API Management speziell für die Gatewaytechnologie verwendet. Hier wird API Management in einer einzigen Region bereitgestellt. Von dieser Gateway-Instanz aus führen Sie ein aktives Load-Balancing über die Regionen hinweg durch. Die Richtlinien in Ihrem Gateway verweisen auf alle Azure OpenAI-Instanzen. Das Gateway benötigt eine direkte Netzwerkverbindung zu jedem Back-End über Regionen hinweg, entweder über regionsübergreifendes Peering virtueller Netzwerke oder über private Endpunkte. Bei Aufrufen von diesem Gateway zu einer Azure OpenAI-Instanz in einer anderen Region kommt es zu einer höheren Netzwerklatenz und zu höheren Egress-Gebühren.

Ihr Gateway muss die Drosselungs- und Verfügbarkeitsmeldungen der Azure OpenAI-Instanzen beachten und fehlerhafte Back-Ends aus dem Pool entfernen, bis es sicher ist, die fehlerhafte oder gedrosselte Azure OpenAI-Instanz wieder hinzuzufügen. Das Gateway sollte bei einem Fehler die aktuelle Anfrage mit einer anderen Back-End-Instanz im Pool wiederholen, bevor es einen Gateway-Fehler zurückgibt. Die Zustandsprüfung des Gateways sollte einen Fehler melden, wenn keine Back-End Azure OpenAI-Instanzen verfügbar sind.

Da diese Topologie einen Single Point of Failure (das Gateway) einführt, ist der Nutzen dieser speziellen Architektur ziemlich begrenzt. Dieses Modell eignet sich gut für die verbrauchsbasierte Abrechnung in Azure OpenAI, wenn sich die Prognose der PTU-Zuweisung als zu schwierig erweisen könnte.

Aktiv/Passiv-Variante

Dieses Modell kann auch verwendet werden, um einen Aktiv/Passiv-Ansatz bereitzustellen, um regionale Fehler nur von Azure OpenAI zu behandeln. In diesem Modus fließt der Datenverkehr normalerweise vom Gateway zur Azure OpenAI-Instanz in derselben Region wie der API Management-Dienst. Diese Instanz von Azure OpenAI würde den gesamten erwarteten Datenverkehrsfluss behandeln, ohne dass regionale Fehler auftreten. Abhängig von Ihrem bevorzugten Abrechnungsmodell kann es PTU-basiert oder verbrauchsbasiert sein. Im Falle eines regionalen Ausfalls, bei dem nur Azure OpenAI betroffen ist, kann das Gateway den Datenverkehr in eine andere Region umleiten, in der Azure OpenAI bereits im Verbrauchsmodus bereitgestellt ist.

Verwenden von Azure API Management (Bereitstellung in mehreren Regionen)

Um die Zuverlässigkeit der früheren Azure API Management-basierten Architektur zu verbessern, unterstützt API Management die Bereitstellung einer -Instanz in mehreren Azure-Regionen. Bei dieser Bereitstellungsoption erhalten Sie eine einzige Steuerungsebene über eine einzige API Management-Instanz, die jedoch replizierte Gateways in den Regionen Ihrer Wahl bereitstellt. In dieser Topologie stellen Sie Gateway-Komponenten in jeder Region bereit, die Azure OpenAI-Instanzen enthält, die eine Aktiv/Aktiv-Gateway-Architektur bereitstellen.

Richtlinien wie das Routing und die Logik zur Bearbeitung von Anfragen werden auf jedes einzelne Gateway repliziert. Die gesamte Richtlinienlogik muss über eine bedingte Logik in der Richtlinie verfügen, um sicherzustellen, dass Sie Azure OpenAI-Instanzen in derselben Region wie das aktuelle Gateway aufrufen. Weitere Informationen finden Sie unter API-Aufrufe zu regionalen Back-End-Diensten routen. Die Gateway-Komponente benötigt dann eine Netzwerksichtverbindung nur zu Azure OpenAI-Instanzen in ihrer eigenen Region, normalerweise über private Endpunkte.

API Management bietet ein sofort einsatzbereites globales Fully Qualified Domain Name (FQDN)-Routing auf der Grundlage der geringsten Latenz. Verwenden Sie diese integrierte, leistungsbasierte Funktionalität für Aktiv/Aktiv-Gatewaybereitstellungen. Diese integrierte Funktionalität trägt zur Leistung bei und bewältigt den Ausfall eines regionalen Gateways. Der integrierte globale Router unterstützt auch Disaster-Recovery-Tests, da der Ausfall von Regionen durch die Deaktivierung einzelner Gateways simuliert werden kann. Stellen Sie sicher, dass Clients die Gültigkeitsdauer (TTL) im FQDN einhalten und über entsprechende Wiederholungslogik verfügen, um ein kürzliches DNS-Failover zu behandeln.

Wenn Sie eine Web Application Firewall in diese Architektur einführen müssen, können Sie die integrierte FQDN-Routinglösung weiterhin als Back-End-Ursprung für Ihren globalen Router verwenden, der eine Web Application Firewall implementiert. Der globale Router würde die Failoververantwortung an API Management delegieren. Alternativ können Sie auch die FQDNs der regionalen Gateways als Back-End-Pool-Mitglieder verwenden. Verwenden Sie in dieser zuletzt genannten Architektur den integrierten /status-0123456789abcdef-Endpunkt auf jedem regionalen Gateway oder einen anderen benutzerdefinierten Integritäts-API-Endpunkt, um regionales Failover zu unterstützen. Wenn Sie unsicher sind, beginnen Sie mit dem Back-End FQDN-Ansatz mit nur einem Ursprung.

Diese Architektur funktioniert am besten, wenn Sie Regionen als vollständig verfügbar oder vollständig nicht verfügbar behandeln können. Dies bedeutet, dass der Clientdatenverkehr nicht mehr an das API Management-Gateway in dieser Region weitergeleitet werden soll, wenn entweder das API Management-Gateway oder die Azure OpenAI-Instanz nicht mehr verfügbar ist. Sofern keine andere Bestimmung getroffen wird, muss der Fehler an den Client weitergegeben werden, wenn das regionale Gateway weiterhin Datenverkehr akzeptiert, während Azure OpenAI nicht verfügbar ist. Einen verbesserten Ansatz zur Vermeidung des Client-Fehlers finden Sie unter Aktiv-Aktiv-Gateway plus Aktiv-Passiv Azure OpenAI-Variante.

Wenn in einer Region ein API Management-Gateway-Ausfall auftritt oder als fehlerhaft gekennzeichnet wird, müssen die verbleibenden verfügbaren Regionen 100 % des Datenverkehrs aus diesen anderen Regionen aufnehmen. Das bedeutet, dass Sie PTU-basierte Azure OpenAI-Instanzen übermäßig bereitstellen müssen, um den neuen sprunghaften Anstieg des Datenverkehrsvolumens zu bewältigen, oder einen Aktiv/Passiv-Ansatz für das Failover verwenden müssen. Verwenden Sie den Azure OpenAI-Kapazitätsrechner für die Kapazitätsplanung.

Stellen Sie sicher, dass sich die Ressourcengruppe, die Azure API Management enthält, am selben Standort befindet wie die API Management-Instanz selbst, um den Einfluss eines damit verbundenen regionalen Ausfalls auf den Zugriff auf den Ressourcenanbieter für Ihre Gateways zu verringern.

Aktiv-Aktiv-Gateway plus Aktiv-Passiv Azure OpenAI-Variante

Im vorherigen Abschnitt geht es um die Verfügbarkeit des Gateways durch die Bereitstellung einer Aktiv/Aktiv-Gateway-Topologie. Diese Topologie kombiniert das Aktiv/Aktiv-Gateway mit einer kostengünstigen Aktiv/Passiv-Azure OpenAI-Topologie. Das Hinzufügen einer Aktiv/Passiv-Logik zum Gateway, um zu einer verbrauchsbasierten Azure OpenAI-Bereitstellung aus einer PTU-basierten Bereitstellung zu gelangen, kann die Zuverlässigkeit der Workload erheblich erhöhen. Mit diesem Modell können Clients weiterhin die integrierte FQDN-Routinglösung von API Management für leistungsbasiertes Routing verwenden.

Verwenden eines benutzerdefinierten codierten Gateways

Wenn Ihre Routing-Regeln pro Gateway für Ihr Team zu komplex sind, um sie als Richtlinien für das API Management für sinnvoll zu halten, müssen Sie eine eigene Lösung bereitstellen und verwalten. Bei dieser Architektur muss es sich um eine multiregionale Bereitstellung Ihres Gateways mit einer hochverfügbaren Skalierungseinheit pro Region handeln. Sie müssen diese Bereitstellungen mit Azure Front Door (Anycast) oder Azure Traffic Manager (DNS) durchführen, in der Regel unter Verwendung von latenzbasiertem Routing und entsprechenden Zustandsprüfungen der Gateway-Verfügbarkeit.

Verwenden Sie Azure Front Door, wenn Sie eine Web Application Firewall und einen öffentlichen Internetzugang benötigen. Verwenden Sie Traffic Manager, wenn Sie keine Web Application Firewall benötigen und DNS TTL ausreichend ist. Wenn Sie Ihre Gateway-Instanzen mit Azure Front Door (oder einem anderen Reverse Proxy) betreiben, stellen Sie sicher, dass das Gateway nicht umgangen werden kann. Machen Sie die Gateway-Instanzen nur über einen privaten Endpunkt verfügbar, wenn Sie Azure Front Door verwenden, und fügen Sie eine Validierung des X_AZURE_FDID HTTP-Headers in Ihre Gateway-Implementierung ein.

Platzieren Sie Ressourcen pro Region, die in Ihrem benutzerdefinierten Gateway in Ressourcengruppen pro Region verwendet werden. Dadurch verringert sich der Radius eines Ausfalls in einer Region, der Ihren Zugriff auf den Ressourcenanbieter für Ihre Gateway-Ressourcen in dieser Region beeinträchtigt.

Sie können auch in Erwägung ziehen, Ihre Gateway-Logik-Implementierung mit API Management zu verbinden, um die anderen Vorteile von API Management zu nutzen, wie TLS, Authentifizierung, Zustandsüberprüfung oder Load-Balancing mit Round-Robin-Verfahren. Auf diese Weise werden allgemeine API-Probleme aus dem angepassten Code Ihres Gateways ausgelagert, und Ihr Gateway kann speziell das Routing für die Bereitstellung von Azure OpenAI-Instanzen und -Modellen übernehmen.

Um die Compliance zu gewährleisten, stellen Sie sicher, dass jede geopolitische Grenze ihre eigene isolierte Bereitstellung dieser Architektur hat und dass Clients nur ihren autorisierten Endpunkt erreichen können.

Gründe, ein Gateway für mehrere Instanzen in mehreren Regionen zu vermeiden

Implementieren Sie kein einheitliches Gateway über geopolitische Regionen hinweg, wenn Datenresidenz und Compliance erforderlich sind. Andernfalls würden Sie gegen die Anforderungen an die Datenresidenz verstoßen. Verwenden Sie individuell adressierbare Gateways pro Region, und befolgen Sie die Anleitung in einem der vorherigen Abschnitte.

Wenn von den Clients kein Failover zwischen den Regionen erwartet wird und Sie die Möglichkeit haben, den Clients ein bestimmtes Gateway zuzuweisen, dann verwenden Sie stattdessen mehrere Gateways, eines pro Region, und befolgen Sie die Anleitung in einem der vorherigen Abschnitte. Binden Sie die Verfügbarkeit anderer Regionen nicht an die Region, die Ihr Gateway als Single Point of Failure enthält.

Implementieren Sie kein einheitliches Gateway, wenn Ihr Modell und Ihre Version nicht in allen vom Gateway bereitgestellten Regionen verfügbar sind. Clients müssen an dasselbe Modell und dieselbe Modellversion weitergeleitet werden. Für Load-Balancing- und Failover-Gateways mit mehreren Regionen müssen Sie ein allgemeines Modell und eine Modellversion wählen, die in allen beteiligten Regionen verfügbar ist. Weitere Informationen finden Sie unter Modellverfügbarkeit. Wenn Sie nicht auf Modell und Modellversion standardisieren können, ist der Nutzen des Gateways begrenzt.

Allgemeine Empfehlungen

Unabhängig davon, welche Topologie Ihr Workload benötigt, gibt es ein paar übergreifende Empfehlungen, die Sie beim Aufbau Ihrer Gateway-Lösung berücksichtigen sollten.

Zustandsbehaftete Interaktionen

Wenn Clients die statusbasierten Funktionen von Azure OpenAI nutzen, wie z. B. die Assistants-API, müssen Sie Ihr Gateway so konfigurieren, dass ein Client während dieser Interaktion einem bestimmten Back-End zugeordnet wird. Dies kann durch das Speichern von Instanz-Daten in einem Cookie erreicht werden. In diesen Szenarien sollten Sie eine Azure OpenAI-API-Antwort wie eine 429 an einen angehefteten Client zurückgeben, anstatt sie an eine andere Azure OpenAI-Instanz umzuleiten. Dies bietet dem Client die Möglichkeit, eine unerwartete Nichtverfügbarkeit explizit zu verarbeiten, anstatt sie zu verbergen und zu einer Instanz zu routen, die keine Historie hat.

Gateway-Integritätsprüfungen

Unabhängig von der Topologie gibt es zwei Perspektiven für die Zustandsprüfung zu berücksichtigen.

Wenn Ihr Gateway für Round-Robin oder ein reines Failover der Dienstverfügbarkeit erstellt wurde, benötigen Sie eine Möglichkeit, eine Azure OpenAI-Instanz (oder ein Modell) aus dem Verfügbarkeitsstatus zu nehmen. Azure OpenAI bietet keine Art von Integritätsprüfungsendpunkt, um vorab zu wissen, ob er für die Verarbeitung von Anforderungen verfügbar ist. Sie könnten synthetische Übergänge senden, aber das verbraucht Modellkapazität. Wenn Sie keine andere verlässliche Signalquelle für die Verfügbarkeit von Azure OpenAI-Instanzen und -Modellen haben, sollte Ihr Gateway wahrscheinlich davon ausgehen, dass die Azure OpenAI-Instanz verfügbar ist, und dann 429, 500, 503 HTTP-Statuscodes als Signal zur Unterbrechung des Circuits für zukünftige Anfragen auf dieser Instanz oder diesem Modell für einige Zeit behandeln. Bei Drosselungen sollten Sie in Ihrer Circuit-Unterbrechungslogik immer die Daten im Retry-After-Header der Azure OpenAI-API-Antworten für 429-Antwortcodes berücksichtigen. Wenn Sie Azure API Management verwenden, sollten Sie die integrierte Circuit-Breaker-Funktionalität nutzen.

Ihre Clients oder Ihr Workload-Betriebsteam möchten vielleicht eine Zustandsprüfung Ihres Gateways für ihre eigenen Routing- oder Introspektionszwecke anzeigen lassen. Wenn Sie API Management verwenden, ist der Standard /status-0123456789abcdef möglicherweise nicht detailliert genug, da er sich hauptsächlich auf die Gateway-Instanz von API Management bezieht und nicht auf Ihre Back-Ends. Erwägen Sie das Hinzufügen einer dedizierten Integritätsprüfungs-API, die aussagekräftige Daten an Clients oder Systeme für Einblicke zur Verfügbarkeit des Gateways oder spezifischer Routen im Gateway zurückgeben kann.

Sichere Bereitstellungsmethoden

Sie können Gateway-Implementierungen verwenden, um Blue-Green-Bereitstellungen aktualisierter Modelle zu orchestrieren. Azure OpenAI-Modelle werden mit neuen Modellversionen und neuen Modellen aktualisiert, und Sie haben möglicherweise neue, fein abgestimmte Modelle.

Nachdem Sie die Auswirkungen einer Änderung in der Pre-Production getestet haben, bewerten Sie, ob die Clients in der Produktion auf die neue Modellversion umgestellt werden sollen oder ob der Datenverkehr stattdessen verlagert werden soll. Das zuvor beschriebene Gateway-Muster lässt im Back-End die Möglichkeit zu, beide Modelle gleichzeitig bereitzustellen. Das gleichzeitige Bereitstellen von Modellen gibt dem Gateway die Möglichkeit, den Datenverkehr auf der Grundlage der sicheren Bereitstellungspraxis des Workload-Teams für die schrittweise Einführung umzuleiten.

Auch wenn Sie keine Blue-Green-Bereitstellungen verwenden, muss der APIOps-Ansatz Ihres Workloads definiert und hinreichend automatisiert sein, um zur Änderungsrate Ihrer Back-End-Instanz und mit den Bereitstellungen der Modelle Schritt zu halten.

Minimale Implementierung

Viele der in diesem Artikel vorgestellten Szenarien tragen dazu bei, das potenzielle Service-Level-Ziel (SLOs) Ihres Workloads zu erhöhen, indem die Komplexität des Clients reduziert und zuverlässige Selbstsicherungstechniken implementiert werden. Andere verbessern die Sicherheit der Workload, indem sie die Zugriffssteuerungen auf bestimmte Modelle von Azure OpenAI verlagern. Stellen Sie sicher, dass die Einführung des Gateways nicht kontraproduktiv für diese Ziele ist. Verstehen Sie die Risiken, die auftreten, wenn ein neuer Single Point of Failure entsteht, sei es durch Dienstfehler oder vom Menschen verursachte Konfigurationsprobleme im Gateway, komplexe Routing-Logik oder die Gefahr, dass mehr Modelle als beabsichtigt für nicht autorisierte Clients zur Verfügung gestellt werden.

Datenhoheit

Die verschiedenen Aktiv/Aktiv- und Aktiv/Passiv-Ansätze müssen aus Sicht der Datenresidenz-Compliance für Ihre Workload bewertet werden. Viele dieser Strukturierungen wären für die Architektur Ihres Workloads anwendbar, wenn die beteiligten Regionen innerhalb der geopolitischen Grenzen bleiben. Um dieses Szenario zu unterstützen, müssen Sie geopolitische Grenzen als isolierte Grenzen behandeln und die Aktiv-Aktiv oder Aktiv-Passiv-Verarbeitung ausschließlich innerhalb dieser Grenzen anwenden.

Insbesondere muss jedes leistungsbasierte Routing genauestens auf die Compliance hinsichtlich der Datenhoheit überprüft werden. In Szenarien, die die Datenhoheit betreffen, können Sie keine Clients mit einer anderen geografischen Lage bedienen und trotzdem die Compliance einhalten. Alle Gateway-Architekturen, die eine Datenresidenz beinhalten, müssen erzwingen, dass Clients nur Endpunkte in ihrer geopolitischen Region verwenden. Die Clients müssen daran gehindert werden, andere Gateway-Endpunkte zu verwenden, und das Gateway selbst verletzt nicht das Vertrauen des Clients, indem es eine geopolitische Anfrage stellt. Der zuverlässigste Weg, diese Segmentierung umzusetzen, besteht darin, Ihre Architektur um ein völlig unabhängiges, hochverfügbares Gateway pro geopolitischer Region zu erstellen.

Azure OpenAI-Autorisierung

Das Gateway muss sich bei allen Azure OpenAI-Instanzen authentifizieren, mit denen es sich verbindet. Sofern Sie das Gateway nicht für eine Passthrough-Authentifizierung konzipiert haben, sollte das Gateway eine verwaltete Identität für seine Anmeldeinformationen verwenden. Daher muss jede Azure OpenAI-Instanz das am wenigsten privilegierte RBAC für die verwalteten Identitäten der Gateways konfigurieren. Stellen Sie bei Aktiv-Aktiv- und Failover-Architekturen sicher, dass die Identität des Gateways in allen beteiligten Azure OpenAI-Instanzen über die gleichen Berechtigungen verfügt.

Azure Policy

Die Konsistenz zwischen Modellbereitstellungen und Azure OpenAI-Instanzen ist in Aktiv/Aktiv- oder Aktiv/Passiv-Situationen wichtig. Verwenden Sie Azure-Richtlinien, um die Konsistenz zwischen den verschiedenen Azure OpenAI-Instanzen oder Bereitstellungsmodellen zu gewährleisten. Wenn die integrierten Richtlinien für Azure OpenAI nicht ausreichen, um die Konsistenz zwischen ihnen sicherzustellen, sollten Sie die Erstellung oder Verwendung von benutzerdefinierten Community-Richtlinien in Betracht ziehen.

Gateway-Redundanz

Die Implementierung des Gateways in jeder Region ist zwar nicht spezifisch für mehrere Back-Ends, sollte aber immer mit Redundanz erstellt werden und innerhalb der Skalierungseinheit hochverfügbar sein. Wählen Sie Regionen mit Verfügbarkeitszonen, und stellen Sie sicher, dass Ihr Gateway über diese Zonen verteilt ist. Stellen Sie mehrere Instanzen des Gateways bereit, sodass sich der Ausfall eines Gateways auf einen kompletten Ausfall der Region beschränkt und nicht auf den Fehler einer einzelnen Instanz in Ihrem Gateway. Stellen Sie für API Management zwei oder mehr Einheiten über zwei oder mehr Zonen bereit. Stellen Sie für benutzerdefinierte Codeimplementierungen mindestens drei Instanzen mit optimaler Leistungsverteilung über Verfügbarkeitszonen bereit.

Gatewayimplementierungen

Azure bietet keine turn-key-Lösung oder Referenzarchitektur zum Erstellen eines solchen Gateways, das sich auf das Routing des Datenverkehrs über mehrere Back-Ends konzentriert. Wie im Einführungsartikel erwähnt, muss Ihr Workload-Team dieses Gateway aufbauen und betreiben. Im Folgenden finden Sie einige Beispiele für von der Community unterstützte Implementierungen, die einige der zuvor genannten Anwendungsfälle abdecken. Erwägen Sie, auf diese GitHub-Beispiele zu verweisen, wenn Sie Ihren eigenen Proof of Concept erstellen.

Implementierung	Beispiel
Azure API Management	Intelligenter Lastenausgleich für Azure OpenAI mit Azure API Management – Dieses GitHub-Repository enthält Beispielrichtliniencode und Anweisungen zur Bereitstellung in Ihrem Abonnement. Skalierung von Azure OpenAI mithilfe von Azure API Management – Dieses GitHub-Repository enthält Beispielrichtliniencode und Anweisungen für PTU und Verbrauchsüberlauf. Das GenAI-Gateway-Toolkit enthält Beispielrichtlinien für die API-Verwaltung sowie ein Belastungstest-Setup zum Testen des Verhaltens der Richtlinien.
Benutzerdefinierter Code	Intelligenter Lastenausgleich für Azure OpenAI mithilfe von Azure Container Apps Dieses GitHub-Repository enthält C#-Beispielcode und Anweisungen zum Erstellen des Containers und Bereitstellen in Ihrem Abonnement.

Das Cloud Adoption Framework für Azure enthält auch Anleitungen zur Implementierung einer Azure API Management-Zielzone für generative KI-Szenarien, einschließlich dieses Multi-Back-End-Szenarios. Wenn Ihre Workload in einer Anwendungslandzone vorhanden ist, lesen Sie diese Anleitung für Implementierungsüberlegungen und Empfehlungen.

Nächste Schritte

Die Implementierung eines Gateways für Ihren Workload bietet Vorteile, die über die in diesem Artikel beschriebenen taktischen Vorteile des mehrfachen Back-End-Routings hinausgehen. Erfahren Sie mehr über die anderen wichtigen Herausforderungen, die ein Gateway lösen kann.

Zugehörige Ressourcen

• Azure OpenAI Service
• API-Gateway in Azure API Management