Acceso a Azure OpenAI y otros modelos de lenguaje a través de una puerta de enlace

Azure OpenAI Service expone las API HTTP que permiten a las aplicaciones realizar inserciones o finalizaciones mediante modelos de lenguaje de OpenAI. Las aplicaciones inteligentes llaman a estas API HTTP directamente desde clientes u orquestadores. Algunos ejemplos de clientes incluyen código de interfaz de usuario de chat y canalizaciones de procesamiento de datos personalizados. Algunos ejemplos de orquestadores son LangChain, Kernel semántico y flujo de solicitud en Azure AI Foundry. Cuando la carga de trabajo se conecta a una o varias instancias de Azure OpenAI, debe decidir si estos consumidores se conectan directamente o a través de una puerta de enlace de API de proxy inverso.

Use esta guía para obtener información sobre los desafíos clave en los cinco pilares del marco de buena arquitectura de Azure que encontrará si el diseño de la carga de trabajo incluye acceso directo de los consumidores a las API del plano de datos de Azure OpenAI. A continuación, obtendrá información sobre cómo introducir una puerta de enlace en la arquitectura puede resolver estos desafíos de acceso directo, al tiempo que presenta nuevos desafíos. En este artículo se describe el patrón de arquitectura, pero no cómo implementar la puerta de enlace.

Dado que una puerta de enlace se puede usar para resolver escenarios específicos que puede que no estén presentes en todas las cargas de trabajo, asegúrese de consultar las Instrucciones de escenario específicas que analizan ese caso de uso específico de una puerta de enlace en mayor profundidad.

Desafíos clave

Sin una puerta de enlace de API o la capacidad de agregar lógica a las API HTTP de Azure OpenAI, el cliente tiene que gestionar la lógica de cliente de API, que incluye mecanismos de reintento o interrupciones del circuito. Esta situación puede ser difícil en escenarios en los que no controla directamente el código de cliente o cuando el código está restringido a un uso específico del SDK. Varios clientes o varias instancias e implementaciones de Azure OpenAI presentan desafíos adicionales, como la coordinación de implementaciones seguras y la observabilidad.

En esta sección se proporcionan ejemplos de desafíos arquitectónicos clave específicos a los que podría enfrentarse si la arquitectura solo admite el acceso directo a Azure OpenAI desde consumidores. Los desafíos se organizan mediante los pilares del marco de buena arquitectura de Azure.

Desafíos de fiabilidad

La fiabilidad de la carga de trabajo depende de varios factores, incluida su capacidad para la conservación y recuperación automáticas, a menudo implementadas mediante mecanismos de replicación y conmutación por error. Sin una puerta de enlace, todos los problemas de fiabilidad deben abordarse exclusivamente utilizando la lógica de cliente y las características de Azure OpenAI Service. Cuando no hay suficiente control de la fiabilidad disponible en cualquiera de esas dos superficies, la fiabilidad de la carga de trabajo se ve comprometida.

• equilibrio de carga o redundancia: conmutación por error entre varias instancias de Azure OpenAI basadas en la disponibilidad del servicio es responsabilidad del cliente que necesita controlar a través de la configuración y la lógica personalizada.

  global, estándar o aprovisionado, y zona de datos, estándar o aprovisionado, no afecten a la disponibilidad del servicio Azure OpenAI desde una perspectiva de disponibilidad del punto de conexión regional. Todavía tiene la responsabilidad de implementar la lógica de conmutación por error usted mismo.

• Escalado horizontal para controlar los picos: la conmutación por error a instancias de Azure OpenAI con capacidad cuando se limita es otra responsabilidad del cliente que necesita controlar a través de la configuración y la lógica personalizada. La actualización de varias configuraciones de cliente para las nuevas instancias de Azure OpenAI presenta un mayor riesgo y tiene problemas de escala de tiempo. Lo mismo sucede con la actualización del código de cliente para implementar cambios en la lógica, como dirigir solicitudes de prioridad baja a una cola durante períodos de alta demanda.

