メインコンテンツまでスキップ
に最終更新

本番運用のためにモデルサービング エンドポイントを最適化する

高スループット、低遅延、信頼性の高いパフォーマンスを必要とする本番運用ワークロード向けにモデルサービング エンドポイントを最適化する方法を学びます。

最適化戦略は、次の 3 つのカテゴリに分類されます。

エンドポイントを最適化するタイミング​

次のいずれかのシナリオに遭遇した場合は、モデルサービングエンドポイントの最適化を検討してください。

  • クエリ量が多い : アプリケーションが 1 秒あたり 50,000 クエリ (QPS) を超えるクエリを単一のエンドポイントに送信します
  • レイテンシ要件 : アプリケーションは100ミリ秒未満の応答時間を必要とします
  • スケーリングのボトルネック : トラフィックの急増時にエンドポイントでキューが発生したり、HTTP 429 エラーが返される
  • コスト最適化 : パフォーマンス目標を維持しながらサービスコストを削減したい
  • 本番運用の準備 : 開発から本番運用のワークロードに移行する準備をしています。

インフラストラクチャの最適化​

インフラストラクチャの最適化により、ネットワーク ルーティング、スケーリング動作、コンピュート容量が向上します。

ルート最適化​

ルート最適化は、高スループットのワークロードに対して最も重要なインフラストラクチャの改善をもたらします。エンドポイントでルート最適化を有効にすると、 Databricksモデルサービスによって推論要求のネットワーク パスが改善され、クライアントとモデル間の通信がより高速かつ直接的になります。

パフォーマンス上の利点:

機能

標準エンドポイント制限

ルート最適化エンドポイント制限

ワークスペースあたりの 1 秒あたりのクエリ数 (QPS)

200

50,000 以上 (上限値を超える場合は Databricks にお問い合わせください)

ワークスペースごとのクライアント同時実行数

192-1024（地域によって異なります）

明示的な制限なし（プロビジョニングされた同時実行によって制限されます）

サービス提供エンティティあたりのエンドポイントプロビジョニング同時実行数

1,024

1,024 (上限値が高い場合は Databricks にお問い合わせください)

ルート最適化を使用する場合:

  • 200 QPS を超えるワークロード
  • 厳しいレイテンシ要件（50ms未満のオーバーヘッド）を持つアプリケーション
  • 複数のユーザーにサービスを提供する本番運用デプロイメント
重要

ルートの最適化は、カスタム モデルサービング エンドポイントでのみ利用できます。 基盤モデルAPIsと外部モデルはルートの最適化をサポートしていません。 認証にはOAuth VPN が必要です。個人的なアクセスはサポートされていません。

セットアップ手順については「サービス エンドポイントでのルート最適化」を、クエリの詳細については「ルートが最適化されたサービス エンドポイントのクエリ」を参照してください。

プロビジョニングされた同時実行​

プロビジョニングされた同時実行性は、エンドポイントが同時に処理できるリクエストの数を制御します。予想される QPS とレイテンシの要件に基づいて、プロビジョニングされた同時実行性を構成します。

構成ガイドライン:

  • 最小同時実行数 : キューイングなしでベースライントラフィックを処理できるほど高く設定します
  • 最大同時実行数 : コストを抑えながらトラフィックの急増に対応できるほど高く設定します
  • オートスケール : オートスケールを有効にして、需要に基づいて容量を動的に調整します

必要な同時実行性を計算します。

Required Concurrency = Target QPS × Average Latency (seconds)

たとえば、目標が 100 QPS、平均レイテンシが 200 ミリ秒の場合:

Required Concurrency = 100 × 0.2 = 20

負荷テストを使用して実際のレイテンシを測定し、最適な同時実行設定を決定します。

インスタンスタイプ​

モデルのコンピュート要件に基づいてインスタンス タイプを選択します。

インスタンスタイプ

どのようなタスクにベストなのか

トレードオフ

CPU（小、中、大）

軽量モデル、シンプルな推論ロジック

低コスト、コンピュート集中型モデルの場合は低速

GPU（小、中、大）

大規模モデル、複雑な計算、画像/ビデオ処理

コストは高いが、ディープラーニングに最適なパフォーマンス

ヒント

開発とテスト用の CPU インスタンスから始めます。高い推論レイテンシが観察された場合、またはモデルで特殊なコンピュート (ディープラーニング操作など) が必要な場合にのみ、GPU インスタンスに切り替えてください。

モデルの最適化​

モデルの最適化により推論速度とリソース効率が向上します。

モデルのサイズと複雑さ​

モデルのサイズと複雑さ: モデルが小さく複雑でないほど、推論時間が短くなり、QPS が高くなります。モデルが大きい場合は、モデルの量子化やプルーニングなどの手法を検討してください。

バッチ処理​

アプリケーションが 1 回の呼び出しで複数のリクエストを送信できる場合は、クライアント側でバッチ処理を有効にします。これにより、予測ごとのオーバーヘッドが大幅に削減されます。

前処理と後処理の最適化​

