高スループット、低待機時間、信頼性の高いパフォーマンスを必要とする運用環境のワークロードに対してモデル サービス エンドポイントを最適化する方法について説明します。
最適化戦略は、次の 3 つのカテゴリに分類されます。
- エンドポイントの最適化: パフォーマンスを向上させるためにエンドポイント インフラストラクチャを構成する
- モデルの最適化: モデルの効率とスループットの向上
- クライアントの最適化: クライアントがサービス エンドポイントと対話する方法を最適化する
エンドポイントを最適化するタイミング
次のいずれかのシナリオが発生した場合は、モデル サービス エンドポイントを最適化することを検討してください。
- 大量のクエリ: アプリケーションが 1 つのエンドポイントに 1 秒あたり 50,000 件を超えるクエリ (QPS) を送信する
- 待機時間の要件: アプリケーションには 100 ミリ秒未満の応答時間が必要です
- スケーリングのボトルネック: トラフィックが急増するとエンドポイントがキュー待ちとなるか、HTTP 429 エラーを返す
- コストの最適化: パフォーマンス目標を維持しながらサービス コストを削減したい
- 運用環境の準備: 開発から運用ワークロードへの移行を準備しています
インフラストラクチャの最適化
インフラストラクチャの最適化により、ネットワーク ルーティング、スケーリング動作、コンピューティング容量が向上します。
ルートの最適化
ルートの最適化 は、高スループットのワークロードに対して最も重要なインフラストラクチャの改善を提供します。 エンドポイントでルートの最適化を有効にすると、Databricks Model Serving によって推論要求のネットワーク パスが改善され、クライアントとモデル間の通信が高速化され、より直接的になります。
パフォーマンス上の利点:
| 特徴 | 標準エンドポイントの制限 | ルート最適化エンドポイントの制限 |
|---|---|---|
| ワークスペースあたりの 1 秒あたりのクエリ数 (QPS) | 200 | 50,000 以上 (上限を超える場合は Databricks にお問い合わせください) |
| ワークスペースごとのクライアント コンカレンシー | 192-1024 (リージョンによって異なります) | 明示的な制限なし (プロビジョニングされたコンカレンシーによって制限されます) |
| サーブされるエンティティごとのエンドポイントのプロビジョニング済みコンカレンシー | 1,024 | 1,024 (上限を超える場合は Databricks にお問い合わせください) |
ルート最適化を使用する場合:
- 200 を超える QPS を必要とするワークロード
- 厳密な待機時間要件を持つアプリケーション (50 ミリ秒未満のオーバーヘッド)
- 複数の同時実行ユーザーにサービスを提供する運用環境のデプロイ
Important
ルートの最適化は、エンドポイントを提供するカスタム モデルでのみ使用できます。 Foundation Model API と外部モデルでは、ルートの最適化はサポートされていません。 認証には OAuth トークンが必要です。個人用アクセス トークンはサポートされていません。
セットアップ手順については、 サービス エンドポイントでのルートの最適化 に関するページを参照し、クエリの詳細については ルート最適化サービス エンドポイントの クエリを実行します。
プロビジョニング済みのコンカレンシー
プロビジョニングされたコンカレンシーは、エンドポイントが処理できる同時要求の数を制御します。 予想される QPS と待機時間の要件に基づいて、プロビジョニングされたコンカレンシーを構成します。
構成ガイドライン:
- 最小コンカレンシー: キューなしでベースライン トラフィックを処理するのに十分な高さに設定する
- 最大コンカレンシー: コストを制御しながらトラフィックの急増に対応するために十分に高く設定する
- 自動スケール: 自動スケールを有効にして、需要に基づいて容量を動的に調整する
必要なコンカレンシーを計算します。
Required Concurrency = Target QPS × Average Latency (seconds)
たとえば、ターゲットが平均待機時間が 200 ミリ秒の 100 QPS の場合は、次のようになります。
Required Concurrency = 100 × 0.2 = 20
ロード テストを使用して、実際の待機時間を測定し、最適なコンカレンシー設定を決定します。
インスタンスの種類
モデルのコンピューティング要件に基づいてインスタンスの種類を選択します。
| インスタンスの種類 | 最適な用途 | Trade-offs |
|---|---|---|
| CPU (小、中、大) | 軽量モデル、単純な推論ロジック | コンピューティング集中型モデルのコストを削減し、低速化する |
| GPU (小、中、大) | 大規模なモデル、複雑な計算、画像/ビデオ処理 | コストが高く、ディープ ラーニングに最適なパフォーマンス |
ヒント
開発とテスト用の CPU インスタンスから始めます。 GPU インスタンスに切り替えるのは、推論の待機時間が長いか、モデルに特殊なコンピューティング (ディープ ラーニング操作など) が必要な場合のみです。
モデルの最適化
モデルの最適化により、推論速度とリソース効率が向上します。
モデルのサイズと複雑さ
モデルのサイズと複雑さ: 一般に、モデルのサイズと複雑さが小さいほど、推論時間が短縮され、QPS が高くなります。 モデルが大きい場合は、モデルの量子化や排除などの手法を検討してください。
Batching
アプリケーションが 1 回の呼び出しで複数の要求を送信できる場合は、クライアント側でバッチ処理を有効にします。 これにより、予測ごとのオーバーヘッドを大幅に削減できます。
前処理と後処理の最適化
複雑な前処理と後処理をエンドポイントの提供からオフロードして、推論インフラストラクチャの負荷を軽減します。
クライアント側の最適化
クライアント側の最適化により、アプリケーションがサービス エンドポイントと対話する方法が向上します。
接続のプール
接続プールでは、要求ごとに新しい接続を作成する代わりに既存の接続が再利用されるため、オーバーヘッドが大幅に削減されます。
- 接続プールのベスト プラクティスを自動的に実装する Databricks SDK を使用する
- カスタム クライアントを使用する場合は、接続プールを自分で実装します。
エラー処理と再試行戦略
堅牢なエラー処理を実装して、特に自動スケール イベントやネットワークの中断中に、一時的な障害を適切に処理します。
ペイロード サイズの最適化
要求と応答のペイロード サイズを最小限に抑えて、ネットワーク転送時間を短縮し、スループットを向上させます。
パフォーマンスの測定と向上
パフォーマンスの監視
モザイク AI モデル サービスによって提供されるツールを使用して、エンドポイントのパフォーマンスを監視します。
| メトリック | 測定対象 | 目標 | 超過した場合のアクション |
|---|---|---|---|
| 待機時間 (P50、P90、P99) | 要求の応答時間 | アプリケーションに依存する (通常は < 100 から 500 ミリ秒) | キューの確認、モデルまたはクライアントの最適化 |
| スループット (QPS) | 1 秒あたりに完了した要求 | ワークロードに依存 | ルートの最適化を有効にし、プロビジョニングされたコンカレンシーを増やす |
| エラー率 | 失敗した要求の割合 | <1% | サービス ログを確認し、容量の問題を確認する |
| キューの深さ | 処理を待機している要求 | 0 (待ち行列なし) | プロビジョニングされたコンカレンシーを増やすか、自動スケールを有効にする |
| CPU/メモリ使用量 | リソース使用率 | <80% | インスタンスの種類のスケールアップまたはコンカレンシーの向上 |
詳細な監視ガイダンスについては、モデル品質とエンドポイント健全性の監視に関する記事を参照し、メトリクスを Prometheus や Datadog などの監視ツールに追跡およびエクスポートするためのエンドポイント健全性メトリクスの追跡とエクスポートを行います。
負荷テスト
ロード テストは、現実的なトラフィック条件下でエンドポイントのパフォーマンスを測定し、次のことに役立ちます。
- プロビジョニングされた最適なコンカレンシー設定を決定する
- パフォーマンスのボトルネックを特定する
- 待機時間とスループットの要件を検証する
- クライアントコンカレンシーとサーバーコンカレンシーの関係を理解する
エンドポイントを提供するためのロード テストを参照してください。
一般的なパフォーマンスの問題のトラブルシューティング
Queuing
Model Serving では、トラフィック パターンに基づいて容量を調整するための自動スケールがサポートされています。 ただし、自動スケールでは負荷の増加を検出し、追加の容量をプロビジョニングする時間が必要になるため、トラフィックが急増するとキューが発生する可能性があります。 この期間中、受信要求が一時的に使用可能な容量を超え、要求がキューに入る可能性があります。
キューは、要求レートまたはコンカレンシーがエンドポイントの現在の処理能力を超えたときに発生します。 これは通常、トラフィックの急激な急増、ワークロードのバースト、またはエンドポイントのプロビジョニングされたコンカレンシーが不十分な場合に発生します。 モデル サービス エンドポイントを使用すると、一時的なキューでバーストを処理できますが、定義されたしきい値を超えると、エンドポイントは HTTP 429 (要求が多すぎます) エラーを返してシステムの安定性を保護します。
キューに登録された要求は処理される前に待機するため、待ち時間が長くなります。 待ち時間を最小限にするには:
- ベースライン トラフィックと一般的なバーストを処理するのに十分な高さにプロビジョニングされた最小コンカレンシーを設定する
- 容量制限を高くするためにルートの最適化を有効にする
- クライアント アプリケーションで指数バックオフを使用して再試行ロジックを実装する
外部 API のボトルネック
モデルでは、多くの場合、推論中にデータ エンリッチメント、機能の取得、またはその他のタスクのために外部 API が呼び出されます。 これらの外部依存関係は、パフォーマンスのボトルネックになる可能性があります。
- 待機時間: 各外部 API 呼び出しの応答時間を測定します。 これらの呼び出しの待機時間が長くなるほど、全体的なサービス待ち時間が直接増加し、スループットが低下します。
- スループットの制限: 外部 API では、レート制限または容量の制約が課される場合があります。 これらの制限を超えると、調整、エラー、パフォーマンスの低下が発生する可能性があります。
- エラー率: 外部 API から頻繁にエラーが発生すると、再試行がトリガーされ、サービス エンドポイントの負荷が増加する可能性があります。
- キャッシュ: 外部 API から頻繁にアクセスされるデータのキャッシュを実装して、呼び出しの数を減らし、応答時間を向上させます。
これらの要因を監視してボトルネックを特定し、高スループットワークロードのターゲット最適化を実装します。