Arquitectura de TrueFoundry en Azure: integración de cómputos y plano de control

Conectando una plataforma de IA generativa en Microsoft Azure significa unir distintas primitivas de computación, identidad e IA. Usted aprovisiona capacidad bruta mediante Azure Kubernetes Service (AKS) y máquinas virtuales de Spot, gestiona la identidad mediante Entra ID y dirige las solicitudes a Azure OpenAI. La dificultad se agrava cuando los equipos de infraestructura tienen que organizar estas conexiones manualmente para cada implementación de un nuevo modelo.

TrueFoundry se implementa como una superposición de infraestructura dentro de su suscripción de Azure. Nos ocupamos del ciclo de vida de la implementación, la federación de identidades y el escalado automático. En esta publicación se detallan los patrones de integración exactos que utilizamos para conectar TrueFoundry con Azure, y se abordan la implementación en planos divididos, los límites de la red y la mecánica de identidad de las cargas de trabajo.

Modelo de implementación: arquitectura de plano dividido

Usamos una arquitectura de plano dividido para aislar la ejecución de la carga de trabajo de la administración de la plataforma. Si construyes plataformas en Amazon EKS, este modelo resulta familiar: se separa la superficie de control del plano de datos.

• El plano de control: Actúa como servidor de API y almacén de metadatos. Contiene los manifiestos de implementación, las configuraciones de RBAC y los datos de telemetría.
• El plano de cálculo: Se ejecuta dentro del clúster de AKS. Está compuesto por el agente TrueFoundry, los controladores locales y los pesos de sus modelos y GPU reales.

Conectamos los dos aviones mediante un sistema seguro y solo de salida gRPC stream o WebSocket. El agente del clúster inicia la conexión con el plano de control para extraer los manifiestos y enviar los registros. No abre ningún puerto de entrada en los grupos de seguridad de la red VNET. Su VNET niega la entrada externa desde Internet de forma predeterminada.

‍

Figura 1: La arquitectura de plano dividido aísla el procesamiento de datos dentro de la VNET del cliente.

Topología de redes y flujo de tráfico

Configuramos las redes del plano de procesamiento mediante Azure CNI para la asignación directa de IP a nivel de pod. Sus recursos informáticos permanecen en subredes privadas.

Entrada y salida

• Tráfico entrante: El tráfico de aplicaciones llega a Azure Application Gateway o a un balanceador de carga interno estándar. La puerta de enlace termina el TLS y pasa el tráfico al Puerta de enlace Istio Ingress ejecutándose dentro de AKS.
• Tráfico saliente: Los nodos de trabajo de AKS enrutan las llamadas salientes a través de una puerta de enlace NAT de Azure. Utilizan esta ruta para extraer imágenes de Azure Container Registry y sondear el plano de control.

Integración de terminales privados

Para cumplir con los estrictos límites de cumplimiento, dirigimos el tráfico a través de Azure Private Link. Las conexiones desde sus módulos de inferencia a Azure OpenAI, Key Vault y Blob Storage se dirigen completamente a la red troncal de Microsoft.

‍

Figura 2: Flujo de tráfico de red que detalla la entrada y la conectividad privada a Azure PaaS.

Federación de identidades: Ingrese Workload ID

Los secretos estáticos codificados y los directores de servicio introducen una gran sobrecarga de rotación. Autenticamos las cargas de trabajo de forma dinámica mediante el ID Entra Workload de Microsoft. Si administra entornos de AWS, este es el equivalente en Azure de Funciones de AWS IAM para cuentas de servicio (IRSA).

Cuando implementas una canalización, ejecutamos esta secuencia:

1. Creación de cuentas de servicio: Proporcionamos un Cuenta de servicio de Kubernetes en el espacio de nombres de la carga de trabajo.
2. Federación: Vinculamos esta cuenta de servicio a una identidad gestionada asignada por el usuario en Entra ID.
3. Intercambio de fichas: El pod solicita un token firmado del AKS Emisor OIDC. El SDK de Azure cambia este token por un token de acceso Entra a través del Conexión OpenID punto final.
4. Acceso a los recursos: El pod usa este token para extraer modelos de Blob Storage o acceder a Azure OpenAI.

Usamos DefaultAzureCredential en el código de la aplicación. Esto limita el radio de explosión estrictamente a los permisos de RBAC otorgados a esa identidad gestionada específica.

‍

Figura 3: El flujo de autenticación de Entra Workload ID.

Orquestación de cómputos: integración de máquinas virtuales puntuales

La ejecución de la inferencia de estado estacionario en máquinas virtuales bajo demanda suele generar costos de referencia más altos. Nos integramos directamente con los grupos de nodos de AKS para organizar Máquinas virtuales Azure Spot (similar a utilizar Instancias puntuales de Amazon EC2).

Administramos la capacidad de Spot mediante la siguiente lógica:

• Aprovisionamiento: Creamos grupos de nodos secundarios con Priority=SPOT y Eviction-Policy=Delete.
• Manejo de desalojos: Nuestro controlador sondea el servicio de metadatos de instancias de Azure. Cuando detectamos una notificación de desalojo (una advertencia de 30 segundos), acordonamos el nodo y activamos la Escalador automático de clústeres de Kubernetes para reprogramar el pod en un nodo de respaldo bajo demanda.

Para los equipos que ejecutan inferencias por lotes o servicios de API tolerantes a errores, esta configuración es muy similar a la ejecución Carpintero en AWS: puede reducir los costos de las instancias de procesamiento hasta en un 80% en función de la flexibilidad de la carga de trabajo.

The AI Gateway: unificación de modelos

La administración de distintas claves de API y límites de token por minuto (TPM) en varias regiones de Azure dificulta las operaciones. La puerta de enlace de IA de TrueFoundry abstrae esta información. Es similar a enrutar las solicitudes a través de lecho rocoso amazónico, los desarrolladores llegan a un único punto final de API interno.

• Enrutamiento inteligente: Equilibramos las solicitudes de carga en todas las regiones de Azure. Si el este de EE. UU. limita tu solicitud, el Gateway vuelve a intentarlo en Europa occidental.
• Conmutación por error: Si se produce una interrupción de Azure PaaS, la puerta de enlace puede transferir por error el tráfico a una instancia de Llama 3 o Mistral alojada directamente en su plano de procesamiento de AKS.

Infraestructura como compatibilidad de código

Nos alineamos con las prácticas estándar de GitOps e IaC. El entorno subyacente de Azure se aprovisiona mediante nuestro sistema mantenido Terraformar módulos.

Su estado de Terraform administra las VNet, el clúster AKS, los emisores de OIDC y las bases de datos PostgreSQL subyacentes. La superposición de TrueFoundry simplemente se asigna a estos recursos nativos, lo que permite que su infraestructura sea auditable y cumpla con las normas.

Comparación operativa

Resumen

La implementación de TrueFoundry en Azure aísla la ejecución de sus procesos y datos mientras nosotros administramos el ciclo de vida de las aplicaciones. Usted mantiene la autoridad directa sobre sus redes virtuales, NSG y perímetros de residencia de datos. Nosotros nos encargamos de la orquestación. Al eliminar el complejo cableado entre AKS, Entra ID y Azure OpenAI, permitimos que sus equipos de ingeniería se centren en los modelos de envío en lugar de en luchar contra la infraestructura.

‍