• limitación: solicitudes de limitación de las API de Azure OpenAI devolviendo un código de respuesta de error HTTP 429 a las solicitudes que superan el tokenPer-Minute (TPM) o requests-Per-Minute (RPM) en el modelo estándar. Las API de Azure OpenAI también limitan las solicitudes que superan la capacidad aprovisionada para el modelo de facturación aprovisionado previamente. El control de la lógica de retroceso y reintento adecuada se deja exclusivamente en las implementaciones de cliente.

  La mayoría de las cargas de trabajo deben resolver este problema específico mediante global y zona de datos implementaciones de Azure OpenAI. Esas implementaciones usan la capacidad del modelo de los centros de datos con la capacidad suficiente para cada solicitud. El uso de implementaciones globales y de zona de datos reducirá significativamente la limitación del servicio sin una complejidad adicional de las puertas de enlace personalizadas. Las implementaciones de zona de datos y globales son una implementación de puerta de enlace.

Desafíos de seguridad

Los controles de seguridad deben ayudar a proteger la confidencialidad, integridad y disponibilidad de la carga de trabajo. Sin una puerta de enlace, todos los problemas de seguridad deben abordarse exclusivamente en la lógica de cliente y en las características de Azure OpenAI Service. Los requisitos de carga de trabajo pueden exigir más de lo que está disponible para la segmentación de cliente, el control de cliente o las características de seguridad del servicio para la comunicación directa.

• Administración de identidades: ámbito de autenticación: las API del plano de datos expuestas por Azure OpenAI se pueden proteger de una de estas dos maneras: la clave de API o el control de acceso basado en roles (RBAC) de Azure. En ambos casos, la autenticación se produce en el nivel de instancia de Azure OpenAI, no en el nivel de implementación individual, lo que introduce complejidad para proporcionar acceso con privilegios mínimos y segmentación de identidades para modelos de implementación específicos.

• Administración de identidades - proveedores de identidades: los clientes que no pueden usar identidades ubicadas en el inquilino de Microsoft Entra que respalde la instancia de Azure OpenAI, deben compartir una única clave de API de acceso completo. Las claves API tienen limitaciones de seguridad y resultan problemáticas cuando intervienen varios clientes y todos comparten la misma identidad.

• Seguridad de red: en función de la ubicación del cliente relativa a las instancias de Azure OpenAI, es posible que sea necesario acceder a Internet público a los modelos de lenguaje.

• Soberanía de datos: la soberanía de datos en el contexto de Azure OpenAI hace referencia a los requisitos legales y normativos relacionados con el almacenamiento y el procesamiento de datos dentro de los límites geográficos de un país o región específicos. La carga de trabajo debe garantizar la afinidad regional para que los clientes puedan cumplir las leyes de residencia y soberanía de datos. Este proceso implica varias implementaciones de Azure OpenAI.

  Debe tener en cuenta que cuando se usa global o zona de datos implementaciones de Azure OpenAI, los datos en reposo permanecen en la geografía de Azure designada, pero los datos se pueden transmitir y procesar para la inferencia en cualquier ubicación de Azure OpenAI.

Desafíos de optimización de costes

Las cargas de trabajo se benefician cuando las arquitecturas minimizan los residuos y maximizan la utilidad. El modelado y la supervisión sólidos de los costes son un requisito importante para cualquier carga de trabajo. Sin una puerta de enlace, el uso del seguimiento de costos aprovisionado o por cliente se puede lograr exclusivamente a partir de la agregación de telemetría de uso de instancias de Azure OpenAI.

• Seguimiento de costes: la capacidad de proporcionar una perspectiva financiera sobre el uso de Azure OpenAI se limita a los datos agregados desde la telemetría de uso de la instancia de Azure OpenAI. Cuando sea necesario para realizar el contracargo o la visualización, debe atribuir esa telemetría de uso con varios clientes en distintos departamentos o incluso clientes para escenarios multiinquilino.

