このベスト プラクティス ガイドでは、利用可能な指標と、GKE 上の推論ワークロードに HorizontalPodAutoscaler（HPA）を設定する際に適切な指標を選択する方法について説明します。HPA は、モデルサーバーが負荷に応じて適切にスケーリングされるようにする効率的な方法です。プロビジョニングされたハードウェアの費用をトラフィックの需要に合わせて調整し、推論サーバーのパフォーマンス目標を達成するための主な方法は、HPA 設定のファインチューニングです。
これらのベスト プラクティスを実装する方法の例については、GKE で GPU を使用して LLM ワークロードの自動スケーリングを構成するをご覧ください。
目標
このガイドは、生成 AI をご利用のお客様、GKE の新規または既存のユーザー、ML エンジニア、LLMOps（DevOps）エンジニアで、Kubernetes で GPU を使用して LLM ワークロードを最適化することに関心のある方を対象としています。
このガイドを読むことで、次のことが可能になります。
- LLM 推論の自動スケーリング指標について理解する。
- どの指標で自動スケーリングするかを検討する際のトレードオフを理解する。
LLM 推論の自動スケーリング指標の概要
GKE で使用できる指標は次のとおりです。
サーバー指標
TGI、vLLM、NVIDIA Triton などの一般的な LLM 推論サーバーは、ワークロード固有のパフォーマンス指標を出力します。GKE は、これらのサーバーレベルの指標に基づき、ワークロードのスクレイピングと自動スケーリングを簡素化します。これらの指標を使用すると、バッチサイズ、キューサイズ、デコード レイテンシなどのパフォーマンス指標を把握できます。
これらの指標に基づいて、最も関連性の高いパフォーマンス指標に自動スケーリングを適用できます。自動スケーリングの主なサーバーレベルの指標は次のとおりです。
- キューサイズ: サーバーキューで処理を待機しているリクエストの数。キューサイズを使用して、特定のターゲット レイテンシしきい値内でスループットを最大化し、費用を最小限に抑えます。詳細については、関連するベスト プラクティスのセクションをご覧ください。
- バッチサイズ: 推論対象のリクエスト数。バッチサイズを使用して、キューサイズよりも低いターゲット レイテンシしきい値に到達させます。詳細については、関連するベスト プラクティスのセクションをご覧ください。
これらの指標は、パフォーマンスとトラフィックの変動に強いため、さまざまな GPU ハードウェア設定で自動スケーリングを行う際に信頼できる出発点となります。
GPU 指標
GPU はさまざまな使用状況とパフォーマンスの指標を出力し、カスタム指標のない推論ワークロードも含め、GPU ベースのあらゆるタスクについて、ワークロードに依存しない自動スケーリングを可能にします。DCGM の収集を設定する方法については、DCGM の収集を構成するをご覧ください。
GKE の一般的な GPU 指標は次のとおりです。
| GPU 指標 | 用途 | 制限事項 |
|---|---|---|
GPU 使用率（DCGM_FI_DEV_GPU_UTIL） |
デューティ サイクル（GPU がアクティブな時間）を測定します。 | GPU がアクティブな間に処理されている作業量は測定されません。このため、レイテンシやスループットなどの推論ベースのパフォーマンス指標を GPU 使用率のしきい値にマッピングすることが困難になります。 |
GPU メモリの使用量（DCGM_FI_DEV_FB_USED） |
特定の時点で使用されている GPU メモリの量を測定します。これは、GPU メモリの動的割り当てを実装するワークロードに役立ちます。 | GPU メモリを事前割り当てするか、メモリを割り当て解除しないワークロード（TGI と vLLM で実行されるワークロードなど）の場合、この指標はスケールアップにのみ適用され、トラフィックが減少してもスケールダウンされません。 |
CPU 指標
GKE では、HPA は設定なしで CPU とメモリベースの自動スケーリングに使用できます。CPU で実行されるワークロードの場合、通常は CPU とメモリ使用率の指標が主な自動スケーリング指標になります。
GPU で実行される推論ワークロードの場合、推論ワークロードは主に GPU リソースに依存するため、ジョブが消費するリソースの量を示す指標として CPU とメモリの使用率のみに頼ることはおすすめしません。このため、自動スケーリングに CPU 指標のみを使用すると、パフォーマンスとコストが最適化されない可能性があります。
自動スケーリングの指標を選択する際の考慮事項
次の考慮事項とベスト プラクティスを使用して、推論ワークロードのパフォーマンス目標を達成できるよう、GKE での自動スケーリングに最適な指標を選択します。
ベスト プラクティス: キューサイズを使用して、特定のターゲット レイテンシしきい値内でスループットを最大化し、費用を最小限に抑える
スループットと費用を最適化する場合や、モデルサーバーの最大バッチサイズの最大スループットでレイテンシ目標を達成できる場合は、キューサイズによる自動スケーリングをおすすめします。
キューサイズは、リクエストのレイテンシと直接的に関連しています。受信リクエストは、処理される前にモデルサーバーのキューに追加されます。このキュー時間は合計レイテンシに加算されます。負荷が増加すると、キューはすぐいっぱいになるので、キューサイズは負荷の急増に対して敏感に反応します。
キューサイズに基づく自動スケーリングでは、負荷が高いときにスケールアップし、キューが空になったときにスケールダウンすることで、キュー時間を最小限に抑えます。キューサイズがリクエスト サイズ、モデル、ハードウェアとは無関係であるため、このアプローチは比較的簡単に実装でき、大部分はワークロードに依存しません。
モデルサーバーの構成を変更せずスループットを最大化するには、キューサイズに注目することを検討してください。キューサイズは、処理中ではなく保留中のリクエストを追跡します。vLLM と TGI は連続バッチ処理を使用するので、同時リクエストを最大化し、バッチスペースが使用可能なときキューを短くできます。バッチスペースが限られている場合、キューは著しく増加するため、増加ポイントをスケールアップの開始シグナルとして使用します。キューサイズの自動スケーリングと最適化されたバッチ スループットを組み合わせることで、リクエスト スループットを最大化できます。
HPA に最適なキューサイズのしきい値を決定する
HPA の許容範囲に注意してください。デフォルトでは、減衰振動のため目標値の前後に 0.1 の無動作範囲が設定されています。
適切なキューサイズのしきい値を選択するには、最初は 3～5 の値から始め、リクエストが目的のレイテンシに達するまで、この値を徐々に増やしていきます。テストには locust-load-inference ツールを使用します。しきい値が 10 未満の場合は、トラフィックの急増に対応できるよう HPA のスケールアップ設定を微調整します。
Cloud Monitoring カスタム ダッシュボードを作成して、指標の動作を可視化することもできます。
制限事項
キューサイズは、同時実行リクエストを直接制御しません。しきい値を使用しても、最大バッチサイズで許容される値よりもレイテンシが低くなるとは限りません。回避策として、最大バッチサイズを手動で減らすか、バッチサイズで自動スケーリングします。
ベスト プラクティス: バッチサイズを使用して、キューサイズよりも低いターゲット レイテンシしきい値に到達させる
キューベースのスケーリングでは要件を満たす速さを得られない、レイテンシの影響を受けやすいワークロードがある場合は、バッチサイズ ベースの自動スケーリングを選択することをおすすめします。
バッチサイズは、受信リクエストのスループットとレイテンシに直接関連しています。バッチサイズは、負荷の急増を示す優れた指標です。負荷が増加すると、既存のバッチに追加されるリクエストが増え、バッチサイズが大きくなります。一般に、バッチサイズが大きいほどレイテンシは高くなります。バッチサイズで自動スケーリングを行うと、ワークロードがスケールアップされ、一度に並列で処理されるリクエスト数が最大化されます。並列で処理されるリクエスト数が少ない場合は、スケールダウンされます。
キューのサイズがすでにレイテンシ ターゲットを満たしている場合は、自動スケーリングの優先度を上げます。 これにより、スループットと費用効率の両方が最大化されます。ただし、レイテンシの影響を受けやすいワークロードには、バッチサイズが役立ちます。バッチサイズが大きいほどスループットは向上しますが、連続バッチ処理モデルサーバーで、一部のリクエストのプリフィル フェーズが他のリクエストのデコード フェーズを中断することから、レイテンシも増加します。バッチサイズのパターンをモニタリングし、自動スケーリングを使用すれば、負荷の急増時に同時リクエストを最小限に抑えることができます。
モデルサーバーで許可されている場合は、追加のチューニング メカニズムとして最大バッチサイズをカスタマイズすることをおすすめします。キューベースの自動スケーリングと組み合わせることもできます。
HPA に最適なバッチサイズのしきい値を決定する
HPA の許容範囲に注意してください。デフォルトでは、減衰振動のために目標値の前後に 0.1 の無動作範囲が設定されています。
適切なバッチサイズのしきい値を選択するには、実験的にサーバーの負荷を増やして、バッチサイズがピークに達するポイントを調べます。また、テストには locust-load-inference ツールを使用することをおすすめします。最大バッチサイズを特定したら、この最大値をわずかに下回る値に最初の目標値を設定してから、目的のレイテンシに達するまで減らしていきます。
Cloud Monitoring カスタム ダッシュボードを作成して、指標の動作を可視化することもできます。
制限事項
バッチサイズに基づく自動スケーリングは、レイテンシの制御に役立ちますが、制限があります。リクエスト サイズとハードウェアの制約はまちまちなため、適切なバッチサイズのしきい値を見つけるのは困難です。
ベスト プラクティス: HPA 構成を最適化する
次の HPA 構成オプションを設定することをおすすめします。
- 安定化ウィンドウ: この HPA 構成オプションを使用すると、指標の変動によるレプリカ数の急激な変化を防ぐことができます。デフォルトは、スケールダウンの場合は 5 分（早期のスケーリングを回避）、スケールアップの場合は 0（応答性を保証）です。ワークロードの不安定性と、求められる応答性に応じて値を調整します。
- スケーリング ポリシー: この HPA 構成オプションを使用して、スケールアップとスケールダウンの動作を微調整します。Pods ポリシーの制限を設定すると、時間単位ごとに変更されるレプリカの絶対数を指定できます。また、Percent ポリシーの制限を設定して、変化率を指定できます。
これらのオプションの詳細については、オープンソースの Kubernetes ドキュメントの水平 Pod 自動スケーリングをご覧ください。
次のステップ
- GPU 上の LLM ワークロードの自動スケーリングを構成する方法を学習する。