Inference Extension 搭載 Gateway のトラフィック管理および推論サービス管理 - Container Compute Service

本トピックでは、Inference Extension 搭載 Gateway コンポーネントの特徴、実装原理、および利点について説明します。

特徴

Inference Extension 搭載 Gateway コンポーネントは、Kubernetes コミュニティの Gateway API およびその Inference Extension 仕様に基づく拡張コンポーネントです。Kubernetes 環境におけるレイヤー 4 およびレイヤー 7 ルーティングをサポートし、生成 AI 推論シナリオ向けに強化された機能を提供します。このコンポーネントにより、生成 AI 推論サービスの管理が簡素化され、複数の推論サービスワークロード間でのロードバランシング性能が最適化されます。

コンポーネントの特徴

モデル推論サービス向けの最適化済みロードバランシング。
モデル認識ルーティング：OpenAI API 仕様で定義されたモデル名に基づいて推論リクエストをルーティングします。同一の基盤モデルに対して、異なる LoRA モデルを名前単位でグレースケールトラフィック操作できます。
モデル重要度設定：各モデルに対して異なる重要度レベルを指定することで、リクエストの優先順位付けを行います。

リソースの説明

Inference Extension 搭載 Gateway コンポーネントは、Gateway API の拡張であるカスタムリソース InferencePool および InferenceModel を使用して、生成 AI 推論サービスを宣言・管理します。

InferencePool：同じコンピューティング構成、アクセラレータ種別、基盤モデル、およびモデルサーバーを共有する Pod グループを表します。AI モデルサービスリソースを論理的にグループ化・管理します。InferencePool オブジェクト 1 つで、複数の ACK ノードにまたがる複数の Pod を含むことができ、スケーラビリティおよび高可用性を実現します。
InferenceModel：InferencePool 内のモデルサーバー Pod が提供するモデルの名称を指定します。InferenceModel リソースは、モデルのサービスプロパティ（例：重要度レベル）も定義します。Critical と分類されたワークロードは、より高い優先度で処理されます。

以下の図は、InferencePool および InferenceModel カスタムリソースと Gateway API リソースとの関係を示しています。

以下の図は、Inference Extension 搭載 Gateway コンポーネントの InferencePool および InferenceModel リソース定義が、推論リクエストをどのように処理するかを示しています。

推論拡張ロードバランシングの利点

従来の HTTP ルーティング

従来の HTTP リクエストでは、古典的なロードバランシングアルゴリズムにより、リクエストを異なるワークロード間で均等に分散できます。しかし、大規模言語モデル（LLM）推論サービスの場合、各リクエストがバックエンドに与える負荷は事前に予測が困難です。推論処理には、以下の 2 つのフェーズがあります：

プリフィルフェーズ： 入力をエンコードします。
デコーディングフェーズ： 複数のステップから構成されます。各ステップでは、前の入力をデコードし、新しいトークンを出力します。トークンは LLM のデータ処理における基本単位であり、LLM 推論出力においてはおおよそ 1 単語に相当します。

各リクエストが出力するトークン数は事前に決定できないため、リクエストを異なるワークロード間で均等に分散すると、負荷の不均一化が生じ、ロードバランスが崩れます。

推論サービスのルーティング

推論サーバーの内部状態は、複数のディメンションから得られるメトリックを用いて評価されます。その後、その内部状態に基づき、複数の推論サーバーワークロード間で負荷がバランスよく分散されます。主なメトリックは以下のとおりです：

リクエストキュー長（vllm: num_requests_waiting）：モデルサーバーによって処理待ちとなっているリクエストの数を表します。キューが短いほど、新規リクエストが迅速に処理される可能性が高くなります。
GPU キャッシュ利用率（vllm: gpu_cache_usage_perc）：モデルサーバーが中間推論結果をキャッシュするために使用する KV キャッシュの利用率（パーセント）を表します。利用率が低いほど、GPU に新規リクエストのリソース割り当てに十分な空き容量があることを意味します。

従来のロードバランシングアルゴリズムと比較して、このアプローチにより、複数の推論サービスワークロード間で GPU 負荷の一貫性が向上します。LLM 推論リクエストの最初のトークン到達時間（TTFT）が大幅に短縮され、スループットも向上します。