Modifier

Partager via

Accédez à Azure OpenAI et à d’autres modèles de langage via une passerelle

Azure AI services
Azure OpenAI Service
Gestion des API Azure

Le service Azure OpenAI expose des API HTTP qui permettent à vos applications d’effectuer des intégrations ou des complétions en utilisant les grands modèles de langage (LLMs) d’OpenAI. Les applications intelligentes appellent ces API HTTP directement à partir de clients ou d’orchestrateurs. Les exemples de clients incluent le code d’interface utilisateur de chat et les pipelines de traitement de données personnalisés. Parmi les exemples d’orchestrateurs, citons LangChain, Le noyau sémantique et le flux d’invite dans Azure AI Foundry. Lorsque votre charge de travail se connecte à une ou plusieurs instances Azure OpenAI, vous devez décider si ces consommateurs se connectent directement ou via une passerelle API à proxy inverse.

Consultez ce guide pour comprendre les principaux défis dans les cinq piliers du Cadre Azure Well-Architected que vous rencontrerez si la conception de votre charge de travail inclut un accès direct de vos consommateurs aux API de plan de données Azure OpenAI. Découvrez ensuite comment l’introduction d’une passerelle dans votre architecture peut contribuer à résoudre ces problèmes d’accès direct, tout en introduisant de nouveaux défis. Cet article décrit le modèle architectural, mais pas la manière de mettre en œuvre la passerelle.

Étant donné qu’une passerelle peut être utilisée pour résoudre des scénarios spécifiques qui ne sont pas forcément présents dans toutes les charges de travail, veillez à consulter les conseils relatifs aux scénarios spécifiques, qui examinent plus en détail ce cas d’utilisation spécifique d’une passerelle.

Principaux défis

Sans passerelle API ou sans la possibilité d’ajouter une logique aux API HTTP Azure OpenAI, le client doit gérer la logique du client API, qui comprend des mécanismes de relance ou des coupe-circuits. Cette situation peut s’avérer difficile dans les scénarios où vous ne contrôlez pas directement le code client, ou lorsque le code est limité à une utilisation spécifique du SDK. Plusieurs clients ou plusieurs instances et déploiements Azure OpenAI présentent d’autres défis, tels que la coordination des déploiements sûrs et l’observabilité.

Cette section fournit des exemples de défis architecturaux clés spécifiques auxquels vous pourriez être confronté si votre architecture ne prend en charge que l’accès direct à Azure OpenAI à partir des consommateurs. Les défis sont organisés en utilisant les piliers du Cadre Azure Well-Architected.

Défis de fiabilité

La fiabilité de la charge de travail dépend de plusieurs facteurs, notamment sa capacité d’auto-préservation et d’auto-récupération, souvent mise en œuvre à travers des mécanismes de réplication et de basculement. Sans passerelle, tous les problèmes de fiabilité doivent être traités exclusivement en utilisant la logique du client et les fonctionnalités du service Azure OpenAI. La fiabilité de la charge de travail est compromise lorsqu’il n’y a pas suffisamment de contrôle de fiabilité disponible dans l’une ou l’autre de ces deux surfaces.

  • équilibrage de charge ou redondance : basculement entre plusieurs instances Azure OpenAI en fonction de la disponibilité du service est une responsabilité cliente que vous devez contrôler par le biais de la configuration et de la logique personnalisée.

    global, standard ou provisionné, et zone de données, standard ou approvisionnée, n’ont pas d’impact sur la disponibilité du service Azure OpenAI du point de terminaison régional. Vous avez toujours la responsabilité d’implémenter vous-même la logique de basculement.

  • Expansion pour gérer les pics : basculer vers des instances Azure OpenAI avec capacité lorsqu’elles sont limitées est une autre responsabilité du client que vous devez contrôler via la configuration et la logique personnalisée. La mise à jour de multiples configurations de clients pour de nouvelles instances Azure OpenAI présente un risque plus important et pose des problèmes de délais. Il en va de même pour la mise à jour du code client pour implémenter des changements de logique, tels que diriger les demandes de faible priorité vers une file d’attente pendant les périodes de forte demande.

  • Limitation : les API Azure OpenAI limitent les demandes en retournant un code de réponse d’erreur HTTP 429 aux requêtes qui dépassent le TPM (Token-Per-Minute) ou requests-Per-Minute (RPM) dans le modèle standard. Les API Azure OpenAI limitent également les demandes qui dépassent la capacité provisionnée pour le modèle de facturation préprovisionné. La gestion d’une logique appropriée de back-off et de réessai est laissée exclusivement aux implémentations client.

    La plupart des charges de travail doivent résoudre ce problème spécifique en utilisant et zone de données déploiements d’Azure OpenAI. Ces déploiements utilisent la capacité du modèle à partir de centres de données avec la capacité suffisante pour chaque requête. L’utilisation de déploiements globaux et de zones de données réduit considérablement la limitation des services sans complexité supplémentaire des passerelles personnalisées. Les déploiements globaux et de zones de données sont eux-mêmes une implémentation de passerelle.

