リアルタイムのキューおよび GPU キャッシュメトリクスに基づいて最適な Pod にリクエストをルーティングし、最初のトークンまでの時間 (TTFT) を削減します。
機能
推論拡張付きゲートウェイは、Kubernetes コミュニティの Gateway API およびその Inference Extension 仕様に基づいて拡張されたゲートウェイコンポーネントです。レイヤー 4 およびレイヤー 7 のルーティングに加えて、生成 AI 推論向けの追加機能を提供することで、推論サービスの管理を簡素化し、複数の推論ワークロード間での負荷分散を最適化します。
以下の AI 推論機能を持つレイヤー 4 およびレイヤー 7 のルーティングをサポートします。
-
推論対応の負荷分散：均等分散ではなく、リアルタイムの推論サーバーメトリクス (キューの深さおよび GPU KV キャッシュ使用率) に基づいてリクエストをルーティングすることで、GPU 使用率を一定に保ち、TTFT を削減します。
-
モデル対応のルーティング：OpenAI API 仕様に従い、モデル名に基づいてリクエストをルーティングします。複数の LoRA アダプターを持つ基盤モデルの場合、カナリアリリースにより、アダプター名に基づいて特定のアダプターにトラフィックを誘導します。
-
モデルの重要度：各モデルに重要度レベルを割り当てます。
Criticalリクエストは、重要度の低いワークロードよりも優先されます。
基本概念
2 つのカスタムリソースが Kubernetes Gateway API を拡張します。
| リソース | 目的 |
|---|---|
| InferencePool | 同じコンピューティング構成、アクセラレータータイプ、基盤モデル、およびモデルサーバーを共有する Pod をグループ化します。スケーラビリティと高可用性を実現するために、ACK ノード全体にまたがる Pod を含めることができます。 |
| InferenceModel | InferencePool によって提供されるモデル名とその重要度レベルを含むプロパティを定義します。 |
次の図は、InferencePool、InferenceModel、および Gateway API リソースの関係を示しています。
仕組み
ゲートウェイは、受信リクエストをルーティングするために、各 Pod で以下のリアルタイムメトリクスを評価します。
-
リクエストキュー長 (
vllm:num_requests_waiting)：キュー内のリクエスト数。キューが短い Pod は、新しいリクエストをより早く処理します。 -
GPU KV キャッシュ使用率 (
vllm:gpu_cache_usage_perc)：使用中の GPU KV キャッシュの割合。使用率が低いほど、新しいリクエスト向けの容量が多くなります。
ゲートウェイは、これらのメトリクスに基づいて、各リクエストを処理するのに最適な Pod にルーティングします。
次の図は、リクエストフローを示しています。
推論対応の負荷分散が必要な理由
標準的な HTTP 負荷分散は、Pod 全体にリクエストを均等に分散します。これはステートレスサービスには有効ですが、各リクエストの計算コストが予測不可能な大規模言語モデル (LLM) 推論には適していません。
LLM 推論には 2 つのフェーズがあります。
-
プレフィルフェーズ：入力をエンコードします。
-
デコーディングフェーズ：ステップごとに、前の入力をデコードし、トークン (おおよそ単語に対応) を出力します。
出力長が予測できないため、均等分散では GPU 負荷が不均一になり、一部の Pod がボトルネックになる一方で、他の Pod はアイドル状態になります。
推論対応の負荷分散は、リアルタイムのキューの深さおよび GPU KV キャッシュ使用率に基づいて、最も容量に余裕のある Pod に各リクエストをルーティングすることで、GPU 負荷のバランスを保ち、TTFT を削減し、スループットを向上させます。