AI 推論ワークロードは、従来のステートレス HTTP アプリケーションのように動作しません。 要求は、多くの場合、モデル固有で実行時間が長く、処理コストが高く、アクセラレータの可用性、キューの深さ、要求の優先順位、トークンの予算、モデル サーバーの容量などのランタイムシグナルに依存します。
Application Gateway for Containers 推論ゲートウェイは、Kubernetes Gateway API Inference Extension と統合することで、これらのワークロードをサポートします。これにより、推論に対応するリソースがゲートウェイ API モデルに追加されます。 推論ゲートウェイを使用すると、モデル対応および読み込み対応のルーティング動作を使用して、Application Gateway for Containers を介してセルフホステッド モデル サーバーを公開できます。
推論ゲートウェイは、大規模な言語モデル (LLM) やその他の推論ワークロードを提供するために専用に構築されています。 汎用負荷分散ではなく、モデル サーバー信号に基づいて要求をルーティングします。これにより、最初のトークン (TTFT) までの時間が短縮され、負荷のタイムアウトが減少し、GPU の効率が向上します。 Application Gateway for Containers のイングレス機能に基づいて構築された推論ゲートウェイでは、AI ワークロードと Web アプリケーション ファイアウォール (WAF) などの機能を組み合わせて、モデル サーバーに到達する前にトラフィックをセキュリティで保護することもできます。
vLLM を含む多くのセルフホステッド推論ランタイムでは、、/v1/chat/completions、/v1/completionsなど、/v1/models公開されています。 OpenAI 互換とは、OpenAI でホストされるモデルに対する制限ではなく、API 形式を指します。 この形式を使用するランタイムまたはプロキシを介して別のモデル ファミリが提供される場合、Application Gateway for Containers では、本文ベースのルーティングに JSON 要求本文の model フィールドを使用できます。
Important
Application Gateway for Containers 推論ゲートウェイは現在プレビュー段階です。
ベータ版、プレビュー版、または他の方法で一般公開されていない Azure の機能に適用される法的条件については、Microsoft Azure プレビューの追加利用規約を参照してください。
ゲートウェイ API 推論拡張機能が提供するもの
ゲートウェイ API 推論拡張機能は、推論固有のバックエンドとスケジュールの概念を追加することで、ゲートウェイ API の実装を推論ゲートウェイに変換します。
拡張機能には、次の主要なリソースとコンポーネントが導入されています。
- InferencePool: モデル サーバー ポッドのグループと、推論要求ごとにポッドを選択するために使用されるエンドポイント ピッカーを表すバックエンド リソース。
- InferenceObjective: InferencePool を共有する要求の要求サービス目標 (優先度など) を表すリソース。
- エンドポイント ピッカー (EPP): クラスターで実行され、推論スケジュールを実装する、顧客が提供する拡張機能。 EPP は要求メタデータを受信し、構成可能なプラグイン (キューの深さ、KV キャッシュ使用率、プレフィックス キャッシュ アフィニティなど) を使用して候補モデル サーバー ポッドをスコア付けし、選択したエンドポイントを返します。 エンドポイントの選択は EPP で実行されるため、使用可能なルーティング動作は、EPP で有効にするスコア付けプラグインによって異なります。
-
本文ベースのルーティング (BBR):OpenAI と互換性のある要求本文を検査し、モデル名を抽出し、モデル対応ルーティングの
X-Gateway-Model-Nameヘッダーとしてゲートウェイで使用できるようにする要求プロセッサ。
Application Gateway for Containers は、BBR プロセッサをゲートウェイのマネージド部分として実行するため、デプロイ、スケーリング、またはパッチを適用するための個別の本文ベースのルーティング層はありません。 顧客が提供する EPP と統合され、要求時ルーティングの決定をサポートします。 推論ゲートウェイはゲートウェイ API 推論拡張機能 API をサポートしているため、標準のゲートウェイ API リソースを使用してこれらの機能を構成し、プラットフォーム チームは、個別のイングレス構成モデルを導入する代わりに、Kubernetes ネイティブ API モデルを使用して推論トラフィックを行うことができます。
Application Gateway for Containers で推論リソースを使用する方法
Application Gateway for Containers では、イングレス構成に標準のゲートウェイ API リソースが引き続き使用されます。 推論動作は、HTTPRouteバックエンド参照が Kubernetes InferencePoolではなくServiceをターゲットにしている場合にアクティブになります。
推論ルート以外の場合、Application Gateway for Containers は既存のゲートウェイ API の動作を保持します。 Kubernetes Service バックエンドを対象とするルートは、推論プロセッサを呼び出せず、推論固有のルーティング動作を受け取りません。
推論ルートの場合、コントロール プレーンはゲートウェイ API と推論リソースを調整し、データ プレーンをプログラムして次の処理を行います。
-
HTTPRouteは、InferencePoolバックエンドを選択します。 -
InferencePoolは、プールに属するモデル サーバー ポッドを選択します。 - プールに関連付けられている EPP は、エンドポイントの選択のために呼び出されます。
- 選択したモデル サーバー エンドポイントが要求を受信します。
- 省略可能なモデル対応ルーティングでは、BBR によって抽出された要求モデル名が使用されます。
要求フロー
一般的な推論要求は、このパスに従います。 番号付きステップは、次の図のラベルにマップされます。
- クライアント要求: クライアントが Application Gateway for Containers フロントエンドに OpenAI と互換性のある要求を送信し、ゲートウェイ リスナーがそれを受け入れます。
-
本文ベースのルーティング (BBR): モデル対応ルートの場合、マネージド BBR プロセッサは要求本文を検査し、モデル名を抽出して、
X-Gateway-Model-Nameヘッダーを挿入します。HTTPRouteはその値に基づいてマッチングを行い、適切なInferencePoolを選択できます。 -
エンドポイントの選択: 一致したルートが
InferencePoolをターゲットにすると、Application Gateway for Containers によって EPP が呼び出され、要求とモデル サーバーのテレメトリが評価され、選択したエンドポイントが返されます。 - InferencePool: Application Gateway for Containers へのルートでは、選択したモデル サーバー ポッドに要求が転送され、モデル サーバーの応答がゲートウェイを介してクライアントに返されます。
ルーティング機能
推論ゲートウェイでは、セルフホステッド AI ワークロードに対してこれらのルーティング パターンがサポートされています。 エンドポイントの選択は EPP で実行されるため、読み込み対応とキャッシュ対応の動作は、EPP で有効にするスコアラー プラグインによって異なります。
- モデル対応ルーティング: マネージド BBR プロセッサが抽出する OpenAI 互換要求本文のモデル名に基づいて要求をルーティングします。
-
トラフィック分割とロールアウト: 標準の
HTTPRoute重み付きbackendRefsを使用して、カナリアまたはブルーグリーン モデルのロールアウトのためにInferencePoolバックエンド間でトラフィックを分割します。 - 読み込み対応およびキャッシュ対応エンドポイントの選択: EPP は、キューの深さや KV キャッシュ使用率などのモデル サーバー テレメトリを使用してエンドポイントをスコア付けします。 EPP でプレフィックスキャッシュ対応スコアリングが有効になると、プロンプト プレフィックスを共有する要求は同じレプリカに移動し、キャッシュ ヒット数を上げて TTFT を下げます。
-
要求の優先度とオーバーロードの保護:
InferenceObjectiveリソースとx-gateway-inference-objective要求ヘッダーを使用して、サービスの優先度を割り当てます。 モデル サーバーが飽和状態になると、EPP は、待ち時間が重要なトラフィックを保護するために、優先順位の低い要求を最初に取り除きます。 -
回復性のあるエンドポイントの選択: 可用性または厳密なエンドポイントの選択がプールにとってより重要であるかに応じて、
FailOpenまたはFailCloseを使用して EPP エラーの動作を構成します。 - ゲートウェイ API の互換性: イングレス構成に対して、ゲートウェイ、HTTPRoute、ReferenceGrant、および標準のゲートウェイ API の状態条件を引き続き使用します。
安全な推論
モデル サーバーをマネージド ゲートウェイの背後でプライベートに保ち、プラットフォームのセキュリティ機能を推論トラフィックに適用します。
- Web アプリケーション ファイアウォール (WAF): 推論ゲートウェイは 、Application Gateway for Containers の既存の WAF 機能とネイティブにペアリングされ、要求がモデル サーバーに到達する前に AI トラフィックに OWASP で調整された保護が適用されます。
- コストの高いバックエンドの保護: ポリシーはマネージド エッジで適用されるため、形式が正しくない要求や不適切な要求は、不足している GPU 容量を消費する前に検査およびブロックできます。
シナリオの例
次のシナリオは、推論ゲートウェイを使用する一般的な方法を示しています。
-
モデル バージョンの提供とロールアウト: OpenAI と互換性のある要求をモデル名で
InferencePoolにルーティングし、重み付けされたHTTPRoutebackendRefs を使用して、ロールアウトを完了する前にカナリア テストのためにトラフィックの割合を新しいモデル バージョンにシフトします。 -
待機時間が重要なトラフィックに優先順位を付ける: 共有プール上の優先度の高いワークロードと優先順位の低いワークロードの
InferenceObjectiveリソースを定義します。 対話型チャット リクエストは高い優先度で扱われる一方、バッチ ジョブはより低い優先度で処理され、プールが飽和した場合には真っ先に切り捨てられます。
InferencePool と Service の比較
Kubernetes Service は、標準アプリケーション トラフィックに適したバックエンド抽象化のままです。 バックエンドが推論固有のエンドポイント選択を必要とするモデル サーバー ポッドのグループである場合は、 InferencePool を使用します。
| バックエンドの種類 | 利用目的 | ルーティングの動作 |
|---|---|---|
Service |
標準 HTTP、gRPC、およびアプリケーション バックエンド | ゲートウェイは、標準的な負荷分散動作を使用してサービス エンドポイントにルーティングします。 |
InferencePool |
セルフホスト型モデルサーバーポッド | ゲートウェイは、構成された EPP を呼び出し、選択したモデル サーバー エンドポイントにルーティングします。 |
InferencePoolには、ポッド セレクター、ターゲット ポート情報、エンドポイント ピッカー参照が含まれます。 EPP は、要求のエンドポイントを選択する役割を担います。 1 つの EPP が 1 つのプールに関連付けられています。
障害時の動作
推論ルーティングは要求時の動作であるため、エンドポイント ピッカーのエラー モードが重要です。
InferencePool エンドポイント ピッカー参照では、次のエラー モードがサポートされています。
- FailOpen: EPP が使用できない場合、または応答しない場合、ゲートウェイはプールの標準エンドポイントの選択を続行できます。 この選択により、可用性は維持されますが、ルーティングの品質が低下する可能性があります。
- FailClose: EPP が使用できない場合、または応答しない場合、ゲートウェイは要求を拒否します。 この選択により、必要なエンドポイント選択の決定なしでトラフィックが送信されなくなります。
要求本文の解析に依存するモデル対応ルーティングの場合、Application Gateway for Containers では正確性が優先されます。 BBR を必要とするルートに対してモデル名を抽出できない場合、間違ったモデル バックエンドにサイレント ルーティングされるのではなく、要求は拒否されます。
運用上の考慮事項
Application Gateway for Containers の背後で推論ワークロードを実行する場合は、次の考慮事項を考慮してください。
-
EPP 容量: EPP は、
InferencePoolバックエンドの要求パスにあります。 重要なアプリケーション コンポーネントのようにサイズを設定し、監視します。 - モデル サーバー テレメトリ: EPP では、高品質のルーティング決定を行うために、新しいモデル サーバー メトリックが必要です。 モデル サーバーが EPP 構成で期待されるメトリックをサポートしていることを確認します。
- GPU の容量とスケジュール: モデル サーバー ポッドには、多くの場合、GPU ノード プール、デバイス プラグイン、およびモデルのダウンロード資格情報が必要です。
- 自動スケール: 水平ポッド オートスケーラーまたは KEDA を使用して、キューの深さや KV キャッシュ使用率などの推論シグナルでモデル サーバー ポッドをスケーリングします。 自動スケールでは、需要の増加に合わせて容量が追加されますが、EPP は既に飽和状態にあるレプリカを中心にルーティングします。
- ストリーミング応答: 多くのチャット完了ワークロードでは、サーバー送信イベントが使用されます。 エンドツーエンドの待機時間とタイムアウト設定をテストするときのストリーミング動作を検証します。
- 可観測性: ゲートウェイと HTTPRoute の状態、InferencePool の状態、EPP の正常性、モデル サーバーの準備状況、アクティブな要求やキューの深さなどのモデル サーバー メトリックを監視します。
制限事項
推論ゲートウェイは、Kubernetes で実行されているセルフホステッド推論ワークロードに重点を置いています。 パブリック またはマネージド モデル プロバイダー エンドポイントへの直接ルーティングは、この統合の範囲外です。
ゲートウェイ API 推論拡張機能は、Application Gateway for Containers とは別に進化します。 クラスターにインストールされている推論拡張機能の CRD に一致する API バージョンとマニフェストを使用します。
