Architektur von TrueFoundry auf Azure: Integration von Steuerungsebene und Rechenleistung

Verkabelung einer generativen KI-Plattform auf Microsoft Azure bedeutet, verschiedene Berechnungs-, Identitäts- und KI-Primitive zusammenzufügen. Sie stellen Rohkapazität über Azure Kubernetes Service (AKS) und Spot-VMs bereit, wickeln die Identität über die Entra-ID ab und leiten Anfragen an Azure OpenAI weiter. Reibungsverluste entstehen, wenn Ihre Infrastrukturteams diese Verbindungen für jede neue Modellbereitstellung manuell orchestrieren müssen.

TrueFoundry wird als Infrastruktur-Overlay in Ihrem Azure-Abonnement bereitgestellt. Wir kümmern uns um den Bereitstellungszyklus, den Identitätsverbund und die automatische Skalierung. In diesem Beitrag werden die genauen Integrationsmuster beschrieben, die wir verwenden, um TrueFoundry mit Azure zu verbinden. Dabei werden die Bereitstellung auf geteilter Ebene, Netzwerkgrenzen und die Mechanismen zur Workload-Identität behandelt.

Bereitstellungsmodell: Split-Plane-Architektur

Wir verwenden eine Split-Plane-Architektur, um die Workload-Ausführung vom Plattformmanagement zu isolieren. Wenn Sie Plattformen erstellen auf Amazon EKS, dieses Modell kommt mir bekannt vor: Sie trennen die Bedienoberfläche von der Datenebene.

• Die Kontrollebene: Fungiert als API-Server und Metadatenspeicher. Es enthält Bereitstellungsmanifeste, RBAC-Konfigurationen und Telemetriedaten.
• Die Rechenebene: Läuft in Ihrem AKS-Cluster. Es besteht aus dem TrueFoundry-Agenten, lokalen Controllern und Ihren tatsächlichen Modellgewichten und GPUs.

Wir verbinden die beiden Flugzeuge über eine sichere, nur für ausgehende Flüge gRPC Stream oder WebSocket. Der clusterseitige Agent initiiert die Verbindung zur Control Plane, um Manifeste abzurufen und Protokolle zu übertragen. Sie öffnen keine eingehenden Ports in Ihren VNET-Netzwerksicherheitsgruppen. Ihr VNET verweigert standardmäßig externen Zugriff aus dem Internet.

‍

Abbildung 1: Die Split-Plane Architecture isoliert die Datenverarbeitung im Kunden-VNET.

Netzwerktopologie und Verkehrsfluss

Wir konfigurieren das Compute Plane Networking mithilfe von Azure CNI für die direkte IP-Zuweisung auf Pod-Ebene. Ihre Rechenressourcen bleiben in privaten Subnetzen.

Ein- und Ausgang

• Eingehender Verkehr: Der Anwendungsdatenverkehr trifft auf ein Azure Application Gateway oder einen standardmäßigen internen Load Balancer. Das Gateway beendet TLS und leitet den Datenverkehr an den weiter Istio Ingress-Gateway läuft in AKS.
• Ausgehender Verkehr: AKS-Worker-Knoten leiten ausgehende Anrufe über ein Azure NAT Gateway weiter. Sie verwenden diesen Pfad, um Bilder aus Azure Container Registry abzurufen und die Control Plane abzufragen.

Integration privater Endpunkte

Aus Gründen strenger Compliance-Grenzen leiten wir den Datenverkehr über Azure Private Link weiter. Verbindungen von Ihren Inferenz-Pods zu Azure OpenAI, Key Vault und Blob Storage werden vollständig über das Microsoft-Backbone geleitet.

‍

Abbildung 2: Netzwerkverkehrsfluss, der den eingehenden und privaten Anschluss an Azure PaaS detailliert beschreibt.

Identitätsverbund: Geben Sie die Workload-ID ein

Fest codierte statische Geheimnisse und Service Principals führen zu einem erheblichen Rotationsoverhead. Wir authentifizieren Workloads dynamisch mithilfe der Microsoft Entra Workload ID. Wenn Sie AWS-Umgebungen verwalten, ist dies das Azure-Äquivalent von AWS IAM-Rollen für Servicekonten (IRSA).

Wenn Sie eine Pipeline bereitstellen, führen wir diese Sequenz aus:

