GKE Inference Gateway を使用して、同じインフラストラクチャでリアルタイム推論と非同期推論を実行する

※この投稿は米国時間 2026 年 4 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

AI ワークロードが実験的なプロトタイプから本番環境グレードのサービスに移行するのに伴い、それらをサポートするインフラストラクチャは、利用率のギャップが拡大するという課題に直面しています。昨今の企業は通常、同時実行性が高く、低レイテンシのリアルタイム リクエストに対応するシステムを構築するか、高スループットの「非同期」処理用に最適化するかという二者択一を迫られています。

Kubernetes 環境では、従来、これらの要件には、サイロ化された別々の GPU および TPU アクセラレータ クラスタによって対応してきました。リアルタイム トラフィックは、バーストを処理するためにオーバープロビジョニングされるため、オフピーク時には大幅なアイドル容量が発生する可能性があります。一方、非同期タスクは多くの場合、セカンダリ クラスタに追いやられるため、ソフトウェア スタックが複雑化し、リソース管理が断片化します。

AI サービング ワークロードの場合、Google Kubernetes Engine（GKE）は、推論パターンの全範囲に対応する統合プラットフォームである GKE Inference Gateway を使用して、この「費用とパフォーマンス」のトレードオフに対処します。Google は OSS ファーストのアプローチを活用することで、アクセラレータの容量を単一の流動的なリソースプールとして扱うスタックを開発しました。これにより、決定論的なレイテンシと高スループットの両方を必要とするワークロードに対応できます。

この投稿では、最新の AI サービスを推進する 2 つの主要な推論パターンと、それぞれのパターンにおける問題および現在利用可能なソリューションについて説明します。このブログ記事を最後までお読みいただくと、GKE が GKE Inference Gateway を介してこれらのパターンにどのように対応するかについておわかりいただけます。

2 つの推論パターン: リアルタイムと非同期

このブログ記事では、リアルタイムと非同期という 2 種類の AI 推論ワークロードを取り上げます。リアルタイム推論の場合、これらは優先度の高い同期リクエストです。たとえば、お客様が LLM からの即時レスポンスを待っている、chatbot とのやり取りなどです。一方、小売業におけるインデックス登録や商品分類のドキュメント化などの非同期トラフィックでは、通常、レイテンシが許容されます。つまり、トラフィックはキューに入れられ、遅延して処理されることがよくあります。

1. リアルタイム推論: レイテンシの影響を受けやすい 0 秒のリクエスト

優先度の高い同期トラフィックの場合、レイテンシが最も重要な指標となります。しかし、従来のロード バランシングでは、高レイテンシを示す KV キャッシュ使用率などのアクセラレータ固有の指標が無視されることが多いため、パフォーマンスを最適化できません。

ソリューション: GKE Inference Gateway

この問題のソリューションは、Inference Gateway です。Inference Gateway は、リアルタイムの指標（KV キャッシュのステータスなど）に基づいてモデルサーバーのパフォーマンスを予測し、レイテンシを考慮したスケジューリングを実行して、最初のトークンまでの時間を最小限に抑えます。これにより、キューイングの遅延も減り、負荷が高い場合でも一貫したパフォーマンスを確保できます。

2. 非同期（ニア リアルタイム）推論: 0 分のレイテンシ

レイテンシが許容されるタスクは、ミリ秒単位の要件ではなく、分単位のサービスレベル目標（SLO）で動作します。従来のセットアップでは、リアルタイム トラフィックとのリソース競合を防ぐために、これらのリクエストを別々の専用インフラストラクチャで実行することがよくありました。この静的なパーティショニングは、利用の断片化とハードウェア費用の膨張につながる可能性があります。さらに、カスタムビルドの非同期ポーラーは、通常、同じアクセラレータにワークロードを多重化するために必要な高度なスケジューリング ロジックを備えていないため、エンジニアは 2 つの異なる複雑なソフトウェア スタックを管理する必要があります。

ソリューション: 非同期プロセッサ エージェント + Inference Gateway

