プロビジョニングされたスループットとは
プロビジョニングされたスループット機能を使用すると、デプロイで必要なスループットの量を指定できます。 その後、サービスは必要なモデル処理容量を割り当て、その準備が整っていることを確認します。 スループットは、デプロイのスループットを表す正規化された方法であるプロビジョニング スループット ユニット (PTU) という観点で定義されます。 各モデルバージョン ペアでは、デプロイして PTU ごとにさまざまな量のスループットを提供するために、さまざまな量の PTU が必要となります。
プロビジョニングされたデプロイの種類では何が提供されますか?
- 予測可能なパフォーマンス: 均一なワークロードに対して安定した最大待ち時間とスループット。
- 予約済み処理機能: デプロイでスループット量が構成されます。 デプロイされると、スループットは、使用の有無にかかわらず利用できます。
- コスト削減: 高スループット ワークロードは、トークンベースの使用と比較したときのコスト削減につながる場合があります。
Azure OpenAI のデプロイは、特定の OpenAI モデルの管理単位です。 デプロイは、推論のためのモデルへの顧客アクセスを提供し、コンテンツ モデレーション (コンテンツ モデレーションのドキュメントを参照してください) などのその他の機能を統合します。
Note
プロビジョニング スループット ユニット (PTU) クォータは、Azure OpenAI の標準クォータとは異なり、既定では利用できません。 このオファリングの詳細については、Microsoft アカウント チームにお問い合わせください。
どうなりますか。
| トピック | プロビジョニング済み |
|---|---|
| Xbox Live ゲームのバインドとは ? | 既存のプロビジョニング オファーよりも増分値の小さいスループットが保証されます。 デプロイでは、特定のモデルバージョンに対して一貫した最大待機時間が存在します。 |
| 対象ユーザー | 最小限の待ち時間の変動で保証されたスループットをお求めのお客様。 |
| クォータ | 特定のモデルのプロビジョニング マネージド スループット ユニット。 |
| Latency | モデルによる制約を受ける最大待機時間。 全体的な待機時間は、呼び出し形式を決める要因となります。 |
| 稼働率 | Azure Monitor で提供されるプロビジョニング マネージド使用率の測定値。 |
| サイズの見積もり | スタジオおよびベンチマーク スクリプトで指定された計算ツール。 |
プロビジョニング スループットにアクセスするにはどうすればよいですか?
プロビジョニング スループットを取得するには、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-35-turbo をデプロイするために GPT-4 のクォータを使用することはできません。 デプロイの種類、モデル、リージョンをまたいでクォータを移動するためのサポート リクエストを提出することはできますが、入れ替えは保証されてはいません。
Microsoft は、クォータが常にデプロイ可能であるようにするためにあらゆる努力を行いますが、クォータにおいて基盤の容量が利用可能であることは保証されていません。 このサービスは、デプロイ操作時に容量を割り当て、容量が利用可能でない場合、デプロイは容量不足エラーで失敗します。
ワークロードに必要な PTU の数の決定
PTU は、モデルの処理容量の大きさを表します。 コンピューターやデータベースと同様に、モデルに対するワークロードや要求が異なると、基になる処理容量の消費量が異なります。 呼び出し形状特性 (プロンプト サイズ、生成サイズ、呼び出し速度) から PTU への変換は複雑で、線形ではありません。 このプロセスを簡単にするには、Azure OpenAI 容量計算ツールを使って、特定のワークロード形状のサイズを確認できます。
高いレベルのいくつかの考慮事項:
- 生成には、プロンプトより多くの容量が必要です
- 呼び出しが大きくなるほど、コンピューティング コストは徐々に高くなります。 たとえば、1,000 トークン プロンプト サイズでの 100 回の呼び出しは、プロンプトに 100,000 個のトークンを含む 1 回の呼び出しより容量が少なくなります。 これは、全体的なスループットではこれらの呼び出し形状の分布が重要であることを意味します。 非常に大きな呼び出しをいくつか含み分布が広いトラフィック パターンでは、プロンプトと完了トークンのサイズの平均が同じで分布が狭い場合より、PTU あたりのスループットが低くなる可能性があります。
使用率の適用のしくみ
プロビジョニング デプロイでは、特定のモデルを実行するためのモデル処理容量の割り当て量が提供されます。 Azure Monitor の Provisioned-Managed Utilization メトリックは、特定のデプロイの使用率を 1 分単位で測定します。 プロビジョニング マネージド デプロイは、受け入れられた呼び出しが一貫したモデル処理時間で処理されることを保証するように最適化されています (実際のエンドツーエンドの待機時間は、呼び出しの特性に依存します)。 ワークロードが割り当てられた PTU 容量を超えると、サービスは使用率が 100% を下回るまで、429 HTTP ステータス コードを返します。
429 応答を受け取ったらどうすればよいですか?
429 応答はエラーではなく、特定のデプロイがある時点で完全に利用されていることをユーザーに伝えるための設計の一部です。 高速な失敗応答の提供によって、ユーザーはアプリケーションの要件に最適な方法でこれらの状況を処理するための制御を行えます。
応答中の retry-after-ms および retry-after ヘッダーは、次の呼び出しが受け入れられるようになるまでの待機時間を伝えます。 この応答をどのように処理するかの選択は、アプリケーションの要件によって決まります。 次にいくつかの考慮事項を示します。
- トラフィックを他のモデル、デプロイ、またはエクスペリエンスにリダイレクトすることも検討できます。 このアクションは 429 シグナルを受信してすぐに実行できるため、この選択肢は最も低遅延の解決策です。
- 呼び出しごとの待機時間が長くなっても問題ない場合は、クライアント側の再試行ロジックを実装します。 この選択肢では、PTU あたりのスループット量が最も高くなります。 Azure OpenAI クライアント ライブラリには、再試行を処理するための組み込みの機能が含まれています。
サービスは 429 を送信するタイミングをどのように判断しますか?
トラフィックにおいて一定のバースト性を許容しながら使用率を 100% 未満に維持するために、リーキー バケット アルゴリズムの一種が使用されています。 大まかなロジックは以下のとおりです。
それぞれのお客様は、デプロイで利用できる一定量の容量を持っています。
要求が行われたとき:
a. 現在の使用率が 100% を超えている場合、サービスは
retry-after-msヘッダーに使用率が 100% を下回るまでの時間を設定して 429 コードを返しますb. それ以外の場合、サービスは、プロンプト トークンを呼び出しで指定された
max_tokensと組み合わせることにより、要求を処理するために必要な使用率がどれくらい増えるかを見積もります。max_tokensパラメーターが指定されていない場合、サービスは値を推定します。 この推定より実際に生成されるトークンの数が少ない場合、予想よりコンカレンシーが低下する可能性があります。 コンカレンシーを最高にするには、max_tokensの値を、実際の生成サイズに可能な限り近くなるようにしてください。要求が完了すると、呼び出しの実際のコンピューティング コストがわかります。 正確な計算を実現するために、次のロジックを使用して使用率を修正します。
a. "実際" > "見積もり" が成り立つ場合は、その差がデプロイの使用率に追加されます b. "実際" < "見積もり" が成り立つ場合は、その差が減算されます。
全体的な使用率は、デプロイされた PTU の数に基づいて連続的な割合で減少します。
Note
呼び出しは、使用率が 100% に達するまで受け入れられます。 100% をわずかに超えるバーストは、短期間であれば許可される可能性がありますが、時間が経つにつれて、トラフィックの使用率は 100% に制限されます。
デプロイでは同時にいくつの呼び出しを行うことができますか?
達成できる同時呼び出し数は、各呼び出しの形状 (プロンプト サイズ、max_token パラメーターなど) によって異なります。 使用率が 100% に達するまで、サービスは呼び出しを受け入れ続けます。 同時呼び出しのおおよその数を確認するには、容量計算ツールで特定の呼び出し形式に対する 1 分あたりの最大要求数をモデル化できます。 max_token のようなサンプリング トークン数よりもシステムによる生成数が少ない場合、より多くの要求が受け入れられます。