Défis de sécurité

Les contrôles de sécurité doivent contribuer à protéger la confidentialité, l’intégrité et la disponibilité de la charge de travail. Sans passerelle, toutes les préoccupations en matière de sécurité doivent être traitées exclusivement dans la logique du client et les fonctionnalités du service Azure OpenAI. Les exigences de charge de travail peuvent exiger plus que ce qui est disponible pour la segmentation client, le contrôle client ou les fonctionnalités de sécurité du service pour une communication directe.

  • Gestion des identités - étendue d’authentification : Les API de plan de données exposées par Azure OpenAI peuvent être sécurisées de deux manières, clé API ou contrôle d’accès basé sur les rôles Azure (RBAC). Dans les deux cas, l’authentification se fait au niveau de l’instance Azure OpenAI, et non au niveau du déploiement individuel, ce qui introduit une complexité pour fournir un accès au moindre privilège et une segmentation de l’identité pour des modèles de déploiement spécifiques.

  • Gestion des identités - fournisseurs d’identités : Les clients qui ne peuvent pas utiliser les identités situées dans le locataire Microsoft Entra qui soutient l’instance Azure OpenAI doivent partager une seule clé API d’accès complet. Les clés API ont une utilité limitée en matière de sécurité et posent des problèmes lorsque plusieurs clients sont impliqués et qu’ils partagent tous la même identité.

  • Sécurité du réseau : selon l’emplacement du client par rapport à vos instances Azure OpenAI, l’accès Internet public aux modèles de langage peut être nécessaire.

  • Souveraineté des données : la souveraineté des données dans le contexte d’Azure OpenAI fait référence aux exigences légales et réglementaires liées au stockage et au traitement des données dans les limites géographiques d’un pays ou d’une région spécifique. Votre charge de travail doit garantir une affinité régionale afin que les clients puissent se conformer aux lois sur la résidence et la souveraineté des données. Ce processus implique plusieurs déploiements d’Azure OpenAI.

    Sachez que lorsque vous utilisez global ou zone de données déploiements d’Azure OpenAI, les données au repos restent dans la zone géographique Azure désignée, mais les données peuvent être transmises et traitées pour inférence dans n’importe quel emplacement Azure OpenAI.

Les défis liés à l’optimisation des coûts