Inference Gateway を Cloud Pub/Sub と統合する「プラグ アンド プレイ」アーキテクチャ。バッチ処理エージェントは、構成されたトピックからリクエストを pull し、それらを「削除可能な」トラフィックとして Inference Gateway にルーティングします。システムはバッチタスクを「フィラー」として扱い、リアルタイムの急増の合間にアイドル状態のアクセラレータ（GPU / TPU）の容量を使用します。これにより、リソースの断片化が最小限に抑えられ、ハードウェア費用を削減できます。

主な機能:

• リアルタイム トラフィックのサポート: リアルタイム推論トラフィックは Inference Gateway によって処理されます。

• 永続的なメッセージング: Pub/Sub を介して信頼性の高いリクエスト処理が行われます。

• インテリジェントな再試行: キューの深さのリアルタイム モニタリングに基づいて、キュー アーキテクチャに組み込まれた構成可能な再試行ロジックを活用します。

• 厳密な優先順位: ゲートウェイ レベルでは、リアルタイム トラフィックがバッチ トラフィックよりも常に優先されます。

• 緊密な統合: ユーザーは Pub/Sub トピックを「プラグイン」するだけで、エージェントが共有アクセラレータ プールへのルーティング ロジックを処理します。

上の図に示されているリクエスト フローは次のとおりです。

1. ユーザーがリアルタイム リクエストを送信します。Inference Gateway はまずそのリクエストのスケジュール作成をします。

2. ユーザーは、構成された Pub/Sub トピックを介して非同期推論リクエストをパブリッシュできます。

3. 非同期プロセッサが、利用可能な容量に基づいてキューから読み取りを行います。

4. 非同期プロセッサは、同じアクセラレータ（GPU / TPU）リソースを利用して、Inference Gateway を介してリクエストをルーティングします。リアルタイム リクエストが優先されます。非同期リクエストは、コンピューティング サイクルで未使用のアクセラレータに割り当てられます（上の図を参照）。

5. 非同期プロセッサは、レスポンスを出力トピックに書き込みます。

6. ユーザーは、レスポンス トピックから非同期リクエストのレスポンスを取得します。

これらのリアルタイム ワークロードと非同期ワークロードを共有アクセラレータに統合することで、GKE は「費用とパフォーマンス」のパラドックスを解決します。脆弱なカスタム キューポーラーを管理したり、使用率の低いクラスタを個別に維持したりする必要はもうありません。さらに、これらの作業はすべてオープンソースで可能です。つまり、複数のクラウドや環境でこれらのプロダクトを使用できます。

統合ワークロードの実例

共有インフラストラクチャでリアルタイム ワークロードと非同期ワークロードを実行するというアイデアは、理論的には素晴らしいものですが、実際にはどのように機能するのでしょうか。優先度の高いリアルタイム ワークロードとレイテンシが許容されるバッチ リクエストを統合リソースプール内で同時に処理する有効性を分析したところ、有望な結果が得られました。

リアルタイム トラフィックは、予測不能な急増が特徴です。低レイテンシの回答を維持するには、ピーク時にプールの容量の 100% をリアルタイム トラフィックに使用できるようにする必要があります。一方、レイテンシが許容されるタスクは、容量が使用可能になるまで保留状態のままにする必要があります。

最初のテストで、管理されていない多重化のリスクが明らかになりました。優先度が低く、レイテンシが許容されるリクエストが、非同期プロセッサ エージェントを使用せずに Inference Gateway に直接送信された場合、リソースの競合によりメッセージの 99% が削除されました。しかし、非同期プロセッサを使用した場合、レイテンシが許容されるリクエストの 100% が利用可能なサイクル中に処理されました。

次のステップ

同じインフラストラクチャでリアルタイム AI ワークロードとバッチ AI ワークロードの両方を実行することに関心をお持ちの場合は、最初に、Inference Gateway を使用した非同期推論のクイックスタート ガイドをご覧ください。GitHub で OSS プロジェクトに参加して、この取り組みに貢献することもできます。開発の次の段階では、期限を考慮したスケジューリングに重点を置き、ユーザーがバッチ完了期間に「ソフトリミット」を設定できるようにすることで、フィラー トラフィックとリアルタイムの需要のバランスをシステムが取る方法をさらに最適化します。この重要な取り組みでコミュニティと連携できることを楽しみにしています。

- シニア プロダクト マネージャー、Poonam Lamba

- シニア スタッフ ソフトウェア エンジニア、Abdullah Gharaibeh