Architecture de TrueFoundry sur Azure : plan de contrôle et intégration du calcul

Câblage d'une plateforme d'IA générative sur Microsoft Azure signifie assembler des primitives distinctes de calcul, d'identité et d'IA. Vous provisionnez la capacité brute via Azure Kubernetes Service (AKS) et les machines virtuelles Spot, gérez l'identité via Entra ID et acheminez les demandes vers Azure OpenAI. Les difficultés surviennent lorsque vos équipes chargées de l'infrastructure doivent orchestrer ces connexions manuellement pour chaque nouveau déploiement de modèle.

TrueFoundry se déploie en tant que superposition d'infrastructure dans votre abonnement Azure. Nous gérons le cycle de vie du déploiement, la fédération des identités et la mise à l'échelle automatique. Cet article décrit les modèles d'intégration exacts que nous utilisons pour connecter TrueFoundry à Azure, en couvrant le déploiement en plans divisés, les limites du réseau et les mécanismes d'identité des charges de travail.

Modèle de déploiement : architecture Split-Plane

Nous utilisons une architecture à plans divisés pour isoler l'exécution de la charge de travail de la gestion de la plateforme. Si vous créez des plateformes sur Amazon EKS, ce modèle vous semble familier : vous séparez la surface de contrôle du plan de données.

• Le plan de contrôle : Agit en tant que serveur d'API et magasin de métadonnées. Il contient les manifestes de déploiement, les configurations RBAC et les données de télémétrie.
• Le plan de calcul : S'exécute à l'intérieur de votre cluster AKS. Il comprend l'agent TrueFoundry, les contrôleurs locaux, les poids réels de votre modèle et vos GPU.

Nous connectons les deux avions à l'aide d'une connexion sécurisée, uniquement sortante grPC stream ou WebSocket. L'agent côté cluster initie la connexion au plan de contrôle pour extraire les manifestes et les journaux push. Vous n'ouvrez aucun port entrant sur vos groupes de sécurité réseau VNET. Votre réseau virtuel refuse les entrées externes depuis Internet par défaut.

‍

Figure 1 : L'architecture Split-Plane isole le traitement des données au sein du réseau virtuel du client.

Topologie du réseau et flux de trafic

Nous configurons le réseau du plan de calcul à l'aide d'Azure CNI pour une attribution IP directe au niveau du pod. Vos ressources informatiques restent dans des sous-réseaux privés.

Entrée et sortie

• Trafic entrant : Le trafic des applications atteint une passerelle d'applications Azure ou un équilibreur de charge interne standard. La passerelle met fin au protocole TLS et transmet le trafic au Passerelle d'entrée Istio fonctionnant à l'intérieur d'AKS.
• Trafic sortant : Les nœuds de travail AKS acheminent les appels sortants via une passerelle Azure NAT. Ils utilisent ce chemin pour extraire des images d'Azure Container Registry et interroger le plan de contrôle.

Intégration de terminaux privés

Pour respecter des limites de conformité strictes, nous acheminons le trafic via Azure Private Link. Les connexions de vos pods d'inférence à Azure OpenAI, Key Vault et Blob Storage passent entièrement par le backbone Microsoft.

‍

Figure 2 : Flux de trafic réseau détaillant l'entrée et la connectivité privée à Azure PaaS.

Fédération d'identités : ID de charge de travail Entra

Les secrets statiques codés en dur et les principes de service entraînent une surcharge de rotation importante. Nous authentifions les charges de travail de manière dynamique à l'aide de l'ID de charge de travail Microsoft Entra. Si vous gérez des environnements AWS, il s'agit de l'équivalent Azure de Rôles AWS IAM pour les comptes de service (IRSA).

Lorsque vous déployez un pipeline, nous exécutons cette séquence :

1. Création d'un compte de service : Nous mettons à votre disposition un Compte de service Kubernetes dans l'espace de noms de la charge de travail.
2. Fédération : Nous associons ce compte de service à une identité gérée attribuée par l'utilisateur dans Entra ID.
3. Échange de jetons : Le pod demande un jeton signé à l'AKS Émetteur OIDC. Le SDK Azure échange ce jeton contre un jeton d'accès Entra via Connexion OpenID point final.
4. Accès aux ressources : Le pod utilise ce jeton pour extraire des modèles depuis Blob Storage ou accéder à Azure OpenAI.

Nous utilisons DefaultAzureCredential dans le code de l'application. Cela limite le rayon d'explosion aux autorisations RBAC accordées à cette identité gérée spécifique.

‍

Figure 3 : Le flux d'authentification d'Entra Workload ID.

Orchestration informatique : intégration de machines virtuelles ponctuelles

L'exécution d'une inférence en régime permanent sur des machines virtuelles à la demande entraîne souvent des coûts de référence plus élevés. Nous nous intégrons directement aux pools de nœuds AKS pour orchestrer Machines virtuelles Azure Spot (similaire à l'utilisation Instances ponctuelles Amazon EC2).

Nous gérons la capacité Spot selon la logique suivante :

• Approvisionnement : Nous créons des pools de nœuds secondaires avec Priority=SPOT et Eviction-Policy=Delete.
• Gestion des expulsions : Notre contrôleur interroge le service de métadonnées d'instance Azure. Lorsque nous détectons un avis d'expulsion (un avertissement de 30 secondes), nous bouclons le nœud et déclenchons le Autoscaler de cluster Kubernetes pour replanifier le pod vers un nœud de secours à la demande.

Pour les équipes qui utilisent l'inférence par lots ou le service d'API tolérant aux pannes, cette configuration ressemble beaucoup à l'exécution Charpentier sur AWS : permet de réduire les coûts des instances de calcul jusqu'à 80 % en fonction de la flexibilité de la charge de travail.

La passerelle IA : des modèles unifiés

La gestion de clés d'API distinctes et de limites de jetons par minute (TPM) dans plusieurs régions Azure entraîne un ralentissement opérationnel. La passerelle TrueFoundry AI en fait la synthèse. Semblable au routage des demandes via Substrat rocheux d'Amazon, les développeurs ont atteint un seul point de terminaison d'API interne.

• Routage intelligent : Nous équilibrons la charge des demandes dans les régions Azure. Si le tarif de votre demande est limité dans l'est des États-Unis, Gateway essaie à nouveau de le faire pour l'Europe de l'Ouest.
• Basculement : En cas de panne d'Azure PaaS, la passerelle peut transférer le trafic vers une instance Llama 3 ou Mistral hébergée directement sur votre plan de calcul AKS.

Compatibilité de l'infrastructure en tant que code

Nous nous alignons sur les pratiques standard de GitOps et IaC. Vous approvisionnez l'environnement Azure sous-jacent à l'aide de notre solution Terraforme modules.

Votre état Terraform gère les réseaux virtuels, le cluster AKS, les émetteurs OIDC et les bases de données PostgreSQL sous-jacentes. La superposition TrueFoundry correspond simplement à ces ressources natives, ce qui permet à votre infrastructure de rester auditable et conforme.

Comparaison opérationnelle

Résumé

Le déploiement de TrueFoundry sur Azure isole l'exécution de vos calculs et de vos données pendant que nous gérons le cycle de vie des applications. Vous conservez une autorité directe sur vos réseaux virtuels, vos NSG et vos périmètres de résidence des données. Nous nous occupons de l'orchestration. En faisant abstraction du câblage complexe entre AKS, Entra ID et Azure OpenAI, nous permettons à vos équipes d'ingénierie de se concentrer sur les modèles d'expédition plutôt que sur la lutte contre l'infrastructure.

‍