プロビジョニングされたスループットとは

プロビジョニング済みスループット オファリングは、モデル デプロイの種類であり、モデル デプロイで必要なスループットの量を指定できます。 その後、Azure OpenAI によって必要なモデル処理容量が割り当てられ、準備が整います。 プロビジョニングされたスループットでは、次の機能が提供されます。

• 予測可能なパフォーマンス: 均一なワークロードに対して安定した最大待ち時間とスループット。
• 処理容量の割り当て: デプロイでスループット量が構成されます。 デプロイされると、スループットは、使用の有無にかかわらず利用できます。
• コスト削減: 高スループット ワークロードは、トークンベースの使用と比較したときのコスト削減につながる場合があります。

プロビジョニング済みスループットを使用するタイミング

適切に定義された予測可能なスループットと待機時間の要件がある場合は、標準デプロイからプロビジョニングされたマネージド デプロイに切り替えることを検討する必要があります。 通常、これは、アプリケーションが本格運用するための準備ができている場合、または運用環境に既にデプロイされていて、予想されるトラフィックを理解している場合に発生します。 これにより、ユーザーは必要な容量を正確に予測し、予期しない課金を回避できます。 プロビジョニングされたマネージド デプロイは、リアルタイム/待機時間の機密性の高い要件があるアプリケーションにも役立ちます。

重要な概念

プロビジョニング スループット ユニット (PTU)

プロビジョニング済みスループット ユニット (PTU) は、プロンプトの処理と完了の生成に必要なスループットを実現するためにプロビジョニングされたデプロイのサイズを設定するために使用できる、モデル処理容量の汎用ユニットです。 プロビジョニングされたスループット ユニットは、クォータとしてサブスクリプションに付与され、コストの定義に使用されます。 各クォータは Azure リージョンに固有であり、そのサブスクリプションおよび Azure リージョン内のデプロイに割り当てられる PTU の最大数が定義されます。 プロビジョニングマネージド オファリングと PTU に関連するコストの詳細については、「 PTU に関連するコストについて」を参照してください。

展開タイプ

Azure AI Foundry でプロビジョニング済みデプロイを作成する場合、[デプロイの作成] ダイアログのデプロイの種類は、指定されたワークロードのデータ処理のニーズに応じて、グローバル プロビジョニング済みマネージド、データ ゾーン プロビジョニング済みマネージド、リージョン プロビジョニング済みマネージドのデプロイの種類に設定できます。

CLI または API を使用して Azure OpenAI でプロビジョニング済みデプロイを作成する場合、sku-name は、指定されたワークロードのデータ処理のニーズに応じて、GlobalProvisionedManaged、DataZoneProvisionedManaged、または ProvisionedManaged に設定できます。 以下の Azure CLI コマンド例を別のデプロイの種類に適応させるには、sku-name パラメーターを、デプロイしたいデプロイの種類に合わせて更新するだけです。

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06  \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged

容量の透明性

Azure OpenAI は、お客様の需要がサービス GPU 容量を超える可能性がある、人気の高いサービスです。 Microsoft は、需要があるすべてのリージョンとモデルに容量を提供するよう努めていますが、リージョンの売り切れの可能性が常にあります。 この制約により、たとえその Azure リージョン内に使用可能なクォータがある場合でも、その Azure リージョン内で必要なモデル、バージョン、または PTU 数のデプロイを作成する顧客の機能が制限される可能性があります。 一般には、以下のようになります。

• クォータは、サブスクリプションおよび Azure リージョン内にデプロイできる PTU の最大数に制限を設定します。使用可能な容量を保証するものではありません。
• 容量はデプロイ時に割り当てられ、デプロイが存在する限り保持されます。 サービス容量が使用できない場合、デプロイは失敗します
• お客様は、クォータ/容量の可用性に関するリアルタイムの情報を使用して、必要なモデル容量を持つシナリオに適したリージョンを選択します
• デプロイをスケールダウンまたは削除すると、容量が解放されリージョンに戻されます。 デプロイをスケールアップまたは後で再作成すると容量が使用可能になるという保証はありません。

リージョンごとの容量のガイダンス

デプロイに必要な容量を調べるには、容量の可用性に関するリアルタイムの情報を提供する、容量の API または Azure AI Foundry のデプロイ エクスペリエンスを使用します。

Azure AI Foundry では、デプロイ エクスペリエンスにより、Azure リージョンでモデルのデプロイに必要な容量が不足する時期を特定します。 これにより、必要なモデル、バージョン、PTU 数を確認します。 容量が利用不可である場合、このエクスペリエンスではユーザーが代わりの Azure リージョンの選択に誘導されます。

デプロイ エクスペリエンスの詳細については、Azure OpenAI プロビジョニングの概要ガイドを参照してください。

モデル容量 API を使用して、指定したモデルの最大サイズのデプロイをプログラムで識別できます。 この API では、リージョン内のクォータとサービス容量の両方が考慮されます。

必要なモデル、バージョン、PTU をサポートするために受け入れ可能なリージョンが使用できない場合は、次の手順を試すこともできます。

• PTU の数を減らしてデプロイを試みます。
• 別の時刻にデプロイを試みます。 容量の可用性は、お客様の需要に基づいて動的に変化し、もっと多くの容量が後で使用可能になる可能性があります。
• 受け入れ可能なすべてのリージョンでクォータが使用可能であることを確認します。 モデル容量 API と Azure AI Foundry エクスペリエンスでは、デプロイを作成するための代替リージョンを返す際にクォータの可用性を考慮します。

