このベスト プラクティス ガイドでは、利用可能な指標と、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 は、これらのサーバーレベルの指標に基づいてワークロードのス craping と自動スケーリングを簡素化します。これらの指標を使用すると、バッチサイズ、キューサイズ、デコード レイテンシなどのパフォーマンス指標を可視化できます。
これらの指標に基づいて、最も関連性の高いパフォーマンス指標に自動スケーリングを適用できます。自動スケーリングの主なサーバーレベルの指標は次のとおりです。
- キューサイズ: サーバーキューで処理を待機しているリクエストの数。キューサイズを使用して、特定のターゲット レイテンシしきい値内でスループットを最大化し、費用を最小限に抑えます。詳細については、関連するベスト プラクティスのセクションをご覧ください。
- バッチサイズ: 推論対象のリクエストの数。バッチサイズを使用して、キューサイズよりも低いターゲット レイテンシしきい値に到達します。詳細については、関連するベスト プラクティスのセクションをご覧ください。
これらの指標は、パフォーマンスとトラフィックの変動に強いため、さまざまな 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 ワークロードの自動スケーリングを構成する方法を学習する。