Les charges de travail bénéficient lorsque les architectures minimisent le gaspillage et maximisent l’utilité. Une modélisation et une surveillance des coûts solides sont une exigence importante pour toute charge de travail. Sans passerelle, l’utilisation du suivi des coûts provisionnés ou par client peut être obtenue exclusivement à partir de l’agrégation des données de télémétrie d’utilisation des instances Azure OpenAI.

  • Suivi des coûts : la capacité de fournir une perspective financière sur l’utilisation d’Azure OpenAI est limitée aux données agrégées à partir de la télémétrie d’utilisation des instances Azure OpenAI. Lorsque vous devez procéder à une facturation ou à une rétrocession, vous devez attribuer cette télémétrie d'utilisation à divers clients dans différents départements ou même à des clients dans le cadre de scénarios multilocataires.

  • Utilisation du débit provisionné : votre charge de travail souhaite éviter le gaspillage en utilisant pleinement le débit provisionné pour lequel vous avez payé. Cela signifie que les clients doivent être approuvés et coordonnés pour utiliser des déploiements de modèles provisionnés avant de basculer dans les déploiements de modèles standard.

Les défis liés à l’excellence opérationnelle

Sans passerelle, l’observabilité, le contrôle des changements et les processus de développement sont limités à ce qui est fourni par la communication directe entre le client et le serveur.

  • Contrôle des quotas : les clients reçoivent des codes de réponse 429 directement d’Azure OpenAI lorsque les API HTTP sont limitées. Les opérateurs de charge de travail sont chargés de veiller à ce qu’un quota suffisant soit disponible pour une utilisation légitime et à ce que les clients qui se comportent mal ne consomment pas en excès. Lorsque votre charge de travail se compose de plusieurs déploiements de modèles ou de plusieurs zones de données, la compréhension de l’utilisation du quota et de la disponibilité des quotas peut être difficile à visualiser.

  • Surveillance et observabilité : Les mesures par défaut d’Azure OpenAI sont disponibles via Azure Monitor. Cependant, la disponibilité des données s’accompagne d’un temps de latence et ne permet pas une surveillance en temps réel.

  • Pratiques de déploiement sûres : Votre processus GenAIOps nécessite une coordination entre les clients et les modèles déployés dans Azure OpenAI. Pour les approches de déploiement avancées, telles que blue-green ou canary, la logique doit être gérée côté client.

Les défis liés à l’efficacité des performances

Sans passerelle, votre charge de travail fait peser sur les clients la responsabilité de bien se comporter individuellement et de se comporter équitablement avec les autres clients face à une capacité limitée.

  • Optimisation des performances - trafic prioritaire : prioriser les demandes des clients afin que les clients à haute priorité aient un accès préférentiel sur les clients à faible priorité nécessiterait une coordination étendue et probablement intenable entre clients. Certains travaux bénéficieraient d’avoir des demandes de faible priorité mises en file d’attente pour s’exécuter lorsque l’utilisation du modèle est faible.

  • Optimisation des performances - conformité des clients : Pour partager la capacité, les clients doivent faire preuve d’un comportement approprié. C’est le cas, par exemple, lorsque les clients s’assurent que max_tokens et best_of sont réglés sur des valeurs approuvées. Sans une passerelle, vous devrez faire confiance aux clients pour agir dans le meilleur intérêt de préserver la capacité de votre instance Azure OpenAI.

  • Minimiser la latence : bien que la latence réseau soit généralement un petit composant du flux global de demandes de suggestion et de complétion, s’assurer que les clients sont dirigés vers un point de terminaison réseau et un modèle proche d’eux pourrait être bénéfique. Sans passerelle, les clients devraient choisir eux-mêmes les points de terminaison de modèle de déploiement à utiliser et les informations d’identification nécessaires pour cette API de plan de données Azure OpenAI spécifique.

Solution

Diagramme montrant une architecture conceptuelle d’injection d’une passerelle entre une application intelligente et Azure OpenAI.

Figure 1 : Architecture conceptuelle d’accès à Azure OpenAI via une passerelle

Pour relever les nombreux défis énumérés dans la section Défis clés, vous pouvez injecter une passerelle de proxy inverse pour découpler l’application intelligente d’Azure OpenAI. Ce délestage de la passerelle vous permet de déplacer la responsabilité, la complexité et l’observabilité des clients et vous donne l’occasion d’augmenter Azure OpenAI en fournissant d’autres capacités qui ne sont pas intégrées. Quelques exemples :

