AI推論モデル提供のネットワーキングのリファレンスアーキテクチャを紹介、推論サーバーのホスト先に合わせて2つから選択可能

「AI推論モデル提供のネットワーキング」で入口が担う役割

AI推論モデル提供のネットワーキングでは、モデルのデプロイを、推論呼び出しのフロントエンドとなる、安定し安全で信頼性の高い入口の背後に公開できます。入口が担うのは、フロントエンドに加え、ポリシーやセキュリティ、ロジックを適用する制御ゾーンの役割です。^[1]

入口の機能は、Cloud Load balancerにもInference Gatewayにも備わっています。入口のエンドポイントはTLSで安全な接続を終端し、API管理コンポーネントとの統合や、Service ExtensionsとModel Armorによる拡張と保護も可能です。

図1　推論の入口と周辺の構成要素

両方のリファレンス設計に共通する主な構成要素の1つは、コンシューマーVPCネットワーク内の接続点になるPrivate Service Connect推論エンドポイントです。トラフィックはプライベートな内部IPアドレスに届き、推論呼び出しはプライベートネットワーク内にとどまります。

両方のリファレンス設計に共通するもう1つの構成要素は、インラインのAI安全性チェックポイントとなるModel Armorです。Model Armorは、プロンプトや出力をプロンプトインジェクションや機密データ漏えいに対して検査します。

Apigee API Managementは両方のリファレンス設計で任意の構成要素で、Apigee Extension Processorのコールアウトを介して統合されます。その役割は、リクエストが計算資源に届く前のクライアントの本人確認やレート制限、割り当ての適用です。

「AI推論モデル提供のネットワーキング」のリクエストの流れ

クライアントアプリケーションは、Private Service ConnectエンドポイントをOpenAI互換のAPIで呼び出します。リクエストにはプロンプトに加えてモデル名を含め、モデル名はホストされている推論サーバーのいずれかのモデル名と一致させる必要があります。^[1][2][3]

図2　推論リクエストの基本の条件

サンプル実装のデプロイに使うのは、GitHubにある「AI推論モデルサービングのネットワーキング」のコードサンプルです。付属のTerraformデプロイには、両設計とも基本的なModel Armor構成が含まれています。

llm-dはオープンソースのプロジェクト名です。GKE Inference Gatewayは、Gateway モードで動作するllm-d Routerです。^[4]

GKE専用設計のリクエストの流れ

GKE専用設計は共通の構成要素に加え、内部アプリケーションロードバランサ（gke-l7-rilb）としてデプロイするGKE Inference Gatewayを使います。GKE Inference Gatewayは入口エンジンとして、受信したリクエストのペイロードを解析します。

コンシューマーVPC内のクライアントアプリケーションが行うのは、ローカルのPrivate Service ConnectエンドポイントへのOpenAI互換のAPI呼び出しです。その呼び出しは、GKE Inference Gatewayを実装するリージョン内部アプリケーションロードバランサへ直接ルーティングされます。

リクエスト本文で指定された対象モデルのパラメータをHTTPヘッダーに加えるのは、GKE Inference Gatewayです。モデルレプリカセットは、単一ノードまたは複数ノードのGPUまたはTPUノードプールにデプロイした、個々のモデルレプリカ（推論サーバーのインスタンス）の均一なグループです。

図3　GKE専用設計のリクエスト処理の要素

Apigeeを使う場合は、Apigeeがクライアントの認証情報やクォータを確認します。続いてModel Armorが、プロンプトのポリシー違反やデータ漏えいを検査する流れです。

推論プールは、同じモデルのレプリカをまとめ、初期サイズと動的な自動スケーリングを構成できる論理グループです。GKE Inference Gatewayは、HTTPRouteのルールを評価してモデル識別子に基づき推論プールを選び、共有プレフィックスキャッシュの文脈も照合します。

転送先は、Prometheusのリアルタイムデータから見て負荷が最も低いGPUまたはTPUのレプリカです。レプリカが推論ワークロードを実行した後の出力トークンは、Model Armorの最終確認を経てプライベート接続でストリーミングされます。

全バックエンド向け設計のリクエストの流れ

全バックエンド向け設計は、GKEやCloud Run、Agent Platform、オンプレミス、外部クラウドなどにまたがりうる環境向けです。Private Service Connectエンドポイントに届いたリクエストは、リージョン内部アプリケーションロードバランサが受け取ります。

このロードバランサは中央のレイヤ7ルーティングプロキシで、SSL終端やService Extensionsのコールアウトも管理します。Inference Payload Processorは、GKE Inference Gatewayの本文ベースのルーティングに似た機能です。

アプリケーションロードバランサで有効にするにはサービス拡張が必要で、ペイロードの送り先はCloud Run上の軽量なコールアウトです。コールアウトはOpenAI APIリクエストのJSON本文からモデル名を取り出し、URLマップのルーティングに使うX-Gateway-Model-Nameヘッダーに書き込みます。

図4　全バックエンド向け設計の処理を担う要素

ポリシーと安全性を適用する段階では、Apigeeを使う構成の場合、リクエストはIDとクォータの検証のためにまずApigeeへ渡ります。続いて渡る先は、機密データの除去と悪意あるプロンプトのブロックを担うModel Armorです。

ロードバランサのURLマップが選ぶ転送先は、挿入されたモデル名ヘッダーに一致するバックエンドのネットワークエンドポイントグループ（NEG）です。転送先のバックエンドがプロンプトを実行すると、Model Armorが出力を検査し、結果は入口の経路に沿ってプライベートに返ります。

「AI推論モデル提供のネットワーキング」の製品・要件・料金

両設計とも、VPCやPrivate Service Connect、Cloud Run、Model Armorを使います。Apigee API Managementは、両設計とも任意の構成要素です。^[1][2][3]

GKE向けリファレンスアーキテクチャはGKEとGKE Inference Gatewayを使い、全バックエンド向けはCloud Load Balancingを使います。GKE Inference Gatewayに追加料金はなく、料金は使用した基盤のGoogle Cloudリソースに対してのみ発生します。^[2][3][4]

図5　リファレンスアーキテクチャの製品と料金

全バックエンド向けリファレンスアーキテクチャで確かめる主な条件は、次の通りです。

「AI推論モデル提供のネットワーキング」の設計の選び方

GKE専用設計は、推論サーバーをすべてGKEでホストする場合を対象にしたリファレンスアーキテクチャです。推論サーバーが1つでもGKE以外にある場合は、全バックエンド向け設計が対象になります。^[1][2][3]

2つの設計の主な違いを、構成要素の役割ごとにまとめた表は次の通りです。

GKE以外のバックエンドも併用する可能性がある場合は、全バックエンド向け設計でGKEを1つのバックエンドとして組み込む構成も確かめます。移行後は中央のリージョン内部アプリケーションロードバランサが入口になり、GKEのレプリカはInference Gatewayの背後で単一のバックエンドになります。

図6　推論サーバーのホスト先で比べる2つの設計