すべてのバックエンドでの AI 推論モデル提供のネットワーキング

Last reviewed 2026-05-20 UTC

このドキュメントでは、オンプレミスまたはサードパーティや などのプロバイダによってホストされている 複数の AI モデルの統合フロントエンドを作成するためのリファレンス アーキテクチャについて説明します。 Google Cloudすべての推論サーバーが Google Kubernetes Engine（GKE）でホストされている場合は、GKE での AI 推論 モデル提供の ネットワーキングをご覧ください。

このアーキテクチャは、デベロッパーがモデルごとに個別の IP アドレスを指定しなくてもモデルを選択できるように設計されています。代わりに、デベロッパーは OpenAI API リクエストをフロントエンド エンドポイントに送信します。アーキテクチャ内のシステムは、指定されたモデルをホストするバックエンドにリクエストをルーティングします。このアーキテクチャのフロントエンド ロードバランサは、次のような集中管理機能を提供します。

  • モデルのホスト方法に関係なく、すべてのモデル呼び出しに対して単一のフロントエンド エンドポイントを使用できます。
  • API 管理機能。
  • AI ガードレールのチェックポイント。
  • Service Extensions の挿入 ポイント（将来の拡張性を考慮）。

このドキュメントは、新規または既存の生成 AI モデルを単一の推論エンドポイントの背後に配置したいネットワーク管理者と生成 AI アプリケーションの管理者を対象としています。このドキュメントでは、アプリケーションの設計方法や個々の生成 AI モデルのデプロイ方法については説明しません。モデルのデプロイ方法については、企業で生成 AI モデルと機械学習モデルを構築してデプロイするをご覧ください。このアーキテクチャは、分散型アプリケーション用のクロスクラウド ネットワークなどのアプリケーション ネットワーキング アーキテクチャや、その他の設計と連携します。

アーキテクチャ

次の図は、コンシューマー ネットワーク内のエンドポイントがリージョン内部アプリケーション ロードバランサのフロントエンドを指すアーキテクチャを示しています。このロードバランサは、指定されたモデルの名前を使用して、オンプレミスまたは任意のプロバイダによってホストされているモデルレプリカセットにリクエストをルーティングします。フロントエンド ロードバランサは、ホストされているすべてのモデルに対して統合サービスを提供します。

AI 推論のネットワーキングの概要。

この図のアーキテクチャには、次のコンポーネントが含まれています。

モデルレプリカセットの構成

このアーキテクチャでは、フロントエンド ロードバランサはモデル名に基づいて特定のバックエンド サービスにトラフィックを転送します。指定されたモデルの推論サーバーは、次の表に示す構成のいずれかでホストできます。

レプリカセットのタイプ 説明 レプリカのロード バランシング
Vertex AI モデルレプリカは Vertex AI で実行されます。Vertex AI エンドポイントを Private Service Connect ネットワーク エンドポイント グループ（NEG）として公開します。フロントエンド ロードバランサは、Private Service Connect NEG を個別のモデルのバックエンドとして使用します。各モデルはバックエンド サービスとして構造化されます。 Vertex AI は内部的にスケーリングとロード バランシングを行います。 Vertex AI は、指標ベースの加重ロード バランシングと接頭辞キャッシュベースのルーティングを実行し、リソース使用率を最適化して推論を高速化します。詳細については、 エンドポイントにモデルをデプロイするをご覧ください。
GKE 推論サーバーは、GKE レプリカセット VPC ネットワーク内の GKE クラスタで Pod として実行されます。GKE 内の複数のモデルレプリカは、Inference Gateway の背後にある単一のバックエンドを形成します。Inference Gateway は、フロントエンド ロードバランサが Private Service Connect NEG を使用してアクセスする Private Service Connect エンドポイントを公開します。 Inference Gateway は、 GKE クラスタ内の推論バックエンドに対してモデル対応のロード バランシングを提供します。Inference Gateway は、該当する場合は接頭辞一致を使用します。接頭辞が一致しない場合、Inference Gateway は GPU または TPU の指標に基づいてリクエストを分散します。この構成は、水平 Pod 自動スケーリングをサポートしています。
Cloud Run 推論サーバーは Cloud Run で実行されます。 Cloud Run は、フロントエンド ロード バランサが サーバーレス NEG を使用してアクセスするエンドポイントを公開します。 Cloud Run トラフィックに基づいてレプリカ数を自動的にスケーリングします 。シングルノード レプリカのみに制限されます。
混合型 推論サーバーはオンプレミスまたは別のクラウドで実行されます。ルーティング VPC ネットワークに リージョン内部プロキシ ネットワーク ロードバランサ を構成します。このロードバランサは、フロントエンド ロードバランサが Private Service Connect NEG を使用してアクセスする Private Service Connect エンドポイントを公開します。ルーティング VPC ネットワーク内の内部ロードバランサには、オンプレミスの推論サーバーの前面にあるオンプレミスまたは他のクラウドのロードバランサの IP アドレスを指すハイブリッド NEG バックエンドがあります。 外部ロードバランサのロード バランシング メカニズムは、外部施設の管理者によって構成されます。
インターネット パブリック インターネット IP アドレスからアクセス可能な推論サーバー。 フロントエンド ロードバランサには、インターネットでホストされているモデルの IP アドレスを指す インターネット NEG バックエンドがあります。 マネージド サービス プロバイダがスケーリングを処理します。

リクエスト フロー