• Uso del rendimiento aprovisionado: la carga de trabajo quiere evitar el desperdicio mediante el uso completo del rendimiento aprovisionado por el que ha pagado. Esto significa que los clientes deben ser de confianza y coordinarse para usar implementaciones de modelos aprovisionadas antes de desbordarse en cualquier implementación de modelos estándar.

Desafíos de excelencia operativa

Sin una puerta de enlace, la observabilidad, el control de cambios y los procesos de desarrollo se limitan a lo que se proporciona con la comunicación directa de cliente a servidor.

• Control de cuota: los clientes reciben códigos de respuesta 429 directamente desde Azure OpenAI cuando se limitan las API HTTP. Los operadores de carga de trabajo son responsables de garantizar que haya suficiente cuota disponible para el uso legítimo y que los clientes que se comportan mal no consuman en exceso. Cuando la carga de trabajo consta de varias implementaciones de modelos o varias zonas de datos, comprender el uso de cuotas y la disponibilidad de la cuota puede ser difícil de visualizar.

• Supervisión y observabilidad: las métricas predeterminadas de Azure OpenAI están disponibles a través de Azure Monitor. Sin embargo, hay latencia con la disponibilidad de los datos y no proporciona supervisión en tiempo real.

• Prácticas de implementación segura: el proceso de GenAIOps requiere coordinación entre los clientes y los modelos que se implementan en Azure OpenAI. En el caso de los enfoques de implementación avanzados, como azul/verde o controlado, la lógica tiene que controlarse en el lado del cliente.

Desafíos de eficiencia del rendimiento

Sin una puerta de enlace, la carga de trabajo hace recaer sobre los clientes la responsabilidad de comportarse bien individualmente y de ser justos con los demás clientes frente a una capacidad limitada.

• Optimización del rendimiento - tráfico prioritario: priorizar las solicitudes de los clientes para que los clientes de alta prioridad tengan acceso preferente sobre los de baja prioridad requeriría una coordinación exhaustiva, y probablemente poco razonable, de cliente a cliente. Algunas cargas de trabajo podrían beneficiarse de tener solicitudes de baja prioridad en cola para ejecutarse cuando la utilización del modelo es baja.

• Optimización del rendimiento - cumplimiento del cliente: para compartir la capacidad, los clientes deben comportarse bien. Un ejemplo de ello es cuando los clientes garantizan que max_tokens y best_of están establecidos en valores aprobados. Sin una puerta de enlace, debe confiar en los clientes para que actúen con el mejor interés de conservar la capacidad de la instancia de Azure OpenAI.

• Minimizar la latencia: aunque la latencia de la red suele ser un componente pequeño del flujo general de solicitudes de prontitud y finalización, garantizar que los clientes se enruten a un punto de conexión de red y a un modelo cercano a ellos podría suponer una ventaja. Sin una puerta de enlace, los clientes necesitarían seleccionar automáticamente qué puntos de conexión de la implementación de modelos usarán y qué credenciales son necesarias para esa API de plano de datos de Azure OpenAI específica.

Solución

Figura 1: Arquitectura conceptual de acceso a Azure OpenAI a través de una puerta de enlace

Para abordar los numerosos desafíos enumerados en la sección de Desafíos clave, puede insertar una puerta de enlace de proxy inverso para desacoplar la aplicación inteligente de Azure OpenAI Service. Esta descarga de puerta de enlace le permite cambiar la responsabilidad, la complejidad y la observabilidad de los clientes y le permite aumentar Azure OpenAI Service proporcionando otras funcionalidades no integradas. Ejemplos:

• Posibilidad de implementar la autenticación federada.

• Capacidad de controlar la presión en los modelos mediante la limitación de velocidad.

• Supervisión transversal y entre modelos.

