Uso de una puerta de enlace delante de varias implementaciones o instancias de Azure OpenAI

Las arquitecturas de carga de trabajo que implican Azure OpenAI Service podrían ser tan sencillas como una o varias aplicaciones cliente que consumen directamente una sola implementación de modelos de Azure OpenAI directamente, pero no todas las cargas de trabajo se pueden diseñar con esta simplicidad. Entre los escenarios más complejos se incluyen topologías con varios clientes, varias implementaciones de Azure OpenAI o varias instancias de Azure OpenAI. En esas situaciones, la introducción de una puerta de enlace delante de Azure OpenAI puede ser beneficiosa para el diseño de la carga de trabajo.

Varias instancias de Azure OpenAI o implementaciones de modelos resuelven requisitos específicos en una arquitectura de carga de trabajo. Se pueden clasificar en cuatro topologías clave.

• Varias implementaciones de modelos en una sola instancia de Azure OpenAI
• Varias instancias de Azure OpenAI en una sola región y una suscripción única
• Varias instancias de Azure OpenAI en una sola región en varias suscripciones
• Varias instancias de Azure OpenAI en varias regiones

Estas topologías por sí mismas no requieren el uso de una puerta de enlace. La elección de una puerta de enlace depende de si la carga de trabajo se beneficia de su inclusión en la arquitectura. En este artículo se describen los desafíos que aborda cada una de las cuatro topologías, así como las ventajas y costes de incluir una puerta de enlace en cada topología.

Varias implementaciones de modelos en una sola instancia de Azure OpenAI

Detalles de topología para varias implementaciones de modelos

• Implementaciones de modelos de Azure OpenAI: varias
• Instancias de Azure OpenAI: una
• Suscripciones: una
• Regiones: una

Casos de uso de topología para varias implementaciones de modelos

Una topología que incluye una única instancia de Azure OpenAI, pero que contiene más de un modelo implementado simultáneamente admite los siguientes casos de uso:

• Exponer diferentes funcionalidades del modelo, como gpt-35-turbo, gpt-4 y modelos personalizados optimizados.

• Exponer diferentes versiones del modelo, como 0613, 1106 y modelos personalizados optimizados para admitir la evolución de la carga de trabajo o implementaciones azules o verdes.

