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

[アーティクル]
10/21/2024

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 の測定。
サイズの見積もり	スタジオおよびベンチマークスクリプトで指定された計算ツール。
プロンプトキャッシュ	サポートされているモデルについては、キャッシュされた入力トークンを最大 100% 割引します。

各モデルに対して取得される PTU あたりのスループット量

デプロイにおいて、PTU ごとに取得されるスループット (1 分あたりのトークン数または TPM) の量は、1 分間の入力および出力のトークンの相関関係になります。出力トークンを生成するには、入力トークンよりも多くの処理が必要であるため、生成される出力トークンが多いほど、全体の TPM は低くなります。サービスでは入力および出力のコストのバランスが動的に調整されるため、ユーザーが特定の入力と出力の制限を設定する必要はありません。このアプローチは、ワークロードの状態の変動に対して、デプロイに回復性があることを意味します。

サイズ設定作業を簡略化するために、gpt-4o および gpt-4o-mini モデルに対する PTU あたりの TPM を次の表で概説します

	gpt-4o, 2024-05-13 & gpt-4o, 2024-08-06	gpt-4o-mini、2024-07-18
デプロイ可能な増分	50	25
PTU あたりの入力 TPM	2,500	37,000
PTU あたりの出力 TPM	833	12,333

完全なリストについては、「AOAI Studio 計算ツール」を参照してください。

重要な概念

展開タイプ

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) は、プロンプトの処理と補完の生成のため必要なスループットを実現するようにプロビジョニングされたデプロイのサイズ指定に使用できるモデル処理容量の一般の単位です。プロビジョニングされたスループットユニットは、クォータとしてサブスクリプションに付与されます。各クォータは Azure リージョンに固有であり、そのサブスクリプションおよび Azure リージョン内のデプロイに割り当てられる PTU の最大数が定義されます。

モデルに依存しないクォータ

他の Azure OpenAI オファリングで使用される 1 分あたりのトークン数 (TPM) クォータとは異なり、PTU はモデルに依存しません。 PTU を使用して、サポートされている任意のモデル/バージョンをリージョンにデプロイできます。

プロビジョニングデプロイの場合、新しいクォータは、プロビジョニングマネージドスループットユニットという名前のクォータ項目として Azure OpenAI Studio に表示されます。グローバルプロビジョニングマネージドデプロイの場合、新しいクォータは、グローバルプロビジョニングマネージドスループットユニットという名前のクォータ項目として Azure OpenAI Studio に表示されます。 Studio の [クォータ] ペイン内で、クォータ項目を展開すると、各クォータの使用に影響するデプロイが表示されます。

PTU クォータの取得

PTU クォータは、多くのリージョンで既定で使用可能です。さらにクォータが必要な場合、顧客は [クォータの要求] リンクを使用してクォータを要求できます。このリンクは、Azure OpenAI Studio 内の [Provisioned Managed Throughput Unit] または [Global Provisioned Managed Throughput Unit] のクォータタブの右側にあります。お客様はこのフォームを使用して、特定のリージョンについて指定した PTU クォータの引き上げを依頼できます。要求が承認されると、顧客は指定したアドレスに、通常は 2 営業日以内にメールを受け取ります。

モデルごとの PTU の最小値

各ユニットに関連する最小 PTU のデプロイ、増分、処理の容量は、モデルの種類およびバージョンによって異なります。

容量の透明性

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

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

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

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

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

新しいデプロイエクスペリエンスの詳細については、Azure OpenAI プロビジョニングの使用開始ガイドに関するページを参照してください。

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

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

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

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

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

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

生成には、プロンプトより多くの容量が必要です
GPT-4o 以降のモデルでは、入出力トークンに対して PTU あたりの TPM が個別に設定されます。以前のモデルでは、呼び出しが大きくなるほど、コンピューティングは徐々に高価になります。たとえば、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 と組み合わせることにより、要求を処理するために必要な使用率がどれくらい増えるかを見積もります。少なくとも 1024 個のキャッシュされたトークンを含む要求の場合、キャッシュされたトークンはプロンプトトークン値から減算されます。顧客は、キャッシュされたトークンのサイズに応じて、プロンプトトークンに対して最大 100% の割引を受けることができます。 max_tokens パラメーターが指定されていない場合、サービスは値を推定します。この推定より実際に生成されるトークンの数が少ない場合、予想よりコンカレンシーが低下する可能性があります。コンカレンシーを最高にするには、max_tokens の値を、実際の生成サイズに可能な限り近くなるようにしてください。
要求が完了すると、呼び出しの実際のコンピューティングコストがわかります。正確な計算を実現するために、次のロジックを使用して使用率を修正します。

a. "実際" > "見積もり" が成り立つ場合は、その差がデプロイの使用率に追加されます b. "実際" < "見積もり" が成り立つ場合は、その差が減算されます。
全体的な使用率は、デプロイされた PTU の数に基づいて連続的な割合で減少します。

Note

呼び出しは、使用率が 100% に達するまで受け入れられます。 100% をわずかに超えるバーストは、短期間であれば許可される可能性がありますが、時間が経つにつれて、トラフィックの使用率は 100% に制限されます。

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

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

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

リージョン	gpt-4o、2024 年 5 月 13 日	gpt-4o、2024-08-06	gpt-4o-mini、2024-07-18	gpt-4、0613	gpt-4、1106-Preview	gpt-4、0125-Preview	gpt-4、turbo-2024-04-09	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	-	-	-	-	-	-	-	-	-	✅
uaenorth	✅	-	-	-	✅	-	-	-	✅	✅
uksouth	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
westus	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
westus3	✅	✅	-	✅	✅	✅	✅	✅	✅	✅

Note

gpt-4 バージョン: turbo-2024-04-09 のプロビジョニングされたバージョンは、現在、テキストのみに制限されています。

次の方法で共有

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

プロビジョニングとグローバルプロビジョニングというデプロイの種類が提供する内容

どうなりますか。

各モデルに対して取得される PTU あたりのスループット量