モデル推論のthroughputをスケールする
ワークロードの起動時やモデルの切り替え時には、Unity Gateway を介したモデルトラフィックを徐々に増やします。このガイダンスは、Databricks によって提供されるプロプライエタリモデルおよびオープンウェイトモデル、および接続された外部プロバイダーを介してアクセスされるモデルに適用されます。
トラフィックを徐々に増やす
利用可能な容量は、モデル、プロバイダー、リージョン、およびサービングモードによって異なります。トラフィックが設定されたレート制限内に収まっている場合でも、リクエストで一時的な容量エラーが発生する可能性があります。クォータを増やしただけでは、サービング容量は確保されません。
throughputを増やすには：
- 構成済みのサービスレート制限と、モデルまたは外部プロバイダーの制限を確認してください。代表的なプロンプトと応答のサイズを含む、入力および出力トークンレートと並列リクエストを見積もります。
- 既知の安定したトラフィックレベルで起動します。新しいワークロードの場合は、小さな代表的な負荷から起動します。
- トラフィックは小さなステップで増やします。各レベルを一定に保ちながら、リクエストの成功率、レイテンシ、トークン使用量、キューの深さ、スロットリングや容量エラーをモニタリングします。ワークロードが安定し、アプリケーションの運用目標を満たしている場合にのみ、再び増やします。
- スロットリング、容量エラー、または待機時間がアプリケーションの許容範囲を超えて増加した場合は、ランプを一時停止し、最後に安定したトラフィックレベルに戻ります。並列処理を減らし、優先度の低い作業をキューに入れるか延期します。
ワークロードと、モデルまたはプロバイダーのガイダンスに基づいて、ステップサイズと観測期間を選択します。モデル、リージョン、またはサービング容量を変更する際に、この検証を繰り返します。
スロットリングと容量エラーの処理
呼び出すAPIのHTTPステータスとエラー本文の両方を検査します。エラーコードとメッセージは、統合 API とプロバイダーネイティブ APIs 間で異なる場合があります。
レスポンス | 意味とアクション |
|---|---|
| 設定されたレート制限またはダウンストリームのスロットリングがリクエストを妨げています。一部のプロバイダーは、トラフィックの急激な増加もスロットリングします。エラー本文から制限を特定し、リクエストレートを下げ、トラフィックを徐々に増やします。エラーに割り当てまたは課金の変更が必要な場合は、再試行する前にその条件を解決します。 |
| サービスまたはモデルが一時的にリクエストを処理できません。これは、構成されたレート制限を下回る場合を含め、トラフィックの増加中に発生する可能性があります。制限付き予算内で再試行し、エラーが続く場合はランプを停止する。 |
その他のプロバイダー過負荷エラー | 一部のプロバイダー APIs は、一時的な過負荷に対して |
容量エラーのみでは、オートスケールが進行中であるか、または容量がいつ利用可能になるかを示すことはできません。
再試行を設定
- 応答に
Retry-Afterヘッダーが含まれている場合は、そのヘッダーを遵守します。そうでない場合は、指数バックオフとランダムジッターを使用して一時的なスロットリングおよび容量エラーを再試行します。 - 試行回数と経過時間に制限を設けて、アプリケーションのレイテンシーバジェット内に収めるようにしてください。エラーが解決しない場合は、リトライを追加するのではなく、トラフィックを減らしてください。
- アプリケーションの再試行を追加する前に、SDKの再試行動作を確認してください。負荷が増加しないように、レイヤー全体での再試行を考慮します。
- ストリームコンシューマーでストリーミング応答が起動された後にエラーを処理します。出力の受信後にリクエストを再試行すると、出力または作業が重複する可能性があります。
永続的なエラーについては、リクエスト ID、Timestamp、モデル名、プロバイダー名、観測されたトークンレート、同時実行数、およびトラフィックランプのタイムラインを Databricks アカウントチームに連絡してください。接続されている外部プロバイダーについては、プロバイダーのサービスステータスとアカウント制限も確認してください。
バッチ推論
サポートされているモデルを持つ大規模なオフラインワークロードの場合は、並列化、再試行、スケーリングを管理するAI Functionsを使用してください。各行に個別の再試行ループを適用する代わりに、バッチ推論のガイダンスに従ってください。