1. Erstellung eines Dienstkontos: Wir bieten eine Kubernetes-Dienstkonto im Namespace des Workloads.
2. Verband: Wir verknüpfen dieses Dienstkonto mit einer vom Benutzer zugewiesenen verwalteten Identität in Entra ID.
3. Token-Austausch: Der Pod fordert ein signiertes Token vom AKS an OIDC-Emittent. Das Azure SDK tauscht dieses Token gegen ein Entra-Zugriffstoken über das OpenID Connect Endpunkt.
4. Zugriff auf Ressourcen: Der Pod verwendet dieses Token, um Modelle aus Blob Storage abzurufen oder Azure OpenAI aufzurufen.

Wir verwenden DefaultAzureCredential im Anwendungscode. Dadurch wird der Explosionsradius ausschließlich auf die RBAC-Berechtigungen beschränkt, die dieser bestimmten verwalteten Identität gewährt wurden.

‍

Abb. 3: Der Authentifizierungsablauf der Entra Workload ID.

Rechenorchestrierung: Spot-VM-Integration

Die Ausführung von Steady-State-Inferenzen auf On-Demand-VMs führt häufig zu höheren Basiskosten. Zur Orchestrierung integrieren wir direkt in AKS-Knotenpools Virtuelle Azure-Spot-Maschinen (ähnlich wie bei der Verwendung Amazon EC2-Spot-Instances).

Wir verwalten die Spot-Kapazität nach der folgenden Logik:

• Bereitstellung: Wir erstellen sekundäre Knotenpools mit priority=SPOT und Eviction-Policy=delete.
• Bearbeitung der Räumung: Unser Controller fragt den Azure Instance Metadata Service ab. Wenn wir einen Räumungsbescheid erkennen (eine 30-Sekunden-Warnung), sperren wir den Knoten ab und lösen den Kubernetes-Cluster Autoscaler um den Pod auf einen On-Demand-Fallback-Knoten umzuplanen.

Für Teams, die Batch-Inferenz oder fehlertolerante API-Serving ausführen, ist dieses Setup — ähnlich wie beim Ausführen Karpenter auf AWS — kann die Kosten für Recheninstanzen je nach Workload-Flexibilität um bis zu 80% senken.

Das KI-Gateway: Vereinheitlichung von Modellen

Die Verwaltung unterschiedlicher API-Schlüssel und Token-Per-Minute-Grenzwerte (TPM) in mehreren Azure-Regionen führt zu Betriebsbelastungen. Das TrueFoundry AI Gateway abstrahiert dies. Ähnlich wie beim Routing von Anfragen über Amazonas Bedrock, haben Entwickler einen einzigen internen API-Endpunkt erreicht.

• Intelligentes Routing: Wir verteilen Anfragen über mehrere Azure-Regionen hinweg. Wenn der Tarif für den Osten der USA Ihre Anfrage begrenzt, versucht das Gateway erneut, Westeuropa abzugleichen.
• Ausfallsicherung: Wenn ein Azure PaaS-Ausfall auftritt, kann das Gateway den Datenverkehr an eine Llama 3- oder Mistral-Instanz weiterleiten, die direkt auf Ihrer AKS-Rechenebene gehostet wird.

Infrastruktur als Code-Kompatibilität

Wir orientieren uns an den Standardpraktiken von GitOps und IaC. Sie stellen die zugrunde liegende Azure-Umgebung mithilfe unserer gepflegten Umgebung bereit Terraform Module.

Ihr Terraform-Status verwaltet die VNets, den AKS-Cluster, die OIDC-Aussteller und die zugrunde liegenden PostgreSQL-Datenbanken. Das TrueFoundry-Overlay wird einfach diesen nativen Ressourcen zugeordnet, sodass Ihre Infrastruktur überprüfbar und konform bleibt.

Operativer Vergleich

Zusammenfassung

Die Bereitstellung von TrueFoundry auf Azure isoliert Ihre Rechenleistung und Datenausführung, während wir den Anwendungslebenszyklus verwalten. Sie behalten die direkte Autorität über Ihre VNets, NSGs und Datenresidenz-Perimeter. Wir kümmern uns um die Orchestrierung. Indem wir die komplexe Verkabelung zwischen AKS, Entra ID und Azure OpenAI abstrahieren, ermöglichen wir es Ihren Entwicklungsteams, sich auf die Versandmodelle zu konzentrieren, anstatt sich mit der Infrastruktur zu befassen.

‍