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

プロビジョニングされたスループット機能を使用すると、デプロイで必要なスループットの量を指定できます。 その後、サービスは必要なモデル処理容量を割り当て、その準備が整っていることを確認します。 スループットは、デプロイのスループットを表す正規化された方法であるプロビジョニング スループット ユニット (PTU) という観点で定義されます。 各モデルバージョン ペアでは、デプロイして PTU ごとにさまざまな量のスループットを提供するために、さまざまな量の PTU が必要となります。

プロビジョニングされたデプロイの種類では何が提供されますか?

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

Azure OpenAI のデプロイは、特定の OpenAI モデルの管理単位です。 デプロイは、推論のためのモデルへの顧客アクセスを提供し、コンテンツ モデレーション (コンテンツ モデレーションのドキュメントを参照してください) などのその他の機能を統合します。

どうなりますか。

プロビジョニング スループットにアクセスするにはどうすればよいですか?

プロビジョニング スループットを取得するには、Microsoft の営業/アカウント チームに問い合わせる必要があります。 営業/アカウント チームがない場合、残念ながら現時点ではプロビジョニング スループットを購入することはできません。

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

重要な概念

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

プロビジョニング スループット ユニット (PTU) は、プロンプトの処理と補完の生成のために予約してデプロイできるモデル処理容量の単位です。 各ユニットに関連する最小 PTU のデプロイ、増分、処理の容量は、モデルの種類およびバージョンによって異なります。

展開タイプ

Azure OpenAI にモデルをデプロイする場合は、sku-name をプロビジョニング マネージドに設定する必要があります。 sku-capacity は、デプロイに割り当てられる PTU の数を指定します。

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613  \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged 

売上予算

プロビジョニング スループット クォータは、デプロイ可能な合計スループットの特定の量を表します。 Azure OpenAI Service のクォータは、サブスクリプション レベルで管理されます。 サブスクリプション内のすべての Azure OpenAI リソースが、このクォータを共有します。

クォータはプロビジョニング スループット ユニットで指定され、(デプロイの種類、モデル、リージョン) の 3 つの組み合わせに対して固有です。 クォータを交換することはできません。 つまり、GPT-3.5-Turbo をデプロイするために GPT-4 のクォータを使用することはできません。

Microsoft は、クォータが常にデプロイ可能であるようにするためにあらゆる努力を行いますが、クォータにおいて基盤の容量が利用可能であることは保証されていません。 このサービスは、デプロイ操作時に容量を割り当て、容量が利用可能でない場合、デプロイは容量不足エラーで失敗します。

ワークロードに必要な DTU の数の決定

PTU は、モデルの処理容量の大きさを表します。 コンピューターやデータベースと同様に、モデルに対するワークロードや要求が異なると、基になる処理容量の消費量が異なります。 呼び出し形状特性 (プロンプト サイズ、生成サイズ、呼び出し速度) から PTU への変換は複雑で、線形ではありません。 このプロセスを簡単にするには、Azure OpenAI 容量計算ツールを使って、特定のワークロード形状のサイズを確認できます。

高いレベルのいくつかの考慮事項:

• 生成には、プロンプトより多くの容量が必要です
• 呼び出しが大きくなるほど、コンピューティング コストは徐々に高くなります。 たとえば、1,000 トークン プロンプト サイズでの 100 回の呼び出しは、プロンプトに 100,000 個のトークンを含む 1 回の呼び出しより容量が少なくなります。 これは、全体的なスループットではこれらの呼び出し形状の分布が重要であることを意味します。 非常に大きな呼び出しをいくつか含み分布が広いトラフィック パターンでは、プロンプトと完了トークンのサイズの平均が同じで分布が狭い場合より、PTU あたりのスループットが低くなる可能性があります。

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

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

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

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

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

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 と組み合わせることにより、要求を処理するために必要な使用率がどれくらい増えるかを見積もります。 max_tokens パラメーターが指定されていない場合、サービスは値を推定します。 この推定より実際に生成されるトークンの数が少ない場合、予想よりコンカレンシーが低下する可能性があります。 コンカレンシーを最高にするには、max_tokens の値を、実際の生成サイズに可能な限り近くなるようにしてください。

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

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

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

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

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

次のステップ

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