スケールモデル推論スループット

ワークロードを起動したりモデルを切り替えたりする際に、Unity Gatewayを通じたモデルトラフィックを徐々に増やしましょう。 このガイダンスは、Azure Databricksが提供する独自モデルおよびオープンウェイトモデル、および接続された外部プロバイダーを通じてアクセスされるモデルに適用されます。

トラフィックを徐々に増やす

利用可能な容量はモデル、プロバイダー、地域、サービスモードによって異なります。 リクエストは、トラフィックが設定されたレート制限内に収まっていても一時的な容量エラーに遭遇することがあります。 割当の増加だけではサービス容量が確保されるわけではありません。

スループットを上げるには:

1. 設定済みのサービスレート制限や、モデルや外部プロバイダーの制限を確認してください。 入力および出力トークン率、同時要求数、代表的なプロンプトおよび応答サイズを推定します。
2. まずは安定したトラフィックレベルから始めましょう。 新しい作業負荷の場合は、まず小規模で代表的な負荷から始めるのが良いでしょう。
3. 少しずつトラフィックを増やすこと。 リクエスト成功率、レイテンシ、トークン使用量、キュー深度、スロットリングや容量エラーを監視しながら、各レベルを安定させてください。 作業量が安定し、アプリケーションの運用目標を満たしたときにのみ再度増やしてください。
4. スロットリング、容量エラー、遅延がアプリケーションの許容範囲を超えて増加した場合は、段階的な引き上げを一時停止し、最後の安定したトラフィックレベルに戻してください。 並行性を減らし、優先度の低い作業はキューに入れたり延期したりします。

作業量やモデルや提供者の指針に基づいて、ステップサイズや観察期間を選びましょう。 モデル、地域、サービス容量を変更する際にこの検証を繰り返します。

スロットリングおよび容量エラーの処理

呼び出したAPIのHTTPステータスとエラーボディの両方を調べてください。 エラーコードやメッセージは、統一APIとプロバイダーネイティブAPIで異なる場合があります。

容量エラーだけではオートスケーリングが進行中であることや、いつ容量が利用可能になるかを示すことはできません。

リトライの設定

• 回答に Retry-After ヘッダーが含まれている場合は、そのまま尊重してください。 それ以外の場合は、一時的なスロットリング エラーや容量エラーを、指数バックオフとランダム ジッターを使用して再試行します。
• アプリケーションの遅延予算に合わせて、総試行回数と経過時間を制限しましょう。 エラーが続く場合は、再試行を増やすのではなくトラフィックを減らしましょう。
• アプリケーションの再試行を追加する前にSDKの再試行動作を確認してください。 レイヤー間の再試行を考慮し、負荷が増大しないようにしましょう。
• ストリームコンシューマーでストリーミング応答が始まった後のエラーを処理します。 出力を受け取った後にリクエストを再送すると、出力または処理が重複する可能性があります。

持続的なエラーについては、リクエストID、タイムスタンプ、モデル名とプロバイダー名、観測されたトークンレート、並行性、トラフィックランプのタイムラインを添えてDatabricksアカウントチームにお問い合わせください。 接続された外部プロバイダーについては、プロバイダーのサービス状況やアカウント制限も確認してください。

バッチ推論

対応モデルでの大規模なオフライン ワークロードには、並列化、リトライ、スケーリングを管理するAI Functionsを使用してください。 各行に別々のリトライループを適用するのではなく、バッチ推論のガイダンスに従ってください。