G-gen の佐々木です。当記事では Google Cloud Next '25 で発表された Google Kubernetes Engine（GKE）における最新の生成 AI 関連機能を紹介します。

概要

Google Cloud の旗艦イベントである Google Cloud Next '25 にて、GKE で生成 AI による推論ワークロードを展開するための新たな機能が発表されました。

当記事では、以下の公式発表に基づいて GKE Inference Quickstart、GKE Inference Gateway、GKE TPU serving stack を紹介します。

参考 : New GKE inference capabilities reduce costs, tail latency and increase throughput

GKE における AI 推論ワークロード

Gemini と同じ技術で作られた LLM である Gemma を代表とする生成 AI オープンモデルは、GKE クラスタ上のマイクロサービスとして AI 推論を提供することができます。

Gemini 等の大規模モデルを API で使用する代わりに、Gemma のような軽量モデルを GKE 上で実行することで、以下のようなメリットを享受することができます。

API ベースで Gemini モデルを利用する場合のように、リクエストの増加に比例してコストが大きくなる心配がない（コストの予測が容易）。
他の利用者によるリクエストによって推論のパフォーマンスが低下する心配がない。
リクエスト送信元のアプリケーションが同じクラスタ上に展開されている場合、レイテンシが抑えられる。
モデルのカスタマイズ性が高い。
AI 推論ワークロードをオンプレミスのクラスタに移行できる。

しかし、自社専用の環境として生成 AI による推論ワークロードを展開したい場合、モデルを実行するサーバやアクセラレータの選定、スケーリング、トラフィック分散、パフォーマンスモニタリングのように、開発から運用にわたって様々な課題があります。

これらの課題を解決するため、新たに3つの機能が GKE で利用できるようになりました。

GKE Inference Quickstart

GKE Inference Quickstart は、生成 AI モデル、モデルを提供するサーバ、アクセラレータ（GPU/TPU）、スケーリングといった要件から、Google によるベンチマークに基づいて最適化された Kubernetes 構成を展開することができるレシピを生成することができます。

レシピには、モデルサーバをホストする Pod を展開するための Deployment リソースや Service リソースだけではなく、指定した要件に基づいた HPA（Horizontal Pod Autoscaler）リソース、Cloud Monitoring との連携を提供する PodMonitoring カスタムリソースが含まれます。　　

このように、GKE Inference Quickstart を使用することで、AI 推論ワークロードを展開するための手動での構成の調整やテストをスキップし、GKE クラスタ上に容易かつ迅速に推論ワークロードを展開することができます。

GKE Inference Quickstart の使用方法については、以下の記事で解説しています。

blog.g-gen.co.jp

詳細は、以下のリンクもご参照ください。

参考 : About model inference on GKE
参考 : Run best practice inference with GKE Inference Quickstart recipes

GKE Inference Gateway

GKE Inference Gateway は負荷分散機能である Gateway API の拡張機能であり、GKE 上に展開した生成 AI の推論ワークロードに対して最適な負荷分散を提供します。

従来の Gateway ではラウンドロビンのように、リクエストパターンが予測可能なアプリケーション向けに想定された負荷分散の仕組みが使用されます。

しかし、LLM に対する推論リクエストはパターンが大きく変動するため、バックエンドの推論ワークロードに対する負荷分散が上手く行われず、コンピューティングリソース使用率が不均一になり、推論レイテンシの増加を引き起こす可能性がありました。

GKE Inference Gateway は、以下のような生成 AI 特有のリクエストパターンに最適化された負荷分散、ルーティングを提供します。

バックエンドのモデルサーバからの指標を負荷分散に活用し、GPU や TPU などのアクセラレータが効率良く使用されるように負荷分散を行う。
バックエンドで複数のモデル、バージョンを展開している場合に、OpenAI API 仕様で定義されたモデル名に基づいたルーティングを行う。
リクエストの Criticality に基づいたルーティング。低レイテンシが要求される推論リクエストをバッチ推論よりも優先し、リソースが限られている場合は優先度の低いリクエストをドロップできる。
Model Armor との統合によりリクエスト、レスポンス、推論処理のログを提供し、事後分析と最適化に役立てることができる。
リクエストレート、レイテンシ、エラー、サチュレーションといった SRE メトリクスが提供される。

詳細は、以下のリンクもご参照ください。