KServeでマルチモデル推論を安定稼働させるコツ

なぜスケーリング指標が大事？

KServeで複数のモデルを同じ環境にのせるとき、「どの指標でスケールさせるか」が安定稼働のカギになります。よくあるのが CPU/GPU使用率 を指標にする方法ですが、これだけでは落とし穴があります。

よくある落とし穴

• CPU/GPU使用率は低いのに遅い！
  実際にはリクエストがキューに溜まっていて、ユーザーの待ち時間が伸びてしまうことがあります。
• 重いモデルが軽いモデルをブロック
  同じノードに「処理が重いモデル」と「軽量モデル」を置くと、重い方の処理に引きずられて軽いモデルもレスポンスが遅くなることがあります。

KServeならできる工夫

KServeは queue-proxy を経由して動作しており、以下のような ユーザー体感に直結する指標 を使えます。

• 同時リクエスト数 (concurrency)
• 待機時間 (queue latency)

これをスケーリング指標に使うことで、単なるCPU/GPU使用率では見えない「レスポンスの悪化」をキャッチできます。

対策のポイント

• レスポンス体感を基準にする
  「inference_request_concurrency」をHPAに組み込み、待機行列が伸びないように調整しましょう。
• CPU/GPU使用率に加えるイメージ
  リソース使用率だけでなく、実際のリクエスト動きを見ることが大事です。

設定例（最小スニペット）

annotations:
  autoscaling.knative.dev/metric: "concurrency"
  autoscaling.knative.dev/target: "5"
  autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"
  autoscaling.knative.dev/minScale: "1"
  autoscaling.knative.dev/maxScale: "10"

まとめ

KServeでマルチモデルを安定稼働させるなら、「CPU/GPU使用率だけに頼らず、ユーザー体感に近い指標（concurrencyや待機時間）」を使うことが重要です。これで、重いモデルと軽いモデルが混在する環境でも安定したレスポンスを実現できます。

📌 参考キーワード:
“KServe HPA custom metrics” / “queue-proxy concurrency” / “inference_request_concurrency”