Architecting TrueFoundry op Azure: Control Plane- en Compute-integratie

Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
Het opzetten van een Generatieve AI-platform op Microsoft Azure betekent dat u afzonderlijke compute-, identiteits- en AI-primitieven aan elkaar moet knopen. U provisioneert ruwe capaciteit via Azure Kubernetes Service (AKS) en Spot VMs, beheert identiteit via Entra ID en routeert verzoeken naar Azure OpenAI. Wrijving ontstaat wanneer uw infrastructuurteams deze verbindingen handmatig moeten orkestreren voor elke nieuwe modeldeployment.
TrueFoundry wordt geïmplementeerd als een infrastructuuroverlay binnen uw Azure-abonnement. Wij verzorgen de deployment-levenscyclus, identiteitsfederatie en automatische schaalvergroting. Deze post legt de exacte integratiepatronen uit die we gebruiken om TrueFoundry te verbinden met Azure, inclusief de split-plane deployment, netwerkgrenzen en het mechanisme achter workloadidentiteit.
Deploymentmodel: Split-Plane Architectuur
We gebruiken een split-plane architectuur om de uitvoering van workloads te scheiden van het platformbeheer. Als u platforms bouwt op Amazon EKS, komt dit model u bekend voor: u scheidt het besturingsvlak van het datavlak.
- Het Control Plane: Fungeert als de API-server en opslag van metadata. Het bevat deployment-manifesten, RBAC-configuraties en telemetriegegevens.
- Het Compute Plane: Draait binnen uw AKS-cluster. Het bestaat uit de TrueFoundry-agent, lokale controllers en uw daadwerkelijke modelgewichten en GPU's.
We verbinden de twee vlakken via een veilige, outbound-only gRPC-stream of WebSocket. De agent aan de clusterzijde initieert de verbinding met het Control Plane om manifesten op te halen en logs te pushen. U hoeft geen inkomende poorten te openen op uw VNET Network Security Groups. Uw VNET weigert standaard externe ingress vanaf het internet.

Fig 1: De Split-Plane Architectuur isoleert gegevensverwerking binnen het VNET van de klant.
Netwerktopologie en Verkeersstroom
We configureren het netwerk van het compute plane met Azure CNI voor directe IP-toewijzing op pod-niveau. Uw compute-resources blijven in private subnetten.
Ingress en Egress
- Inkomend verkeer: Applicatieverkeer komt binnen op een Azure Application Gateway of standaard interne Load Balancer. De gateway beëindigt TLS en stuurt het verkeer door naar de Istio Ingress Gateway die binnen AKS draait.
- Uitgaand verkeer: AKS worker nodes routen uitgaande calls via een Azure NAT Gateway. Ze gebruiken dit pad om images op te halen uit Azure Container Registry en het Control Plane te pollen.
Private Endpoint-integratie
Voor strenge compliance-grenzen routen we het verkeer via Azure Private Link. Verbindingen van uw inference-pods naar Azure OpenAI, Key Vault en Blob Storage verlopen volledig via de Microsoft-backbone.

Fig 2: Netwerkverkeersstroom met details over ingress en private connectiviteit naar Azure PaaS.
Identiteitsfederatie: Entra Workload ID
Hardcoded statische geheimen en Service Principals zorgen voor een aanzienlijke rotatie-overhead. We authenticeren workloads dynamisch met behulp van Microsoft Entra Workload ID. Als u AWS-omgevingen beheert, is dit het Azure-equivalent van AWS IAM Roles for Service Accounts (IRSA).
Wanneer u een pipeline deployt, voeren we deze reeks stappen uit:
- Aanmaken van Service Account: We provisioneren een Kubernetes Service Account in de namespace van de workload.
- Federatie: We koppelen dit Service Account aan een door de gebruiker toegewezen Managed Identity in Entra ID.
- Token-uitwisseling: De pod vraagt een ondertekend token aan bij de AKS OIDC Issuer. De Azure SDK ruilt dit token om voor een Entra-toegangstoken via het OpenID Connect-endpoint.
- Toegang tot resources: De pod gebruikt dit token om modellen op te halen uit Blob Storage of Azure OpenAI aan te roepen.
We gebruiken DefaultAzureCredential in de applicatiecode. Dit beperkt de blast radius strikt tot de RBAC-machtigingen die aan die specifieke Managed Identity zijn verleend.

Fig 3: De authenticatiestroom van Entra Workload ID.
Compute-orkestratie: Spot VM-integratie
Het uitvoeren van steady-state inference op On-Demand VM's leidt vaak tot hogere basiskosten. We integreren rechtstreeks met AKS node pools om Azure Spot Virtual Machines te orkestreren (vergelijkbaar met het gebruik van Amazon EC2 Spot Instances).
We beheren Spot-capaciteit met behulp van de volgende logica:
- Provisioning: We bouwen secundaire node pools met priority=Spot en eviction-policy=Delete.
- Afhandeling van uitzettingen (evictions): Onze controller pollt de Azure Instance Metadata Service. Wanneer we een melding van uitzetting detecteren (een waarschuwing van 30 seconden), cordonen we de node af en activeren we de Kubernetes Cluster Autoscaler om de pod te herplannen naar een On-Demand fallback-node.
Voor teams die batch inference of fouttolerante API-diensten uitvoeren, kan deze opzet—net zoals het draaien van Karpenter op AWS—de kosten voor compute-instances met wel 80% verlagen, afhankelijk van de flexibiliteit van de workload.
De AI Gateway: Modellen Centraliseren
Het beheren van afzonderlijke API-sleutels en Token-Per-Minute (TPM)-limieten over meerdere Azure-regio's zorgt voor operationele vertraging. De TrueFoundry AI Gateway abstraheert dit. Vergelijkbaar met het routen van verzoeken via Amazon Bedrock, spreken ontwikkelaars één enkel intern API-endpoint aan.
- Slimme Routing: We verdelen verzoeken via load balancing over verschillende Azure-regio meegerekend. Als East US uw verzoek onderwerpt aan rate-limiting, probeert de Gateway het opnieuw via West Europe.
- Failover: Als er een Azure PaaS-storing optreedt, kan de Gateway het verkeer omleiden naar een Llama 3- of Mistral-instance die rechtstreeks op uw AKS compute plane gehost wordt.
Compatibiliteit met Infrastructure as Code
We sluiten aan bij standaard GitOps- en Infrastructure-as-code (IaC)-praktijken. U provisioneert de onderliggende Azure-omgeving met onze onderhouden Terraform-modules.
Uw Terraform-state beheert de VNET's, het AKS-cluster, de OIDC-issuers en de onderliggende PostgreSQL-databases. De TrueFoundry-overlay mapt eenvoudig naar deze native resources, waardoor uw infrastructuur auditeerbaar en compliant blijft.
Operationele Vergelijking
Samenvatting
Het deployen van TrueFoundry op Azure isoleert uw compute- en data-uitvoering terwijl wij de levenscyclus van de applicatie beheren. U behoudt de directe controle over uw VNET's, NSG's en dataresidentie-grenzen. Wij zorgen voor de orkestratie. Door de complexe verbindingen tussen AKS, Entra ID en Azure OpenAI te abstraheren, stellen we uw engineeringteams in staat zich te richten op het opleveren van modellen in plaats van te worstelen met de infrastructuur.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.















.png)

.webp)



.webp)








.webp)





