So lässt sich TrueFoundry in GCP integrieren: Die Control Plane Architecture

Auf Geschwindigkeit ausgelegt: ~ 10 ms Latenz, auch unter Last
Unglaublich schnelle Methode zum Erstellen, Verfolgen und Bereitstellen Ihrer Modelle!
- Verarbeitet mehr als 350 RPS auf nur 1 vCPU — kein Tuning erforderlich
- Produktionsbereit mit vollem Unternehmenssupport
Die Bereitstellung generativer KI auf der Google Cloud Platform (GCP) erfordert die Orchestrierung einer komplexen Reihe von Grundelementen: Google Kubernetes Engine (GKE), Cloud-TPUs und Scheitelpunkt-KI. GCP liefert zwar die Rohdatenverarbeitung, aber die Einbindung dieser Daten in eine konforme Internal Developer Platform (IDP) erfordert umfangreiche kundenspezifische Entwicklungen.
TrueFoundry fungiert als Infrastruktur-Overlay. Wir kümmern uns um die Orchestrierung, sodass Sie die Kontrolle über die VPC und die Datenresidenz behalten. In diesem Beitrag werden unsere Integrationsmuster mit GCP detailliert beschrieben, insbesondere in Bezug auf die Split-Plane-Architektur. Arbeitslast-Identitätsverbundund TPU-Management.
Bereitstellungsmodell: Split-Plane-Architektur
Wir verwenden eine Split-Plane-Architektur, um die Verwaltungsschnittstelle von Ihrer Workload-Ausführungsumgebung zu isolieren.
- Die Kontrollebene: Unser gehosteter API-Server und Dashboard. Es verarbeitet Metadaten, RBAC und Auftragsplanung.
- Die Rechenebene: Agenten und Controller, die direkt auf Ihrem GKE-Cluster ausgeführt werden. Es verarbeitet Modellgewichte, Kundendaten und Inferenzen.
Sicherheitsgrenze Wir benötigen keine Firewallregeln für eingehenden Datenverkehr. Der Agent in Ihrem Cluster initiiert einen sicheren, nur ausgehenden WebSocket- oder gRPC-Stream zu unserer Control Plane. Er fragt nach Bereitstellungslisten und überträgt Telemetrie. Ihre VPC bleibt für externen eingehenden Datenverkehr privat.

Abbildung 1: Die Split-Plane-Architektur isoliert die Datenverarbeitung innerhalb der Kunden-VPC.
Netzwerktopologie
Für eine hohe Leistung konfigurieren wir die zu verwendende Rechenebene VPC-native Cluster unter Verwendung von Alias-IPs. Alle Rechenressourcen befinden sich in privaten Subnetzen.
Ingress (Inferenzanfragen) Der Anwendungsdatenverkehr gelangt in die VPC über Cloud-Lastenausgleich (in der Regel ein Global External ALB). Der ALB beendet TLS und leitet Anfragen an den weiter Istio Ingress-Gateway läuft innerhalb des GKE-Clusters.
Privater Google-Zugang Um die Einhaltung der Vorschriften zu gewährleisten, wird der Datenverkehr zu den Google-APIs (Cloud Storage, Vertex AI) über Privater Google-Zugang. Dadurch wird der Datenverkehr zwischen Inferenz-Pods und GCP-verwalteten Diensten auf dem Google-Netzwerk-Backbone gehalten und das öffentliche Internet umgangen.
Austritt GKE-Worker-Knoten benötigen ausgehenden Zugriff, um Container-Images abzurufen Artefaktregister. Wir leiten diesen Verkehr durch Cloud-NAT an die privaten Subnetze angeschlossen.

Abbildung 2: Netzwerkverkehrsfluss mit detaillierten Angaben zu eingehender und privater Konnektivität.
Identitätsverbund
Wir erzwingen die Entfernung statischer Dienstkontoschlüssel (.json-Dateien). TrueFoundry implementiert GKE-Workload-Identität für die gesamte Workload-Authentifizierung.
Die Authentifizierungssequenz
- Schöpfung: Wenn Sie einen Service bereitstellen, erstellen wir ein Kubernetes Service Account (KSA).
- Einband: Wir kommentieren den KSA, um ihn über die roles/iam.workloadIdentityUser-Bindung an ein Google-Dienstkonto (GSA) zu binden.
- Umtausch: Das GKE-Metadatenserver fängt Anfragen ab und tauscht das KSA-Token gegen ein kurzlebiges Google Cloud-Zugriffstoken aus.
- Zugriff: Der Pod verwendet dieses Token, um sich nativ (ADC) mit Ressourcen wie BigQuery oder Vertex AI zu authentifizieren.
Wenn ein Pod kompromittiert ist, ist der Explosionsradius strikt auf die IAM-Rollen beschränkt, die dieser bestimmten GSA zugewiesen wurden.