容量を監視するにはどうすればよいですか?

Azure Monitor のProvisioned-Managed Utilization V2 は、特定のデプロイの使用率を 1 分単位で測定するメトリックです。 すべてのプロビジョニング済みデプロイの種類は、受け入れられた呼び出しが一貫したモデル処理時間で処理されることを保証するように最適化されています (実際のエンドツーエンドの待機時間は、呼び出しの特性に依存します)。

使用率のパフォーマンスのしくみ

プロビジョニング デプロイでは、特定のモデルを実行するためのモデル処理容量の割り当て量が提供されます。

すべてのプロビジョニング済みデプロイの種類では、容量を超えると、API から 429 HTTP 状態エラーが返されます。 この迅速な応答により、ユーザーはそのトラフィックを管理する方法を決定できるようになります。 ユーザーは、要求を別のデプロイにリダイレクトしたり、標準のデプロイ インスタンスにリダイレクトしたり、再試行戦略を使用して特定の要求を管理したりできます。 使用率が 100% を下回るまで、サービスからは引き続き 429 HTTP 状態コードが返されます。

429 応答を受け取ったらどうすればよいですか?

429 応答はエラーではなく、特定のデプロイがある時点で完全に利用されていることをユーザーに伝えるための設計の一部です。 高速な失敗応答の提供によって、ユーザーはアプリケーションの要件に最適な方法でこれらの状況を処理するための制御を行えます。

応答中の retry-after-ms および retry-after ヘッダーは、次の呼び出しが受け入れられるようになるまでの待機時間を伝えます。 この応答をどのように処理するかの選択は、アプリケーションの要件によって決まります。 次にいくつかの考慮事項を示します。

• トラフィックを他のモデル、デプロイ、またはエクスペリエンスにリダイレクトすることも検討できます。 このアクションは 429 シグナルを受信してすぐに実行できるため、この選択肢は最も低遅延の解決策です。 このパターンを効果的に実装する方法のアイデアについては、こちらのコミュニティの投稿を参照してください。
• 呼び出しごとの待機時間が長くなっても問題ない場合は、クライアント側の再試行ロジックを実装します。 この選択肢では、PTU あたりのスループット量が最も高くなります。 Azure OpenAI クライアント ライブラリには、再試行を処理するための組み込みの機能が含まれています。

サービスは 429 を送信するタイミングをどのように判断しますか?

すべてのプロビジョニング済みデプロイの種類では、各要求は、プロンプト サイズ、予想される生成サイズ、モデルに従って個別に評価され、予想される使用率が決定されます。 これは、トラフィックの推定負荷に基づいて カスタムレート制限動作を 持つ標準デプロイとは対照的です。 標準デプロイでは、トラフィックが均等に分散されていない場合、定義済みのクォータ値を超える前に HTTP 429 エラーが生成される可能性があります。

プロビジョニング済みデプロイの場合、トラフィックにおいて一定のバースト性を許容しながら使用率を 100% 未満に維持するために、リーキー バケット アルゴリズムの一種が使用されています。 大まかなロジックは以下のとおりです。

1. それぞれのお客様は、デプロイで利用できる一定量の容量を持っています。

2. 要求が行われたとき:

   a. 現在の使用率が 100% を超えている場合、サービスは retry-after-ms ヘッダーに使用率が 100% を下回るまでの時間を設定して 429 コードを返します

   b。 それ以外の場合、サービスはプロンプト トークン (キャッシュされたトークンを除く) と呼び出しで指定された max_tokens を組み合わせることによって、要求を処理するために必要な使用率への増分変更を見積もります。 顧客は、キャッシュされたトークンのサイズに応じて、プロンプト トークンに対して最大 100% の割引を受けることができます。 max_tokens パラメーターが指定されていない場合、サービスは値を推定します。 この推定より実際に生成されるトークンの数が少ない場合、予想よりコンカレンシーが低下する可能性があります。 コンカレンシーを最高にするには、max_tokens の値を、実際の生成サイズに可能な限り近くなるようにしてください。

3. 要求が完了すると、呼び出しの実際のコンピューティング コストがわかります。 正確な計算を実現するために、次のロジックを使用して使用率を修正します。

   a. 実際の > 見積もりが成り立つ場合は、その差がデプロイの使用率に追加されます。

   b。 "実際" < "見積もり" が成り立つ場合は、その差が減算されます。

4. 全体的な使用率は、デプロイされた PTU の数に基づいて連続的な割合で減少します。

デプロイでは同時にいくつの呼び出しを行うことができますか?

実現できる同時呼び出しの数は、各呼び出しの形状 (プロンプト サイズ、max_tokens パラメーターなど) によって異なります。 サービスは、使用率が 100% に達するまで、引き続き呼び出しを受け入れます。 同時呼び出しのおおよその数を決定するには、容量計算ツール内で特定の呼び出し形式に対する 1 分あたりの最大要求数をモデル化してください。 max_tokens パラメーターで設定された数より少ない出力トークンがシステムによって生成された場合、プロビジョニング済みデプロイはさらに多くの要求を受け入れます。

プロビジョニングされたスループットに使用できるモデルとリージョンは何ですか?

次のステップ

• プロビジョニング デプロイのオンボード手順について学習する
• プロビジョニング スループット ユニット (PTU) の概要ガイド