このドキュメントでは、GKE で推論ワークロードを実行するためのベスト プラクティスの概要について説明します。
このドキュメントは、Kubernetes と GKE で GPU や TPU などのアクセラレータを使用して推論ワークロードのベスト プラクティスを導入したいデータ管理者、オペレーター、デベロッパーを対象としています。一般的なロールの詳細については、GKE ユーザーの一般的なロールとタスクをご覧ください。
GKE での推論サービングを準備する
このセクションでは、推論ワークロードのデプロイを準備する際に従うべき基本的なベスト プラクティスについて説明します。これらのプラクティスには、ユースケースの分析、モデルの選択、アクセラレータの選択が含まれます。
推論ユースケースの特徴を分析する
推論ワークロードをデプロイする前に、その固有の要件を分析します。この分析は、パフォーマンス、費用、信頼性のバランスを考慮したアーキテクチャ上の意思決定に役立ちます。ユースケースを理解することで、サービスレベル目標（SLO）を満たす適切なモデル、アクセラレータ、構成を選択できます。
分析をガイドするには、ワークロードの次の主要なディメンションを評価します。
- パフォーマンスとレイテンシの要件を定義する: レイテンシとスループットに関するアプリケーションの SLO を決定します。定義する主な指標には、1 秒あたりのリクエスト数（RPS）、レスポンス レイテンシ、入力トークンと出力トークンの長さ、プレフィックス キャッシュ ヒット率などがあります。詳細については、推論パフォーマンス指標をご覧ください。
- モデルの要件とスケールを評価する: 選択したモデルの特性は、インフラストラクチャのニーズに直接影響します。モデルがサポートする最大コンテキスト長を考慮し、ワークロードで必要なものと比較します。ユースケースで最大コンテキストが必要ない場合は、最大コンテキスト長を短くすることで、より大きな KV キャッシュ用にアクセラレータ メモリを解放し、スループットを向上させることができます。
- 費用とビジネスの制約を確立する: 予算とビジネス目標は、持続可能で費用対効果の高い推論サービスを設計するうえで重要な要素です。入力と出力の目標トークン単価と、このワークロードの月間予算の合計額を定義します。費用対効果、最小レイテンシ、最大スループットなどの最適化目標と、アプリが可変レイテンシを許容できるかどうかを特定します。
推論のユースケースに適したモデルを選択する
適切なモデルを選択することは、推論アプリケーションのパフォーマンス、費用、実現可能性に直接影響します。最適なモデルを選択するには、次の基準に基づいて候補を評価します。
- タスクとモダリティの調整: 指定されたタスクとサポートされているモダリティに基づいてモデルを評価します。特定のタスク用に最適化されたモデルは、汎用モデルよりもほぼ常に優れたパフォーマンスを発揮します。
- 技術的特性: モデルのアーキテクチャとデータ型の精度（FP16、FP8、FP4 など）は、リソース要件とパフォーマンスを決定する重要な要素です。この評価は、量子化手法を適用する必要があるかどうかを判断するのに役立ちます。モデルの重みのサポートされている精度を確認し、フレームワークのサポートを確認して、モデルの最大サポート コンテキスト長を確認します。
- パフォーマンスと費用対効果: データドリブンな意思決定を行うには、一般公開されているベンチマークと独自の内部テストを使用して、候補モデルを比較します。Chatbot Arena などのリーダーボードを使用してモデルを比較し、ターゲット ハードウェア上の各モデルの 100 万トークンあたりの費用を評価します。
モデルに量子化を適用する
量子化は、モデルのメモリ フットプリントを削減して推論ワークロードを最適化する手法です。モデルの重み、活性化、キーと値（KV）キャッシュを高精度浮動小数点形式（FP16、FP32、FP64 など）から低精度形式（FP8、FP4 など）に変換します。メモリを削減することで、パフォーマンスと費用対効果の両方を大幅に改善できます。
量子化により、モデルのメモリ フットプリントが削減され、データ転送のオーバーヘッドが削減され、より大きな KV キャッシュ用のメモリが解放されます。
モデルに量子化を効果的に適用するには、次の推奨事項に従ってください。
- 精度のトレードオフを評価する: 量子化によってモデルの精度が低下することがあります。量子化の精度のトレードオフを評価する際は、8 ビット量子化では精度の低下が最小限に抑えられることが多いことを考慮してください。一方、4 ビット量子化では、アクセラレータのメモリ要件を最大 4 分の 1 に削減できますが、8 ビット量子化と比較して精度が大幅に低下する可能性があります。量子化されたモデルのパフォーマンスを特定のユースケースで評価し、精度が許容範囲内であることを確認します。精度の低下を評価するには、OpenCompass や Language Model Evaluation Harness などのツールを使用できます。
- ハードウェア アクセラレーションのサポートを評価する: 量子化を最大限に活用するには、量子化されたモデルが使用するデータ形式のハードウェア アクセラレーションを提供するアクセラレータを使用します。たとえば、次のような情報が得られます。
- NVIDIA H100 GPU は、FP8 オペレーションと FP16 オペレーションのハードウェア アクセラレーションを提供します。
- NVIDIA B200 GPU は、FP4、FP8、FP16 オペレーションのハードウェア アクセラレーションを提供します。
- Cloud TPU v5p は、FP8 オペレーションのハードウェア アクセラレーションを提供します。
- 事前量子化モデルを確認する: モデルを自分で量子化する前に、Hugging Face などの公開モデル リポジトリを確認します。理想的には、低精度でネイティブにトレーニングされたモデルを見つけます。これにより、トレーニング後の量子化による精度の低下を招くことなく、パフォーマンスの向上を実現できます。
- 量子化ライブラリを使用する: 事前量子化モデルを使用できない場合は、ライブラリを使用して量子化を自分で実行します。vLLM などの推論サーバーは、さまざまな手法で量子化されたモデルの実行をサポートしています。llm-compressor などのツールを使用して、量子化されていないモデルに量子化手法を適用できます。
- KV キャッシュの量子化を検討する: モデルの重みを量子化するだけでなく、KV キャッシュを量子化することもできます。この手法により、実行時に KV キャッシュに必要なメモリがさらに削減され、パフォーマンスの向上につながります。
詳細については、GPU で LLM 推論ワークロードを最適化するをご覧ください。
適切なアクセラレータを選択する
適切なアクセラレータを選択すると、推論サービスのパフォーマンス、費用、ユーザー エクスペリエンスに直接影響します。最適な選択は、モデルのメモリ要件、パフォーマンス目標、予算の分析によって異なります。
特定のユースケースに適したアクセラレータを選択する手順は次のとおりです。
メモリ要件を計算する: まず、モデルの読み込みと実行に必要な最小アクセラレータ メモリを計算します。合計メモリは、モデルの重み、推論エンジンのオーバーヘッド、中間アクティベーション、KV キャッシュに必要なメモリの合計です。
必要なメモリを推定するには、次の式を使用します。
\[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]
この方程式の各項は次のとおりです。
- モデルの重み: モデルのパラメータのサイズ。
- オーバーヘッド: 推論サーバーやその他のシステム オーバーヘッド用のバッファ。通常は 1 ～ 2 GB。
- アクティベーション: モデルの実行中に中間アクティベーションに必要なメモリ。
- バッチあたりの KV キャッシュ: 単一のシーケンスの KV キャッシュに必要なメモリ。コンテキスト長とモデル構成に応じてスケーリングされます。
- バッチサイズ: 推論エンジンが同時に処理するシーケンス（
max_num_sequences）の数。
例: Gemma 3 のアクセラレータ メモリ要件を計算する
テキスト生成のユースケースで BF16 の精度で Gemma 3 270 億パラメータ モデルをデプロイするために必要なアクセラレータ メモリを計算するには、次の値を使用します。
この計算のインタラクティブなチュートリアルについては、モデルに必要な VRAM の量をご覧ください。Colab ノートブック。
- 入力:
- モデルの重み: 54 GB
- バッチサイズ（
max_num_sequences）: 1 - 平均入力長: 1,500 トークン
- 平均出力長: 200 トークン
- 推論エンジンのオーバーヘッド: 1 GB（推定）
- KV キャッシュ データ型のサイズ: 2（BF16 の場合）
- KV ベクトル: 2（Key 用と Value 用）
- Gemma 3 27B 指示チューニング済みモデルのモデル構成:
hidden_size: 5376intermediate_size: 21504num_attention_heads: 32num_hidden_layers: 62num_key_value_heads: 16
- メモリの計算:
sequence_length=avg_input_length+avg_output_length= 1,500 + 200 = 1,700 個のトークンpytorch_activation_peak_memory= (max_num_sequences*sequence_length* (18 *hidden_size+ 4 *intermediate_size)) / (1000^3) = 約 0.31 GB（推定値）。head_dims=hidden_size/num_attention_heads= 5376 / 32 = 168kv_cache_memory_per_batch=（kv_vectors×max_num_sequences×sequence_length×num_key_value_heads×head_dims×num_hidden_layers×kv_data_type_size）/（1000^3）=（2 × 1 × 1,700 × 16 × 168 × 62 × 2）/（1000^3）= 約 1.13 GB- 必要なアクセラレータ メモリ =
Model weights+Overhead+Activations+KV cache per batch= 54 + 1 + 0.31 + 1.13 = 約 56.44 GB
モデルのデプロイに必要なアクセラレータ メモリの合計見積もりは約 57 GB です。
アクセラレータ オプションを評価する: メモリ要件を見積もったら、GKE で使用可能な GPU と TPU のオプションを評価します。
アクセラレータ メモリの量に加えて、評価の際は次のモデル要件を考慮してください。
- 複数のアクセラレータを必要とするモデルの場合は、NVLINK や GPUDirect などの高速接続のサポートを確認して、通信レイテンシを短縮します。
- 量子化モデルの場合は、FP8 や FP4 などの低精度データ型でネイティブ ハードウェア アクセラレーションを使用するアクセラレータを使用して、パフォーマンスのメリットを最大限に引き出します。
選択には、これらの機能、パフォーマンス、費用、可用性の間のトレードオフが伴います。
ユースケース別の推奨アクセラレータ
ヒント: サービング パフォーマンスのベンチマークと費用分析に基づく最新のアクセラレータの推奨事項については、GKE Inference Quickstart ツールも使用できます。詳細については、GKE Inference クイックスタートのドキュメントをご覧ください。 ワークロードに適したアクセラレータを選択できるように、次の表に一般的な推論ユースケースに最適なオプションをまとめます。これらのユースケースは次のように定義されます。
- 小規模モデルの推論: 数十億のパラメータを持つモデルで、計算負荷が単一のホストに限定される場合。
- 単一ホストの大規模モデル推論: 数十億から数百億のパラメータを持つモデルの場合。計算負荷は単一のホストマシンの複数のアクセラレータ間で共有されます。
- マルチホスト大規模モデル推論: パラメータ数が数千億から数兆のモデルの場合。複数のホストマシン上の複数のアクセラレータ間で計算負荷が共有されます。
ユースケース 推奨されるアクセラレータ マシンシリーズ 主な特性 小規模モデルの推論 NVIDIA L4 G2 小規模モデル向けの費用対効果の高いオプション（GPU あたり 24 GB のメモリ）。 NVIDIA RTX Pro 6000 G4 300 億個未満のパラメータ モデルと画像生成に費用対効果が高い（GPU あたり 96 GB のメモリ）。GPU 間の直接ピアツーピア通信をサポートしているため、単一ホストのマルチ GPU 推論に適しています。 TPU v5e - 費用対効果を最適化します。 TPU v6e - トランスフォーマー モデルとテキスト画像変換モデルに最も高い値を提供します。 単一ホストの大規模モデルの推論 NVIDIA A100 A2 単一ノードに収まるほとんどのモデル（合計メモリが最大 640 GB）に適しています。 NVIDIA H100 A3 単一ノードに収まる推論ワークロード（合計メモリ最大 640 GB）に最適です。 NVIDIA B200 A4 単一ノードに収まる要求の厳しいモデル向けの将来を見据えたオプション（合計メモリ最大 1,440 GB）。 TPU v4 - 費用とパフォーマンスのバランスが取れています。 TPU v5p - 要求の厳しいワークロード向けのハイ パフォーマンス オプション。 マルチホストの大規模モデルの推論 NVIDIA H200 A3 Ultra 大容量のメモリ使用量の多いモデルに適しています（合計メモリは最大 1,128 GB）。 NVIDIA B200 / GB200 A4 / A4X 最も要求の厳しい、コンピューティング負荷の高い、ネットワーク バウンドのワークロード。A4X マシンは Arm ベースの CPU を使用します。ワークロードで x86 固有の機能や最適化を使用している場合は、ワークロードのリファクタリング（単純なコンテナの再ビルドを超えるコード変更）が必要になることがあります。 TPU v5e - 中規模から大規模の LLM サービングの費用対効果とパフォーマンスを最適化します。 TPU v5p - 大規模な並列化を必要とするマルチホスト推論用のハイ パフォーマンス オプション。 TPU v6e - トランスフォーマー、テキスト画像変換、CNN サービングに最適化されています。 例: 260 GB モデルのアクセラレータを選択する
合計 260 GB のアクセラレータ メモリ（モデルに 200 GB、KV キャッシュに 50 GB、オーバーヘッドに 10 GB）を必要とするモデルをデプロイする必要があるとします。
メモリ要件のみに基づいて、NVIDIA L4 GPU を除外できます。これは、最大の G2 マシンが最大 192 GB のアクセラレータ メモリを提供するためです。また、L4 GPU はアクセラレータ間の高速で低レイテンシの接続をサポートしていないため、複数のノードにワークロードを分散することは、目的のパフォーマンスを実現するための現実的な選択肢ではありません。
x86-64 ワークロードのリファクタリング（別のタイプのプロセッサで実行できるようにコードを変更すること）を回避する場合は、Arm ベースの CPU を使用する NVIDIA GB200 アクセラレータと GB300 アクセラレータも除外します。
これにより、次のオプションが残ります。
- NVIDIA A100
- NVIDIA RTX Pro 6000
- NVIDIA H100
- NVIDIA H200
- NVIDIA B200
これらのアクセラレータには十分なメモリがあります。次のステップでは、対象地域での利用可能性を評価します。特定のリージョンで NVIDIA A100 GPU と NVIDIA H100 GPU のみが使用可能であるとします。この 2 つのオプションの費用対効果を比較した後、ワークロードに NVIDIA H100 を選択する場合があります。
マルチインスタンス GPU
GPU 使用率を高めて GPU 費用を最適化するには、マルチインスタンス GPU 構成を使用します。この構成では、サポートされている GPU をパーティショニングして、GKE の複数のコンテナ間で単一の GPU を共有します。マルチインスタンス GPU をプロビジョニングする場合は、GPU 全体を GKE ノードにのみ接続します。対応する GPU の料金が適用されます。信頼できるワークロードでのみマルチインスタンス GPU を使用することをおすすめします。
たとえば、NVIDIA RTX PRO 6000 を接続して、次の操作を行うことができます。
- 4 つのインスタンスにパーティショニングし（各インスタンスは 24 GB のアクセラレータ メモリを提供）、約 80 億個のパラメータを持ち、モデルの重みに FP16 データ形式の精度を使用するモデルなど、拡散モデルまたは小規模モデルの推論ワークロードを実行します。このパーティションは、NVIDIA L4 よりも費用対効果が高い可能性があります。
- 2 つのインスタンスにパーティショニングし（各インスタンスは 48 GB のアクセラレータ メモリを提供）、約 150 億個のパラメータを持ち、モデルの重みに FP16 データ形式の精度を使用するモデルなど、小規模なモデル推論ワークロードを実行します。このパーティションは、NVIDIA A100 40 GB GPU で推論ワークロードを実行する代替手段となる可能性があります。
詳細については、マルチインスタンス GPU の実行をご覧ください。
詳細については、Compute Engine ドキュメントの GPU マシンタイプとアクセラレータ最適化マシン ファミリーをご覧ください。
推論の分散戦略を選択する: モデルが単一のアクセラレータに対して大きすぎる場合は、ワークロードの要件に基づいて分散戦略を選択します。
まず、ハードウェアのトポロジに基づいて分散戦略を選択します。
- 単一アクセラレータ: モデルが単一のアクセラレータに収まる場合は、これが最もシンプルで推奨されるアプローチです。
- シングルノード、マルチアクセラレータ: モデルが複数のアクセラレータを備えた単一ノードに収まる場合は、テンソル並列処理を使用して、そのノードのアクセラレータ間でモデルを分散できます。
- マルチノード、マルチ アクセラレータ: モデルが単一ノードに収まらない場合は、テンソル並列処理とパイプライン並列処理を組み合わせて、複数のノードに分散できます。
これらの戦略を実装するには、次の並列処理手法を使用します。
テンソル並列処理: この手法では、モデルのレイヤを複数のアクセラレータにシャーディングします。NVLINK や直接ピアツーピア PCIe などの高速相互接続を備えた単一ノード内では非常に効果的ですが、アクセラレータ間の通信が大幅に必要になります。
例: テンソル並列処理
たとえば、1, 090 億個のパラメータを含むモデルをデプロイする必要があるとします。デフォルトの BF16（16 ビット）精度では、モデルの重みをアクセラレータ メモリに読み込むのに約 113 GB が必要です。1 つの NVIDIA H100 GPU は 80 GB のメモリを提供します。したがって、KV キャッシュなどの他のメモリ要件を考慮しなくても、テンソル並列処理サイズを 2 にしてモデルを読み込むには、少なくとも 2 つの NVIDIA H100 GPU が必要です。
パイプライン並列処理: この手法では、モデルのレイヤを複数のノードに順次分割します。マルチホスト デプロイでモデルを複数のノードに分散するのに適しており、テンソル並列処理よりもモデルランク間の通信が少なくて済みます。
例: ハイブリッド並列処理（テンソルとパイプライン）
6, 000 億を超えるパラメータを持つ非常に大きなモデルの場合、メモリ要件が 1.1 TB を超えることがあります。2 つの
a3-megagpu-8gノード（それぞれ 8 個の NVIDIA H100 GPU を搭載）があるシナリオでは、クラスタ全体のアクセラレータ メモリは 1.28 TB になります。モデルを実行するには、各ノード内で 8 方向テンソル並列処理、2 つのノード間で 2 方向パイプライン並列処理というハイブリッド戦略を実装します。モデルは 2 つのステージに分割され、レイヤの前半が最初のノードに、後半が 2 番目のノードに配置されます。リクエストが到着すると、最初のノードがリクエストを処理し、中間データをネットワーク経由で 2 番目のノードに送信します。2 番目のノードが計算を完了します。
単一モデル レプリカの分散推論戦略の選択に関するガイドラインについては、vLLM ドキュメントの並列処理とスケーリングをご覧ください。
アクセラレータ最適化マシンタイプを選択する: 選択したアクセラレータと必要な数に基づいて、それらのリソースを提供するマシンタイプを選択します。各マシンタイプには、vCPU、システム メモリ、ネットワーク帯域幅の特定の組み合わせが用意されています。この組み合わせは、ワークロードのパフォーマンスにも影響します。たとえば、16 個の NVIDIA H100 GPU が必要な場合は、
a3-megagpu-16gマシンタイプを選択します。独自のベンチマークを実行する: 推論ワークロードのパフォーマンスは、特定のユースケースに大きく依存します。独自のベンチマークを実行して、選択内容を検証し、構成を微調整します。
推論サーバーの構成を最適化する
推論ワークロードのデプロイ時に最適なパフォーマンスを実現するには、ベンチマークとチューニングのサイクルをおすすめします。
- まず、GKE Inference Quickstart を使用して、ユースケースに合わせて最適化されたベースライン Kubernetes 構成を取得します。
- ベンチマークを実行して、ベースラインのスループットとレイテンシの指標を取得します。
- 推論サーバーの構成を調整します。
- ベンチマークを再度実行し、結果を比較して変更を検証します。
次の推奨事項は vLLM 推論サーバーに基づいています。ただし、原則は他のサーバーにも適用されます。使用可能なすべての設定の詳細なガイダンスについては、vLLM の最適化とチューニングのドキュメントをご覧ください。
- 並列処理を構成する:
- Tensor Parallelism（
tensor_parallel_size）: ワークロードをシャード化するために、単一ノード上のアクセラレータの数に設定します。たとえば、tensor_parallel_size=4を設定すると、ワークロードが 4 つのアクセラレータに分散されます。この値を大きくすると、同期オーバーヘッドが過剰になる可能性があります。 - パイプラインの並列処理（
pipeline_parallel_size）: モデルを分散するノードの数に設定します。たとえば、それぞれ 8 個のアクセラレータを持つ 2 つのノードにデプロイする場合は、tensor_parallel_size=8とpipeline_parallel_size=2を設定します。この値を大きくすると、レイテンシ ペナルティが発生する可能性があります。
- Tensor Parallelism（
- KV キャッシュ（
gpu_memory_utilization）を調整する: このパラメータは、モデルの重み、アクティベーション、KV キャッシュ用に予約される GPU メモリの割合を制御します。値を大きくすると、KV キャッシュ サイズが増加し、スループットが向上する可能性があります。この値は0.9～0.95の範囲で設定することをおすすめします。メモリ不足（OOM）エラーが発生した場合は、この値を小さくします。 - 最大コンテキスト長（
max_model_len）を構成する: KV キャッシュ サイズとメモリ要件を減らすため、モデルのデフォルトよりも小さい最大コンテキスト長を設定できます。これにより、より小型で費用対効果の高い GPU を使用できます。たとえば、ユースケースで必要なコンテキストが 40,000 トークンのみで、モデルのデフォルトが 256,000 の場合、max_model_lenを 40,000 に設定すると、より大きな KV キャッシュ用のメモリが解放され、スループットが向上する可能性があります。 - 同時リクエスト数（
max_num_batched_tokens、max_num_seqs）を構成する: KV キャッシュの空き容量が少ない場合にプリエンプションを回避するため、vLLM が同時に処理するリクエストの最大数を調整します。max_num_batched_tokensとmax_num_seqsの値を小さくすると、メモリ要件が減ります。値を大きくすると、OOM エラーのリスクはありますが、スループットが向上します。最適な値を見つけるには、パフォーマンス テストを実行し、vLLM がエクスポートする Prometheus 指標でプリエンプション リクエストの数をモニタリングすることをおすすめします。
詳しくは、次のリソースをご覧ください。
- これらのパラメータのチューニング方法について詳しくは、vLLM のパフォーマンス チューニング: xPU 推論構成の徹底ガイドをご覧ください。
- モデルのメモリ最適化に関するガイダンスについては、GKE の GPU を使用して大規模言語モデルの推論を最適化する際のベスト プラクティスをご覧ください。
- デプロイ可能な完全な例については、GKE Inference リファレンス実装をご覧ください。
レイテンシと可用性を重視して最適化する
推論サービスが応答性と信頼性の両方を確保するには、起動レイテンシを短縮し、リソースの可用性を高めるように最適化する必要があります。
推論ワークロードのコールド スタート レイテンシを最適化する
推論ワークロードの起動にかかる時間を最小限に抑えることは、費用対効果とユーザー エクスペリエンスの両方にとって重要です。コールド スタートのレイテンシが低いと、クラスタを迅速にスケールアップして需要に対応できるため、応答性の高いサービスを確保しながら、コストのかかるオーバー プロビジョニングの必要性を最小限に抑えることができます。
Pod の起動時間を最適化する
Pod が準備完了になるまでの時間は、コンテナ イメージの pull とモデルの重みのダウンロードにかかる時間によって大きく左右されます。両方を最適化するには、次の戦略を検討してください。
最適化されたデータローダーでモデルの読み込みを高速化する: モデルの重みを保存して読み込む方法が、起動時間に大きな影響を与えます。vLLM バージョン 0.10.2 以降では、Run:ai Model Streamer を使用して、Cloud Storage バケットから直接ストリーミングすることでモデルを読み込む方法をおすすめします。
ストリーマーがユースケースで使用できない場合は、Cloud Storage FUSE を使用して Cloud Storage バケットをマウントし、階層型名前空間を有効にして、並列ダウンロードやプリフェッチなどの手法を使用してパフォーマンスを調整できます。これらの手法の詳細については、GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化するをご覧ください。いずれの場合も、Anywhere Cache を使用してバケット用の高性能なゾーン読み取りキャッシュを作成し、均一なバケットレベルのアクセスを有効にしてバケットへのアクセスを均一に制御することをおすすめします。
トレーニング ワークロードの高性能ファイル ストレージに Managed Lustre をすでに使用している場合は、推論用のモデルの重みを読み込むためにも使用できます。このアプローチは、データのローカリティと POSIX 互換性が重要な場合に、低レイテンシ アクセスを提供します。
イメージ ストリーミングを有効にする: コンテナ イメージの pull にかかる時間を短縮するには、GKE クラスタでイメージ ストリーミングを有効にします。イメージ ストリーミングを使用すると、イメージ全体がダウンロードされる前にコンテナを起動できるため、Pod の起動時間を大幅に短縮できます。
高速起動ノードを有効にする
迅速なスケーリングが必要なワークロードには、GKE の高速起動ノードを利用できます。高速起動ノードは、標準ノードよりも起動時間が大幅に短い、事前に初期化されたハードウェア リソースです。クラスタが要件を満たしている場合、GKE は高速起動ノードを自動的に有効にします。
容量を計画し、アクセラレータの入手可能性を最大化する
GPU や TPU などの需要の高いアクセラレータは、可用性が制限される可能性があるため、事前対応型の容量計画戦略が不可欠です。
容量を計画して予約する
需要の高いアクセラレータは可用性が制限される可能性があるため、事前対応型の容量計画戦略が不可欠です。必要なリソースへのアクセスを保証するには、次の推奨事項に従ってください。
容量のベースラインとピーク処理を決定する: 予約する必要があるベースライン アクセラレータ容量を計画します。予約する金額は、ユースケースによって異なります。たとえば、遅延が許容されない重要なワークロードに必要な容量の 100% を予約したり、特定のパーセンタイル（90 パーセンタイルや 95 パーセンタイルなど）を予約して、残りをオンデマンドで取得してピークを処理したりできます。
ベースライン容量を予約する: 確実性の高いリソースを取得するには、予約を作成します。ニーズに応じて予約タイプを選択できます。たとえば、特定の将来の期間にアクセラレータなどの需要の高いリソースを予約するには、カレンダー モードで将来の予約を作成します。
ピーク時の容量をオーケストレートする: ベースライン予約を超える需要に対して、オンデマンド、Spot VM、Dynamic Workload Scheduler（DWS）などの他の容量タイプを使用してフォールバック戦略を実装できます。このフォールバック戦略を自動化するには、カスタム コンピューティング クラスを使用して、さまざまな容量タイプのプロビジョニングの優先順位を定義します。
割引料金を利用する: ベースライン容量に対して、確約利用割引（CUD）を購入すると、1 年間または 3 年間の確約と引き換えに大幅な割引料金を利用できます。
ワークロードで容量の取得の遅延が許容される場合は、Dynamic Workload Scheduler を Flex Start プロビジョニング モードで使用する
容量の取得に多少の遅延が許容されるワークロードの場合、Flex Start プロビジョニング モードの Dynamic Workload Scheduler（DWS）は、割引料金でアクセラレータを取得するオプションです。DWS では、容量のリクエストを最大 7 日間キューに登録できます。
Flex Start プロビジョニング モードで DWS を使用する場合は、次のことをおすすめします。
- カスタム コンピューティング クラスに組み込む: カスタム コンピューティング クラスを使用して、容量を取得するための優先フォールバック戦略の一部として DWS を定義します。
- 最大実行時間を設定する:
maxRunDurationSecondsパラメータは、DWS を介してリクエストされたノードの最大実行時間を設定します。この値をデフォルトの 7 日よりも小さい値に設定すると、リクエストされたノードを取得できる可能性が高くなります。 - ノードのリサイクルを有効にする: ワークロードのダウンタイムを防ぐには、ノードのリサイクルを有効にします。この機能は、古いノードの有効期限が切れる前に新しいノードのプロビジョニングを開始し、スムーズな移行を実現します。
- 中断を最小限に抑える: ノードの強制排除とアップグレードによる中断を最小限に抑えるには、メンテナンスの時間枠と除外を構成し、ノードの自動修復を無効にして、短期間のアップグレード戦略を活用します。
カスタム コンピューティング クラスを使用する
カスタム コンピューティング クラス（CCC）は、ワークロードのインフラストラクチャ構成の優先順位付きリストを定義できる GKE の機能です。CCC は、アクセラレータの入手可能性を高めるように設計された主要な機能を提供します。
- フォールバック コンピューティングの優先度: 優先順位付きの構成リストを定義できます。スケールアップ イベント中に優先オプションを使用できない場合、オートスケーラーはリストの次のオプションに自動的にフォールバックするため、容量を正常に取得できる可能性が大幅に高まります。
- 優先度の高いノードへのアクティブな移行: この機能を構成すると、GKE は優先度の低い構成で実行されているノードを、優先度の高い構成のノードに自動的に置き換えます。これにより、最終的に Pod が最も優先度の高い（多くの場合、最も費用対効果の高い）ノードで実行されるようになります。
カスタム コンピューティング クラス（CCC）を使用すると、ノードを取得するためのフォールバック戦略を作成できます。この戦略では、オンデマンド VM、Spot VM、予約など、さまざまな容量タイプの優先順位付きリストを使用します。これらの容量タイプには、それぞれ異なる可用性レベルがあります。
- 予約: 容量を確実に確保できます。CCC で予約を使用する場合は、制限事項を考慮してください。たとえば、予約タイプによっては、予約できるマシンタイプやリクエストできるマシンの最大数が制限されます。
- オンデマンド: 標準のプロビジョニング モデル。柔軟性がありますが、需要の高いリソースについてはリージョン容量の制約を受ける可能性があります。
- Spot VM: 予備容量を低価格で使用できますが、プリエンプトされる可能性があります。プリエンプション イベントが発生すると、GKE は影響を受ける Pod に最大 30 秒の正常終了期間をベスト エフォート ベースで提供します。このメリットを活かすには、チェックポイントと再試行メカニズムを実装して、ワークロードがプリエンプション イベントに対応できるようにします。
- Dynamic Workload Scheduler（DWS）: 希少なリソースに対するリクエストを割引料金でキューに登録できます。この機能は、容量の取得の遅延を許容できるワークロードに最適です。
優先度リストの順序は、主な目標がレイテンシの最小化か費用の最適化かによって異なります。たとえば、ワークロードの要件に応じて、次のような優先度リストを構成できます。
| 優先度 | 低レイテンシのワークロード | コスト最適化（レイテンシ許容）ワークロード |
|---|---|---|
| 1 | 予約（特定の予約、任意の予約） | 予約（特定の予約、任意の予約） |
| 2 | オンデマンド | Spot VM |
| 3 | Spot VM | Dynamic Workload Scheduler |
| 4 | Dynamic Workload Scheduler | オンデマンド |
低レイテンシのユースケースでは、オンデマンド容量は予約の後に優先されます。これは、容量不足を迅速に報告し、CCC が次のオプションに迅速にフォールバックできるようにするためです。
費用最適化されたユースケースでは、予約の後に Spot VM と Flex Start を使用した DWS が優先され、低コストのメリットが活かされます。オンデマンド容量は最終的なフォールバックとして使用されます。
GKE クラスタとノードプールのロケーション ポリシーを構成する
クラスタ オートスケーラーのロケーション ポリシーは、スケールアップ イベント中に GKE がゾーン間でノードを分散する方法を制御します。この設定は、カスタム コンピューティング クラスを使用する場合に特に重要です。CCC の優先度リストを適用する前に、クラスタ オートスケーラーがどのゾーンを考慮するかを決定するためです。
アクセラレータを取得する可能性を高めるには、ワークロードの要件に基づいてロケーション ポリシーを構成します。
location-policy=ANY: ゾーン間でノードを均等に分散するよりも、容量の取得を優先します。この設定は、CCC に Spot VM や可用性が変動するマシンタイプが含まれている場合に特に重要です。ANYを使用すると、クラスタ オートスケーラーは CCC の優先ノードタイプを満たす可能性が最も高いゾーンを選択できます。この設定を使用して、未使用の予約の使用を優先することもできます。このポリシーを使用する場合は、クラスタ オートスケーラーが容量を最大限に柔軟に検出できるように、num-nodes=0から始めることをおすすめします。location-policy=BALANCED: 使用可能なすべてのゾーンにノードを均等に分散しようとします。ワークロードが容易に取得できるリソースを使用し、高可用性を実現するためにゾーン冗長性を維持する場合は、このポリシーを使用します。
この設定は、ノードプールの作成時または更新時に構成できます。
効率と費用を最適化する
アクセラレータを注意深くモニタリングし、ワークロードをインテリジェントにスケーリングすることで、無駄を大幅に削減し、運用コストを削減できます。
アクセラレータと推論サーバーをモニタリングする
推論ワークロードのパフォーマンスと使用率を把握するには、包括的なオブザーバビリティ戦略が不可欠です。GKE には、アクセラレータと推論サーバーのモニタリングに役立つツールセットが用意されています。
- NVIDIA GPU の DCGM 指標をモニタリングする: NVIDIA GPU の正常性とパフォーマンスをモニタリングするには、NVIDIA Data Center GPU Manager（DCGM）の指標を Cloud Monitoring に送信するように GKE を構成します。
- 自動アプリケーション モニタリングを有効にする: 推論サーバーのモニタリング プロセスを簡素化するには、GKE で自動アプリケーション モニタリングを有効にします。
- OpenTelemetry でワークロードを計測する: 自動アプリケーション モニタリングでサポートされていないワークロードの場合は、OpenTelemetry を使用してカスタム指標とトレースを収集します。
Pod を自動的にスケーリングする
推論ワークロードが需要の変化に動的に適応できるようにするには、HorizontalPodAutoscaler（HPA）を使用して Pod の数を自動的にスケーリングします。推論ワークロードでは、標準の CPU 指標やメモリ指標ではなく、推論サーバーの負荷を直接反映する指標に基づいてスケーリングの決定を行うことが重要です。
推論ワークロードの自動スケーリングを構成する場合は、次のことをおすすめします。
推論認識指標に基づいて HPA を構成する: 最適なパフォーマンスを得るには、推論サーバーの指標に基づいてスケーリングするように HPA を構成します。最適な指標は、低レイテンシと高スループットのどちらを最適化するかによって異なります。
レイテンシの影響を受けやすいワークロードの場合、主に次の 2 つの選択肢があります。
- KV キャッシュ使用率（
vllm:gpu_cache_usage_percなど）: この指標は、レイテンシの急増を予測するのに最適な指標であることがよくあります。KV キャッシュの使用率が高い場合は、推論エンジンが容量に近づいていることを示します。HPA はこのシグナルを使用して、レプリカを事前に追加し、安定したユーザー エクスペリエンスを維持できます。 - 実行中のリクエスト数（バッチサイズ）（例:
vllm:num_requests_running）: この指標はレイテンシに直接関連しています。通常、バッチサイズが小さいほどレイテンシが低くなります。ただし、スループットの最大化は受信リクエストのサイズに依存するため、これを使用して自動スケーリングを行うのは難しい場合があります。HPA が適切にスケールアップするように、最大バッチサイズよりも小さい値を選択する必要がある場合があります。
- KV キャッシュ使用率（
スループットに敏感なワークロードの場合は、キューサイズ（
vllm:num_requests_waitingなど）に基づいてスケーリングします。この指標は、作業バックログを直接測定し、処理能力と受信需要を一致させる簡単な方法です。この指標は、現在処理中のリクエストではなく、待機中のリクエストのみを考慮するため、バッチサイズに基づくスケーリングと比較して、可能な限り低いレイテンシを実現できない可能性があります。
最小レプリカ数を設定する: 一貫した可用性とベースラインのユーザー エクスペリエンスを確保するには、推論デプロイの最小レプリカ数を常に設定します。
パフォーマンス HPA プロファイルを有効にする: GKE バージョン 1.33 以降では、HPA のリアクション時間を短縮するために、対象クラスタでパフォーマンス HPA プロファイルがデフォルトで有効になっています。
詳細については、GPU 上の LLM ワークロードの HPA を構成すると TPU で LLM 推論ワークロードを自動スケーリングするをご覧ください。
データをワークロードの近くに移動する
ワークロードがモデルの重みなどのデータを読み込むのにかかる時間は、レイテンシの大きな原因となる可能性があります。データをコンピューティング リソースの近くに移動することで、データ転送時間を短縮し、全体的なパフォーマンスを向上させることができます。
- Anywhere Cache でゾーン読み取りキャッシュを作成する: Cloud Storage を使用して AI/ML ワークロードのデータを保存する場合は、Anywhere Cache を有効にします。Anywhere Cache は、Cloud Storage バケットに高性能なゾーン読み取りキャッシュを作成します。
- ローカル SSD に頻繁にアクセスされるデータをキャッシュに保存する: 一時データへの超低レイテンシ アクセスを必要とするワークロードの場合は、ローカル SSD を高パフォーマンスのキャッシュとして使用します。ローカル SSD を低レイテンシの一時ストレージとして使用して、頻繁に使用されるデータを保持すると、アクセラレータなどの高価なリソースのアイドル時間を短縮できます。これは、アクセラレータが I/O オペレーションの完了を待つ時間を大幅に短縮できるためです。すべてのマシンシリーズがローカル SSD をサポートしているわけではありません。このため、アクセラレータの選択に影響する可能性があります。
- GKE Data Cache でキャッシュを管理する: Persistent Disk からデータを頻繁に読み取るワークロードの場合は、GKE Data Cache を有効にします。GKE Data Cache は、ローカル SSD を使用して、Persistent Disk 用のマネージド型の高性能キャッシュを作成します。ほとんどの本番環境ワークロードでは、
Writethroughモードを使用して、キャッシュと基盤となる永続ディスクの両方にデータを同期的に書き込むことで、データ損失を防ぐことをおすすめします。
高度なスケーリング アーキテクチャ向けに最適化する
大規模なアプリケーションやグローバルに分散されたアプリケーションの需要を満たすには、高度なスケーリング アーキテクチャを採用して、パフォーマンス、信頼性、トラフィック管理を強化できます。
GKE Inference Gateway でトラフィックをロード バランシングする
単一クラスタの推論ワークロードには、GKE Inference Gateway の使用をおすすめします。Inference Gateway は、推論指標をモニタリングしてリクエストを最適なエンドポイントに転送する AI 対応のロードバランサです。この機能により、パフォーマンスとアクセラレータの使用率が向上します。
GKE Inference Gateway を使用する場合は、次のベスト プラクティスに従うことをおすすめします。
- サービング Pod を
InferencePoolにグループ化する: 推論ワークロードを処理する Pod のグループごとにInferencePoolを定義します。詳細については、GKE Inference Gateway の構成をカスタマイズするをご覧ください。 - レイテンシが重要なワークロードを多重化する:
InferenceObjectivesを定義して、モデルのサービング プロパティ（名前や優先度など）を指定します。GKE Inference Gateway は、優先度の高いワークロードを優先します。これにより、レイテンシが重要なワークロードとレイテンシに寛容なワークロードを多重化し、トラフィックが多いときにロード シェディング ポリシーを実装できます。 - モデル対応ルーティングを使用する: リクエスト本文のモデル名に基づいてリクエストをルーティングするには、本文ベースのルーティングを使用します。本文ベースのルーティングを使用する場合は、バックエンドの高可用性を確保してください。拡張機能が使用できない場合、ゲートウェイはエラーを返し、リクエストが誤ってルーティングされるのを防ぎます。
- ゲートウェイがトラフィックを自動的に分散できるようにする: GKE Inference Gateway は、
InferencePoolの推論サーバーから主要な指標（KV キャッシュ使用率、キューの長さ、プレフィックス キャッシュ インデックスなど）をモニタリングして、トラフィックをインテリジェントにルーティングします。このリアルタイム ロード バランシングにより、従来の方式と比較して、アクセラレータの使用率が最適化され、テール レイテンシが短縮され、全体的なスループットが向上します。 - Apigee と Model Armor との統合: セキュリティと管理を強化するために、API 管理用に Apigee と統合し、安全性チェック用に Model Armor と統合します。
複数のノードに推論ワークロードをデプロイする
単一ノードに収まらない非常に大きなモデルの場合は、推論ワークロードを複数のノードに分散する必要があります。これには、ノード間の通信レイテンシを最小限に抑え、分散ワークロードのすべてのコンポーネントが単一のユニットとして管理されるアーキテクチャが必要です。
次のベスト プラクティスを検討してください。
アクセラレータのネットワーク帯域幅とスループットを最大化する: ワークロードが複数のノードに分散されている場合、ネットワークは重要なパフォーマンス要因になります。ノード間の通信レイテンシを最小限に抑えるには、NVIDIA GPUDirect などの高性能ネットワーキング技術を使用します。クラスタの規模とワークロードに必要な通信の強度に応じて、次のオプションから選択できます。
- GPUDirect-TCPX: A3 High で実行されるさまざまなマルチノード推論ワークロードに有効です。
- GPUDirect-TCPXO: オフロードと帯域幅が向上し、パフォーマンスが向上します。これは、標準の TCPX よりも大規模なクラスタに適しており、A3 Mega マシンで実行されます。
- GPUDirect RDMA: 異なるノード間で GPU 間のダイレクト メモリ アクセスを可能にし、CPU をバイパスすることで、最高のノード間帯域幅と最小のレイテンシを実現します。A3 Ultra マシンと A4 マシンで最も要求の厳しい大規模な推論シナリオに最適です。
詳しくは以下をご覧ください。
マルチノード ネットワーク構成が想定どおりに動作していることを検証するには、NVIDIA Collective Communications Library（NCCL）などのツールを使用してテストを実行することをおすすめします。
LeaderWorkerSet を使用して分散ワークロードを管理する: マルチノード推論サービスなどのステートフル分散ワークロードをデプロイする場合は、すべてのコンポーネントを単一のユニットとして管理することが不可欠です。これを行うには、関連する Pod のグループを単一のエンティティとして管理できる Kubernetes ネイティブ API である LeaderWorkerSet を使用します。LeaderWorkerSet は、セット内のすべての Pod が同時に作成および削除されるようにします。これは、分散ワークロードの完全性を維持するために重要です。
コンパクト プレースメントを使用してノードを物理的に近接した場所に配置する: 分散ワークロードのノード間の物理的な距離は、ノード間のネットワーク レイテンシに大きな影響を与える可能性があります。このレイテンシを最小限に抑えるには、GKE ノードプールにコンパクト プレースメント ポリシーを使用します。コンパクト プレースメント ポリシーは、ゾーン内でノードプール内のノードをできるだけ物理的に近い場所に配置するように GKE に指示します。
複数のリージョンに推論ワークロードをデプロイする
高可用性と低レイテンシを必要とするグローバルに分散されたアプリケーションの場合、推論ワークロードを複数のリージョンにデプロイすることは重要なベスト プラクティスです。マルチリージョン アーキテクチャは、信頼性の向上、アクセラレータの入手性の向上、ユーザーが認識するレイテンシの短縮、ロケーション固有の規制要件の遵守に役立ちます。
マルチリージョン推論サービスを効果的にデプロイして管理するには、次の推奨事項に従ってください。
- ピーク時の負荷を処理するために容量を予約しているか、容量が必要になると予想される複数のリージョンに GKE クラスタをプロビジョニングします。
- モデルの重みに適したストレージ戦略を選択します。運用効率を最適化するには、マルチリージョン Cloud Storage バケットを作成します。費用を最適化するには、各リージョンにリージョン バケットを作成し、モデルの重みを複製します。
- Anywhere Cache を使用して、Cloud Storage バケットのゾーン読み取りキャッシュを作成し、ネットワーク レイテンシとデータ下り（外向き）のコストの両方を削減します。
ベスト プラクティスの概要
次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。
| トピック | タスク |
|---|---|
| デプロイと構成 |
|
| コールド スタート レイテンシ |
|
| キャパシティ プランニングとアクセラレータの入手可能性 |
|
| リソースとアクセラレータの効率 |
|
| 負荷分散 |
|
| マルチノード デプロイ |
|
| マルチリージョン環境 |
|
次のステップ
- GKE 推論リファレンス アーキテクチャをご覧ください。