• Capacidad de introducir la agregación de puerta de enlace y el enrutamiento avanzado a varios servicios, como el enrutamiento de mensajes de prioridad baja a una cola para el nivelado de la carga según la cola o para el proceso para realizar tareas.

• Equilibrio de carga que usa supervisión de puntos de conexión de mantenimiento para enrutar solo a puntos de conexión correctos interrumpir el circuito en implementaciones de modelos no disponibles o sobrecargadas.

Algunos escenarios específicos tienen más instrucciones disponibles que abordan directamente una puerta de enlace de API e instancias de Azure OpenAI. Estos escenarios se enumeran en la sección Pasos siguientes.

Consideraciones

La decisión de agregar una puerta de enlace y qué tecnología usar se toma como parte del diseño de aplicaciones de descrito en las cargas de trabajo de inteligencia artificial de Azure Well-Architected Framework en azure guía. Como arquitecto, deberá tomar la decisión de incluir o excluir este componente.

Cuando se introduce un nuevo componente en la arquitectura, hay que evaluar las ventajas y desventajas. Al insertar una puerta de enlace de API entre los clientes y el plano de datos de Azure OpenAI para abordar cualquiera de los desafíos clave, se presentan nuevas consideraciones para la arquitectura. Evalúe cuidadosamente si el impacto de la carga de trabajo a través de estas consideraciones arquitectónicas justifica el valor añadido o la utilidad de la puerta de enlace.

Fiabilidad

La confiabilidad garantiza que la aplicación cumpla los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

• La solución de puerta de enlace puede introducir un único punto de error. Este error podría tener su origen en la disponibilidad del servicio de la plataforma de puerta de enlace, las interrupciones debido a implementaciones de código o configuración, o incluso la configuración incorrecta de los puntos de conexión de API críticos en la puerta de enlace. Asegúrese de diseñar la implementación para satisfacer los requisitos de disponibilidad de la carga de trabajo. Considere las capacidades de resistencia y tolerancia a fallos en la implementación incluyendo la puerta de enlace en el análisis del modo de errores de la carga de trabajo.

• La solución puede requerir funcionalidades de enrutamiento global si la arquitectura requiere instancias de Azure OpenAI en varias regiones para aumentar la disponibilidad de los puntos de conexión de Azure OpenAI, como la capacidad de seguir atendiendo solicitudes en caso de una interrupción regional. Esta situación puede complicar aún más la topología mediante la administración de nombres de dominio completo (FQDN) adicionales, certificados TLS y más componentes de enrutamiento global.

Seguridad

Al considerar cómo una puerta de enlace de API beneficia a la arquitectura, use la lista de comprobación de revisión de diseño para la seguridad para evaluar el diseño. Debe abordar consideraciones de seguridad como las siguientes:

• El área expuesta de la carga de trabajo se incrementa al agregar la puerta de enlace. Esa área expuesta aporta consideraciones adicionales de administración de identidades y acceso (IAM) de los recursos de Azure, aumento de los esfuerzos de protección, etc.

• La puerta de enlace puede actuar como transición de límite de red entre el espacio de red del cliente y el espacio de red privado de Azure OpenAI. Aunque la puerta de enlace hace que un punto de conexión de Azure OpenAI que antes estaba accesible desde Internet sea ahora privado mediante el uso de Azure Private Link, ahora se convierte en el nuevo punto de entrada y debe protegerse adecuadamente.

• Una puerta de enlace se encuentra en una posición única para ver los datos sin procesar de la solicitud y las respuestas formuladas del modelo de lenguaje, que podrían incluir datos confidenciales de cualquiera de las fuentes. El cumplimiento de datos y el ámbito normativo ahora se extienden a este otro componente.

• Una puerta de enlace puede ampliar el ámbito de la autorización de cliente y la autenticación más allá de Microsoft Entra ID y la autenticación de clave de API, potencialmente en varios proveedores de identidades (IdP).