Abbildung 3: Der GKE Workload Identity-Authentifizierungsablauf.
Berechnung: TPU- und Spot-Optimierung
Wir integrieren mit GKE-Knotenpools um NVIDIA-GPUs und Cloud-TPUs zu orchestrieren.
TPU-Orchestrierung Bei der Planung auf TPUs müssen bestimmte Topologieeinschränkungen berücksichtigt werden. TrueFoundry verwaltet den NodeSelector und die Toleranzen, die für die Planung von Pods auf TPU-Slices erforderlich sind (z. B. v4-8, v5e). Wir fügen automatisch die erforderlichen Treiber und Ressourcenbeschränkungen in das Bereitstellungsmanifest ein und abstrahieren so die Kubernetes-Konfiguration auf niedriger Ebene.
Spot-VM-Verwaltung Für Batch-Verarbeitungs- oder Entwicklungsworkloads verwalten wir Spot-VMs um die Kosten zu senken (in der Regel 60-90% im Vergleich zu On-Demand).
- Bereitstellung: Wir orchestrieren Node Pools mit aktiviertem Spot-Provisioning.
- Bearbeitung von Kündigungen: Wir achten auf die 30-Sekunden-Vorkaufsmitteilung. Bei Erkennung sperren wir den Knoten ab und veranlassen den Scheduler, den Pod in einen On-Demand-Fallback-Pool oder einen alternativen Spot-Node zu verschieben.
AI Gateway: Einheitliche Oberfläche
Verwaltung verschiedener Schlüssel für Modelle wie Gemini Pro verursacht betrieblichen Aufwand. TrueFoundry bietet ein AI-Gateway, das als einheitliche API-Schnittstelle fungiert.
- Vereinheitlichte Authentifizierung: Authentifizieren Sie sich einmal gegenüber dem Gateway. Wir kümmern uns um den nachgelagerten Workload-Identitätsaustausch mit Vertex AI.
- Modellwechsel: Wechseln Sie von gemini pro zu einem selbst gehosteten llama-3-70b, indem Sie einen Konfigurationsparameter ändern. Kein Umschreiben von Code.
- Kostenzuweisung: Wir protokollieren die Token-Nutzung pro Projekt, sodass Sie die gemeinsam genutzten Vertex-KI-Kosten den internen Kostenstellen zuordnen können.
Operativer Vergleich
Zusammenfassung
Diese Integration ermöglicht es Ihrem Team, die Hardwarevorteile von GCP — insbesondere TPUs und Netzwerke mit hohem Durchsatz — voll auszuschöpfen, ohne sich in den betrieblichen Reibungen der reinen Kubernetes-Verwaltung zu verzetteln. TrueFoundry wirkt wie ein Multiplikator für Ihre Infrastruktur: Wir abstrahieren die Komplexität der GKE-Orchestrierung, während Sie die absolute Kontrolle über Sicherheit und Datenspeicherort behalten. Dieses Gleichgewicht ermöglicht es Ihnen, GEnAI-Workloads sofort zu operationalisieren und die Infrastruktur von einer Einschränkung in einen Geschwindigkeitsvorteil im Wettbewerb zu verwandeln.
TrueFoundry AI Gateway bietet eine Latenz von ~3—4 ms, verarbeitet mehr als 350 RPS auf einer vCPU, skaliert problemlos horizontal und ist produktionsbereit, während LiteLM unter einer hohen Latenz leidet, mit moderaten RPS zu kämpfen hat, keine integrierte Skalierung hat und sich am besten für leichte Workloads oder Prototyp-Workloads eignet.
Der schnellste Weg, deine KI zu entwickeln, zu steuern und zu skalieren











.png)




.png)






.webp)

.webp)



