推論サービングは、生成 AI モデルを実際のアプリケーションにデプロイするうえで重要です。GKE は、コンテナ化されたワークロードを管理するための堅牢でスケーラブルなプラットフォームを提供します。そのため、開発環境または本番環境でモデルをサービングする場合に最適な選択肢となります。GKE を使用すると、オーケストレーション、スケーリング、高可用性のために Kubernetes の機能を使用して、推論サービスを効率的にデプロイし、管理できます。
AI/ML 推論の特定の要件を認識し、 Google Cloud では GKE 生成 AI 機能が導入されました。これは、GKE での推論サービングを強化して最適化するために特別に設計された機能スイートです。特定の機能の詳細については、GKE 生成 AI 機能をご覧ください。
GKE で AI/ML モデル推論を始める
GKE での AI/ML モデル推論は、数分で使い始めることができます。GKE の無料枠を使用して、クラスタ管理に費用をかけずに Kubernetes を開始できます。
- モデルをデプロイするの手順に沿って、コンテナ化されたモデルとモデルサーバーをデプロイします。
- 推論の計画で、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 のデータにすばやくアクセスします。 一貫したスケールアウト パフォーマンスを必要とする推論ワークロードには、最大 2,500 個の Pod に接続できるネットワーク接続ディスクであるGoogle Cloud Hyperdisk ML が適しています。 |
|
推論の計画
このセクションでは、GKE での推論ワークロードについて考慮すべき重要な事項について説明します。
費用対効果
大規模な生成 AI モデルのサービングは、アクセラレータの使用により費用がかかる可能性があるため、リソースの効率的な使用に重点を置く必要があります。アクセラレータのメモリをモデルサイズと量子化レベルに一致させるには、適切なマシンタイプとアクセラレータを選択することが重要です。たとえば、NVIDIA L4 GPU を搭載した G2 インスタンスは小規模なモデルに適しており、A3 インスタンスは大規模なモデルに適しています。
費用対効果を最大化するには、次のヒントと推奨事項を参考にしてください。
- Inference Quickstart を使用して、パフォーマンスのニーズに基づいて推奨されるアクセラレータを取得します。
- 量子化やリクエスト バッチ処理などの手法を使用して、サービングの効率を高めます。詳細については、GPU を使用して大規模言語モデルの推論を最適化する際のベスト プラクティスをご覧ください。
自動スケーリングを使用します。自動スケーリングは、需要に応じてリソースを動的に調整します。これにより、特に変動するワークロードの費用を削減できます。詳細については、次のリソースをご覧ください。
パフォーマンス
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 として測定されます。この指標は入力トークンと出力トークンの両方をカウントするため、プレフィル時間が長いワークロードとデコード時間が長いワークロードを比較するのに役立ちます。 |
パフォーマンスに関するその他のヒントと推奨事項は次のとおりです。
- パフォーマンスのニーズに基づいて推奨されるアクセラレータを取得するには、Inference Quickstart を使用します。
- パフォーマンスを向上させるには、ベスト プラクティス ガイドに記載されているバッチ処理や PagedAttention などのモデルサーバーの最適化手法を使用します。また、トークン間のレイテンシを常に低く保つために、効率的なメモリ管理とアテンション計算を優先します。
- モデルサーバー（Hugging Face TGI、vLLM、NVIDIA Triton など）で標準化された指標を使用して、自動スケーリングとロード バランシングを改善します。これにより、選択したレイテンシでスループットを向上させることができます。GKE は、複数のモデルサーバーに対してアプリケーションの自動モニタリングを提供します。
- Inference Gateway などの GKE ネットワーク インフラストラクチャ機能を使用して、レイテンシを最小限に抑えます。
Cloud Storage FUSE と並列ダウンロードおよびキャッシュ保存、または Hyperdisk ML を使用して、永続ストレージからのモデルの重み付けの読み込みを高速化します。
大規模なトレーニングや推論には、Pathways を使用します。Pathways は、単一の JAX クライアントで複数の大規模な TPU スライスにまたがるワークロードをオーケストレートすることで、大規模な ML 計算を簡素化します。詳細については、Pathways をご覧ください。
取得可能性
リソース（CPU、GPU、TPU）の取得可能性の確保は、推論ワークロードのパフォーマンス、可用性、費用対効果を維持するために重要です。推論ワークロードでは、バースト的で予測不可能なトラフィック パターンが頻繁に発生し、ハードウェア容量が不足することがあります。GKE は、次のような機能でこれらの課題に対処します。
- リソース使用量のオプション: 保証容量の予約、費用対効果の高いスケーリング、Dynamic Workload Scheduler、Spot VM などのオプションから選択して、費用を最適化し、すぐに利用できるオンデマンド アクセスを実現します。
- リソースの適正サイズ設定: たとえば、 Google Cloud は、費用対効果の高い生成 AI 推論スケーリング用に、NVIDIA H100 GPU（1g、2g、4g）を搭載した小規模な A3 High VM を提供しています。この VM は Spot VM をサポートしています。
- アクセラレータのコンピューティング クラス: カスタム コンピューティング クラスを使用すると、よりきめ細かい制御が可能になり、オーバー プロビジョニングを防ぎ、自動フォールバック オプションを使用してリソースの取得可能性を最大化できます。
ノードのアップグレード
GKE ではアップグレード プロセスの多くが自動化されていますが、特に互換性とテストについては、アップグレード戦略を検討する必要があります。手動アップグレードでは、推論ワークロードの中断に対する許容度に基づいて、サージ アップグレードまたは Blue/Green アップグレードを選択できます。サージ アップグレードは高速ですが、サービスに一時的に影響する可能性があります。Blue/Green アップグレードは、リアルタイム推論に不可欠なほぼゼロのダウンタイムを実現します。詳細については、ノードのアップグレード戦略をご覧ください。
GPU と TPU はライブ マイグレーションをサポートしていないため、メンテナンスには Pod の再起動が必要です。GKE 通知を使用して、中断に備えます。Pod Disruption Budget（PDB）を使用して、最低限の Pod が使用可能な状態を維持することをおすすめします。Pod が終了を適切に処理できることを確認します。TPU スライスは単一ホストイベントによって中断される可能性があるため、冗長性を計画してください。その他のベスト プラクティスについては、GPU と TPU の GKE ノードの中断を管理するをご覧ください。
推論の例を試す
生成 AI モデル、アクセラレータ、モデルサーバーの GKE デプロイ例を確認します。初めて使用する場合は、GKE の GPU で vLLM を使用して Gemma オープンモデルを提供するチュートリアルをご覧ください。
または、キーワードでチュートリアルを検索します。
| アクセラレータ | モデルサーバー | チュートリアル |
|---|---|---|
| GPU | vLLM | GKE で DeepSeek-R1 671B や Llama 3.1 405B などの LLM を提供する |
| GPU | vLLM | GKE の GPU で vLLM を使用して Llama モデルをサービングする |
| GPU | vLLM | GKE の GPU で vLLM を使用して Gemma オープンモデルを提供する |
| GPU | vLLM | GKE Inference Gateway を使用して LLM をサービングする |
| GPU | vLLM | 事前構成されたアーキテクチャ を使用して GKE でオープン LLM を提供する |
| GPU | NVIDIA Triton | GKE で単一の GPU を持つモデルを提供する |
| GPU | Ray Serve | Ray を使用して L4 GPU で LLM を提供する |
| GPU | TGI | GKE で複数の GPU を使用して LLM を提供する |
| GPU | NVIDIA Triton | Triton と TensorRT-LLM を備えた GKE で GPU を使用して Gemma オープンモデルを提供する |
| GPU | Hugging Face TGI | GKE の GPU で Hugging Face TGI を使用して Gemma オープンモデルを提供する |
| GPU | TensorFlow Serving | GKE で単一の GPU を持つモデルを提供する |
| TPU | vLLM | GKE で TPU Trillium と vLLM を使用して LLM をサービングする |
| TPU | vLLM | GKE で vLLM を実行して TPU を使用して LLM をサービングする |
| TPU | JetStream | GKE の TPU で JetStream と PyTorch を使用して LLM をサービングする |
| TPU | JetStream | GKE で TPU と JetStream を使用して Gemma をサービングする |
| TPU | MaxDiffusion | MaxDiffusion を備えた GKE で TPU を使用して Stable Diffusion XL（SDXL）を提供する |
| TPU | Optimum TPU | Optimum TPU を活用し、GKE 上で TPU を使用してオープンソース モデルをサービングする |
次のステップ
- GKE での AI / ML のオーケストレーション ポータルにアクセスして、GKE で AI / ML ワークロードを実行するための公式ガイド、チュートリアル、ユースケースを確認する。
- モデル提供の最適化の詳細について GPU を使用して大規模言語モデルの推論を最適化する際のベスト プラクティスで確認する。量子化、テンソル並列処理、メモリ管理など、GKE の GPU で LLM を提供する際のベスト プラクティスについて説明します。
- GKE を活用して AI/ML イニシアチブを加速するための試験運用版のサンプルを GKE AI Labs で確認する。