このページでは、GKE Inference Quickstart を使用して、Google Kubernetes Engine（GKE）での AI / ML 推論ワークロードのデプロイを簡素化する方法について説明します。Inference Quickstart は、推論のビジネス要件を指定し、モデル、モデルサーバー、アクセラレータ（GPU、TPU）、スケーリング、ストレージに関するベスト プラクティスと Google のベンチマークに基づいて、最適化された Kubernetes 構成を取得できるユーティリティです。これにより、構成を手動で調整してテストする必要がなくなり、時間を節約することができます。
このページは、AI / ML 推論用に GKE を効率的に管理して最適化する方法を探している機械学習（ML）エンジニア、プラットフォーム管理者、オペレーター、データおよび AI スペシャリストを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。
モデル サービングのコンセプトと用語、GKE の生成 AI 機能を使用してモデル サービングのパフォーマンスを強化する方法については、GKE でのモデル推論についてをご覧ください。
このページを読む前に、Kubernetes、GKE、モデル サービングについて理解しておいてください。
Inference Quickstart の使用
Inference Quickstart を使用すると、推論ワークロードのパフォーマンスと費用対効果を分析し、リソース割り当てとモデル デプロイ戦略についてデータに基づいた意思決定を行うことができます。
Inference Quickstart を使用する手順の概要は次のとおりです。
パフォーマンスと費用を分析する:
gcloud container ai profiles listコマンドを使用して、使用可能な構成を調べ、パフォーマンスと費用の要件に基づいてフィルタします。特定の構成のベンチマーク データの完全なセットを表示するには、gcloud container ai profiles benchmarks listコマンドを使用します。このコマンドを使用すると、特定のパフォーマンス要件に最も費用対効果の高いハードウェアを特定できます。マニフェストをデプロイする: 分析後、最適化された Kubernetes マニフェストを生成してデプロイできます。必要に応じて、ストレージと自動スケーリングの最適化を有効にできます。デプロイは、 Google Cloud コンソールから行うことも、
kubectl applyコマンドを使用して行うこともできます。デプロイする前に、 Google Cloud プロジェクトで選択した GPU または TPU に十分なアクセラレータ割り当てがあることを確認する必要があります。（省略可）独自のベンチマークを実行する: 提供されている構成とパフォーマンス データは、ShareGPT データセットを使用するベンチマークに基づいています。ワークロードのパフォーマンスは、このベースラインと異なる場合があります。さまざまな条件下でモデルのパフォーマンスを測定するには、試験運用版の inference-benchmark ツールを使用します。
利点
Inference Quickstart から最適化された構成が提供されるため、時間とリソースを節約できます。この最適化により、次のようにパフォーマンスを向上させ、インフラストラクチャの費用を抑えることができます。
- アクセラレータ（GPU と TPU）、モデルサーバー、スケーリング構成を設定する際の詳細なベスト プラクティスが提示されます。GKE は、最新の修正、イメージ、パフォーマンス ベンチマークを使用して Inference Quickstart を定期的に更新します。
- Google Cloud コンソール UI またはコマンドライン インターフェースを使用して、ワークロードのレイテンシとスループットの要件を指定し、Kubernetes デプロイ マニフェストとして詳細なベスト プラクティスを取得できます。
仕組み
Inference Quickstart は、モデル、モデルサーバー、アクセラレータ トポロジの組み合わせに対する単一レプリカのパフォーマンスについて、Google の包括的な内部ベンチマークを使用して、カスタマイズされたベスト プラクティスを提供します。これらのベンチマークでは、キューサイズや KV キャッシュ指標など、レイテンシとスループットをグラフで表示し、それぞれの組み合わせのパフォーマンス曲線を示します。
カスタマイズされたベスト プラクティスの生成方法
レイテンシは、出力トークンあたりの正規化された時間（NTPOT）と最初のトークンまでの時間（TTFT）でミリ秒単位で測定されます。また、アクセラレータを飽和させることで、出力トークンあたりのスループットが秒単位で測定されます。これらのパフォーマンス指標の詳細については、GKE でのモデル推論についてをご覧ください。
次のレイテンシ プロファイルの例は、スループットが横ばいになる変曲点（緑色）、レイテンシが悪化する変曲点（赤色）、レイテンシ ターゲットで最適なスループットを得るための理想的なゾーン（青色）を示しています。Inference Quickstart には、この理想的なゾーンのパフォーマンス データと構成が用意されています。
Inference Quickstart は、推論アプリケーションのレイテンシ要件に基づいて適切な組み合わせを特定し、レイテンシとスループットの曲線上の最適な動作ポイントを決定します。このポイントで、HorizontalPodAutoscaler（HPA）のしきい値が設定され、スケールアップ レイテンシを考慮したバッファが設定されます。全体的なしきい値では、必要なレプリカの初期数も示しますが、HPA はワークロードに基づいてこの数を動的に調整します。
コスト計算
費用を計算するために、Inference Quickstart は構成可能な出力対入力の費用比率を使用します。たとえば、この比率が 4 に設定されている場合、各出力トークンの費用は入力トークンの 4 倍と見なされます。次の式を使用して、トークンあたりの費用指標を計算します。
\[ \$/\text{output token} = \frac{\text{GPU \$/s}}{(\frac{1}{\text{output-to-input-cost-ratio}} \cdot \text{input tokens/s} + \text{output tokens/s})} \]
ここで
\[ \$/\text{input token} = \frac{\text{\$/output token}}{\text{output-to-input-cost-ratio}} \]
ベンチマーク
提供されている構成とパフォーマンス データは、ShareGPT データセットを使用して次の入出力分布でトラフィックを送信するベンチマークに基づいています。
| 入力トークン | 出力トークン | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 最小 | 中央値 | 平均 | P90 | P99 | 最大 | 最小 | 中央値 | 平均 | P90 | P99 | 最大 |
| 4 | 108 | 226 | 635 | 887 | 1024 | 1 | 132 | 195 | 488 | 778 | 1024 |
始める前に
作業を始める前に、次のタスクが完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateコマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
Google Cloud コンソールのプロジェクト セレクタページで、 Google Cloud プロジェクトを選択または作成します。
プロジェクトに十分なアクセラレータ容量があることを確認します。
- GPU を使用している場合: [割り当て] ページを確認します。
- TPU を使用している場合: TPU と他の GKE リソースの割り当てを確保するをご覧ください。
GKE AI / ML ユーザー インターフェースを使用する準備をする
Google Cloud コンソールを使用する場合、プロジェクトに Autopilot クラスタがまだ作成されていなければ、Autopilot クラスタの作成も必要になります。Autopilot クラスタを作成するの手順に沿って操作します。
コマンドライン インターフェースを使用する準備をする
gcloud CLI を使用して Inference Quickstart を実行する場合は、次の追加コマンドも実行する必要があります。
gkerecommender.googleapis.comAPI を有効にします。gcloud services enable gkerecommender.googleapis.comAPI 呼び出しに使用する課金割り当てプロジェクトを設定します。
gcloud config set billing/quota_project PROJECT_IDgcloud CLI のバージョンが 536.0.1 以降であることを確認します。そうでない場合は、次のコマンドを実行します。
gcloud components update
制限事項
Inference Quickstart の使用を開始する前に、次の制限事項に注意してください。
- Google Cloud コンソールでモデルをデプロイする場合、Autopilot クラスタへのデプロイのみがサポートされています。
- Inference Quickstart では、特定のモデルサーバーでサポートされているすべてのモデルのプロファイルが提供されるわけではありません。
- Hugging Face の大規模モデル（90 GiB 以上）用に生成されたマニフェストを使用するときに
HF_HOME環境変数を設定しない場合は、デフォルトよりも大きいブートディスクを含むクラスタを使用するか、マニフェストを変更してHF_HOMEを/dev/shm/hf_cacheに設定する必要があります。これにより、ノードのブートディスクではなく、RAM がキャッシュに使用されます。詳細については、トラブルシューティングをご覧ください。 - Cloud Storage からのモデルの読み込みは、Cloud Storage FUSE CSI ドライバと Workload Identity Federation for GKE が有効になっているクラスタへのデプロイのみをサポートしています。これらはどちらも、Autopilot クラスタでデフォルトで有効になっています。詳細については、GKE 用に Cloud Storage FUSE CSI ドライバを設定するをご覧ください。
モデル推論用に最適化された構成を分析して表示する
このセクションでは、Google Cloud CLI を使用して構成の推奨事項を調査して分析する方法について説明します。
gcloud container ai profiles コマンドを使用して、最適化されたプロファイル（モデル、モデルサーバー、モデルサーバー バージョン、アクセラレータの組み合わせ）を探索して分析します。
モデル
モデルを探索して選択するには、models オプションを使用します。
gcloud container ai profiles models list
プロファイル
list コマンドを使用して、生成されたプロファイルを調べ、パフォーマンスと費用の要件に基づいてフィルタします。次に例を示します。
gcloud container ai profiles list \
--model=openai/gpt-oss-20b \
--pricing-model=on-demand \
--target-ttft-milliseconds=300
出力には、変曲点でのスループット、レイテンシ、100 万トークンあたりの費用などのパフォーマンス指標を含む、サポートされているプロファイルが表示されます。たとえば、次のように表示されます。
Instance Type Accelerator Cost/M Input Tokens Cost/M Output Tokens Output Tokens/s NTPOT(ms) TTFT(ms) Model Server Model Server Version Model
a3-highgpu-1g nvidia-h100-80gb 0.009 0.035 13335 67 297 vllm gptoss openai/gpt-oss-20b
この値は、このアクセラレータ タイプで特定のプロファイルの処理量の増加が停止し、レイテンシが急増し始めるポイント（つまり、変曲点または飽和点）で観測されたパフォーマンスを表します。これらのパフォーマンス指標の詳細については、GKE でのモデル推論についてをご覧ください。
設定できるフラグの完全なリストについては、list コマンドのドキュメントをご覧ください。
すべての料金情報は米ドルでのみ提供され、A3 マシンを使用する構成を除き、デフォルトで us-east5 リージョンに設定されます。A3 マシンを使用する構成は、デフォルトで us-central1 リージョンに設定されます。
ベンチマーク
特定のプロファイルのすべてのベンチマーク データを取得するには、benchmarks list コマンドを使用します。
次に例を示します。
gcloud container ai profiles benchmarks list \
--model=deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \
--model-server=vllm
出力には、さまざまなリクエスト レートで実行されたベンチマークのパフォーマンス指標のリストが含まれます。
コマンドは、出力を CSV 形式で表示します。出力をファイルとして保存するには、出力のリダイレクトを使用します。例: gcloud container ai profiles benchmarks list > profiles.csv。
設定できるフラグの完全なリストについては、benchmarks list コマンドのドキュメントをご覧ください。
モデル、モデルサーバー、モデルサーバーのバージョン、アクセラレータを選択したら、デプロイ マニフェストの作成に進みます。
推奨構成をデプロイする
このセクションでは、 Google Cloud コンソールまたはコマンドラインを使用して構成の推奨事項を生成し、デプロイする方法について説明します。
コンソール
- Google Cloud コンソールで、[GKE AI/ML] ページに移動します。
- [モデルをデプロイ] をクリックします。
デプロイするモデルを選択します。Inference Quickstart でサポートされているモデルには、「最適化」というタグが表示されます。
- 基盤モデルを選択すると、モデルページが開きます。[デプロイ] をクリックします。実際のデプロイ前に構成を変更できます。
- プロジェクトに Autopilot クラスタがない場合、Autopilot クラスタを作成するよう求められます。Autopilot クラスタを作成するの手順に沿って操作します。クラスタを作成したら、 Google Cloud コンソールの [GKE AI / ML] ページに戻り、モデルを選択します。
モデルのデプロイページに、選択したモデルと、推奨されるモデルサーバー / アクセラレータが自動的に入力されています。最大レイテンシやモデルソースなどの設定も構成できます。
（省略可）推奨構成のマニフェストを表示するには、[YAML を表示] をクリックします。
推奨構成でマニフェストをデプロイするには、[デプロイ] をクリックします。デプロイ オペレーションが完了するまでに数分かかることがあります。
デプロイを表示するには、[Kubernetes Engine] > [ワークロード] ページに移動します。
gcloud
モデルレジストリからモデルを読み込む準備をする: 推論クイックスタートでは、Hugging Face または Cloud Storage からモデルを読み込むことができます。
Hugging Face
Hugging Face アクセス トークンと、対応する Kubernetes Secret を生成します（まだ生成していない場合）。
Hugging Face トークンを含む Kubernetes Secret を作成するには、次のコマンドを実行します。
kubectl create secret generic hf-secret \ --from-literal=hf_api_token=HUGGING_FACE_TOKEN \ --namespace=NAMESPACE次の値を置き換えます。
- HUGGING_FACE_TOKEN: 先ほど生成した Hugging Face トークン。
- NAMESPACE: モデルサーバーをデプロイする Kubernetes Namespace。
モデルによっては、ライセンス契約に同意して署名することが求められることもあります。
Cloud Storage
調整された Cloud Storage FUSE 設定を使用して、Cloud Storage からサポートされているモデルを読み込むことができます。これを行うには、まず Hugging Face から Cloud Storage バケットにモデルを読み込む必要があります。
この Kubernetes Job をデプロイしてモデルを転送し、
MODEL_IDを推論クイックスタートでサポートされているモデルに変更できます。マニフェストを生成する: マニフェストの生成には次のオプションがあります。
- 基本構成: 単一レプリカ推論サーバーをデプロイするための標準の Kubernetes Deployment、Service、PodMonitoring マニフェストを生成します。
- （省略可）ストレージ最適化構成: チューニングされた Cloud Storage FUSE 設定を含むマニフェストを生成し、Cloud Storage バケットからモデルを読み込みます。この構成は、
--model-bucket-uriフラグを使用して有効にします。調整された Cloud Storage FUSE 設定により、LLM Pod の起動時間を 7 倍以上短縮できます。 （省略可）自動スケーリング用に最適化された構成: HorizontalPodAutoscaler（HPA）を含むマニフェストを生成し、トラフィックに基づいてモデルサーバー レプリカの数を自動的に調整します。この構成を有効にするには、
--target-ntpot-millisecondsなどのフラグを使用してレイテンシ ターゲットを指定します。
基本構成
ターミナルで
manifestsオプションを使用して、Deployment、Service、PodMonitoring のマニフェストを生成します。gcloud container ai profiles manifests create必要な
--model、--model-server、--accelerator-typeパラメータを使用して、マニフェストをカスタマイズします。必要に応じて、次のパラメータを設定できます。
--target-ntpot-milliseconds: このパラメータを設定して HPA しきい値を指定します。このパラメータを使用すると、スケーリングしきい値を定義し、出力トークンあたりの正規化時間（NTPOT）の P50 レイテンシ（50 パーセンタイルで測定）を指定値未満に保つことができます。アクセラレータの最小レイテンシより大きい値を選択します。アクセラレータの最大レイテンシを超える NTPOT 値を指定すると、HPA は最大スループット用に構成されます。次に例を示します。gcloud container ai profiles manifests create \ --model=google/gemma-2-27b-it \ --model-server=vllm \ --model-server-version=v0.7.2 \ --accelerator-type=nvidia-l4 \ --target-ntpot-milliseconds=200--target-ttft-milliseconds: TTFT レイテンシ ターゲットを超えるプロファイルをフィルタで除外します。--output-path: 指定すると、出力はターミナルではなく、指定されたパスに保存されるため、デプロイする前に出力を編集できます。たとえば、マニフェストを YAML ファイルに保存する場合は、--output=manifestオプションを使用します。次に例を示します。gcloud container ai profiles manifests create \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --model-server vllm \ --accelerator-type=nvidia-tesla-a100 \ --output=manifest \ --output-path /tmp/manifests.yaml
設定できるフラグの完全なリストについては、
manifests createコマンドのドキュメントをご覧ください。ストレージ最適化
調整された Cloud Storage FUSE 構成を使用して Cloud Storage からモデルを読み込むことで、Pod の起動時間を短縮できます。Cloud Storage からの読み込みには、GKE バージョン 1.29.6-gke.1254000、1.30.2-gke.1394000 以降が必要です
その手順は次のとおりです。
- Hugging Face リポジトリから Cloud Storage バケットにモデルを読み込みます。
マニフェストを生成するときに
--model-bucket-uriフラグを設定します。これにより、Cloud Storage FUSE CSI ドライバを使用して Cloud Storage バケットから読み込むようにモデルが構成されます。URI は、モデルのconfig.jsonファイルと重みを含むパスを指している必要があります。バケット URI にディレクトリのパスを追加することで、バケット内のディレクトリのパスを指定できます。次に例を示します。
gcloud container ai profiles manifests create \ --model=google/gemma-2-27b-it \ --model-server=vllm \ --accelerator-type=nvidia-l4 \ --model-bucket-uri=gs://BUCKET_NAME \ --output-path=manifests.yamlBUCKET_NAMEは、Cloud Storage バケットの名前に置き換えます。マニフェストを適用する前に、マニフェストのコメントにある
gcloud storage buckets add-iam-policy-bindingコマンドを実行する必要があります。このコマンドは、Workload Identity Federation for GKE を使用して Cloud Storage バケットにアクセスする権限を GKE サービス アカウントに付与するために必要です。Deployment を複数のレプリカにスケーリングする場合は、次のいずれかのオプションを選択して、XLA キャッシュ パス（
VLLM_XLA_CACHE_PATH）への同時書き込みエラーを防ぐ必要があります。- オプション 1（推奨）: まず、Deployment を 1 つのレプリカにスケーリングします。Pod の準備ができるまで待ちます。これにより、XLA キャッシュに書き込むことができます。次に、必要なレプリカ数にスケールアップします。後続のレプリカは、書き込みの競合なしで、入力されたキャッシュから読み取ります。
- オプション 2: マニフェストから
VLLM_XLA_CACHE_PATH環境変数を完全に削除します。この方法は簡単ですが、すべてのレプリカのキャッシュ保存が無効になります。
TPU アクセラレータ タイプでは、このキャッシュ パスは XLA コンパイル キャッシュの保存に使用されます。これにより、繰り返しデプロイするモデルの準備が高速化されます。
パフォーマンスを向上させるためのその他のヒントについては、GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化するをご覧ください。
自動スケーリング向けに最適化
HorizontalPodAutoscaler（HPA）を構成して、負荷に基づいてモデルサーバー レプリカの数を自動的に調整できます。これにより、モデルサーバーは必要に応じてスケールアップまたはスケールダウンすることで、さまざまな負荷を効率的に処理できます。HPA 構成は、GPU と TPU のガイドの自動スケーリングのベスト プラクティスに準拠しています。
マニフェストの生成時に HPA 構成を含めるには、
--target-ntpot-millisecondsフラグと--target-ttft-millisecondsフラグのいずれかまたは両方を使用します。これらのパラメータは、NTPOT または TTFT の P50 レイテンシを指定値未満に保つための HPA のスケーリングしきい値を定義します。これらのフラグのいずれか 1 つのみを設定すると、その指標のみがスケーリングの対象となります。アクセラレータの最小レイテンシより大きい値を選択します。アクセラレータの最大レイテンシを超える値を指定すると、HPA は最大スループット用に構成されます。
次に例を示します。
gcloud container ai profiles manifests create \ --model=google/gemma-2-27b-it \ --accelerator-type=nvidia-l4 \ --target-ntpot-milliseconds=250クラスタを作成する: GKE Autopilot クラスタまたは GKE Standard クラスタでモデルを提供できます。フルマネージドの Kubernetes エクスペリエンスを実現するには、Autopilot クラスタを使用することをおすすめします。ワークロードに最適な GKE の運用モードを選択するには、GKE の運用モードを選択するをご覧ください。
既存のクラスタがない場合は、次の操作を行います。
Autopilot
次の手順で Autopilot クラスタを作成します。プロジェクトに必要な割り当てがある場合、GKE はデプロイ マニフェストに基づいて GPU または TPU 容量を持つノードのプロビジョニングを処理します。
Standard
- ゾーンまたはリージョン クラスタを作成します。
適切なアクセラレータを使用してノードプールを作成します。選択したアクセラレータ タイプに応じて、次の操作を行います。
- GPU: まず、 Google Cloud コンソールの [割り当て] ページで、十分な GPU 容量があることを確認します。次に、GPU ノードプールを作成するの手順に沿って操作します。
- TPU: まず、TPU と他の GKE リソースの割り当てを確保するの手順に沿って、十分な TPU があることを確認します。次に、TPU ノードプールを作成するに進みます。
（省略可、ただし推奨）オブザーバビリティ機能を有効にする: 生成されたマニフェストのコメント セクションには、推奨されるオブザーバビリティ機能を有効にするための追加コマンドがあります。これらの機能を有効にすると、ワークロードと基盤となるインフラストラクチャのパフォーマンスやステータスをモニタリングする際に役立つ詳細な分析情報を得ることができます。
オブザーバビリティ機能を有効にするコマンドの例を次に示します。
gcloud container clusters update $CLUSTER_NAME \ --project=$PROJECT_ID \ --location=$LOCATION \ --enable-managed-prometheus \ --logging=SYSTEM,WORKLOAD \ --monitoring=SYSTEM,DEPLOYMENT,HPA,POD,DCGM \ --auto-monitoring-scope=ALL詳細については、推論ワークロードをモニタリングするをご覧ください。
（HPA のみ）指標アダプタをデプロイする: デプロイ マニフェストで HPA リソースが生成された場合は、Custom Metrics Stackdriver Adapter などの指標アダプタが必要です。指標アダプタを使用すると、HPA は kube external metrics API を使用するモデルサーバー指標にアクセスできます。アダプタをデプロイするには、GitHub のアダプタ ドキュメントをご覧ください。
マニフェストをデプロイする:
kubectl applyコマンドを実行し、マニフェストの YAML ファイルを渡します。次に例を示します。kubectl apply -f ./manifests.yaml
デプロイ エンドポイントをテストする
マニフェストをデプロイした場合、デプロイされたサービスは次のエンドポイントで公開されます。
http://model-model_server-service:8000/
モデルサーバー（vLLM など）は通常、ポート 8000 をリッスンします。
デプロイをテストするには、ポート転送を設定する必要があります。別のターミナルで次のコマンドを実行します。
kubectl port-forward service/model-model_server-service 8000:8000
エンドポイントにリクエストを作成して送信する方法の例については、vLLM のドキュメントをご覧ください。
マニフェストのバージョニング
Inference Quickstart には、最新の GKE クラスタ バージョンで検証された最新のマニフェストが用意されています。プロファイルに対して返されるマニフェストは、デプロイ時に最適化された構成を受け取れるように、時間の経過とともに変更される可能性があります。安定したマニフェストが必要な場合は、マニフェストを個別に保存して保管します。
マニフェストには、次の形式のコメントと recommender.ai.gke.io/version アノテーションが含まれています。
# Generated on DATE using:
# GKE cluster CLUSTER_VERSION
# GPU_DRIVER_VERSION GPU driver for node version NODE_VERSION
# Model server MODEL_SERVER MODEL_SERVER_VERSION
上記のアノテーションには次の値があります。
- DATE: マニフェストが生成された日付。
- CLUSTER_VERSION: 検証に使用される GKE クラスタのバージョン。
- NODE_VERSION: 検証に使用される GKE ノードのバージョン。
- GPU_DRIVER_VERSION:（GPU のみ）検証に使用される GPU ドライバのバージョン。
- MODEL_SERVER: マニフェストで使用されるモデルサーバー。
- MODEL_SERVER_VERSION: マニフェストで使用されるモデルサーバーのバージョン。
推論ワークロードをモニタリングする
デプロイされた推論ワークロードをモニタリングするには、 Google Cloud コンソールの Metrics Explorer に移動します。
自動モニタリングを有効にする
GKE には、より広範なオブザーバビリティ機能の一部として自動モニタリング機能があります。この機能は、サポートされているモデルサーバーで実行されているワークロードをクラスタでスキャンし、これらのワークロード指標を Cloud Monitoring に表示できるようにする PodMonitoring リソースをデプロイします。自動モニタリングの有効化と構成の詳細については、ワークロードの自動アプリケーション モニタリングを構成するをご覧ください。
この機能を有効にすると、GKE はサポートされているワークロードのアプリケーションをモニタリングするための事前構築済みダッシュボードをインストールします。
Google Cloud コンソールの GKE AI / ML ページからデプロイすると、targetNtpot 構成を使用して PodMonitoring リソースと HPA リソースが自動的に作成されます。
トラブルシューティング
- レイテンシを低く設定しすぎると、推奨事項が生成されないことがあります。この問題を解決するには、選択したアクセラレータで観測された最小レイテンシと最大レイテンシの間のレイテンシ目標を選択します。
- Inference Quickstart は GKE コンポーネントとは独立して存在するため、クラスタのバージョンはサービスの使用に直接関係しません。ただし、パフォーマンスの差異を回避するため、新しいクラスタまたは最新のクラスタを使用することをおすすめします。
gkerecommender.googleapis.comコマンドで割り当てプロジェクトが見つからないというPERMISSION_DENIEDエラーが発生した場合は、手動で設定する必要があります。gcloud config set billing/quota_project PROJECT_IDを実行して修正します。
エフェメラル ストレージが不足しているため、Pod が強制排除されました
Hugging Face から大規模モデル（90 GiB 以上）をデプロイすると、Pod が強制終了され、次のようなエラー メッセージが表示されることがあります。
Fails because inference server consumes too much ephemeral storage, and gets evicted low resources: Warning Evicted 3m24s kubelet The node was low on resource: ephemeral-storage. Threshold quantity: 10120387530, available: 303108Ki. Container inference-server was using 92343412Ki, request is 0, has larger consumption of ephemeral-storage..,
このエラーは、モデルがノードのブートディスク（エフェメラル ストレージの一種）にキャッシュ保存されているために発生します。デプロイ マニフェストで HF_HOME 環境変数がノードの RAM 内のディレクトリに設定されていない場合、ブートディスクはエフェメラル ストレージに使用されます。
- デフォルトでは、GKE ノードには 100 GiB のブートディスクがあります。
- GKE は、ブートディスクの 10% をシステム オーバーヘッド用に予約し、ワークロード用に 90 GiB を残します。
- モデルサイズが 90 GiB 以上で、デフォルト サイズのブートディスクで実行されている場合、kubelet は Pod を削除してエフェメラル ストレージを解放します。
この問題を解決するには、次のいずれかのオプションを選択します。
- モデルのキャッシュ保存に RAM を使用する: Deployment マニフェストで、
HF_HOME環境変数を/dev/shm/hf_cacheに設定します。これにより、ブートディスクではなくノードの RAM を使用してモデルをキャッシュに保存します。 -
ブートディスクのサイズを増やす:
- GKE Standard: クラスタの作成、ノードプールの作成、またはノードプールの更新時に、ブートディスクのサイズを増やします。
- Autopilot: より大きなブートディスクをリクエストするには、カスタム コンピューティング クラスを作成し、
machineTypeルールでbootDiskSizeフィールドを設定します。
Cloud Storage からモデルを読み込むときに Pod がクラッシュ ループに入る
--model-bucket-uri フラグで生成されたマニフェストをデプロイすると、Deployment が停止し、Pod が CrashLoopBackOff 状態になることがあります。inference-server コンテナのログを確認すると、huggingface_hub.errors.HFValidationError などの誤解を招くエラーが表示されることがあります。次に例を示します。
huggingface_hub.errors.HFValidationError: Repo id must use alphanumeric chars or '-', '_', '.', '--' and '..' are forbidden, '-' and '.' cannot start or end the name, max length is 96: '/data'.
このエラーは通常、--model-bucket-uri フラグで指定された Cloud Storage パスが正しくない場合に発生します。vLLM などの推論サーバーが、マウントされたパスで必要なモデルファイル（config.json など）を見つけられません。ローカル ファイルが見つからない場合、サーバーはパスが Hugging Face Hub リポジトリ ID であると想定します。パスが有効なリポジトリ ID ではないため、サーバーは検証エラーで失敗し、クラッシュ ループに入ります。
この問題を解決するには、--model-bucket-uri フラグに指定したパスが、モデルの config.json ファイルと関連するすべてのモデルの重みを含む Cloud Storage バケット内の正確なディレクトリを指していることを確認します。
次のステップ
- GKE での AI / ML のオーケストレーション ポータルにアクセスして、GKE で AI / ML ワークロードを実行するための公式ガイド、チュートリアル、ユースケースを確認する。
- モデル サービング最適化の詳細を確認する。GPU を使用して大規模言語モデルの推論を最適化する際のベスト プラクティスをご覧ください。量子化、テンソル並列処理、メモリ管理など、GKE の GPU で LLM を提供する際のベスト プラクティスについて説明します。
- 自動スケーリングのベスト プラクティスの詳細については、次のガイドをご覧ください。
- ストレージのベスト プラクティスについては、GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化するをご覧ください。
- GKE を活用して AI / ML イニシアチブを加速するための試験運用版のサンプルを GKE AI Labs で確認する。