• Se debe tener en cuenta la soberanía de los datos en las implementaciones en varias regiones. Asegúrese de que la lógica de enrutamiento y proceso de la puerta de enlace cumple los requisitos de soberanía establecidos en la carga de trabajo.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Todas las puertas de enlace de API implementadas tienen costes en tiempo de ejecución que se deben presupuestar y tener en cuenta. Estos costes suelen aumentar al añadir características para abordar la fiabilidad, la seguridad y el rendimiento de la propia puerta de enlace junto con los costes operativos añadidos con la administración de APIOps agregada. Estos costes añadidos deben medirse en relación con el nuevo valor aportado por el sistema con la puerta de enlace. Lo ideal es llegar a un punto en el que las nuevas funcionalidades introducidas mediante el uso de una puerta de enlace superen el coste de implementar y mantener la puerta de enlace. En función de la relación de la carga de trabajo con sus usuarios, es posible que pueda cobrar por el uso.

Para ayudar a gestionar los costes al desarrollar y probar una puerta de enlace, tiene la opción de usar un punto de conexión simulado para Azure OpenAI. Por ejemplo, use la solución en el repositorio de GitHub del simulador de API de Azure OpenAI.

Excelencia operativa

Al considerar cómo una puerta de enlace de API beneficia a la arquitectura, use la lista de comprobación de revisión de diseño para la excelencia operativa para evaluar el diseño. Debe abordar consideraciones de excelencia operativa como las siguientes:

• La propia puerta de enlace debe supervisarse mediante la solución de supervisión de la carga de trabajo y potencialmente por los clientes. Esto significa que el proceso y las operaciones de la puerta de enlace deben incluirse en el modelado de estado de la carga de trabajo.

• Los procedimientos de implementación seguros ahora deben abordar la implementación de la infraestructura de la puerta de enlace de API y el código o la configuración del enrutamiento de la puerta de enlace. La solución de automatización de la infraestructura e infraestructura como código (IaC) debe tener en cuenta cómo tratar la puerta de enlace como un recurso de larga duración en la carga de trabajo.

• Debe compilar o ampliar el enfoque de APIOps para cubrir las API expuestas en la puerta de enlace.

• Las funcionalidades duplicadas que están disponibles a través de soluciones como el recurso del servicio Azure AI o la funcionalidad de distribución de carga de la zona de datos de Azure OpenAI.

Eficiencia del rendimiento

Al considerar cómo una puerta de enlace de API beneficia a la arquitectura, use la lista de comprobación de revisión de diseño para la eficiencia del rendimiento para evaluar el diseño. Debe abordar consideraciones sobre la eficiencia del rendimiento como las siguientes:

• El servicio de puerta de enlace puede introducir un cuello de botella en el rendimiento. Asegúrese de que la puerta de enlace tenga un rendimiento adecuado para administrar toda la carga simultánea y que pueda escalarse fácilmente en línea con sus expectativas de crecimiento. Asegúrese de la elasticidad de la solución para que la puerta de enlace pueda reducir el suministro, o reducción vertical, cuando la demanda es baja, como el uso en los días laborables.

• El servicio de puerta de enlace tiene que procesar cada solicitud e introduce una latencia añadida por cada invocación de la API. Debe optimizar la lógica de enrutamiento para que las solicitudes funcionen bien.

• En la mayoría de los casos, la puerta de enlace debe estar geográficamente cerca de los usuarios y las instancias de Azure OpenAI para reducir la latencia. Aunque la latencia de red suele ser un pequeño porcentaje de tiempo en las llamadas API generales a modelos de lenguaje, podría ser un factor competitivo para la carga de trabajo.

• Evalúe el impacto de la puerta de enlace en características de Azure OpenAI, como respuestas de streaming o anclaje de instancias para interacciones con estado, como la API de asistentes.

Opciones de implementación