複雑な前処理と後処理をサービスエンドポイントからオフロードして、推論インフラストラクチャの負荷を軽減します。

クライアント側の最適化​

クライアント側の最適化により、アプリケーションがサービス エンドポイントと対話する方法が改善されます。

接続プール​

接続プールは、リクエストごとに新しい接続を作成する代わりに既存の接続を再利用するため、オーバーヘッドが大幅に削減されます。

  • 接続プールのベストプラクティスを自動的に実装する Databricks SDK を使用する
  • カスタム クライアントを使用する場合は、接続プールを自分で実装します。

エラー処理と再試行戦略​

特にオートスケール イベントやネットワーク中断時の一時的な障害を適切に処理するために、堅牢なエラー処理を実装します。

ペイロードサイズの最適化​

リクエストとレスポンスのペイロード サイズを最小限に抑えて、ネットワーク転送時間を短縮し、スループットを向上させます。

パフォーマンスを測定して改善する​

パフォーマンスモニタリング​

Mosaic AI Model Serving が提供するツールを使用してエンドポイントのパフォーマンスを監視します。

メトリクス

何を測定しているか

ターゲット

超過した場合の措置

レイテンシー（P50、P90、P99）

リクエストへの応答時間

アプリケーションに依存（通常は <100-500ms）

キューイングをチェックし、モデルまたはクライアントを最適化する

スループット（QPS）

1秒あたりに完了したリクエスト数

ワークロード依存

ルート最適化を有効にし、プロビジョニングされた同時実行性を向上させる

エラー率

失敗したリクエストの割合

<1%

サービスログを確認し、容量の問題がないか確認する

キューの深さ

処理待ちのリクエスト

0（キューなし）

プロビジョニングの同時実行性を高めるか、オートスケールを有効にします

CPU/メモリ使用量

リソースの活用

<80%

インスタンスタイプをスケールアップするか同時実行性を高める

詳細なモニタリング ガイダンスについては「モデルの品質とエンドポイントの健全性の監視」を参照し、可観測性ツールへのメトリクスのエクスポートについては「サービング エンドポイントの健全性メトリクスの追跡と Prometheus および Datadog へのエクスポート」を参照してください。

負荷テスト​

負荷テストは、現実的なトラフィック条件下でエンドポイントのパフォーマンスを測定し、次のことに役立ちます。

  • 最適なプロビジョニング同時実行設定を決定する
  • パフォーマンスのボトルネックを特定する
  • レイテンシとスループットの要件を検証する
  • クライアントの同時実行性とサーバーの同時実行性の関係を理解する

「サービスエンドポイントの負荷テスト」を参照してください。

一般的なパフォーマンスの問題のトラブルシューティング​

キューイング​

モデルサービングは、トラフィック パターンに基づいて容量を調整するオートスケールをサポートしています。 ただし、オートスケールでは負荷の増加を検出し、追加容量をプロビジョニングするのに時間がかかるため、突然のトラフィックの急増によりキューが発生する可能性があります。 この期間中、受信リクエストが一時的に利用可能な容量を超え、リクエストがキューに入れられる可能性があります。

キューイングは、要求レートまたは同時実行性がエンドポイントの現在の処理能力を超えたときに発生します。これは通常、トラフィックの急増、ワークロードのバースト、またはエンドポイントにプロビジョニングされた同時実行性が不十分な場合に発生します。モデルサービング エンドポイントでは、バーストを処理するために一時的なキューイングが許可されますが、定義されたしきい値を超えると、エンドポイントはシステムの安定性を保護するために HTTP 429 (リクエストが多すぎます) エラーを返します。

キューイングにより、キューに入れられたリクエストは処理されるまで待機するため、待ち時間が増加します。待ち行列を最小限に抑えるには:

  • ベースライントラフィックと一般的なバーストを処理できるほど高い最小プロビジョニング同時実行数を設定します。
  • より高い容量制限のためにルート最適化を有効にする
  • クライアント アプリケーションに指数バックオフを使用した再試行ロジックを実装する

外部APIのボトルネック​

モデルは、推論中にデータエンリッチメント、特徴の取得、またはその他のタスクのために外部APIsを呼び出すことがよくあります。 これらの外部依存関係はパフォーマンスのボトルネックになる可能性があります。

  • レイテンシ : 各外部 API 呼び出しの応答時間を測定します。これらの呼び出しのレイテンシが高いと、全体的なサービスレイテンシが直接増加し、スループットが低下します。
  • スループット制限 : 外部APIsレート制限または容量制限を課す場合があります。 これらの制限を超えると、スロットル、エラー、パフォーマンスの低下が発生する可能性があります。
  • エラー率 : 外部APIsからのエラーが頻繁に発生すると再試行がトリガーされ、サービス エンドポイントの負荷が増加する可能性があります。
  • キャッシュ : 外部APIsから頻繁にアクセスされるデータのキャッシュを実装して、呼び出し回数を減らし、応答時間を改善します。

これらの要因を監視してボトルネックを特定し、高スループットのワークロードにターゲットを絞った最適化を実装します。

その他のリソース​