Pour certains scénarios spécifiques, il existe davantage de conseils qui concernent directement une passerelle API et les instances Azure OpenAI. Ces scénarios sont répertoriés dans la section Étape suivante.

À propos de l’installation

Lorsque vous introduisez un nouveau composant dans votre architecture, vous devez évaluer les nouveaux compromis introduits. Lorsque vous injectez une passerelle API entre vos clients et le plan de données Azure OpenAI pour résoudre l’un des défis essentiels, vous introduisez de nouvelles considérations dans votre architecture. Évaluez attentivement si l’impact sur la charge de travail à travers ces considérations architecturales justifie la valeur ajoutée ou l’utilité de la passerelle.

Fiabilité

La fiabilité garantit que votre application respecte les engagements que vous avez pris envers vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

  • La solution de passerelle peut introduire un point de défaillance unique. Cette défaillance peut avoir son origine dans la disponibilité du service de la plateforme de la passerelle, les interruptions dues aux déploiements de code ou de configuration, ou même la mauvaise configuration des points de terminaison API critiques dans votre passerelle. Assurez-vous de concevoir votre implémentation pour répondre aux exigences de disponibilité de votre charge de travail. Tenez compte des capacités de résilience et de tolérance aux pannes dans l’implémentation en incluant la passerelle dans l’analyse du mode de défaillance de la charge de travail.

  • Votre solution peut nécessiter des fonctionnalités de routage globales si votre architecture nécessite des instances Azure OpenAI dans plusieurs régions pour augmenter la disponibilité de vos points de terminaison Azure OpenAI, telles que la possibilité de continuer à traiter les demandes en cas de panne régionale. Cette situation peut compliquer davantage la topologie par la gestion de noms de domaine pleinement qualifiés supplémentaires, de certificats TLS et de composants de routage plus globaux.

Important

Ne mettez pas en œuvre une passerelle si cela risque de compromettre la capacité de votre charge de travail à atteindre les objectifs de niveau de service (SLO) convenus.

Sécurité

Lorsque vous considérez comment une passerelle API bénéficie à votre architecture, utilisez la liste de contrôle de conception pour la sécurité pour évaluer votre conception. Vous devez prendre en compte les considérations de sécurité, telles que les suivantes :

  • L’empreinte de la charge de travail est augmentée avec l’ajout de la passerelle. Cette augmentation de l’empreinte apporte des considérations supplémentaires en matière de gestion des identités et des accès (IAM) des ressources Azure, des efforts de renforcement accrus, et plus encore.

  • La passerelle peut agir comme une transition de frontière réseau entre l’espace réseau client et l’espace réseau privé Azure OpenAI. Même si la passerelle rend privé un point de terminaison Azure OpenAI qui faisait auparavant face à Internet grâce à l’utilisation d'une liaison privée Azure, il devient le nouveau point d’entrée et doit être sécurisé de manière adéquate.

  • Une passerelle est dans une position unique pour voir les données de requête brutes et les réponses formulées du modèle de langage, qui pourraient inclure des données confidentielles provenant de l’une ou l’autre source. La conformité des données et le champ d’application de la réglementation s’étendent désormais à cet autre composant.

  • Une passerelle peut étendre la portée de l’autorisation et de l’authentification client au-delà de l’authentification par Microsoft Entra ID et clé API, potentiellement à travers plusieurs fournisseurs d’identité (IdP).

  • La souveraineté des données doit être prise en compte dans votre mise en œuvre pour les implémentations multirégionales. Assurez-vous que votre logique de calcul de passerelle et de routage respecte les exigences de souveraineté imposées à votre charge de travail.

Important

