【PTU徹底解説】Azure OpenAIを高パフォーマンス&安定稼働で使う方法知ってる?【割引有り】
本記事では、Azure OpenAIを利用する上で理解しておくべき概念である PTU (Provisioned Throughput Units) について、完全に理解する為の記事です。
PTU とは何か、どのように活用できるのか、利用するとどのようなメリットがあるのか詳細に解説します。
また、Azure OpenAI の PTUは、購入モデルと Azure 標準との調整や、モデルに依存しないクォータへの移行を含めて、2024 年 8 月 12 日に大規模な更新がありました。
本記事はこの更新によって何が変わるのかも記載したいと思います。
PTUとは何か?
定義と役割
PTU(Provisioned Throughput Units) とは、Azure OpenAIサービスで使用される単位で、指定されたスループット(一定時間内に処理できるリクエストの量)を予約する仕組みのことです。
Azure VMで言うところのリザーブドインスタンスみたいな感じですね。
PTUを利用することで、スケーラブルなAIサービスを提供し、リクエストの高負荷時にも安定したパフォーマンスを維持することができます。
PTUで処理能力を事前に予約することで、応答速度の向上と安定稼働を実現することが出来ます。
主なメリットとして以下のような点があります。
メリット | 解説 |
---|---|
予測可能なパフォーマンス | Azure OpenAIを処理するリソースの占有的な利用が可能なので、安定した最大待ち時間とスループットを出すことが出来る |
予約済み処理機能 | 処理能力を事前に予約することが出来るので、応答速度の向上と安定稼働を実現することが出来る |
コスト削減 | 高速なレスポンスや高い可用性が求められる用途に適しているPTUは、高スループットワークロードを実現出来、トークンベースの使用と比較したときのコスト削減につながる場合がある |
要するに、PTUを使うことで、AOAIのアプリケーションを安定稼働させることが出来、コストも削減出来るかもしれないということですね。
背景と必要性
通常、Azureのようなクラウドサービスでは、リクエストの量に応じて自動的にリソースがスケールされます。
しかし急にリクエストが増えると対応が遅れたり、パフォーマンスが低下することがあります。
そこでPTUを使うと、事前に1秒あたりの処理リクエスト数(スループット)を予約しておくことができるので、リクエストが集中しても安定したパフォーマンスを保てます。
なので、AIサービスの提供者は安定稼働を確保するために、PTUを活用することが重要です。
Azure OpenAI のデプロイタイプについて
Azure OpenAIのデプロイタイプは現在のところ4種類あります。
- Global Batch
- Global Standard
- Standard
- PTU
それぞれの特徴は以下の表を参照です。
サービス | Global Batch | Global Standard | Standard | PTU |
---|---|---|---|---|
最適な用途 | オフライン スコアリング 遅延に敏感ではなく数時間で完了できるワークロード。 データ処理の場所に関する要件がないユース ケース向け。 |
お客様に推奨される出発点。 Global-Standard では、Standard よりも高い既定クォータとより多くのモデルを利用できます。 データ処理の場所に関する要件がない運用アプリケーション向け。 |
データ所在地の要件があるお客様向け。 中程度以下のボリューム用に最適化。 |
大きくて一貫したボリューム用のリアルタイム スコアリング。 最高のコミットメントと制限が含まれます。 |
動作のしくみ | ファイルを介したオフライン処理 | 世界中のどこにでもトラフィックをルーティングできます | - | - |
作業の開始 | Global-Batch | モデル デプロイ | モデル デプロイ | プロビジョニング済みのオンボード |
原価 | 最も安価なオプション Global Standard の価格と比べて 50% 低いコスト。 クォータ割り当てが大きい新しいモデルすべてにアクセス可能。 |
グローバル デプロイの価格 | リージョンの価格 | 一貫した使用ではコストを節約できる可能性があります |
取得内容 | Global Standard と比較した場合の大幅な割引 | 最も高い既定の呼び出し単位の支払い制限で、すべての新しいモデルに簡単にアクセスできます。 使用量が多いお客様は、待ち時間の変動が大きくなる可能性があります |
可用性に関するSLA で簡単にアクセスできます。 バースト性が高い中程度以下のボリューム用に最適化。 一貫して使用量が多いお客様は、待ち時間の変動が大きくなる可能性があります。 |
非常に高く予測可能なスループットでのリージョン アクセス。 提供されている容量計算ツールを使用して PTU あたりのスループットを決定します |
得られないもの | ❌リアルタイム呼び出しのパフォーマンス ❌データ処理の保証 保存されたデータは指定された Azure の地理的な場所に留まりますが、推論のためのデータ処理は任意の Azure OpenAI の場所で実行される可能性があります。データ所在地の詳細を確認する |
❌データ処理の保証 保存されたデータは指定された Azure の地理的な場所に留まりますが、推論のためのデータ処理は任意の Azure OpenAI の場所で実行される可能性があります。データ所在地の詳細を確認する |
❌一貫した低遅延での高いボリューム | ❌呼び出し単位の支払いの柔軟性 |
StandardとPTUは何が違うのか
StandardとPTUの違いは主に以下の3つの観点で見ることが出来ます。
- スケーラビリティ
- パフォーマンス
- コスト
それでは、どのような違いがあるか見てみましょう。
Standard | PTU | |
---|---|---|
スケーラビリティ | トークン数の上限値あり | 必要な量を事前に確保 毎月予約量を変更可能 |
パフォーマンス | 共有のコンピューティングリソースを利用 レイテンシーのばらつき・遅れの可能性あり |
専用のコンピューティングリソースを利用 レイテンシーの安定性が高い |
コスト | 毎月のトークン利用数に応じた支払い コスト予測 = 複雑 |
事前に予約したユニット数支払い コスト予測 = 簡単 |
PTUが使用出来るモデルとリージョン
PTUが利用出来るモデルとリージョンは以下の通りです。
PTUが使用出来るモデルとリージョン一覧
こちらについては、2024年8月18日時点での情報です。
最新の情報はMicrosoftの営業担当に聞いてみてください。
リージョン | gpt-4、0613 | gpt-4、1106-Preview | gpt-4、0125-Preview | gpt-4、turbo-2024-04-09 | gpt-4o、2024 年 5 月 13 日 | 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 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
上記の表より、リージョン毎にPTUが使えないモデルもあるので、契約時点ではよく確認してから契約する必要がありそうです。
PTUの利用方法
Deploy方法について
Azure OpenAI Studio でPTUを用いてデプロイを実施する場合、[デプロイの作成] から ダイアログのデプロイの種類は ProvisionedManaged です。
CLI または API を使用して Azure OpenAI でPTUデプロイを用いてデプロイする場合は、sku-name を ProvisionedManaged に設定し、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 Studio の Capacity Plannerで簡単に測定することが出来ます。
ワークロードの見積もりを簡単に取得するには、Azure OpenAI Studio の画面左側ペインより[共有リソース¥クォータ] > [AzureOpenAIプロビジョニング済み] > [容量計算ツール]を開きます。
これで、Capacity Planner が開き、必要なPTUの数を計算することができます。
PTUの計算において入力が必要なのは、以下の項目です。
- peak calls per min : モデルに対して予想される 1 分あたりの呼び出し回数
- Tokens in prompt calls : モデルへの各呼び出しのプロンプト内のトークン数
- Tokens in model response : モデルへの各呼び出しから生成されるトークンの数
では、具体的に計算してみましょう。
以下の様に設定してみます。
- peak calls per min : 100回
- Tokens in prompt calls : 300 tokens
- Tokens in model response : 300 tokens
※ちなみに300tokensは264文字ぐらいです。
それでは計算結果を見てみましょう。
これぐらいのtoken数とリクエスト回数であれば、PTUは50で大丈夫ということがわかりました。
契約時点で不要なPTUを設定することなく数値を検証出来るので、非常に便利ですね。
PTUの種類とコスト
Azure OpenAI PTUは契約した会社が占有環境を使えることに加え、時間課金、1か月間予約、1年予約の3つの予約モデルで事前購入することが可能です。
PTUの種類
PTUの種類は予約モデルと予約なしに分けることが出来ます。
- 予約モデル
- 1か月予約
- 1年予約
- 予約なし
- 時間課金
それぞれの使い方としては、時間課金で新しいモデルのテストや、PTUアセスメント時に使用して、予約モデルで本番環境にデプロイするといった使い方が最も良いでしょう。
現時点でどれぐらいの費用か(2024/08/18 時点)
PTUは個人のサブスクリプションでも購入が可能です。
Azureの検索窓より 予約 → 作成 → Azure OpenAI Service Provisioned を選択してください。
現在、個人用のサブスクリプションでは、以下の3パターンのPTUを購入することが可能です。
それぞれ見てみましょう。
(ここでの比較はpay as you goではなく、PTUのHourlyと比較した割引額となっています。ご注意ください。)
-
1ヶ月契約で前払いする場合
- 260USDで82%Offのようですね。
- 260USDで82%Offのようですね。
-
1年間契約で月毎の支払いをする場合
- 221USDで84%Offのようですね。やはり長期で契約した方がお得のようです。
- 221USDで84%Offのようですね。やはり長期で契約した方がお得のようです。
-
1年間契約で前払いをする場合
- 2,652USDで84%Offのようですね。
- 2,652USDで84%Offのようですね。
2024年8月の最新Updateで何が変わったのか
そんなPTUですが、2024年8月中旬にMicrosoftは改善を開始しました。
新たな支払いオプションやデプロイシナリオが変更されたようなので説明します。
何が変わったか①:クォータ管理が楽になりました
GPT-4のような大規模で高度なモデルは、より多くの計算リソースを必要とするため、同じトークン数やリクエスト数でも、リソースの消費が高くなることがあります。
したがって、GPT-4に対してはより厳しいクォータ制限が設定されることがありました。
- リージョンのクォータ制限
https://learn.microsoft.com/ja-jp/azure/ai-services/openai/quotas-limits#regional-quota-limits
今回のUpdateでプロビジョニング済みのクォータは、モデルに関わらず、単一のクォータ制限となりました。
サブスクリプションとリージョン内の各モデルとバージョンが独自のクォータ制限を持つのではなく、サブスクリプションとリージョンごとに単一のクォータ項目があり、サポートされている全てのモデルとバージョンにデプロイできる PTU の合計数が制限される様になり、クォータ管理がとても楽になります。
機能 | 長所 |
---|---|
モデルに依存しないクォータ | すべてのモデル/バージョンをカバーする単一のクォータ制限により、クォータ管理が軽減され、新しいモデルでの実験が高速化されます。 |
セルフサービス クォータ要求 | 営業チームの関与なく、クォータの引き上げを要求します。多くは自動承認されます。 |
既定のクォータ | 最初からある一定のクォータが準備された状態からスタート出来るので、AOAIがすばやく開始できます。 |
リアルタイムな使用可能容量に関する透過的な情報 + 新しいデプロイ フロー | 可用性に関するネゴシエーションが削減でき、市場投入までの時間が短縮されます。 |
モデルに依存しないクォータ
2024年8月12日から、既存のお客様の現在のモデル固有のクォータが、モデルに依存しないクォータに変換されました。
これは自動的に行われます。
切り替えに伴い、クォータが失われることはありません。
既存のクォータ制限が合計され、新しいモデルに依存しないクォータ項目に割り当てられます。
GPT-35-turboでもGPT-4でも、同じクォータ制限が適応出来、モデル毎に計算する必要がなくなって管理が楽になったということですね。
セルフサービス クォータ要求
お客様は販売チームに問い合わせてクォータを取得できなくなりました。 代わりに、セルフサービス クォータ要求フォームを使用し、PTU マネージド クォータの種類を指定します。 フォームには、クォータ項目の右側のリンクからアクセスできます。 目標は、2 営業日以内にすべてのクォータ要求に応答することです。(がんばれ...!!中の人...!!)
営業に問い合わせなくても、必要な分だけセルフで要求できる様になったということですね。
既定のクォータ
新規および既存のサブスクリプションには、多くのリージョンでわずかなプロビジョニング済みクォータが割り当てられます。
これによりお客様は最初にクォータを要求することなくこれらのリージョンの使用を開始できます。
いちいちクォータ要求して、承認まで待機してからAOAIを使い始めるみたいな待ち時間がなくなったということですね
※既存のお客様でリージョンに既にクォータの割り当てが含まれている場合、そのリージョンのクォータ制限は変更されません。 この場合、自動的に新しい規定の金額が増えるわけではありません。
制限としてのクォータ
8 月の更新プログラム以前、プロビジョニング済み Azure OpenAI は少数のお客様のみが利用でき、デプロイして使用する機能を最大限に活用するようクォータが割り当てられていました。
これらの変更により、すべてのユーザーに対してクォータを取得するプロセスが簡略化され、デプロイを試みた場合にサービス容量の制限が発生する可能性が高くなります。
新しい API とスタジオ エクスペリエンスを使用すると、サブスクリプションにクォータがあり、サービスが希望するモデルのデプロイをサポートする容量があるリージョンをユーザーが見つけられるようにします。
また、コミットメントを使用しているお客様は、コミットメントを作成または拡張する前にデプロイを作成することをお勧めします。 これにより、コミットメントを作成する前に容量を確保でき、コミットメントの過剰な購入の防止を保証します。 これをサポートするために、デプロイがコミットメントよりも大きく作成されることを防止していた制限が削除されました。 クォータ、使用可能な容量、コミットメントに対するこの新しいアプローチは、時間単位/予約モデルで提供されているものと一致し、コミットメント (または時間単位モデルの場合は予約) を購入する前にデプロイするガイダンスは両方で同じです
何が変わったか②:コミットメント支払モデルと新しい時間単位/予約の支払いモデルが利用可能になりました
プロビジョニング済みデプロイ用に "コミットメント" 支払モデルと "時間単位/予約" 支払いモデルを導入されたようです。
機能 | 長所 |
---|---|
時間単位のコミットされていない使用 | コミットメントする必要のない時間単位の支払いオプションを使用すると、短期間でのデプロイ シナリオが可能になります。 |
Azure Reservations を使用した期間割引 | Azure Reservations では、1 か月と 1 年間の期間の場合、時間制より大幅な割引が提供されます。また、柔軟なスコープを提供することで、現在のリソースに縛られたコミットメントに関連する管理作業を最小限に抑えます。 |
多くのリージョンにおいて、既定でプロビジョニング済みのマネージド クォータ | 最初にクォータを要求することなく、新しいリージョンですばやく作業を開始できます。 |
既にプロビジョニング済みのお客様に対する柔軟な支払いモデルの選択 | コミットメントを持つお客様は、少なくとも 2024 年末までコミットメント モデルを維持できます。また、セルフサービスまたはマネージドプロセスにより、既存のコミットメントを時間単位/予約に移行することもできます。 |
最新のモデル世代をサポート | 2024 年 8 月 1 日以降にリリースされたモデルをデプロイするには、時間単位/予約モデルが必要です。 |
要するに、現在のコミットメント支払いモデルに加え、時間単位の予約支払いモデルが導入されたとのことですね。
コミットメント支払モデル
AOAIの利用について、1カ月や1年を年額一括支払いや月毎分割払いを契約をする支払いモデルです。
- プロビジョニング済み (契約上より長期に利用可能な期間) を使用するには、リージョンの月単位のコミットメントが必要です。
- コミットメントは Azure OpenAI リソースにバインドされるため、リソース間でのデプロイの移動が困難になります。
- コミットメントは、新しい PTU を追加する場合以外は、期間中に取り消す、または変更することはできません。
- 2024 年 8 月 1 日より前にリリースされたモデルをサポートします。
時間単位の予約支払いモデル
時間単位の予約支払いモデルは、コミットメントなしでサポートされる支払いモデルです。
新しいモデルのテストや、PTUのアセスメント時に最適な支払いモデルです。
- 支払いモデルは、他の製品の Azure 標準に合わせて調整されています。
- 時間単位の使用は、コミットメントなしでサポートされます。
- 1 か月と 1 年間の期間割引は、リージョンの Azure Reservations として購入できます。
- 予約は複数のサブスクリプションに対応するようにスコープを柔軟に設定できます。また、スコープは中期的に変更できます。
まとめ
大きく理解しておくべき事項は以下4つです。
- PTUはAzure OpenAIサービスで使用されるデプロイ方法で、指定されたスループット(一定時間内に処理できるリクエストの量)を予約する形式です。(Azure VMで言うところのリザーブドインスタンスみたいな感じ)
- PTUが使用出来るモデルとリージョンは、リージョン毎にPTUが使えないモデルもあるので、契約時点ではよく確認してから契約する必要があります。
- PTUがどれだけ必要かどうかは、Azure OpenAI Studio の Capacity Plannerで簡単に測定することが可能です。
- 2024年8月の最新Updateで、クォータの管理が楽になったことやセルフでクォータ要求できる様になったこと、既定のクォータがDeploy時点から付与されていること、コミットメント単位・時間単位の予約支払いモデルがあらたに導入されたことがわかりました。
是非、Azure OpenAI を利用する際には、PTUを一度検討してみてください。
それでは👋
参考資料
プロビジョニングされたスループットとは
Azure OpenAI プロビジョニング 2024 年 8 月の更新プログラム
Azure OpenAI で API 管理による PTU/TPM を使用する - スケーリングの特別なソースを使用する
Azure OpenAI Service でプロビジョニングされたデプロイの使用を開始する
Discussion