このドキュメントでは、Google Kubernetes Engine（GKE）を使用して複数モデルの推論サービスを作成するためのリファレンス アーキテクチャについて説明します。このアーキテクチャでは、 GKE でホストされる推論プールが GKE Inference Gateway の背後に配置されます。 このアーキテクチャには次のメリットがあります。
- すべての推論リクエストに対応する単一のインターフェース。
- 各リクエストを最も効率的に処理できるモデルと推論サーバーへのインテリジェントなルーティング。
- 認可、セキュリティ、その他のサービスの一元化。
このドキュメントは、GKE で実行される推論サーバーのデプロイの統合を担当するネットワーキング アーキテクトを対象としています。すべての推論サーバーが GKE でホストされていない場合は、 すべての バックエンドでの AI 推論モデル提供のネットワーキングをご覧ください。このドキュメントでは、アプリケーションの設計方法や個々の生成 AI モデルのデプロイ方法については説明しません。モデルのデプロイ方法については、企業で生成 AI モデルと ML モデルを構築して デプロイする をご覧ください。
このアーキテクチャは、分散型 アプリケーション のクロスクラウド ネットワークやその他の設計などのアプリケーション ネットワーキング アーキテクチャと連携します。
アーキテクチャ
次の図は、GKE でホストされる推論サーバーの前に Inference Gateway を含むアーキテクチャを示しています。Gateway は、ホストされているすべてのモデルに対して統合されたサービスを提供します。
図のアーキテクチャには、次のコンポーネントが含まれています。
- Private Service Connect 推論エンドポイント: ホストされているすべてのモデルの統合エンドポイント 。エンドユーザーは、エンドポイントの IP アドレスに推論リクエストを送信します。この図は、単一のコンシューマー Virtual Private Cloud（VPC）ネットワーク内の Private Service Connect エンドポイントを示しています。エンドポイントは、複数の VPC ネットワークまたは共有サービス VPC ネットワークでホストできます。
- Inference Gateway: Inference Gateway は GKE Gateway
を拡張して、GKE が生成 AI アプリケーションと
ワークロードを提供する方法を最適化します。モデル名に基づいて、モデルレプリカの推論プールにトラフィックをルーティングします。Gateway は、プレフィックス マッチングを使用して、レプリカプール内のトラフィックをルーティングします。プレフィックスが一致しない場合、Gateway 推論プロセッサは GPU または TPU の Prometheus 指標を使用して、プール内で最も負荷の低いレプリカを選択します。推論プロセッサは、プレフィックス キャッシュも処理します。このアーキテクチャでは、
顧客向けのアプリケーションが OpenAI
API 呼び出しを行い、
Gateway を介してモデルにアクセスします。Gateway はリージョン内部アプリケーション ロードバランサ（
gke-l7-rilb）に基づいてデプロイされるため、インターネットから直接アクセスすることはできません。- API 管理: API マネージャーは、API 認証、 セキュリティ、レート制限、割り当てトラッキング、その他の API 管理サービスを提供します。 このアーキテクチャでは Apigee を使用しますが、他のオプションもサポートしています。ロードバランサから Apigee を呼び出すために、 アーキテクチャと Terraform デプロイでは、Service Extensions トラフィック拡張機能を使用して Apigee Extension Processorを呼び出します。
- Model Armor: 推論プロンプトが推論サーバーに到達する前に安全性チェックを行う AI ガードレール システム。次に、送信レスポンスに対して安全性チェックを行います。このアーキテクチャでは、AI ガードレールに Model Armor を使用しますが、NVIDIA Nemo Guardrails などの他のオプションもサポートしています。このリファレンス アーキテクチャに付属の Terraform デプロイには、基本的な Model Armor 構成が含まれています。
- 推論プール: 推論プールには、同じモデルのレプリカが含まれます。
Gateway はプロンプトを受信すると、
HTTPRouteルックアップ を使用して、 推論プールをモデル ID に基づいて選択します。プールには初期サイズがありますが、自動スケーリングするように構成できます。 - モデルレプリカ セット: モデル レプリカは、1 つ以上の GPU または TPU にデプロイされる推論サーバーの コピーです。モデルレプリカは、シングルノードまたはマルチノードにできます。レプリカセット は、ロードバランサによってフロントエンド処理されるモデルレプリカの均一なグループです。レプリカセットがマルチノードの場合、GPU はバックエンド RDMA VPC ネットワークを介して相互に接続されます。このネットワークは、レール整列型の GPU 間ロスレス低レイテンシ ネットワーキングを提供します。
リクエスト フロー
システムは、次のように推論リクエストをルーティングします。
- エンドユーザーが OpenAI API リクエストを Private Service Connect エンドポイントに送信します。このリクエストには次のものが含まれます。
- プロンプト。
- モデル名。ホストされている推論サーバーのいずれかのモデル名と一致する必要があります。
- Private Service Connect エンドポイントは、リクエストを Inference Gateway のリージョン内部アプリケーション ロードバランサ バージョンに転送します。
- Gateway は、リクエスト本文からモデル名を抽出し、 本文ベースのルーティングを使用してリクエスト ヘッダーに挿入します。
- Gateway は、必要な API 管理サービスについて、リクエストを API 管理システムに転送します。
- Gateway は、スクリーニングのためにプロンプトを Model Armor に送信します。
- プロンプトに編集できない機密情報が含まれている場合、プロンプトはブロックされ、Model Armor はポリシー違反が検出されたことを示すレスポンスを返します。
- プロンプトに編集可能な機密情報が含まれている場合、またはプロンプトに問題がない場合、Model Armor は機密情報を編集し、プロンプトを転送します。
- Gateway は、リクエストのモデルに一致する推論プールのリストについて
HTTPRouteを参照します。このリストから、Gateway は優先度に基づいて 1 つを選択します。 - Gateway は、プール内のすべてのレプリカのプレフィックス キャッシュと現在の負荷を参照し、その情報を使用してレプリカを選択します。
- レプリカはリクエストを処理し、Gateway に返送します。
- Gateway は、承認または拒否のためにレスポンスを Model Armor に送信します。
- Gateway は、レスポンスを Private Service Connect エンドポイントに返送し、エンドユーザーに送信します。
次の図は、デプロイ例のルーティング ビューを示しています。
この例では、ユーザーが選択したモデルに応じてプロンプトが処理されます。
- Llama: システムは、Llama モデルをホストする 2 つの レプリカセット間で、これらのプロンプトを 90:10 の比率でロード バランシングします。これら 2 つのレプリカセットは、同じ方法でホストする必要はありません。たとえば、1 つのレプリカセットを Vertex AI でホストし、もう 1 つのレプリカセットを GKE でホストできます。
- LoRA-1-gemma または LoRA-2-gemma: システムは、すべてのプロンプトを 同じレプリカセットに送信します。このレプリカセットは両方のモデルを処理できます。
いずれの場合も、Gateway はプレフィックス マッチングと最小負荷の組み合わせを使用して、関連するプール内のレプリカを選択します。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Google Kubernetes Engine（GKE）: Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイ して運用するために使用できる Kubernetes サービス。
- GKE Inference Gateway: Google Kubernetes Engine Gateway を拡張したもので、生成 AI ワークロードの提供に最適化された ルーティングとロード バランシングを提供します。これにより、AI 推論ワークロードのデプロイ、管理、オブザーバビリティが簡素化されます。
- Virtual Private Cloud（VPC）: ワークロードにグローバルでスケーラブルな ネットワーキング機能を提供する仮想システム。 Google Cloud VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
- Private Service Connect: コンシューマーが VPC ネットワーク内から マネージド サービスにプライベート接続でアクセスできるようにする機能。
- Cloud Run: Google のスケーラブルなインフラストラクチャ上で コンテナを直接実行できるマネージド コンピューティング プラットフォーム。
- Apigee: API へのアクセス方法と使用方法を詳細に制御できる API 管理ツール。セキュリティ、レート制限、割り当て適用、分析を提供します。
- Model Armor: プロンプト インジェクション、センシティブ データの漏洩、有害なコンテンツから生成 AI リソースとエージェント型 AI リソースを保護するサービス。
代替案を設計する
このセクションでは、このアーキテクチャの基本前提の一部に代わる方法について説明します。
AI ガードレール
AI ガードレールには Model Armor を使用することをおすすめします。管理を一元化するには、このアーキテクチャのようにロードバランサから直接呼び出すことをおすすめします。Model Armor は、次の代替方法で実装することもできます。
- API 管理ポリシーを使用して Model Armor を呼び出す。
- レプリカにのみ Model Armor をデプロイする。
モデル エンドポイント以外に AI ガードレールを実装する場合は、必要に応じてフロントエンド ロードバランサで Model Armor を無効にできます。Model Armor を使用しない場合は、 トラフィック拡張機能を使用して、 NVIDIA NeMo Guardrailsなどの他のガードレール オファリングを デプロイできます。
API 管理
このドキュメントのアーキテクチャでは、API 管理に Apigee を使用します。これは、ロードバランサ Service Extension を使用してデプロイされます。Apigee がニーズを満たさない場合は、Service Extensions を使用して別の API 管理サービスをデプロイできます。
Service Extensions を使用して API 管理をデプロイしてもニーズを満たせない場合は、クライアント向けネットワークと API 向けネットワークをデプロイする必要があるかもしれません。このシナリオでは、API 管理サービスが 2 つのネットワーク間のブリッジとして機能します。Apigee にこれをデプロイする方法については、Apigee ネットワーキング オプションをご覧ください。
他のネットワークへの接続
このドキュメントのアーキテクチャでは、単一のコンシューマー VPC ネットワークを使用します。ただし、 Cross-Cloud Network デプロイでサービス アクセス VPC ネットワークを使用すると、Private Service Connect エンドポイントを他の多くの ネットワークと共有できます。
設計上の考慮事項
ワークロードのアーキテクチャを構築する際は、ベスト プラクティスと 推奨事項を Google Cloud Well-Architected Frameworkで検討してください。
セキュリティ、プライバシー、コンプライアンス
分散型サービス拒否攻撃（DDoS）からの保護、ウェブ アプリケーション ファイアウォール（WAF）機能、IP アドレス検査をデプロイに追加するには、 Google Cloud Armorをフロントエンド のリージョン内部アプリケーション ロードバランサに追加します。
信頼性
リージョンの障害を防ぐため、マルチリージョン デプロイ アーキタイプを使用して、デプロイを 2 つ目のリージョンにレプリケートします。Google Cloud
費用の最適化
GKE の費用最適化に関する推奨事項については、コストが最適化された Kubernetes アプリケーションを GKE で実行するための ベスト プラクティスをご覧ください。
運用効率
Inference Gateway ダッシュボードを使用して、Inference Gateway 推論リクエストのパフォーマンスをモニタリングします。ダッシュボードには、エラーと、リクエスト率、レイテンシ、飽和度などの指標が表示されます。ダッシュボードの結果を使用して、デプロイを最適化します。
パフォーマンスの最適化
GKE での推論のベスト プラクティスの概要 の推奨事項に従ってください。
デプロイ
このアーキテクチャのサンプル実装をデプロイするには、GitHub で入手できる AI 推論モデル 提供のネットワーキングの コードサンプルを使用します。
次のステップ
- 検索拡張生成（RAG）を デプロイに追加する方法については、RAG 対応生成 AI アプリケーションのプライベート接続をご覧ください。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
作成者: Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
その他の寄稿者:
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- James Duncan | ソリューション プロダクト マネージャー
- Ammett Williams | デベロッパー リレーションズ エンジニア