N’implémentez pas une passerelle si cela laisse votre charge de travail incapable de protéger la confidentialité, l’intégrité ou la disponibilité de celle-ci ou des données de ses utilisateurs.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Toutes les passerelles API mises en œuvre ont des coûts d’exécution qui doivent être budgétisés et pris en compte. Ces coûts augmentent généralement avec les fonctionnalités visant à garantir la fiabilité, la sécurité et les performances de la passerelle elle-même, ainsi qu’avec les coûts opérationnels introduits par la gestion de l’APIOps ajoutée. Ces coûts supplémentaires doivent être mesurés par rapport à la nouvelle valeur délivrée par le système avec la passerelle. Vous voulez atteindre un point où les nouvelles capacités introduites par l’utilisation d’une passerelle l’emportent sur le coût de mise en œuvre et de maintenance de la passerelle. En fonction de la relation de votre charge de travail avec ses utilisateurs, vous pourriez être en mesure de facturer l’utilisation.

Pour aider à gérer les coûts lors du développement et des tests d’une passerelle, envisagez d’utiliser un point de terminaison simulé pour Azure OpenAI. Par exemple, utilisez la solution du référentiel GitHub Azure OpenAI API simulator.

Excellence opérationnelle

Lorsque vous considérez comment une passerelle API bénéficie à votre architecture, utilisez la liste de contrôle de conception pour l’excellence opérationnelle pour évaluer votre conception. Vous devez prendre en compte des considérations d’excellence opérationnelle telles que les suivantes :

  • La passerelle elle-même doit être surveillée par la solution de surveillance de votre charge de travail et éventuellement par les clients. Cela signifie que le calcul et les opérations de la passerelle doivent être inclus dans la modélisation de l’intégrité de votre charge de travail.

  • Vos pratiques de déploiement sûr doivent maintenant aborder le déploiement de l’infrastructure de passerelle API et le code ou la configuration du routage de la passerelle. Votre solution d’automatisation de l’infrastructure et d’infrastructure en tant que code (IaC) doit prendre en compte la manière de traiter votre passerelle comme une ressource à longue durée de vie dans la charge de travail.

  • Vous devez construire ou étendre votre approche APIOps pour couvrir les API exposées dans la passerelle.

  • Vous dupliquez les fonctionnalités disponibles via des solutions telles que la ressource Azure AI Service ou la fonctionnalité de distribution de charge de zone de données Azure OpenAI.

Efficacité des performances

Lorsque vous considérez comment une passerelle API bénéficie à votre architecture, utilisez la liste de contrôle de conception pour l’efficacité des performances pour évaluer votre conception. Vous devez tenir compte de considérations liées à l’efficacité des performances, telles que les suivantes :

  • Le service de passerelle peut introduire un goulot d’étranglement de débit. Assurez-vous que la passerelle a des performances adéquates pour gérer la charge complète concurrente et peut facilement s’adapter à vos attentes de croissance. Veillez à l’élasticité de la solution afin que la passerelle puisse réduire l’offre, ou diminuer l’échelle, lorsque la demande est faible, comme dans le cas d’une utilisation pendant les jours ouvrables.

  • Le service de passerelle doit effectuer un traitement par requête et introduit une latence supplémentaire par invocation de l’API. Vous devez optimiser votre logique de routage pour maintenir des performances élevées.

  • Dans la plupart des cas, la passerelle devrait être géographiquement proche à la fois des utilisateurs et des instances Azure OpenAI pour réduire la latence. Bien que la latence du réseau ne représente généralement qu’un faible pourcentage du temps dans l’ensemble des appels d’API aux modèles de langage, elle peut constituer un facteur concurrentiel pour votre charge de travail.

  • Évaluez l’impact de la passerelle sur les fonctionnalités d’Azure OpenAI, telles que les réponses en continu ou l’épinglage d’instances pour les interactions avec état, comme l’API Assistants.

Important