Azure no ofrece una solución de turno diseñada específicamente para proxy de la API HTTP de Azure OpenAI u otras API de inferencia de modelos de lenguaje personalizado para cubrir todos estos escenarios. No obstante, sigue habiendo varias opciones para que el equipo de cargas de trabajo implemente, como una puerta de enlace en Azure.

Uso de Azure API Management

Azure API Management es un servicio administrado por la plataforma diseñado para descargar problemas transversales para las API basadas en HTTP. Se basa en la configuración y admite la personalización a través de su sistema de directivas de procesamiento de solicitudes entrantes y salientes. Admite réplicas de alta disponibilidad, con redundancia de zona e incluso en varias regiones a través de un único plano de control.

La mayoría de la lógica de enrutamiento y control de solicitudes de puerta de enlace deben implementarse en el sistema de directivas de API Management. Puede combinar directivas integradas específicas de Azure OpenAI, como Limitar el uso de tokens de api de Azure OpenAI o Emitir métricas para el consumo de tokens de Azure OpenAIy sus propias directivas personalizadas. El repositorio de GitHub del kit de herramientas de puerta de enlace de GenAI incluye una serie de directivas personalizadas de API Management junto con una configuración de pruebas de cargas para probar la aplicación de las directivas.

Use la guía del servicio del marco de buena arquitectura de para API Management al diseñar una solución que implique Azure API Management. Si la carga de trabajo existe como parte de una zona de aterrizaje de la aplicación, revise las instrucciones disponibles en Cloud Adoption Framework para Azure para implementar una zona de aterrizaje de Azure API Management.

El uso de Azure API Management para la implementación de la puerta de enlace suele ser el enfoque preferido para crear y utilizar una puerta de enlace de Azure OpenAI. Se prefiere porque el servicio es una oferta de plataforma como servicio (PaaS) con funcionalidades integradas enriquecidas, alta disponibilidad y opciones de red. También ofrece enfoques sólidos de APIOps para administrar las API de finalización.

Usar código personalizado

El enfoque de código personalizado requiere un equipo de desarrollo de software para crear una solución codificada personalizada e implementar esa solución en una plataforma de aplicaciones de Azure de su elección. La creación de una solución autoadministrada para controlar la lógica de la puerta de enlace puede ser una buena opción para los equipos de cargas de trabajo que se encargan de administrar el código de red y enrutamiento.

Normalmente, la carga de trabajo puede usar el proceso con el que está familiarizada, como hospedar el código de puerta de enlace en Azure App Service, Azure Container Apps o Azure Kubernetes Service.

Las implementaciones de código personalizado también se pueden usar con API Management cuando API Management se usa exclusivamente para sus principales funcionalidades de puerta de enlace de API HTTP entre los clientes y el código personalizado. De este modo, el código personalizado se conecta exclusivamente con las API HTTP de Azure OpenAI en función de la lógica de negocios necesaria.

También puede considerarse parte de este enfoque el uso de tecnología de puerta de enlace no de Microsoft, que es un producto o servicio que Azure no proporciona de forma nativa.

Arquitectura de ejemplo

Figura 2: Arquitectura de ejemplo de acceso a Azure OpenAI mediante una puerta de enlace basada en Azure API Management

Pasos siguientes

Obtenga información sobre un escenario específico en el que se usa la implementación de una puerta de enlace entre una aplicación inteligente y las implementaciones de Azure OpenAI para satisfacer los requisitos de carga de trabajo:

• Equilibrio de carga o conmutación por error entre varias instancias de back-end
• Autenticación y autorización personalizadas para aplicaciones cliente

Obtenga información sobre los métodos de Implementación del registro y la supervisión de modelos de Azure OpenAI.

Recursos relacionados

• Azure OpenAI Service
• Puerta de enlace de API en Azure API Management
• Repositorio de GitHub de Zona de aterrizaje de API Management donde se incluyen contextos de uso de IA generativa
• Kit de herramientas de la puerta de enlace de API Management
• Simulador de API de OpenAI