TrueFoundryとGCPの統合:コントロールプレーンアーキテクチャ

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Google Cloud Platform (GCP) 上で生成AIをデプロイするには、複雑なプリミティブ群のオーケストレーションが必要です。 Google Kubernetes Engine (GKE)、Cloud TPU、および Vertex AIGCPは生のコンピューティングリソースを提供しますが、これらを準拠した内部開発者プラットフォーム (IDP) に組み込むには、かなりのカスタムエンジニアリングが必要です。
TrueFoundryはインフラストラクチャオーバーレイとして機能します。当社がオーケストレーションを処理し、お客様はVPCとデータレジデンシーを制御できます。この記事では、GCPとの統合パターン、特にスプリットプレーンアーキテクチャについて詳しく説明します。 Workload Identity連携、およびTPU管理です。
デプロイモデル:スプリットプレーンアーキテクチャ
当社はスプリットプレーンアーキテクチャを使用し、管理インターフェースをお客様のワークロード実行環境から分離しています。
- コントロールプレーン: 当社のホスト型APIサーバーとダッシュボードです。メタデータ、RBAC、ジョブスケジューリングを処理します。
- コンピュートプレーン: お客様のGKEクラスター上で直接実行されるエージェントとコントローラーです。モデルの重み、顧客データ、推論を処理します。
セキュリティ境界 インバウンドファイアウォールルールは必要ありません。お客様のクラスター内のエージェントは、当社のコントロールプレーンへのセキュアなアウトバウンド専用WebSocketまたはgRPCストリームを開始します。デプロイマニフェストをポーリングし、テレメトリーをプッシュします。お客様のVPCは、外部からのイングレストラフィックに対してプライベートなままです。

図1:スプリットプレーンアーキテクチャは、顧客VPC内でデータ処理を分離します。
ネットワークトポロジー
高いパフォーマンスを実現するため、コンピュートプレーンを構成し、以下を使用します。 VPCネイティブクラスター を使用して エイリアスIP。すべてのコンピュートリソースはプライベートサブネット内に配置されます。
イングレス(推論リクエスト) アプリケーションのトラフィックは Cloud Load Balancing (通常はグローバル外部ALB)を介してVPCに入ります。ALBはTLSを終端し、リクエストを Istio Ingress Gateway GKEクラスター内で実行されているIstio Ingress Gatewayに転送します。
Private Google Access コンプライアンスを維持するため、Google API(Cloud Storage、Vertex AI)へのトラフィックは Private Google Accessを介してルーティングされます。これにより、推論ポッドとGCPマネージドサービス間のトラフィックはGoogleネットワークのバックボーン上に維持され、公衆インターネットを迂回します。
イーグレス GKEワーカーノードは、 Artifact Registryからコンテナイメージをプルするためにアウトバウンドアクセスを必要とします。このトラフィックは Cloud NAT プライベートサブネットにアタッチされたものです。

図2:イングレスとプライベート接続の詳細を示すネットワークトラフィックフロー。
IDフェデレーション
静的サービスアカウントキー(.jsonファイル)の削除を義務付けています。TrueFoundryは GKEワークロードID すべてのワークロード認証に利用しています。
認証シーケンス
- 作成: サービスをデプロイすると、Kubernetesサービスアカウント(KSA)が作成されます。
- バインディング: KSAにアノテーションを付与し、roles/iam.workloadIdentityUserバインディングを介してGoogleサービスアカウント(GSA)にバインドします。
- 交換: この GKEメタデータサーバー リクエストをインターセプトし、KSAトークンを短期間有効なGoogle Cloudアクセストークンと交換します。
- アクセス: Podはこのトークンを使用して、BigQueryやVertex AIのようなリソースに対してネイティブに(ADC)認証します。
Podが侵害された場合、影響範囲はその特定のGSAに付与されたIAMロールに厳密に限定されます。

図3:GKEワークロードID認証フロー。
コンピュート:TPUとスポット最適化
と連携します GKEノードプール をオーケストレーションします。
TPUオーケストレーション TPU上でのスケジューリングには、特定のトポロジー制約への対応が必要です。TrueFoundryは、TPUスライス(例:v4-8、v5e)にPodをスケジューリングするために必要なnodeSelectorとtolerationsを管理します。必要なドライバーとリソース制限をデプロイメントマニフェストに自動的に挿入し、低レベルのKubernetes設定を抽象化します。
スポットVM管理 バッチ処理や開発ワークロードの場合、当社は スポットVM を管理し、コストを削減します(通常、オンデマンドと比較して60~90%)。
- プロビジョニング: スポットプロビジョニングが有効なノードプールをオーケストレーションします。
- 終了処理: 30秒のプリエンプション通知を監視します。通知を検知すると、ノードをコーディングし、スケジューラーをトリガーしてPodをフォールバックのオンデマンドプールまたは代替のスポットノードに移動させます。
AIゲートウェイ:統合インターフェース
のようなモデルごとに異なるキーを管理すると Gemini Pro 運用上のオーバーヘッドが発生します。TrueFoundryは、統合されたAPIインターフェースとして機能するAIゲートウェイを提供します。
- 統合認証: ゲートウェイに対して一度認証するだけで済みます。Vertex AIとのダウンストリームのワークロードID交換は当社が処理します。
- モデル切り替え: 設定パラメータを変更するだけで、gemini proからセルフホスト型llama-3-70bに切り替え可能。コードの書き換えは不要です。
- コスト配分: プロジェクトごとにトークン使用量を記録するため、共有のVertex AIコストを社内のコストセンターに割り当てることができます。
運用比較
概要
この統合により、お客様のチームは、生のKubernetes管理における運用上の煩雑さに悩まされることなく、GCPのハードウェアの利点、特にTPUと高スループットネットワークを最大限に活用できます。TrueFoundryは、お客様のインフラストラクチャの能力を飛躍的に高めます。GKEオーケストレーションの複雑さを抽象化しつつ、お客様はセキュリティとデータレジデンシーに対する絶対的な権限を保持できます。このバランスにより、GenAIワークロードを即座に運用開始でき、インフラストラクチャを制約から競争上の速度優位性へと転換させることが可能です。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.














.webp)
.webp)


.png)

.png)