Ne mettez pas en œuvre une passerelle si cela rend impossible la réalisation des objectifs de performance négociés ou si cela compromet d’autres compromis.

Options d’implémentation

Azure n’offre pas de solution clé en clé conçue spécifiquement pour proxyr l’API HTTP d’Azure OpenAI ou d’autres API de langage personnalisé pour couvrir tous ces scénarios. Mais il existe tout de même plusieurs options à mettre en œuvre par votre équipe de charge de travail, comme une passerelle dans Azure.

Utiliser Gestion des API Azure

Azure API Management est un service géré par la plate-forme conçu pour décharger les préoccupations transversales des API basées sur HTTP. Il est piloté par configuration et prend en charge la personnalisation grâce à son système de stratégies de traitement des demandes entrantes et sortantes. Il prend en charge des répliques hautement disponibles, redondantes par zone, et même multi-régions à travers un seul plan de contrôle.

La plupart de la logique de routage et de traitement des demandes de la passerelle doit être implémentée dans le système de stratégies de l’API Management. Vous pouvez combiner stratégies intégrées spécifiques à Azure OpenAI, telles que limiter l’utilisation des jetons d’API Azure OpenAI ou Émettre des métriques pour la consommation de jetons Azure OpenAIet vos propres stratégies personnalisées. Le référentiel GitHub GenAI gateway toolkit contient un certain nombre de politiques de gestion des API personnalisées ainsi qu’une configuration de tests de charge pour évaluer le comportement des politiques.

Utilisez le Guide de service du cadre bien construit pour la gestion des API lors de la conception d’une solution impliquant Azure API Management. Si votre charge de travail existe dans le cadre d’une zone d’atterrissage d’application, passez en revue les instructions disponibles dans cloud Adoption Framework pour Azure sur l’implémentation d’une zone d’atterrissage Azure Gestion des API.

L’utilisation d’Azure API Management pour votre implémentation de passerelle est généralement l’approche privilégiée pour construire et exploiter une passerelle Azure OpenAI. Cette solution est privilégiée car le service est une offre de plateforme en tant que service (PaaS) avec de riches capacités intégrées, une haute disponibilité et des options de mise en réseau. Il dispose également d’approches APIOps robustes pour gérer vos API d’achèvement.

utiliser du code personnalisé.

L’approche du code personnalisé exige qu’une équipe de développement logiciel crée une solution codée personnalisée et la déploie sur une plateforme d’application Azure de son choix. La création d’une solution auto-gérée pour gérer la logique de passerelle peut convenir aux équipes de charge de travail compétentes dans la gestion du code de réseau et de routage.

La charge de travail peut généralement utiliser le compute qui leur est familier, comme l’hébergement du code de la passerelle sur Azure App Service, Azure Container Apps ou Azure Kubernetes Service.

Les déploiements de code personnalisé peuvent également être frontalisés avec API Management lorsque API Management est utilisé exclusivement pour ses capacités de passerelle API HTTP de base entre vos clients et votre code personnalisé. Ainsi, votre code personnalisé s’interface exclusivement avec vos API HTTP Azure OpenAI sur la base de la logique commerciale nécessaire.

L’utilisation d’une technologie de passerelle non Microsoft, c’est-à-dire d’un produit ou d’un service qui n’est pas fourni de manière native par Azure, peut être considérée comme faisant partie de cette approche.

Exemple d’architecture

Diagramme illustrant un exemple d’architecture d’injection d’une passerelle entre une application intelligente et Azure OpenAI.

Figure 2 : Exemple d’architecture d’accès à Azure OpenAI via une passerelle basée sur Azure API Management

Étapes suivantes

Découvrez un scénario spécifique où le déploiement d’une passerelle entre une application intelligente et les déploiements Azure OpenAI est utilisé pour répondre aux besoins de charge de travail :

Découvrez les moyens de mettre en œuvre la journalisation et la surveillance pour les modèles Azure OpenAI.