推論サービングは、生成 AI モデルを実際のアプリケーションにデプロイするうえで重要です。GKE は、コンテナ化されたワークロードを管理するための堅牢でスケーラブルなプラットフォームを提供します。そのため、開発環境または本番環境でモデルをサービングする場合に最適な選択肢となります。GKE を使用すると、オーケストレーション、スケーリング、高可用性のために Kubernetes の機能を使用して、推論サービスを効率的にデプロイし、管理できます。
AI/ML 推論の特定の要件を認識し、 Google Cloud では GKE 生成 AI 機能が導入されました。これは、GKE での推論サービングを強化して最適化するために特別に設計された機能スイートです。特定の機能の詳細については、GKE 生成 AI 機能をご覧ください。
GKE で AI/ML モデル推論を始める
GKE での AI/ML モデル推論は、数分で使い始めることができます。GKE の無料枠を使用して、クラスタ管理に費用をかけずに Kubernetes を開始できます。
- モデルをデプロイするの手順に沿って、コンテナ化されたモデルとモデルサーバーをデプロイします。
- GKE での推論に関するベスト プラクティスの概要を読み、GKE で推論ワークロードを計画して実行するためのガイダンスとリソースを確認します。
用語
このページでは、GKE での推論に関連する次の用語を使用します。
- 推論: GKE クラスタ内で大規模言語モデルや拡散モデルなどの生成 AI モデルを実行し、入力データからテキスト、エンベディング、その他の出力を生成するプロセス。GKE でのモデル推論では、アクセラレータを活用して、リアルタイムまたはバッチ処理の複雑な計算を効率的に処理します。
- モデル: データからパターンを学習し、推論に使用される生成 AI モデル。モデルのサイズとアーキテクチャは、小規模なドメイン固有のモデルから、多様な言語タスク用に最適化された数十億のパラメータを持つ大規模なニューラル ネットワークまで、多岐にわたります。
- モデルサーバー: 推論リクエストを受信して推論を返すコンテナ化されたサービス。このサービスは Python アプリの場合もあれば、vLLM、JetStream、TensorFlow Serving、Triton Inference Server などのより堅牢なソリューションの場合もあります。モデルサーバーは、モデルをメモリに読み込み、アクセラレータで計算を実行して、推論を効率的に返します。
- アクセラレータ: GKE ノードにアタッチして計算を高速化できる特殊なハードウェア（NVIDIA のグラフィック プロセッシング ユニット（GPU）や Google の Tensor Processing Unit（TPU）など）。特にトレーニング タスクと推論タスクで効果を発揮します。
- 量子化: モデルの重みと活性化を高精度のデータ型から低精度のデータ型に変換することで、AI/ML モデルのサイズを縮小し、推論の速度を向上させるために使用される手法。
推論に GKE を使用するメリット
GKE での推論サービングには、次のようなメリットがあります。
- 効率的な費用対効果: 推論サービングのニーズに合わせて価値と速度を提供します。GKE では、さまざまな高性能アクセラレータ（GPU と TPU）から選択できるため、必要なパフォーマンスに対してのみ料金を支払うことができます。
- デプロイの高速化: GKE 生成 AI 機能によって提供される、カスタマイズされたベスト プラクティス、認定、ベスト プラクティスにより、製品化までの時間を短縮します。
- スケーラブルなパフォーマンス: GKE Inference Gateway、HorizontalPodAutoscaling（HPA）、カスタム指標を使用して、事前構築されたモニタリングでパフォーマンスをスケールアウトします。80 億～6,710 億個のパラメータで、さまざまな事前トレーニング済みモデルまたはカスタムモデルを実行できます。
- 完全な移植性: オープン スタンダードによる完全な移植性を活用できます。Google は、Gateway や LeaderWorkerSet などの主要な Kubernetes API に貢献しており、すべての API は Kubernetes ディストリビューションで移植可能です。
- エコシステムのサポート: 高度なリソース キューイングと管理のための Kueue や、分散コンピューティングのための Ray などのツールをサポートする GKE の堅牢なエコシステムを基盤として、スケーラブルで効率的なモデルのトレーニングと推論を容易にします。
GKE での推論の仕組み
このセクションでは、推論サービングに GKE を使用する手順について概略的に説明します。
モデルをコンテナ化する: アプリケーションをコンテナ化するとは、アプリケーションの実行に必要なすべての要素（コード、ランタイム、システムツール、システム ライブラリ、設定）を含む実行可能パッケージであるコンテナ イメージを作成することです。シンプルなアプリケーションは 1 つの単位としてコンテナ化できますが、複雑なアプリケーションは複数のコンテナ化されたコンポーネントに分割できます。モデルサーバー（vLLM など）をコンテナ化し、Cloud Storage または Hugging Face などのリポジトリからモデルの重みを読み込んで、モデルをデプロイします。GKE Inference Quickstart を使用すると、コンテナ化されたイメージがマニフェストで自動的に管理されます。
GKE クラスタを作成する: デプロイをホストする GKE クラスタを作成します。マネージド エクスペリエンスを利用するには Autopilot を、カスタマイズするには Standard を選択します。クラスタサイズ、ノードタイプ、アクセラレータを構成します。最適化された構成については、推論クイックスタートをご覧ください。
モデルを Kubernetes Deployment としてデプロイする: 推論サービスを管理する Kubernetes Deployment を作成します。Deployment は、クラスタ内のノードに分散された Pod の複数のレプリカを実行できる Kubernetes API オブジェクトです。Docker イメージ、レプリカ、設定を指定します。Kubernetes はイメージを pull し、GKE クラスタノードでコンテナを実行します。必要に応じて LoRA アダプタを含め、モデルサーバーとモデルを使用して Pod を構成します。
推論サービスを公開する: Kubernetes Service を作成して Deployment のネットワーク エンドポイントを提供し、推論サービスにアクセスできるようにします。生成 AI 推論ワークロード専用のインテリジェントなロード バランシングとルーティングには、推論ゲートウェイを使用します。生成 AI ワークロード用に調整されたインテリジェントなロード バランシングを行うには、推論ゲートウェイを使用します。あるいは、ロード バランシング戦略の比較を参照して、ニーズに最適なオプションを選択してください。
推論リクエストを処理する: アプリケーション クライアントから Service のエンドポイントに、想定される形式（JSON、gRPC）でデータを送信します。ロードバランサを使用している場合、リクエストはモデルのレプリカに分散されます。モデルサーバーはリクエストを処理し、モデルを実行して推論を返します。
推論デプロイをスケールしてモニタリングする: HPA を使用して推論をスケールし、CPU またはレイテンシに基づいてレプリカを自動的に調整します。HorizontalPodAutoscaler（HPA）は、CPU 使用率やカスタム指標などの観測された指標に基づいて、ワークロード（Deployment など）の Pod の数を自動的に増減する Kubernetes コントローラです。推論クイックスタートを使用して、自動生成されたスケーリングの推奨事項を取得します。パフォーマンスを追跡するには、Cloud Monitoring と Cloud Logging を使用します。これらには、vLLM などの一般的なモデルサーバーのダッシュボードを含む、事前構築済みのオブザーバビリティが含まれています。
特定のモデル、モデルサーバー、アクセラレータを使用する詳細な例については、推論の例をご覧ください。
GKE の生成 AI 機能
GKE 環境での生成 AI モデルのサービングとリソース使用率の向上における主な課題に対処するために、これらの機能は追加費用なしで併用または個別に使用できます。
| 名前 | 説明 | 利点 |
|---|---|---|
| GKE Inference Quickstart |
推論ワークロードのパフォーマンスと費用対効果を分析します。ビジネスニーズを指定すると、ニーズに最適なアクセラレータ、スケーリング、ストレージの構成、モデルサーバーの組み合わせに関するカスタマイズされたベスト プラクティスが提供されます。このサービスには、gcloud CLI と Google Cloud コンソールを使用してアクセスできます。 詳細については、GKE Inference Quickstart を使用してモデル提供のパフォーマンスと費用を分析するをご覧ください。 |
|
| GKE Inference Gateway | レイテンシを改善するために、KV キャッシュ使用率などの指標をもとにルーティングを取得します。 詳細については、GKE Inference Gateway についてをご覧ください。 |
|
| モデルの重み読み込みアクセラレータ | キャッシュ保存と並列ダウンロードが可能な Cloud Storage FUSE を使用して、Cloud Storage のデータにすばやくアクセスします。AI/ML ワークロードに Cloud Storage FUSE を使用する方法については、リファレンス アーキテクチャをご覧ください。 Google Cloud Managed Lustre は、AI 向けに最適化された、高パフォーマンスでフルマネージドの並列ファイル システムで、10,000 個以上の Pod に接続できます。AI/ML ワークロードに Managed Lustre を使用する方法については、リファレンス アーキテクチャをご覧ください。 Google Cloud Hyperdisk ML は、最大 2,500 個の Pod に接続できるネットワーク接続ディスクです。 |
|
推論パフォーマンス指標
推論ワークロードを最適化するには、パフォーマンスを測定する方法を理解することが重要です。次の表に、GKE での推論パフォーマンスに関する主要なベンチマーク指標を示します。
| ベンチマーク指標 | 指標の（単位） | 説明 |
|---|---|---|
| レイテンシ | 最初のトークンまでの時間（TTFT）（ミリ秒） | リクエストの最初のトークンを生成するのにかかる時間。 |
| 正規化された出力トークンあたりの時間（NTPOT）（ミリ秒） | 出力トークンの数で正規化されたリクエストのレイテンシ。request_latency / total_output_tokens として測定されます。 |
|
| 出力トークンあたりの時間（TPOT）（ミリ秒） | 1 つの出力トークンの生成にかかる時間。(request_latency - time_to_first_token) / (total_output_tokens - 1) で測定されます。 |
|
| トークン間のレイテンシ（ITL）（ミリ秒） | 2 つの出力トークン生成間のレイテンシを測定します。リクエスト全体のレイテンシを測定する TPOT とは異なり、ITL は個々の出力トークンの生成にかかる時間を測定します。これらの個々の測定値が集計され、平均値、中央値、パーセンタイル値（p90 など）が生成されます。 | |
| リクエストのレイテンシ（ミリ秒） | リクエストを完了するまでのエンドツーエンドの時間。 | |
| スループット | 1 秒あたりのリクエスト数 | 1 秒あたりに処理するリクエストの合計数。この指標はコンテキストの長さによって大きく異なる可能性があるため、LLM スループットを測定する信頼性の高い方法ではない場合があります。 |
| 1 秒あたりの出力トークン数 | total_output_tokens_generated_by_server / elapsed_time_in_seconds として測定される一般的な指標。 |
|
| 1 秒あたりの入力トークン数 | total_input_tokens_generated_by_server / elapsed_time_in_seconds として測定されます。 |
|
| 1 秒あたりのトークン数 | total_tokens_generated_by_server / elapsed_time_in_seconds として測定されます。この指標は入力トークンと出力トークンの両方をカウントするため、プレフィル時間が長いワークロードとデコード時間が長いワークロードを比較するのに役立ちます。 |
推論の計画
推論のデプロイを成功させるには、費用対効果、パフォーマンス、リソースの取得可能性など、いくつかの重要な分野で慎重に計画を立てる必要があります。スケーラビリティ、パフォーマンス、費用対効果に優れた推論プラットフォームを構築するための詳細な推奨事項については、GKE での推論に関するベスト プラクティスの概要をご覧ください。
推論の例を試す
生成 AI モデル、アクセラレータ、モデルサーバーの GKE デプロイ例を確認します。初めて使用する場合は、GKE の GPU で vLLM を使用して Gemma オープンモデルを提供するチュートリアルをご覧ください。
または、キーワードでチュートリアルを検索します。
| アクセラレータ | モデルサーバー | チュートリアル |
|---|---|---|
| GPU | vLLM | GKE で DeepSeek-R1 671B や Llama 3.1 405B などの LLM を提供する |
| GPU | vLLM | GKE の GPU で vLLM を使用して Gemma オープンモデルを提供する |
| GPU | vLLM | GKE Inference Gateway を使用して LLM をサービングする |
| GPU | vLLM | 事前構成されたアーキテクチャ を使用して GKE でオープン LLM を提供する |
| GPU | Ray Serve | Ray を使用して L4 GPU で LLM を提供する |
| GPU | TGI | GKE で複数の GPU を使用して LLM を提供する |
| GPU | TorchServe | GKE で TorchServe を使用して T5 をサービングする |
| TPU | vLLM | GKE で TPU Trillium と vLLM を使用して LLM をサービングする |
| TPU | vLLM | GKE で vLLM を実行して TPU を使用して LLM をサービングする |
| TPU | MaxDiffusion | MaxDiffusion を備えた GKE で TPU を使用して Stable Diffusion XL（SDXL）を提供する |
| TPU | vLLM | マルチホスト TPU を使用して LLM をサービングする |
| TPU | vLLM | 事前構成されたアーキテクチャ を使用して TPU でオープン LLM を提供する |
次のステップ
- GKE での AI / ML オーケストレーション ポータルにアクセスして、GKE で AI / ML ワークロードを実行するための公式ガイド、チュートリアル、ユースケースを確認する。
- GKE を活用して AI / ML イニシアチブを加速するための試験運用版のサンプルを GKE AI Labs で確認する。