プロビジョニングされたスループットとは
Note
Azure OpenAI プロビジョニング オファリングは、購入モデルと Azure 標準との調整や、モデルに依存しないクォータへの移行を含めて、大幅な更新を 2024 年 8 月 12 日に受信しました。 この日付より前に利用開始したお客様は、Azure OpenAI プロビジョニングの 8 月の更新に関するページを読んで、これらの変更の詳細を確認することを強くお勧めします。
プロビジョニングされたスループット機能を使用すると、デプロイで必要なスループットの量を指定できます。 その後、サービスは必要なモデル処理容量を割り当て、その準備が整っていることを確認します。 スループットは、デプロイのスループットを表す正規化された方法であるプロビジョニング スループット ユニット (PTU) という観点で定義されます。 各モデルバージョン ペアでは、デプロイして PTU ごとにさまざまな量のスループットを提供するために、さまざまな量の PTU が必要となります。
プロビジョニングとグローバル プロビジョニングというデプロイの種類が提供する内容
- 予測可能なパフォーマンス: 均一なワークロードに対して安定した最大待ち時間とスループット。
- 予約済み処理機能: デプロイでスループット量が構成されます。 デプロイされると、スループットは、使用の有無にかかわらず利用できます。
- コスト削減: 高スループット ワークロードは、トークンベースの使用と比較したときのコスト削減につながる場合があります。
Azure OpenAI のデプロイは、特定の OpenAI モデルの管理単位です。 デプロイは、推論のためのモデルへの顧客アクセスを提供し、コンテンツ モデレーション (コンテンツ モデレーションのドキュメントを参照してください) などのその他の機能を統合します。 Global デプロイは、非グローバル デプロイ タイプと同じ Azure OpenAI リソースで利用できます。ただし、Azure のグローバル インフラストラクチャを利用して、トラフィックを要求ごとに最適な可用性のデータ センターに動的にルーティングできます。
どうなりますか。
| トピック | プロビジョニング済み |
|---|---|
| Xbox Live ゲームのバインドとは ? | 既存のプロビジョニング オファーよりも増分値の小さいスループットが保証されます。 デプロイでは、特定のモデルバージョンに対して一貫した最大待機時間が存在します。 |
| 対象ユーザー | 最小限の待ち時間の変動で保証されたスループットをお求めのお客様。 |
| 売上予算 | リージョンごとに割り当てられたプロビジョニング マネージド スループット ユニットまたはグローバル プロビジョニング マネージド スループット ユニット。 クォータは、使用できるすべての Azure OpenAI モデルで使用できます。 |
| Latency | モデルによる制約を受ける最大待機時間。 全体的な待機時間は、呼び出し形式を決める要因となります。 |
| 稼働率 | Azure Monitor で提供されるプロビジョニングマネージド使用率 V2 の測定。 |
| サイズの見積もり | スタジオおよびベンチマーク スクリプトで指定された計算ツール。 |
プロビジョニングされたスループットに使用できるモデルとリージョンは何ですか?
| リージョン | gpt-4、0613 | gpt-4、1106-Preview | gpt-4、0125-Preview | gpt-4、turbo-2024-04-09 | gpt-4o、2024 年 5 月 13 日 | gpt-4o-mini、2024-07-18 | gpt-4-32k、0613 | gpt-35-turbo、1106 | gpt-35-turbo、0125 |
|---|---|---|---|---|---|---|---|---|---|
| australiaeast | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| brazilsouth | ✅ | ✅ | ✅ | - | ✅ | - | ✅ | ✅ | - |
| canadacentral | ✅ | - | - | - | - | - | ✅ | - | ✅ |
| canadaeast | ✅ | ✅ | - | ✅ | ✅ | ✅ | - | ✅ | - |
| eastus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| eastus2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| francecentral | ✅ | ✅ | ✅ | - | ✅ | - | ✅ | - | ✅ |
| germanywestcentral | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | - |
| japaneast | - | ✅ | ✅ | ✅ | ✅ | - | - | - | ✅ |
| koreacentral | ✅ | - | - | ✅ | ✅ | - | ✅ | ✅ | - |
| northcentralus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| norwayeast | ✅ | - | ✅ | - | - | - | ✅ | - | - |
| polandcentral | ✅ | ✅ | ✅ | - | - | - | ✅ | ✅ | ✅ |
| southafricanorth | ✅ | ✅ | - | ✅ | - | - | ✅ | ✅ | - |
| southcentralus | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| southindia | ✅ | ✅ | ✅ | - | ✅ | - | ✅ | ✅ | ✅ |
| swedencentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| switzerlandnorth | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| switzerlandwest | - | - | - | - | - | - | - | - | ✅ |
| uksouth | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| westus | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| westus3 | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
Note
gpt-4 バージョン turbo-2024-04-09 のプロビジョニングされたバージョンは、現在、テキストのみに制限されています。
重要な概念
展開タイプ
Azure OpenAI Studio でプロビジョニングされたデプロイを作成する場合、[デプロイの作成] ダイアログのデプロイの種類は Provisioned-Managed です。 Azure Open Studio でグローバル プロビジョニング マネージド デプロイを作成する場合、[デプロイの作成] ダイアログのデプロイの種類は "グローバル プロビジョニングマネージド" です。
CLI または API を使用して Azure OpenAI でプロビジョニング デプロイを作成する場合は、sku-name を ProvisionedManaged に設定する必要があります。 CLI または API を使用して Azure OpenAI でグローバル プロビジョニング デプロイを作成する場合は、sku-name を GlobalProvisionedManaged に設定する必要があります。 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
売上予算
プロビジョニング スループット ユニット
プロビジョニング スループット ユニット (PTU) は、プロンプトの処理と補完の生成のため必要なスループットを実現するようにプロビジョニングされたデプロイのサイズ指定に使用できるモデル処理容量の一般の単位です。 プロビジョニング スループット ユニットは、リージョンごとにクォータとしてサブスクリプションに付与されます。これにより、そのサブスクリプションとリージョンのデプロイに割り当てることができる PTU の最大数が定義されます。
モデルに依存しないクォータ
他の Azure OpenAI オファリングで使用される 1 分あたりのトークン数 (TPM) クォータとは異なり、PTU はモデルに依存しません。 PTU を使用して、サポートされている任意のモデル/バージョンをリージョンにデプロイできます。
プロビジョニング デプロイの場合、新しいクォータは、プロビジョニング マネージド スループット ユニットという名前のクォータ項目として Azure OpenAI Studio に表示されます。 グローバル プロビジョニング マネージド デプロイの場合、新しいクォータは、グローバル プロビジョニング マネージド スループット ユニットという名前のクォータ項目として Azure OpenAI Studio に表示されます。 Studio の [クォータ] ウィンドウで、クォータ項目を展開すると、各クォータの使用に影響するデプロイが表示されます。
PTU クォータの取得
PTU クォータは、多くのリージョンで既定で使用可能です。 追加のクォータが必要な場合、Azure OpenAI Studio のプロビジョニング マネージド スループット ユニットまたはグローバル プロビジョニング マネージド スループット ユニットのクォータ項目の右側にある [クォータの要求] リンクを使用して、追加のクォータを要求できます。 お客様はこのフォームを使用して、特定のリージョンについて指定した PTU クォータの引き上げを依頼できます。 要求が承認されると、お客様は、通常は 2 営業日以内に、含まれているアドレスで電子メールを受け取ります。
モデルごとの PTU の最小値
各ユニットに関連する最小 PTU のデプロイ、増分、処理の容量は、モデルの種類およびバージョンによって異なります。
容量の透明性
Azure OpenAI は、お客様の需要がサービス GPU 容量を超える可能性がある、人気の高いサービスです。 Microsoft は、需要があるすべてのリージョンとモデルに容量を提供するよう努めていますが、リージョンの売り切れの可能性が常にあります。 これにより、目的のリージョンに使用可能なクォータがある場合であっても、そのリージョンで必要なモデル、バージョン、または数の PTU のデプロイを作成するお客様側の機能が制限される可能性があります。 一般には、以下のようになります。
- クォータは、サブスクリプションとリージョンにデプロイできる PTU の最大数に制限を設定し、容量の可用性を保証するものではありません。
- 容量はデプロイ時に割り当てられ、デプロイが存在する限り保持されます。 サービス容量が使用できない場合、デプロイは失敗します
- お客様は、クォータ/容量の可用性に関するリアルタイムの情報を使用して、必要なモデル容量を持つシナリオに適したリージョンを選択します
- デプロイをスケールダウンまたは削除すると、容量が解放されリージョンに戻されます。 デプロイをスケールアップまたは後で再作成すると容量が使用可能になるという保証はありません。
リージョンごとの容量のガイダンス
ユーザーがデプロイに必要な容量を見つけるのに役立つように、お客様は新しい API と Studio のエクスペリエンスを使用して、リアルタイムの情報を提供します。
Azure OpenAI Studio では、デプロイ エクスペリエンスにより、必要なモデル、バージョン、および数の PTU をサポートする容量がリージョンにない時点を特定し、必要に応じて、代替リージョンを選択するようにユーザーを誘導します。
新しいデプロイ エクスペリエンスの詳細については、Azure OpenAI プロビジョニングの使用開始ガイドに関するページを参照してください。
新しいモデル容量 API を使用すると、サブスクリプション内のクォータとリージョン内のサービス容量の両方の可用性に基づいて、各リージョンに作成できる指定されたモデルの最大サイズのデプロイをプログラムで識別することもできます。
必要なモデル、バージョン、PTU をサポートするために受け入れ可能なリージョンが使用できない場合は、次の手順を試すこともできます。
- PTU の数を減らしてデプロイを試みます。
- 別の時刻にデプロイを試みます。 容量の可用性は、お客様の需要に基づいて動的に変化し、もっと多くの容量が後で使用可能になる可能性があります。
- 受け入れ可能なすべてのリージョンでクォータが使用可能であることを確認します。 モデル容量 API と Studio エクスペリエンスでは、デプロイを作成するための代替リージョンを返す際にクォータの可用性を考慮します。
ワークロードに必要な 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% 未満に維持するために、リーキー バケット アルゴリズムの一種が使用されています。 大まかなロジックは以下のとおりです。
それぞれのお客様は、デプロイで利用できる一定量の容量を持っています。
要求が行われたとき:
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 のようなサンプリング トークン数よりもシステムによる生成数が少ない場合、より多くの要求が受け入れられます。