システムは、次のように推論リクエストをルーティングします。

  1. エンドユーザーが Private Service Connect エンドポイントに OpenAI API リクエストを送信します。このリクエストには次のものが含まれます。
    • プロンプト。
    • モデル名。ホストされている推論サーバーのいずれかのモデル名と一致する必要があります。
  2. Private Service Connect エンドポイントは、リクエストをフロントエンド内部アプリケーション ロードバランサに転送します。
  3. ロードバランサは、リクエストを Service Extensions に転送します。
  4. Service Extensions 本文ベースのルーティング コード は、リクエスト本文からモデル名を読み取り、 X-Gateway-Model-Name ヘッダーに書き込みます。
  5. ロードバランサは、Service Extensions トラフィック拡張機能のコールアウトを使用して、必要な API 管理サービスについて API 管理システムにリクエストを送信します。
  6. ロードバランサは、Service Extensions トラフィック拡張機能のコールアウトを使用して、スクリーニングのためにプロンプトを Model Armor に送信します。
    • プロンプトに編集できない機密情報が含まれている場合、プロンプトはブロックされ、Model Armor はポリシー違反が検出されたことを示すレスポンスを返します。
    • プロンプトに編集可能な機密情報が含まれている場合、またはプロンプトに問題がない場合、Model Armor は機密情報を編集してプロンプトを転送します。
  7. リクエストが Model Armor で許可されている場合、ロードバランサは URL マップを参照し、モデル名カスタム ヘッダーに基づいてリクエストをバックエンド サービスに転送します。必要に応じて、URL マップはリクエストの URL とパスを書き換えて、バックエンドに必要なものと一致させます。
  8. バックエンド サービスは、リクエストを関連付けられたレプリカセット ロードバランサに転送します。
  9. 特定の推論サービスのロードバランサは、リクエストをレプリカの 1 つに割り当てます。
  10. レプリカはリクエストを処理し、レスポンスを返します。
  11. フロントエンドのリージョン内部アプリケーション ロードバランサは、スクリーニングのためにレスポンスを Model Armor に送信します。
  12. アプリケーション ロードバランサは、レスポンスを Private Service Connect エンドポイントに返送し、エンドユーザーに送信します。

次の図は、デプロイ例のルーティング ビューを示しています。

レプリカセットのサンプリングのプロンプトのフロー。

この例では、プロンプトはユーザーが選択したモデルに応じて処理されます。

  • Gemma: すべてのプロンプトは、 Gemma モデルをホストするレプリカセットにルーティングされます。
  • Llama: システムは、Llama モデルをホストする 2 つのレプリカ セット間でこれらのプロンプトを均等にロード バランシングします。これらの 2 つのレプリカセットは、同じ方法でホストする必要はありません。たとえば、1 つのレプリカセットを Vertex AI でホストし、もう 1 つのレプリカセットを GKE でホストできます。
  • LoRA-1-gemma または LoRA-2-gemma: システムは、すべてのプロンプトを 同じレプリカセットに送信します。このレプリカセットは両方のモデルを処理できます。

使用するプロダクト

このドキュメントのリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。

  • Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサと リージョン ロードバランサのポートフォリオ。
  • 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 Extensions を使用してデプロイされます。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 アドレス検査をデプロイに追加するには、 Cloud Armorをフロントエンドの リージョン内部アプリケーション ロードバランサに追加します。
  • すべてのバックエンドに共通の認証レイヤを追加するには、 Identity-Aware Proxy（IAP）を実装して ID を確認し、認可ポリシーを適用します。
  • ウェブ アプリケーションから Vertex AI モデルにトラフィックをルーティングする場合は、認証用の ID モデルを選択する必要があります。
    • サービス アカウント ID（一般的なウェブアプリにおすすめ）: アプリケーションは IAP を介してエンドユーザーを認証しますが、 サービス ワークロード ID（ たとえば Cloud Run、 GKE、または サードパーティ ID の使用など）を使用して Vertex AI を呼び出します。 この実装では、Identity and Access Management（IAM）がエンドユーザーから抽象化されますが、どのユーザーがどのプロンプトを生成したかを追跡するには、アプリケーション レベルのロギングが必要です。
    • エンドユーザー ID のパススルー（厳格な監査可能性におすすめ）: アプリケーションはエンドユーザーの Google OAuth アクセス トークンを取得し、Authorization: Bearer ヘッダーで Vertex AI に直接渡します。 この実装では、ユーザー アクションの Cloud Audit Logs ロギングが組み込まれていますが、すべてのエンドユーザーに 権限がプロビジョニングされている必要があります（ Google Cloud IAM などroles/aiplatform.user）。

信頼性

リージョンの障害を防ぐため、マルチリージョン デプロイ アーキタイプを使用して、デプロイを 2 つ目のリージョンにレプリケートします。Google Cloud

運用効率

  • トラフィック フローをモニタリングして問題を迅速に特定して修復できるようにするには、リージョン内部アプリケーション ロードバランサに Cloud Logging ログを使用します。
  • 組織がサポートするモデルを簡単に検出できるようにするには、クエリを実行して使用可能なモデルを返すリストを実装します。たとえば、 リストモデル API 呼び出しに応答するサーバーにリストを作成できます。

パフォーマンスの最適化

デプロイ

このアーキテクチャのサンプル実装をデプロイするには、GitHub で入手できる Networking for AI Inference Model Serving のコードサンプルを使用します。

AI モデルのデプロイ方法については、次のリソースをご覧ください。

次のステップ

寄稿者

作成者: Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング

その他の寄稿者:

  • Mark Schlagenhauf | テクニカル ライター、ネットワーキング
  • James Duncan | ソリューション プロダクト マネージャー
  • Ammett Williams | デベロッパー リレーションズ エンジニア