• Exponer diferentes cuotas asignadas (30 000 tokens por minuto (TPM), TPM de 60 000 para admitir la limitación de consumo en varios clientes.

Introducción de una puerta de enlace para varias implementaciones de modelos

La introducción de una puerta de enlace en esta topología consiste principalmente en abstraer a los clientes de la selección automática de una instancia de modelo específica entre las implementaciones disponibles en la instancia. Una puerta de enlace permite que el control del lado servidor dirija una solicitud de cliente a un modelo específico sin necesidad de volver a implementar el código de cliente ni cambiar la configuración del cliente.

Una puerta de enlace es especialmente beneficiosa cuando no controla el código de cliente. También es beneficiosa cuando la implementación de la configuración del cliente es más compleja o arriesgada que la implementación de cambios en una configuración de enrutamiento de puerta de enlace. Puede cambiar el modelo al que apunta un cliente en función de una estrategia de lanzamiento azul/verde de las versiones del modelo, como implementar un nuevo modelo ajustado o pasar de la versión X a X+1 del mismo modelo.

La puerta de enlace también se puede usar como un único punto de entrada de API que permite a la puerta de enlace identificar el cliente. A continuación, puede determinar qué implementación de modelo se usa para atender el aviso en función de la identidad de ese cliente u otra información en la solicitud HTTP. Por ejemplo, en una solución multiinquilino, los inquilinos pueden limitarse a un rendimiento específico y la implementación de la arquitectura es una implementación de modelo por inquilino con cuotas específicas. En este caso, el enrutamiento al modelo del inquilino sería responsabilidad de la puerta de enlace en función de la información de la solicitud HTTP.

El uso de una puerta de enlace en esta topología permite el seguimiento del uso basado en el cliente. A menos que los clientes usen distintas entidades de servicio de Microsoft Entra, los registros de acceso para Azure OpenAI no podrán distinguir varios clientes. Tener una puerta de enlace delante de la implementación ofrece a la carga de trabajo una oportunidad para realizar un seguimiento del uso por cliente en varias implementaciones de modelos disponibles para admitir modelos de contracargo o visualización.

Recomendaciones para la topología de implementaciones de varios modelos

• Aunque la puerta de enlace está en condiciones de cambiar completamente qué modelo se usa, por ejemplo de gpt-35-turbo a gpt-4, ese cambio probablemente se consideraría un cambio importante para el cliente. No deje que las nuevas funcionalidades funcionales de la puerta de enlace distraigan de realizar siempre prácticas de implementación seguras para esta carga de trabajo.

• Esta topología suele ser lo suficientemente sencilla como para implementarla a través de la directiva de Azure API Management en lugar de una solución de código personalizada.

• Para admitir el uso de SDK nativos con las especificaciones publicadas de las API de Azure OpenAI, mantenga la compatibilidad de la API con la API de Azure OpenAI. Esta situación es una preocupación mayor cuando el equipo no crea todo el código de los clientes de carga de trabajo. Al decidir diseñar la API HTTP para la puerta de enlace, tenga en cuenta las ventajas de mantener la compatibilidad con la API HTTP de Azure OpenAI.

• Aunque esta topología admite técnicamente credenciales de cliente de tránsito (tokens de acceso o clave de API) para la instancia de Azure OpenAI, considere la posibilidad de implementar la terminación de credenciales y volver a establecerla. De este modo, el cliente está autorizado en la puerta de enlace y, a continuación, la puerta de enlace se autoriza a través de RBAC de Azure a la instancia de Azure OpenAI.

• Si la puerta de enlace está diseñada para usar credenciales de tránsito, asegúrese de que los clientes no puedan omitir la puerta de enlace ni ninguna restricción de modelo basada en el cliente.

• Implemente la puerta de enlace en la misma región que la instancia de Azure OpenAI.

• Implemente la puerta de enlace en un grupo de recursos dedicado en la suscripción independiente de la instancia de Azure OpenAI. Aislar la suscripción de los back-end puede ayudar a impulsar un enfoque de APIOps a través de la separación de preocupaciones.

• Implemente la puerta de enlace en una red virtual que contenga una subred para el punto de conexión privado de Azure Private Link de la instancia de Azure OpenAI. Aplique reglas de grupo de seguridad de red (NSG) a esa subred para permitir solo el acceso de la puerta de enlace a ese punto de conexión privado. No se debe permitir el acceso al resto del plano de datos a las instancias de Azure OpenAI.

Motivos para evitar una puerta de enlace para varias implementaciones de modelos

Si controlar la configuración de los clientes es tan fácil o más que controlar el enrutamiento en el nivel de puerta de enlace, el impacto añadido de fiabilidad, seguridad, coste, mantenimiento y rendimiento de la puerta de enlace puede que no merezca la pena el componente arquitectónico añadido.

Además, algunos escenarios de carga de trabajo podrían beneficiarse de migrar desde un enfoque de implementación de varios modelos a un enfoque de implementación de varias instancias de Azure OpenAI. Por ejemplo, considere varias instancias de Azure OpenAI si tiene varios clientes que deben usar diferentes RBAC o claves de acceso para acceder a su modelo. El uso de varias implementaciones en una sola instancia de Azure OpenAI y el control de la segmentación de identidades lógicas en el nivel de puerta de enlace es posible, pero podría ser excesivo cuando hay disponible un enfoque de segmentación de RBAC físico mediante instancias distintas de Azure OpenAI.

Varias instancias de Azure OpenAI en una sola región y una suscripción única

Detalles de topología para varias instancias en una sola región y una suscripción única

• Implementaciones de modelos de Azure OpenAI: una o varias
• Instancias de Azure OpenAI: varias
• Suscripciones: una
• Regiones: una

Casos de uso de topología para varias instancias en una sola región y una suscripción única

Una topología que incluye varias instancias de Azure OpenAI en una sola región y una suscripción única admite los siguientes casos de uso:

• Habilita los límites de segmentación de seguridad, como la clave o RBAC por cliente.

• Habilita un modelo de contracargo sencillo para diferentes clientes

• Habilita una estrategia de conmutación por error para la disponibilidad de Azure OpenAI, como una interrupción de la plataforma que afecta a una instancia específica, una configuración incorrecta de red o una implementación eliminada accidentalmente.

• Habilita una estrategia de conmutación por error para la disponibilidad de cuota de Azure OpenAI, como el emparejamiento de una instancia basada en PTU y una instancia basada en el consumo para el desbordamiento.

Introducción de una puerta de enlace para varias instancias en una sola región y suscripción

Es posible que un modelo no sea accesible para un cliente por varias razones. Estos motivos incluyen interrupciones en Azure OpenAI Service, solicitudes de limitación de Azure OpenAI o problemas relacionados con las operaciones de carga de trabajo, como la configuración incorrecta de la red o una eliminación involuntaria de una implementación de modelos. Para abordar estos desafíos, debe implementar la lógica de reintento e interrupción del circuito.

Esta lógica se podría implementar en clientes o en el lado servidor de una puerta de enlace. La implementación de la lógica en una puerta de enlace abstrae la lógica de los clientes, por lo que no se repite el código y existe un único lugar para probar la lógica. Independientemente de si posee el código de cliente o no, este cambio puede aumentar la fiabilidad de la carga de trabajo.

El uso de una puerta de enlace con varias instancias de Azure OpenAI en una sola región y suscripción le permite tratar todos los back-end como implementaciones activas-activas y no solo usarlas en conmutaciones por error activas-pasivas. Puede implementar el mismo modelo basado en PTU en varias instancias de Azure OpenAI y usar la puerta de enlace para equilibrar la carga entre ellas.

Una opción que tiene un equipo de carga de trabajo al aprovisionar Azure OpenAI es decidir si el modelo de facturación y rendimiento está basado en PTU o en el consumo. Una estrategia de optimización de costes para evitar el desperdicio a través de PTU sin usar consiste en aprovisionar ligeramente la instancia de PTU e implementar también una instancia basada en el consumo a lo largo del lado. El objetivo de esta topología es que los clientes consuman primero todas las PTU disponibles y, a continuación, "expandan" a la implementación basada en el consumo para el uso por encima del límite. Esta forma de conmutación por error planeada se beneficia del mismo motivo que se mencionó en el párrafo de apertura de esta sección: mantener esta complejidad fuera del código de cliente.

Cuando una puerta de enlace está implicada, se encuentra en una posición única para capturar detalles sobre todos los clientes de implementaciones de modelos con los que interactúan. Aunque cada instancia de Azure OpenAI puede capturar su propia telemetría, si lo hace dentro de la puerta de enlace, el equipo de carga de trabajo puede publicar datos de telemetría y respuestas de error en todos los modelos consumidos en un único almacén para facilitar la creación de paneles unificados y las alertas.

Recomendaciones para la topología de varias instancias en una sola región y suscripción

• Asegúrese de que la puerta de enlace usa la información de Retry-After disponible en la respuesta HTTP de Azure OpenAI al admitir escenarios de conmutación por error en la puerta de enlace. Use esa información autoritativa para controlar la implementación del disyuntor. No pulse continuamente un punto de conexión que devuelva 429 Too Many Requests. En su lugar, interrumpa el circuito para esa instancia del modelo.

• Intentar predecir eventos de limitación antes de que se produzcan mediante el seguimiento del consumo del modelo a través de solicitudes anteriores es posible en la puerta de enlace, pero se detecta con casos perimetrales. En la mayoría de los casos, es mejor no intentar predecir, sino usar códigos de respuesta HTTP para impulsar decisiones futuras de enrutamiento.

• Cuando se realiza la conmutación por error o round robin a un punto de conexión diferente, incluido el desbordamiento de PTU en el consumo, asegúrese siempre de que esos puntos de conexión usen el mismo modelo en la misma versión. Por ejemplo, no conmute por error de gpt-4 a gpt-35-turbo o desde la versión X a la versión X+1 o el equilibrio de carga entre ellos. Este cambio de versión puede provocar un comportamiento inesperado en los clientes.

• El equilibrio de carga y la lógica de conmutación por error se pueden implementar en las directivas de Azure API Management. Es posible que pueda proporcionar un enfoque más sofisticado mediante una solución de puerta de enlace basada en código, pero API Management es suficiente para este caso de uso.

• Implemente la puerta de enlace en la misma región que la instancia de Azure OpenAI.

• Implemente la puerta de enlace en un grupo de recursos dedicado en la suscripción independiente de las instancias de Azure OpenAI. Tener la puerta de enlace aislada de los back-end puede ayudar a impulsar un enfoque de APIOps a través de la separación de preocupaciones.

• Coloque todos los puntos de conexión privados de Private Link de la instancia de Azure OpenAI en una sola subred de la red virtual de la puerta de enlace. Aplique reglas de NSG a esa subred para permitir solo el acceso de la puerta de enlace a esos puntos de conexión privados. No se debe permitir el acceso al resto del plano de datos a las instancias de Azure OpenAI.

• Para simplificar la lógica en el código de enrutamiento de la puerta de enlace, use el mismo nombre de implementación del modelo para minimizar la diferencia entre las rutas HTTP. Por ejemplo, el nombre del modelo gpt4-v1 se puede usar en todas las instancias de carga equilibrada o de desbordamiento, tanto si se basa en el consumo o en PTU.

Motivos para evitar una puerta de enlace para varias instancias en una sola región y suscripción

Una puerta de enlace en sí no mejora la capacidad de contracargo de modelos en distintos clientes para esta topología específica. En esta topología, se podría conceder acceso a los clientes a sus propias instancias dedicadas de Azure OpenAI, lo que admitiría la capacidad del equipo de carga de trabajo para realizar el contracargo o la visualización. Este modelo admite perímetros de red e identidad únicos, por lo que no es necesario introducir una puerta de enlace específicamente para la segmentación.

Si tiene algunos clientes en el área en que controla el código y los clientes se pueden actualizar fácilmente, la lógica que tendría que compilar en la puerta de enlace podría agregarse directamente al código. Considere la posibilidad de usar el enfoque de puerta de enlace para la conmutación por error o el equilibrio de carga principalmente cuando no posee el código de cliente o existe demasiada complejidad para que los clientes la controlen.

Varias instancias de Azure OpenAI en una sola región en varias suscripciones

Detalles de topología para varias instancias de Azure OpenAI en una sola región en varias suscripciones

• Implementaciones de modelos de Azure OpenAI: una o varias
• Instancias de Azure OpenAI: varias
• Suscripciones: varias
• Regiones: una

Casos de uso de topología para varias instancias de Azure OpenAI en una sola región en varias suscripciones

Una topología que incluye varias instancias de Azure OpenAI en una sola región en varias suscripciones admite los siguientes casos de uso:

• Incluye todos los casos de uso enumerados para varias instancias de Azure OpenAI en una sola región y una suscripción única.

• Permite obtener más cuotas basadas en el consumo, ya que el límite de la suscripción es un factor disponible para el modelo de consumo. Puede usar esta cuota adicional para admitir un consumo muy simultáneo.

Introducción de una puerta de enlace para varias instancias en una sola región y varias suscripciones

Las mismas razones que se tratan en Introducción de una puerta de enlace para varias instancias en una sola región y suscripción se aplican a esta topología.

Además de esos motivos, agregar una puerta de enlace en esta topología también admite un equipo centralizado que proporciona un modelo de "Azure OpenAI como servicio" para su organización. Dado que una cuota basada en el consumo está enlazada a la suscripción, un equipo centralizado que proporciona servicios de Azure OpenAI que usan el modelo basado en el consumo tiene que implementar instancias de Azure OpenAI en varias suscripciones para obtener la cuota necesaria. La lógica de la puerta de enlace sigue siendo en gran medida la misma.

Recomendaciones para la topología de varias instancias en una sola región y varias suscripciones

• Lo ideal sería que todas las suscripciones estuvieran respaldadas por el mismo inquilino de Microsoft Entra para admitir la coherencia en RBAC de Azure y Azure Policy.

• Implemente la puerta de enlace en la misma región que la instancia de Azure OpenAI.

• Implemente la puerta de enlace en una suscripción dedicada independiente de las instancias de Azure OpenAI. Esto ayuda a aplicar una coherencia para abordar las instancias de Azure OpenAI y proporciona una segmentación lógica de tareas entre las implementaciones de Azure OpenAI y su enrutamiento.

• Al enrutar solicitudes desde la puerta de enlace entre suscripciones, asegúrese de que se puede acceder a los puntos de conexión privados. Puede usar el enrutamiento transitivo a través de un centro a puntos de conexión privados para los back-end en sus respectivos radios. Es posible que pueda exponer puntos de conexión privados para los servicios de Azure OpenAI directamente en la suscripción de puerta de enlace mediante conexiones de Private Link entre suscripciones. Se prefieren las conexiones de vínculo privado entre suscripciones si la arquitectura y la organización admiten este enfoque.

Motivos para evitar una puerta de enlace para varias instancias en una sola región y varias suscripciones

Todas las razones para evitar una puerta de enlace para varias instancias en una sola región y suscripción se aplican a esta topología.

Varias instancias de Azure OpenAI en varias regiones

Detalles de topología para varias instancias de Azure OpenAI en varias regiones

• Implementaciones de modelos de Azure OpenAI: varias
• Instancias de Azure OpenAI: varias
• Suscripciones: una o varias
• Regiones: varias

Casos de uso de topología para varias instancias de Azure OpenAI en varias regiones

Una topología que incluye varias instancias de Azure OpenAI distribuidas entre dos o más regiones de Azure admite los siguientes casos de uso:

• Incluye todos los casos de uso enumerados para varias instancias de Azure OpenAI en una sola región en varias suscripciones.

• Habilita una estrategia de conmutación por error para la disponibilidad del servicio, como el uso de pares entre regiones.

• Habilita un diseño de residencia y cumplimiento de datos.

• Habilita la disponibilidad de modelos mixtos. Algunas regiones tienen diferentes modelos y diferentes cuotas disponibles para los modelos.

Aunque técnicamente no son diferentes regiones de Azure, esta topología también es aplicable cuando tiene un modelo de inteligencia artificial expuesto en una situación entre entornos, como el entorno local o en otra nube.

Introducción de una puerta de enlace para varias instancias en varias regiones

En el caso de las arquitecturas críticas para la empresa que deben sobrevivir a una interrupción regional completa, una puerta de enlace unificada global ayuda a eliminar la lógica de conmutación por error del código de cliente. Esta implementación requiere que la puerta de enlace no se vea afectada por una interrupción regional.

El equilibrio de carga entre regiones no es habitual, pero podría utilizarse estratégicamente para combinar cuotas disponibles en implementaciones basadas en el consumo entre regiones. Este escenario no requiere que la puerta de enlace siga sin verse afectada por una interrupción regional, pero se recomienda para lograr una fiabilidad máxima de la carga de trabajo.

Uso de Azure API Management (implementación en una sola región)

En esta topología, Azure API Management se usa específicamente para la tecnología de puerta de enlace. Aquí, API Management se implementa en una sola región. Desde esa instancia de puerta de enlace, se realiza el equilibrio de carga activo-activo entre regiones. Las directivas de la puerta de enlace hacen referencia a todas las instancias de Azure OpenAI. La puerta de enlace requiere una línea de visión de red para cada back-end entre regiones, ya sea a través del emparejamiento de red virtual entre regiones o puntos de conexión privados. Las llamadas de esta puerta de enlace a una instancia de Azure OpenAI en otra región incurren en más cargos de latencia de red y salida.

La puerta de enlace debe respetar las señales de limitación y disponibilidad de las instancias de Azure OpenAI y quitar los back-end defectuosos del grupo hasta que sea seguro volver a agregar la instancia de Azure OpenAI con errores o limitada. La puerta de enlace debe reintentar la solicitud actual en otra instancia de back-end del grupo tras un error, antes de volver a devolver un error de puerta de enlace. La comprobación de estado de la puerta de enlace debe indicar un estado incorrecto cuando no haya ninguna instancia de Azure OpenAI de back-end disponible.

Dado que esta topología presenta un único punto de error (la puerta de enlace) la utilidad de esta arquitectura específica es bastante limitada. Este modelo se presta bien a la facturación basada en el consumo en Azure OpenAI, cuando predecir la asignación de PTU podría resultar demasiado difícil.

Variante activa-pasiva

Este modelo también se puede usar para proporcionar un enfoque activo-pasivo para controlar específicamente los errores regionales de solo Azure OpenAI. En este modo, el tráfico normalmente fluye desde la puerta de enlace a la instancia de Azure OpenAI en la misma región que el servicio API Management. Esa instancia de Azure OpenAI controlaría todo el flujo de tráfico esperado sin errores regionales. Podría basarse en PTU o en el consumo, en función del modelo de facturación preferido. En el caso de un error regional de solo Azure OpenAI, la puerta de enlace puede redirigir el tráfico a otra región con Azure OpenAI ya implementado en modo de consumo.

Uso de Azure API Management (implementación en varias regiones)

Para mejorar la fiabilidad de la arquitectura anterior basada en Azure API Management, API Management admite la implementación de una instancia en varias regiones de Azure. Esta opción de implementación proporciona un único plano de control, a través de una sola instancia de API Management, pero proporciona puertas de enlace replicadas en las regiones de su elección. En esta topología, se implementan componentes de puerta de enlace en cada región que contiene instancias de Azure OpenAI que proporcionan una arquitectura de puerta de enlace activa-activa.

Directivas como la lógica de enrutamiento y de control de solicitudes se replican en cada puerta de enlace individual. Toda la lógica de directiva debe tener lógica condicional en la directiva para asegurarse de que llama a instancias de Azure OpenAI en la misma región que la puerta de enlace actual. Para obtener más información, consulte Enrutamiento de llamadas API a servicios back-end regionales. A continuación, el componente de puerta de enlace requiere una línea de visión de red solo para las instancias de Azure OpenAI en su propia región, normalmente a través de puntos de conexión privados.

API Management ofrece el enrutamiento de nombres de dominio completo (FQDN) global de fábrica en función de la latencia más baja. Use esta funcionalidad integrada basada en el rendimiento para las implementaciones de puerta de enlace activa-activa. Esta funcionalidad integrada ayuda a abordar el rendimiento y controla una interrupción de la puerta de enlace regional. El enrutador global integrado también admite pruebas de recuperación ante desastres, ya que las regiones se pueden simular mediante la deshabilitación de puertas de enlace individuales. Asegúrese de que los clientes respetan el período de vida (TTL) en el FQDN y tienen la lógica de reintento adecuada para controlar una conmutación por error de DNS reciente.

Si necesita introducir un firewall de aplicaciones web en esta arquitectura, puede seguir usando la solución de enrutamiento de FQDN integrada como origen de back-end para el enrutador global que implementa un cortafuegos de aplicaciones web. El enrutador global delegaría la responsabilidad de conmutación por error a API Management. También puede usar los FQDN de puerta de enlace regional como miembros del grupo de back-end. En esa última arquitectura, use el punto de conexión /status-0123456789abcdef integrado en cada puerta de enlace regional u otro punto de conexión de API de mantenimiento personalizado para admitir la conmutación por error regional. Si no está seguro, comience con el enfoque de FQDN de back-end de origen único.

Esta arquitectura funciona mejor si puede tratar las regiones como totalmente disponibles o totalmente no disponibles. Esto significa que si la puerta de enlace de API Management o la instancia de Azure OpenAI no está disponible, quiere que el tráfico de cliente ya no se enrute a la puerta de enlace de API Management en esa región. A menos que se realice otro aprovisionamiento, si la puerta de enlace regional sigue aceptando tráfico mientras Azure OpenAI no está disponible, el error debe propagarse al cliente. Para evitar el error de cliente, consulte un enfoque mejorado en Puerta de enlace activa-activa más variante de Azure OpenAI activa-pasiva.

Si una región experimenta una interrupción de la puerta de enlace de API Management o está marcada como incorrecta, las regiones disponibles restantes deben absorber el 100 % del tráfico de esas otras regiones. Esto significa que necesita sobreaprovisionar instancias de Azure OpenAI basadas en PTU para controlar la nueva ráfaga de tráfico o usar un enfoque activo-pasivo para la conmutación por error. Use la calculadora de capacidad de Azure OpenAI para planificar la capacidad.

Asegúrese de que el grupo de recursos que contiene Azure API Management esté en la misma ubicación que la propia instancia de API Management para reducir el radio de impacto de una interrupción regional relacionada que afecta a la capacidad de acceder al proveedor de recursos para las puertas de enlace.

Puerta de enlace activa-activa más variante de Azure OpenAI activa-pasiva

En la sección anterior se trató la disponibilidad de la puerta de enlace proporcionando una topología de puerta de enlace activa-activa. Esta topología combina la puerta de enlace activa-activa con una topología de Azure OpenAI activa-pasiva rentable. Agregar lógica activa-pasiva a la puerta de enlace para conmutar por error a una implementación de Azure OpenAI basada en el consumo desde una implementación basada en PTU puede aumentar significativamente la fiabilidad de la carga de trabajo. Este modelo sigue permitiendo a los clientes usar la solución de enrutamiento de FQDN integrada de API Management para el enrutamiento basado en el rendimiento.

Uso de una puerta de enlace codificada personalizada

Si las reglas de enrutamiento por puerta de enlace son demasiado complejas para que el equipo las considere razonables como directivas de API Management, debe implementar y administrar su propia solución. Esta arquitectura debe ser una implementación en varias regiones de la puerta de enlace, con una unidad de escalado de alta disponibilidad por región. Debe abordar esas implementaciones con Azure Front Door (Anycast) o Azure Traffic Manager (DNS), normalmente mediante el enrutamiento basado en latencia y las comprobaciones de estado adecuadas de la disponibilidad de la puerta de enlace.

Use Azure Front Door si necesita un firewall de aplicaciones web y acceso a internet público. Use Traffic Manager si no necesita un firewall de aplicaciones web y el TTL de DNS es suficiente. Al tratar las instancias de puerta de enlace con Azure Front Door (o cualquier proxy inverso), asegúrese de que no se puede omitir la puerta de enlace. Haga que las instancias de puerta de enlace solo estén disponibles a través del punto de conexión privado al usar Azure Front Door y agregue la validación del encabezado HTTP X_AZURE_FDID en la implementación de la puerta de enlace.

Coloque los recursos por región que se usan en la puerta de enlace personalizada en grupos de recursos por región. Esto reduce el radio de impacto de una interrupción regional relacionada que afecta a la capacidad de acceder al proveedor de recursos para los recursos de puerta de enlace de esa región.

También puede considerar la posibilidad de abordar la implementación lógica de la puerta de enlace con API Management, para obtener las demás ventajas de API Management, como TLS, autenticación, comprobación de estado o equilibrio de carga round robin. Esto desplaza los problemas de API comunes fuera del código personalizado de la puerta de enlace y deja que esta se ocupe específicamente de la instancia de Azure OpenAI y el enrutamiento de implementación del modelo.

Para el cumplimiento de residencia de datos, asegúrese de que cada límite geopolítico tenga su propia implementación aislada de esta arquitectura y que los clientes solo puedan llegar a su punto de conexión autorizado.

Motivos para evitar una puerta de enlace para varias instancias en varias regiones

No implemente una puerta de enlace unificada entre regiones geopolíticas cuando se requiera residencia y cumplimiento de datos. Esto infringiría los requisitos de residencia de datos. Use puertas de enlace direccionables individualmente por región y siga las instrucciones de una de las secciones anteriores.

Si no se espera que los clientes conmuten por error entre regiones tiene la posibilidad de dar a los clientes una puerta de enlace específica para utilizar, use en su lugar varias puertas de enlace, una por región, y siga las instrucciones de una de las secciones anteriores. No vincule la disponibilidad de otras regiones a la región que contiene la puerta de enlace como un único punto de error.

No implemente una puerta de enlace unificada si el modelo y la versión no están disponibles en todas las regiones expuestas por la puerta de enlace. Los clientes deben enrutarse al mismo modelo y a la misma versión del modelo. Para las puertas de enlace de conmutación por error y con equilibrio de carga en varias regiones, debe elegir un modelo común y una versión del modelo que estén disponibles en todas las regiones implicadas. Para obtener más información, consulte Disponibilidad de modelo. Si no puede estandarizar el modelo y la versión del modelo, la ventaja de la puerta de enlace es limitada.

Recomendaciones generales

Independientemente de la topología que necesite la carga de trabajo, hay algunas recomendaciones transversales que se deben tener en cuenta al compilar la solución de puerta de enlace.

Interacciones con estado

Cuando los clientes usan las características con estado de Azure OpenAI, como la API de asistentes, debe configurar la puerta de enlace para anclar un cliente a un back-end específico durante esa interacción. Esto se puede lograr almacenando datos de instancia en una cookie. En estos escenarios, considere la posibilidad de devolver una respuesta de API de Azure OpenAI, como 429, a un cliente anclado en lugar de redirigirle a una instancia de Azure OpenAI diferente. Esto permite al cliente controlar explícitamente la falta de disponibilidad repentina frente a ocultarla y enrutarlo a una instancia de modelo que no tiene historial.

Comprobaciones de estado de la puerta de enlace

Hay dos perspectivas de comprobación de estado que hay que tener en cuenta, independientemente de la topología.

Si la puerta de enlace se basa en round robin o realiza estrictamente la conmutación por error de disponibilidad del servicio, querrá una manera de quitar el estado de disponibilidad de una instancia de Azure OpenAI (o modelo). Azure OpenAI no proporciona ningún tipo de punto de conexión de comprobación de estado para saber de forma preventiva si está disponible para controlar las solicitudes. Puede enviar transiciones sintéticas, pero eso consume capacidad del modelo. A menos que tenga otro origen de señal fiable para la instancia de Azure OpenAI y la disponibilidad del modelo, es probable que la puerta de enlace suponga que la instancia de Azure OpenAI está activa y, a continuación, controle los códigos de estado HTTP 429, 500, 503 como una señal para interrumpir el circuito para las solicitudes futuras en esa instancia o modelo durante un tiempo. Para situaciones de limitación, respete siempre los datos del encabezado Retry-After que se encuentran en las respuestas de la API de Azure OpenAI para los códigos de respuesta 429 en la lógica de interrupción del circuito. Si utiliza Azure API Management, evalúe el uso de la funcionalidad del disyuntor integrado.

Es posible que los clientes o el equipo de operaciones de carga de trabajo deseen tener una comprobación de estado expuesta en la puerta de enlace para sus propios fines de enrutamiento o introspección. Si usa API Management, es posible que el valor predeterminado /status-0123456789abcdef no sea lo suficientemente detallado, ya que se dirige principalmente a la instancia de puerta de enlace de API Management, no a los back-end. Considere la posibilidad de agregar una API de comprobación de estado dedicada que pueda devolver datos significativos a clientes o sistemas de observabilidad en la disponibilidad de la puerta de enlace o rutas específicas de la puerta de enlace.

Procedimientos de implementación seguros

Puede usar implementaciones de puerta de enlace para orquestar implementaciones azules o verdes de modelos actualizados. Los modelos de Azure OpenAI se actualizan con nuevas versiones de modelo y nuevos modelos, y es posible que tenga nuevos modelos ajustados.

Después de probar los efectos de un cambio en preproducción, evalúe si los clientes de producción deben "transicionar" a la nueva versión del modelo o, en su lugar, cambiar el tráfico. El patrón de puerta de enlace descrito anteriormente permite que el back-end tenga ambos modelos implementados simultáneamente. La implementación simultánea de modelos proporciona a la puerta de enlace la capacidad de redirigir el tráfico en función de la práctica de implementación segura del equipo de carga de trabajo de implementación incremental.

Incluso si no usa implementaciones azules o verdes, el enfoque de APIOps de la carga de trabajo debe definirse y automatizarse suficientemente con la velocidad de cambio de la instancia de back-end y las implementaciones de modelos.

Implementación suficiente

Muchos de los escenarios presentados en este artículo ayudan a aumentar el objetivo de nivel de servicio (SLO) potencial de la carga de trabajo reduciendo la complejidad del cliente e implementando técnicas fiables de autoconservación. Otros mejoran la seguridad de la carga de trabajo moviendo controles de acceso a modelos específicos fuera de Azure OpenAI. Asegúrese de que la introducción de la puerta de enlace no acabe yendo en contra de estos objetivos. Comprenda los riesgos de agregar un único punto de error, ya sea por errores de servicio o por problemas de configuración causados por personas en la puerta de enlace, por una lógica de enrutamiento compleja o por los riesgos de exponer más modelos de lo previsto a clientes no autorizados.

Soberanía de los datos

Los distintos enfoques activo-activo y activo-pasivo deben evaluarse desde una perspectiva de cumplimiento de residencia de datos para la carga de trabajo. Muchos de estos patrones serían aplicables a la arquitectura de la carga de trabajo si las regiones implicadas permanecen dentro del límite geopolítico. Para admitir este escenario, debe tratar los límites geopolíticos como sellos aislados y aplicar el control activo-activo o activo-pasivo exclusivamente dentro de ese sello.

En concreto, cualquier enrutamiento basado en el rendimiento debe examinarse minuciosamente para el cumplimiento de la soberanía de datos. En escenarios de soberanía de datos, no se puede prestar servicio a clientes con otra geografía y seguir cumpliendo la normativa. Todas las arquitecturas de puerta de enlace que implican la residencia de datos deben exigir que los clientes usen solo puntos de conexión en su región geopolítica. Los clientes deben tener bloqueado el uso de otros puntos de conexión de puerta de enlace y la propia puerta de enlace no debe infringir la confianza del cliente al hacer una solicitud intergeopolítica. La forma más fiable de implementar esta segmentación es crear la arquitectura en torno a una puerta de enlace totalmente independiente y de alta disponibilidad por región geopolítica.

Autorización de Azure OpenAI

La puerta de enlace debe autenticarse con todas las instancias de Azure OpenAI con las que interactúa. A menos que haya diseñado la puerta de enlace para realizar la autenticación de tránsito, la puerta de enlace debe usar una identidad administrada para sus credenciales. Por lo tanto, cada instancia de Azure OpenAI debe configurar RBAC con privilegios mínimos para las identidades administradas de las puertas de enlace. Para las arquitecturas de conmutación por error activa-activa, asegúrese de que la identidad de la puerta de enlace tiene permisos equivalentes en todas las instancias de Azure OpenAI implicadas.

Azure Policy

La coherencia entre las implementaciones de modelos y las instancias de Azure OpenAI es importante en situaciones de enfoque activo-activo o activo-pasivo. Use Azure Policy para ayudar a aplicar la coherencia entre las distintas instancias de Azure OpenAI o las implementaciones de modelos. Si las directivas integradas para Azure OpenAI no son suficientes para garantizar la coherencia entre ellas, considere la posibilidad de crear o usar directivas personalizadas creadas por la comunidad.

Redundancia de puerta de enlace

Aunque no es específico de varios back-end, la implementación de puerta de enlace de cada región siempre debe crearse con redundancia y estar altamente disponible dentro de la unidad de escalado. Elija regiones con zonas de disponibilidad y asegúrese de que la puerta de enlace se distribuye entre ellas. Implemente varias instancias de la puerta de enlace para que un único punto de error esté limitado a una interrupción regional completa, no debido al error de una sola instancia de proceso en la puerta de enlace. Para API Management, implemente dos o más unidades en dos o más zonas. En el caso de las implementaciones de código personalizadas, implemente al menos tres instancias con una distribución de mejor esfuerzo entre zonas de disponibilidad.

Implementaciones de puerta de enlace

Azure no ofrece una solución de turno ni una arquitectura de referencia para crear una puerta de enlace de este tipo que se centre en el enrutamiento del tráfico entre varios back-end. Como se mencionó en el artículo de introducción, el equipo de cargas de trabajo es el que debe crear y utilizar esta puerta de enlace. A continuación se muestran algunos ejemplos de implementaciones compatibles con la comunidad que abarcan algunos de los casos de uso mencionados anteriormente. Considere la posibilidad de hacer referencia a estos ejemplos de GitHub al crear su propia prueba de concepto.

Implementación	Ejemplo
Azure API Management	Equilibrio de carga inteligente para Azure OpenAI mediante Azure API Management - Este repositorio de GitHub contiene código de directiva de ejemplo e instrucciones para implementarlo en la suscripción. Escalado de Azure OpenAI mediante Azure API Management - Este repositorio de GitHub contiene código de directiva de ejemplo e instrucciones para PTU y desbordamiento de consumo. El kit de herramientas de puerta de enlace de GenAI incluye unas directivas de API Management de ejemplo junto con una configuración de pruebas de cargas para probar la aplicación de las directivas.
Código personalizado	Equilibrio de carga inteligente para Azure OpenAI mediante Azure Container Apps Este repositorio de GitHub contiene código de C# de ejemplo e instrucciones para compilar el contenedor e implementarlo en la suscripción.

Cloud Adoption Framework para Azure también contiene instrucciones sobre la implementación de una zona de aterrizaje de Azure API Management para escenarios de inteligencia artificial generativa, incluido este escenario de varios back-end. Si la carga de trabajo existe en una zona de aterrizaje de la aplicación, asegúrese de consultar esta guía para conocer las consideraciones y recomendaciones de implementación.

Pasos siguientes

Tener una implementación de puerta de enlace para la carga de trabajo proporciona ventajas más allá de la ventaja táctica de enrutamiento de varios back-end que se describe en este artículo. Obtenga información sobre otros desafíos clave que puede resolver una puerta de enlace.

Recursos relacionados

• Azure OpenAI Service
• Puerta de enlace de API en Azure API Management