すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:Gateway with Inference Extension を使用したトラフィックおよび推論サービスの管理

    ドキュメントセンター

    Container Service for Kubernetes:Gateway with Inference Extension を使用したトラフィックおよび推論サービスの管理

    最終更新日:Mar 07, 2026

    この Topic では、Gateway with Inference Extension コンポーネントの特徴、実装、およびメリットについて説明します。

    機能

    The 推論拡張機能付きゲートウェイ コンポーネントは、推論拡張仕様のサポートにより Kubernetes Gateway API を強化します。レイヤー 4 およびレイヤー 7 ルーティングをサポートし、生成 AI 推論向けの高度な機能を提供します。このコンポーネントは、生成 AI の推論サービスの管理を簡素化し、複数の推論サービスワークロード間での負荷分散を最適化します。

    コンポーネントの機能

    • モデル推論サービス向けの最適化されたロードバランシング。

    • モデル認識ルーティング: OpenAI API 仕様で定義されたモデル名に基づいて推論リクエストをルーティングできます。これにより、同じ基盤モデルの異なる LoRA モデルに対して、名前によるグレースケールトラフィック操作を実行できます。

    • モデルの重要度構成: 異なるモデルの重要度レベルを指定して、リクエストを優先させることができます。

    リソースの説明

    推論拡張機能付きゲートウェイ は、Gateway API を拡張する、InferencePool および InferenceModel カスタムリソース定義 (CRD) を使用して、生成 AI 推論サービスを宣言および管理します。

    • InferencePool: 同じコンピューティング構成、アクセラレータタイプ、基盤モデル、およびモデルサーバーを共有する Pod のグループを表します。AI モデルサービスリソースを論理的にグループ化および管理します。単一の InferencePool オブジェクトは、複数の ACK ノードにわたる複数の Pod を含むことができ、スケーラビリティと高可用性を提供します。

    • InferenceModel: InferencePool 内のモデルサーバー Pod によって提供されるモデルの名前を指定します。InferenceModel リソースは、モデルの重要度レベルなどのサービスプロパティも定義します。Critical と分類されたワークロードは優先されます。

    次の図は、InferencePool および InferenceModel CRD と Gateway API リソース間の関係を示しています。

    image

    以下の図は、Gateway with Inference Extension コンポーネントが、InferencePool および InferenceModel のリソース定義を使用して推論リクエストを処理する方法を示しています。

    image

    Inference Extension ロードバランシングの利点

    従来の HTTP ルーティング

    従来の HTTP リクエストの場合、従来のロードバランシングアルゴリズムは、リクエストを異なるワークロードに均等に分散できます。しかし、大規模言語モデル (LLM) 推論サービスの場合、各リクエストがバックエンドにかける負荷は予測が困難です。推論プロセス中、リクエスト処理には次の2つのフェーズが含まれます。

    • プリフィルフェーズ: 入力をエンコードします。

    • デコーディングフェーズ: いくつかのステップで構成されます。各ステップは以前の入力をデコードし、新しいトークンを出力します。トークンは LLM の基本的なデータ処理単位であり、LLM の出力における単語におおよそ対応します。

    各リクエストがいくつのトークンを出力するかを事前に決定することはできないため、リクエストを異なるワークロードに均等に分散すると、一貫性のない負荷が発生し、負荷の不均衡を引き起こします。

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

    推論サーバーの内部状態は、複数のディメンションからのメトリックを使用して評価されます。その後、この内部状態に基づいて、複数の推論サーバーワークロードにわたるロードバランシングが実行されます。主要なメトリックは次のとおりです。

    • リクエストキューの長さ (vllm: num_requests_waiting): モデルサーバーによってキューに入れられ、処理を待機しているリクエストの数を表します。キューが短いほど、新しいリクエストが迅速に処理される可能性が高くなります。

    • GPU キャッシュ使用率 (vllm: gpu_cache_usage_perc): モデルサーバーが中間推論結果をキャッシュするために使用する KV キャッシュ使用率の割合を表します。使用率が低いほど、GPU が新しいリクエストにリソースを割り当てるための十分なスペースがあることを示します。

    従来のロードバランシングアルゴリズムと比較して、この方法は複数の推論サービスワークロードにわたるより一貫した GPU 負荷を確保します。これにより、LLM 推論リクエストの Time to First Token (TTFT) が大幅に削減され、LLM 推論リクエストのスループットが向上します。