Azure OpenAI Service でプロビジョニングされたデプロイの使用を開始する
以下のガイドでは、Azure OpenAI Service リソースを使用するプロビジョニングされたデプロイを設定する手順について説明します。
前提条件
- Azure サブスクリプション - 無料アカウントを作成します
- 目的の Azure サブスクリプション内の Azure OpenAI に付与されたアクセス権。 現時点では、このサービスへのアクセスには申請が必要です。 Azure OpenAI Service へのアクセスを申請するには、https://aka.ms/oai/access のフォームに入力してください。
- プロビジョニングされたデプロイのクォータを取得し、コミットメントを購入済みであること。
Note
プロビジョニングされたスループット ユニット (PTU) は、Azure OpenAI の標準クォータとは異なり、既定では利用できません。 このオファリングの詳細については、Microsoft アカウント チームにお問い合わせください。
プロビジョニングされたデプロイを作成する
クォータのコミットメントを購入したら、デプロイを作成できます。 プロビジョニングされたデプロイを作成するには、次の手順に従います。説明されている選択肢は、スクリーンショットに示されているエントリを反映しています。
- Azure OpenAI Studio にサインインします
- プロビジョニングされたデプロイが有効になっているサブスクリプションを選択し、クォータがあるリージョンで目的のリソースを選択します。
- 左側のナビゲーションの [管理] で [デプロイ] を選択します。
- [新しいデプロイの作成] を選択し、以下のフィールドを構成します。 [詳細オプション] ドロップダウンを展開します。
- 各フィールドに値を入力します。 次に例を示します。
フィールド | Description | 例 |
---|---|---|
モデルの選択 | デプロイする特定のモデルを選択します。 | GPT-4 |
モデル バージョン | デプロイするモデルのバージョンを選択します。 | 0613 |
展開名 | デプロイ名は、クライアント ライブラリと REST API を使用してモデルを呼び出すためにコードで使用されます。 | gpt-4 |
コンテンツ フィルター | デプロイに適用するフィルター ポリシーを指定します。 詳細については、「コンテンツのフィルター処理」の方法を参照してください。 | 既定値 |
展開の種類 | これはスループットとパフォーマンスに影響します。 プロビジョニングされたデプロイに対して Provisioned-Managed を選択します | Provisioned-Managed |
プロビジョニングされたスループット ユニット | デプロイに含めるスループットの量を選択します。 | 100 |
プログラムでデプロイを作成する場合は、次の Azure CLI コマンドを使用してそれを行うことができます。 希望するプロビジョニングされたスループット ユニットの数で sku-capacity
を更新します。
az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group <myResourceGroupName> \
--deployment-name MyModel \
--model-name GPT-4 \
--model-version 0613 \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged
REST、ARM テンプレート、Bicep、Terraform を使用してデプロイを作成することもできます。 クォータの管理の攻略ガイドにあるデプロイの自動化に関するセクションを参照し、sku.name
を "Standard" ではなく "ProvisionedManaged" に置き換えます。
最初の呼び出しを行う
プロビジョニングされたデプロイの推論コードは、標準のデプロイの種類と同じです。 次のコード スニペットは、GPT-4 モデルへのチャット入力候補呼び出しを示しています。 これらのモデルをプログラムで初めて使う場合は、クイックスタート ガイドから始めることをお勧めします。 バージョン 1.0 以降の OpenAI ライブラリを使用することをお勧めします。理由は、ライブラリ内の再試行ロジックが含まれるためです。
#Note: The openai-python library support for Azure OpenAI is in preview.
import os
from openai import AzureOpenAI
client = AzureOpenAI(
azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT"),
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
api_version="2024-02-01"
)
response = client.chat.completions.create(
model="gpt-4", # model = "deployment_name".
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Does Azure OpenAI support customer managed keys?"},
{"role": "assistant", "content": "Yes, customer managed keys are supported by Azure OpenAI."},
{"role": "user", "content": "Do other Azure AI services support this too?"}
]
)
print(response.choices[0].message.content)
重要
運用環境では、Azure Key Vault などの資格情報を格納してアクセスする安全な方法を使用します。 資格情報のセキュリティについて詳しくは、Azure AI サービスのセキュリティに関する記事をご覧ください。
予想されるスループットについて
エンドポイントで達成できるスループットの量は、デプロイされた PTU の数、入力サイズ、出力サイズ、呼び出しレートをかけ合わせたものです。 同時呼び出しの数と処理されるトークンの合計数は、これらの値によって異なる場合があります。 デプロイのスループットを決定するための推奨される方法は次のとおりです。
- サイズの見積もりには容量計算ツールを使用します。 容量計算ツールは、Azure OpenAI Studio の [クォータ] ページと [プロビジョニング済み] タブにあります。
- 実際のトラフィック ワークロードを使用して負荷のベンチマークを実行します。 ベンチマークの詳細については、ベンチマークのセクションを参照してください。
デプロイ使用率を測定する
指定された数のプロビジョニングされたスループット ユニット (PTU) をデプロイすると、そのエンドポイントで、設定された量の推論スループットが使用できるようになります。 このスループットの使用率は、モデル、モデル バージョンの呼び出し速度、プロンプトのサイズ、生成サイズに基づく複雑な数式です。 この計算を簡略化するために、Azure Monitor に使用率メトリックが用意されています。 使用率が 100% を超えて上昇した場合、新しい呼び出しでデプロイから 429 が返されます。 プロビジョニングされた使用率は次のように定義されています。
PTU デプロイ使用率 = (一定期間に消費された PTU) / (その期間内にデプロイされた PTU)
使用率のメジャーは、リソースの Azure-Monitor セクションで確認できます。 監視ダッシュボードにアクセスするには、https://portal.azure.com にサインインし、Azure OpenAI リソースに移動して、左側のナビゲーションから [メトリック] ページを選択します。 メトリックのページで、"Provisioned-managed utilization" メジャーを選択します。 リソースに複数のデプロイがある場合は、[分割を適用する] ボタンをクリックして、デプロイごとに値を分割する必要もあります。
デプロイの監視の詳細については、「Azure OpenAI Service の監視」ページを参照してください。
高使用率を処理する
プロビジョニングされたデプロイでは、特定のモデルを実行するために割り当てられたコンピューティング容量が提供されます。 Azure Monitor の "Provisioned-Managed Utilization" は、デプロイの使用率を 1 分単位で測定するメトリックです。 また、プロビジョニングされたマネージド デプロイは最適化され、受け入れられた呼び出しは、呼び出しごとに一貫した最大待機時間で処理されます。 ワークロードが割り当てられた容量を超えると、使用率が 100% を下回るまで、サービスからは 429 HTTP 状態コードが返されます。 再試行までの時間は、retry-after
と retry-after-ms
の応答ヘッダーで提供され、それぞれ秒とミリ秒の単位で時間が示されます。 このアプローチを使用すると、呼び出しごとの待機時間の目標を維持しながら、高負荷の状況を処理する方法 (たとえば再試行や別のエクスペリエンスまたはエンドポイントへの転送など) を開発者が制御できます。
429 応答を受け取ったらどうすればよいですか?
429 応答は、割り当てられた PTU が呼び出し時にすべて消費されていることを示します。 この応答には、次の呼び出しが受け入れられるまで待機する時間を示す、retry-after-ms
および retry-after
ヘッダーが含まれます。 429 応答についてどのような処理方法を選ぶかは、アプリケーションの要件によって異なります。 次にいくつかの考慮事項を示します。
- 呼び出しごとの待機時間が長くても問題ない場合は、クライアント側の再試行ロジックを実装して
retry-after-ms
の時間だけ待機し、再試行します。 この方法を使用すると、デプロイでのスループットを最大化できます。 Microsoft が提供するクライアント SDK では、既に適切な既定値で処理されています。 ユース ケースに基づいて、さらにチューニングが必要になる場合があります。 - トラフィックを他のモデル、デプロイ、またはエクスペリエンスにリダイレクトすることを検討してください。 このアクションは 429 信号を受信するとすぐに実行できるため、この方法は最も低遅延の解決策です。 429 信号は、高使用率にプッシュする場合の予期しないエラー応答ではなく、プロビジョニングされたデプロイのキューと高負荷を管理するための設計の一部です。
クライアント ライブラリ内の再試行ロジックを変更する
Azure OpenAI SDK の既定では、クライアントのバックグラウンドで 429 応答を (最大再試行回数まで) 再試行します。 ライブラリは retry-after
の時間を優先します。 エクスペリエンスに合わせて再試行の動作を変更することもできます。 Python ライブラリの例を次に示します。
max_retries
オプションを使用して、再試行設定を構成するか無効にすることができます。
from openai import AzureOpenAI
# Configure the default for all requests:
client = AzureOpenAI(
azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT"),
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
api_version="2024-02-01",
max_retries=5,# default is 2
)
# Or, configure per-request:
client.with_options(max_retries=5).chat.completions.create(
model="gpt-4", # model = "deployment_name".
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Does Azure OpenAI support customer managed keys?"},
{"role": "assistant", "content": "Yes, customer managed keys are supported by Azure OpenAI."},
{"role": "user", "content": "Do other Azure AI services support this too?"}
]
)
ベンチマークを実行する
インスタンスの正確なパフォーマンスとスループットの機能は、行う要求の種類と正確なワークロードによって異なります。 ワークロードのスループットを判断する最良の方法は、独自のデータに対してベンチマークを実行することです。
この作業を支援するために、ベンチマーク ツールには、デプロイに対してベンチマークを簡単に実行する方法が用意されています。 このツールには、構成済みのワークロード シェイプがいくつか用意されており、主要なパフォーマンス メトリックが出力されます。 このツールと構成設定の詳細については、GitHub リポジトリの https://aka.ms/aoai/benchmarking を参照してください。
次のワークフローをお勧めします。
- 容量計算ツールを使用してスループットの PTU を見積もります。
- このトラフィック シェイプでベンチマークを長時間 (10 分以上) 実行すると、安定した状態の結果が観察されます。
- ベンチマーク ツールと Azure Monitor からの使用率、処理されたトークン数、呼び出しレートの値を確認します。
- クライアント実装を使用して、独自のトラフィック シェイプとワークロードでベンチマークを実行します。 必ず Azure Openai クライアント ライブラリまたはカスタム ロジックを使用して再試行ロジックを実装します。
次のステップ
- クラウド アプリケーションのベスト プラクティスの詳細については、「クラウド アプリケーションのベスト プラクティス」を参照してください
- プロビジョニングされたデプロイの詳細については、「プロビジョニングされたスループットとは」を確認してください
- 各 SDK 内の再試行ロジックの詳細については、以下を参照してください。