Azure OpenAI を Microsoft Foundry Models クォータ (クラシック) で管理する

現在表示中:Foundry (クラシック) ポータルのバージョン - 新しい Foundry ポータルのバージョンに切り替える

メモ

この記事のリンクは、現在表示している Foundry (クラシック) ドキュメントではなく、新しい Microsoft Foundry ドキュメントのコンテンツを開く場合があります。

クォータを使用すると、サブスクリプション内のデプロイ全体でレート制限の割り当てを積極的に管理する柔軟性が提供されます。 この記事では、Azure OpenAI クォータを管理するプロセスについて説明します。

前提 条件

重要

使用可能なクォータを表示する必要があるタスクの場合は、 Cognitive Services の使用状況閲覧者ロールを 使用することをお勧めします。 このロールは、Azure サブスクリプション全体のクォータ使用量を表示するために必要な最小限のアクセスを提供します。 このロールと、OpenAI Azureアクセスするために必要なその他のロールの詳細については、Azure ロールベースのアクセス制御ガイド を参照してください。

このロールは、Azure portal の [Subscriptions>][アクセス制御 (IAM)>][ロールの割り当てを追加する>] 検索で「Cognitive Services Usages 閲覧者」を検索をすることで見つかります。 このロール はサブスクリプション レベルで適用する必要があります。リソース レベルには存在しません。

このロールを使用しない場合、サブスクリプション 閲覧者 ロールは同等のアクセス権を提供しますが、クォータとモデルのデプロイを表示するために必要な範囲を超える読み取りアクセス権も付与されます。

クォータの概要

Azure OpenAI のクォータ機能は、quota と呼ばれるグローバル制限まで、デプロイにレート制限を割り当てることができます。 クォータは、リージョンごと、モデルごと、デプロイの種類ごとに、1 分あたりのトークン (TPM) 単位でサブスクリプションに割り当てられます。 Azure OpenAI にサブスクリプションをオンボードすると、最も利用可能なモデルの既定のクォータが受け取られます。 次に、作成された各デプロイにTPMを割り当て、そのモデルの使用可能なクォータがその分だけ減少します。 引き続きデプロイを作成し、クォータ制限に達するまで TPM を割り当てることができます。 その場合は、同じモデルの他のデプロイに割り当てられている TPM を減らす (使用するために TPM を解放する) か、目的のリージョンでのモデル クォータの引き上げを要求して承認することによってのみ、そのモデルの新しいデプロイを作成できます。

メモ

米国東部の GPT-4o に対して 240,000 TPM のクォータを使用すると、1 つのデプロイとして 240 K TPM、120 K TPM の 2 つの展開、または 1 つまたは複数の Azure OpenAI リソース内の任意の数の展開を作成できます(そのリージョンの合計が最大 240 K 未満である限り)。

デプロイが作成されると、割り当てられた TPM は、推論要求に適用される 1 分あたりのトークンレート制限に直接マップされます。 毎分リクエスト (RPM) レート制限も適用され、その値は以下の比率で TPM 割り当てに比例して設定されます。

重要

クォータに対する 1 分あたりの要求数 (RPM) とトークン/分 (TPM) の比率は、モデルによって異なる場合があります。 プログラムを使用してモデルをデプロイしたり 、クォータの引き上げを要求 したりする場合、TPM と RPM を独立した値としてきめ細かく制御することはできません。 クォータは、RPM と TPM の対応する量を持つ容量の単位で割り当てられます。

モデル 容量 1 分あたりの要求数 (RPM) 1 分あたりのトークン数 (TPM)
以前のチャット モデル 1 ユニット 6 回転毎分 (RPM) 1,000 TPM
o1 & o1-preview 1 ユニット 1 RPM 6,000 TPM
o3 1 ユニット 1 回転数毎分 (RPM) 1,000 TPM
o4-mini 1 ユニット 1 RPM 1,000 TPM
o3-mini 1 ユニット 1 RPM 10,000 TPM
o1-mini 1 ユニット 1 RPM 10,000 TPM
o3-pro 1 ユニット 1 RPM 10,000 TPM

これは、RPM/TPM 比の変更によってクォータが誤って割り当てされる可能性があり、プログラムによるモデルのデプロイでは特に重要です。

サブスクリプションとリージョン内で TPM をグローバルに分散する柔軟性により、Azure OpenAI は他の制限を緩和できます。

  • リージョンあたりの最大リソース数は 30 に増加します。
  • リソース内に同じモデルのデプロイを 1 つも作成できないという制限が削除されました。

より多くのクォータを要求する

quota の増加要求フォームを送信して、Azure、Azure OpenAI モデル、およびAnthropic モデルによって直接販売されるファンドリー モデルのクォータの引き上げを要求します。 Anthropicモデルを除き、パートナーやコミュニティのモデルはクォータの引き上げをサポートしていません。

クォータの引き上げ要求は受け取った順序で処理され、優先度は既存のクォータ割り当てを積極的に使用している顧客に適用されます。 この条件を満たしていない要求は拒否される可能性があります。

モデル固有の設定

モデル クラスとも呼ばれるさまざまなモデル デプロイには、制御できる一意の最大 TPM 値があります。 これは、特定のリージョンでその種類のモデルデプロイに割り当てることができる TPM の最大量を表します。

他のすべてのモデル クラスには、共通の最大 TPM 値があります。

メモ

クォータ トークン-Per-Minute (TPM) の割り当ては、モデルの最大入力トークン制限とは関係ありません。 モデル入力トークンの制限は モデル テーブル で定義され、TPM に加えられた変更の影響を受けません。

クォータの割り当て

モデルデプロイを作成するときは、そのデプロイに Tokens-Per-Minute (TPM) を割り当てるオプションがあります。 TPM は 1,000 単位で変更でき、上で説明したように、デプロイに適用される TPM と RPM のレート制限にマップされます。

Microsoft Foundry ポータル内から新しいデプロイを作成するには、デプロイメント>モデルをデプロイ>基本モデルをデプロイ>モデルを選択>確認を選択します。

デプロイ後は、Foundry ポータルの [デプロイ] ページからモデルを選択して編集することで、TPM の割り当てを調整できます。 この設定は、[ 管理>Model クォータ ] ページから変更することもできます。

重要

クォータと制限は変更される可能性があります。 最新情報については、クォータと制限に関する記事を参照してください。

クォータの表示と要求

特定のリージョン内のデプロイ全体のクォータ割り当てをすべて表示するには、Foundry ポータルで >Quota] を選択します。

  • デプロイメント: モデルクラスごとに分類されたモデルデプロイメント。
  • クォータの種類: モデルの種類ごとにリージョンごとに 1 つのクォータ値があります。 割り当ては、そのモデルのすべてのバージョンを対象とします。
  • クォータの割り当て: クォータ名には、デプロイで使用されているクォータの量と、このサブスクリプションとリージョンに対して承認されたクォータの合計が表示されます。 使用されたクォータの量は、棒グラフにも示されています。
  • 要求クォータ: アイコンは、クォータを増やす要求を送信できる このフォーム に移動します。

既存のデプロイの移行

新しいクォータ システムと TPM ベースの割り当てへの移行の一環として、既存のすべての Azure OpenAI モデルデプロイは、クォータを使用するように自動的に移行されています。 以前のカスタム レート制限の増加により、既存の TPM/RPM 割り当てが既定値を超えた場合、影響を受けるデプロイに同等の TPM が割り当てられます。

レート制限について

展開に TPM を割り当てると、前述の説明のように、デプロイメントの分あたりのトークン (TPM) と分あたりのリクエスト (RPM) レート制限が設定されます。 TPM レート制限は、要求の受信時に要求によって処理されると推定されるトークンの最大数に基づいています。 これは、すべての処理が完了した後に計算される、課金に使用されるトークン数と同じではありません。

各要求を受信すると、OpenAI Azureは、次を含む推定最大処理トークン数を計算します。

  • プロンプトテキストとカウント
  • 「max_tokens」パラメーターの設定
  • 「best_of」パラメーターの設定

要求がデプロイ エンドポイントに入ると、推定最大処理トークン数が、1 分ごとにリセットされるすべての要求の実行中のトークン数に追加されます。 その分の間に TPM レート制限値に達した場合、それ以降の要求はカウンターがリセットされるまで 429 応答コードを受け取ります。

重要

レート制限の計算で使用されるトークン数は、API 要求の文字数に基づく推定値です。 レート制限トークンの見積もりは、要求がモデルの入力トークン制限を下回っていることを課金/判断するために使用されるトークン計算と同じではありません。 レート制限トークンの計算のおおよその性質上、各要求の正確なトークン数の測定と比較して、予想される値より前にレート制限をトリガーできる動作が予想されます。

RPM レート制限は、時間の経過と同時に受信した要求の数に基づいています。 レート制限では、要求が 1 分間にわたって均等に分散されることを想定しています。 この平均フローが維持されていない場合、1 分間に測定された制限に達しなかった場合でも、要求は 429 応答を受け取る可能性があります。 この動作を実装するために、Azure OpenAI は、一定期間 (通常は 1 秒または 10 秒) の受信要求のレートを評価します。 その間に受信した要求の数が、設定された RPM 制限で予想される数を超えた場合、新しい要求は次の評価期間まで 429 応答コードを受け取ります。 たとえば、Azure OpenAI が 1 秒間隔で要求レートを監視している場合、各 1 秒間に 10 を超える要求が受信された場合 (1 秒あたり 600 要求 = 1 秒あたり 10 要求) に対してレート制限が発生します。

メモ

プロビジョニング済みスループット ユニット (PTU) を使用している場合、システムはレート制限を異なる方法で計算します。 詳細については、「Foundry モデルのプロビジョニングスループットとは」の「使用率ベースの要求評価」セクションを参照してください。

レート制限応答ヘッダー

Azure OpenAI には、すべての API 呼び出しの HTTP 応答ヘッダーにレート制限情報が含まれています。 これらのヘッダーを使用して、プログラムによって使用状況を監視し、429 エラーを事前に回避します。

ヘッダー 値の例 説明
x-ratelimit-limit-requests 60 このデプロイで 1 分あたりに許可される要求の最大数。
x-ratelimit-limit-tokens 150000 このデプロイで 1 分あたりに許可されるトークンの最大数。
x-ratelimit-remaining-requests 59 レート制限に達する前の残りの要求。
x-ratelimit-remaining-tokens 149984 レート制限に達する前の残りのトークン。
x-ratelimit-reset-requests 10 要求ベースのレート制限がリセットされるまでの時間。
x-ratelimit-reset-tokens 300 トークンベースのレート制限がリセットされるまでの時間。
retry-after-ms 2000 429 件の応答に含まれます。 再試行する前の推奨待機時間 (ミリ秒)。

ヒント

アプリケーション内の x-ratelimit-remaining-requests と x-ratelimit-remaining-tokens を監視して、制限に近づいていることを検出し、429 を受信する前に事前にリクエストを制限します。

レート制限のベスト プラクティス

レート制限に関連する問題を最小限に抑えるには、次の手法を使用します。

要求を最適化する

  • max_tokensを、シナリオに対応する最小値に設定します。 レート制限トークンの見積もりには、実際の応答がはるかに短い場合でも、 max_tokensが含まれます。 たとえば、約 200 個のトークンの応答が予想される場合は、 max_tokens を 4,000 に設定しないでください。
  • best_of必要な場合を除き、を1に設定してください。 best_ofの増分ごとに、トークン数がレート制限に対して乗算されます。
  • 可能な場合は、プロンプト のサイズを小さくします。 プロンプトが短いほど、レート制限に向けて使用されるトークンが少なくなります。

指数バックオフを使用して再試行ロジックを実装する

429 応答を受信したら、要求を自動的に再試行します。 retry-after-ms ヘッダー値が存在する場合は使用します。それ以外の場合は、ランダム ジッターで指数バックオフを使用します。

  1. 最初の障害が発生した後、短くランダムな遅延を待機します。
  2. 再試行が失敗した場合は、遅延を 2 倍にします (指数バックオフ)。
  3. ランダム ジッターを追加して、すべてのクライアントが同時に再試行されないようにします。
  4. 無限ループを回避するために、再試行の最大数 (5 ~ 10 など) を設定します。

重要

失敗した要求は、1 分あたりのレート制限に引き続きカウントされます。 バックオフなしで要求を継続的に再送信すると、調整が悪化します。

オプション 1: SDK の組み込み再試行を使用する (最も簡単 - 推奨)

Azure OpenAI Python SDK (openai v1.0 以降) には、429 エラーおよび一時的なエラーに対する指数バックオフを使用した組み込みの自動再試行機能があります。 既定値は 2 回の再試行です。 次の値を増やすことができます。

from openai import AzureOpenAI

# Set max_retries globally on the client (default is 2)
client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=5  # up to 5 retries with automatic exponential backoff
)

# All calls through this client automatically retry on 429
response = client.chat.completions.create(
    model="gpt-4o",  # deployment name
    messages=[{"role": "user", "content": "Hello"}]
)

# Or override per-request:
response = client.with_options(max_retries=8).chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

メモ

SDK では、 retry-after ヘッダーが自動的に考慮され、ジッターを伴う指数バックオフが使用されます。 ほとんどのアプリケーションでは、クライアントで max_retries を構成するだけで十分です。サードパーティの再試行ライブラリは必要ありません。

オプション 2: tenacity ライブラリを使用したカスタム再試行 (詳細)

これは、再試行の動作をより詳細に制御する必要がある場合に使用します (カスタム ログ記録、選択的例外処理、サーキット ブレーカーなど)。

import openai
from openai import AzureOpenAI
from tenacity import (
    retry,
    retry_if_exception_type,
    stop_after_attempt,
    wait_random_exponential,
)

client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=0  # disable SDK built-in retry to avoid double-retrying
)

@retry(
    wait=wait_random_exponential(min=1, max=60),
    stop=stop_after_attempt(6),
    retry=retry_if_exception_type(openai.RateLimitError),  # only retry on 429
    reraise=True
)
def chat_completion_with_backoff(**kwargs):
    return client.chat.completions.create(**kwargs)

response = chat_completion_with_backoff(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

重要

カスタム再試行ライブラリを使用する場合は、SDK クライアントで max_retries=0 を設定して、組み込みの再試行を無効にします。 そうしないと、テナリティからの各試行自体が最大 2 回の追加の SDK 再試行をトリガーし、予想よりもはるかに多くの要求が発生する可能性があります。

オプション 3: 手動実装 (サード パーティ製ライブラリなし)

import time
import random
import openai
from openai import AzureOpenAI

client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=0  # disable SDK built-in retry
)

def retry_with_exponential_backoff(
    func,
    initial_delay: float = 1,
    exponential_base: float = 2,
    jitter: bool = True,
    max_retries: int = 10,
    errors: tuple = (openai.RateLimitError,),
):
    """Retry a function with exponential backoff."""
    def wrapper(*args, **kwargs):
        num_retries = 0
        delay = initial_delay
        while True:
            try:
                return func(*args, **kwargs)
            except errors as e:
                num_retries += 1
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    ) from e
                delay *= exponential_base * (1 + jitter * random.random())
                time.sleep(delay)
            except Exception as e:
                raise e
    return wrapper

@retry_with_exponential_backoff
def chat_completion_with_backoff(**kwargs):
    return client.chat.completions.create(**kwargs)

Polly (v7) を使用した C# の例:

using Azure;
using Azure.AI.OpenAI;
using Polly;

var retryPolicy = Policy
    .Handle<RequestFailedException>(ex => ex.Status == 429)
    .WaitAndRetryAsync(
        retryCount: 6,
        sleepDurationProvider: (retryAttempt, exception, context) =>
        {
            // Use retry-after-ms header if available
            if (exception is RequestFailedException rfEx)
            {
                var raw = rfEx.GetRawResponse();
                if (raw != null && raw.Headers.TryGetValue("retry-after-ms", out string value)
                    && int.TryParse(value, out int ms))
                {
                    return TimeSpan.FromMilliseconds(ms);
                }
            }
            // Otherwise, exponential backoff with jitter
            return TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))
                + TimeSpan.FromMilliseconds(Random.Shared.Next(0, 1000));
        },
        onRetry: (exception, timespan, retryCount, context) =>
        {
            Console.WriteLine($"Retry {retryCount} after {timespan.TotalSeconds:F1}s due to: {exception.Message}");
        }
    );

// Usage
var endpoint = new Uri("https://<your-resource>.openai.azure.com/");
var credential = new AzureKeyCredential("<your-api-key>");
var client = new AzureOpenAIClient(endpoint, credential);

await retryPolicy.ExecuteAsync(async () =>
{
    var response = await client.GetChatClient("gpt-4o")
        .CompleteChatAsync([new UserChatMessage("Hello")]);
    Console.WriteLine(response.Value.Content[0].Text);
});

メモ

.NETのAzure SDKには、再試行のサポートも組み込まれています。 AzureOpenAIClientOptionsを構築するときは、Polly を使用する代わりに、options.Retry.MaxRetriesとoptions.Retry.Mode = RetryMode.Exponentialを構成できます。 より高度なパターン (サーキット ブレーカー、バルクヘッドなど) が必要な場合は、Polly を使用します。

デプロイ レベルの使用状況を監視および管理する

  • サブスクリプション レベルのクォータだけでなく、デプロイごとの TPM 割り当てを確認します。 サブスクリプション レベルでクォータを承認したものの、そのクォータがトラフィックを受信している特定のデプロイメントに割り当てられていないため、429 エラーが発生する場合があります。
  • 監視された使用状況に基づいて、デプロイ間でクォータを再調整します。 Azure Monitorメトリックを使用して、24 時間と 7 日間の使用状況の傾向を確認し、バースト パターンを検出します。
  • Foundry ポータルでクォータ管理を使用して、トラフィックの多いデプロイで TPM を増やし、使用率の低いデプロイでは TPM を減らします。

トラフィックを均等に分散する

  • ワークロードの急激な急増を避けます。 RPM レート制限では、要求が 1 分間に均等に分散されることを想定しています。 要求の合計が 1 分あたりの制限を下回っている場合でも、1 秒または 10 秒以内のバーストによって 429 がトリガーされる可能性があります。
  • 新しいワークロードのオンボード時や負荷の増加時に、トラフィックを徐々に増やします。
  • ワークロードで 1 つのデプロイサポートよりも高いスループットが必要な場合は、複数のデプロイまたはリージョンに要求を分散します。

可能な限り非同期/バッチ処理を使用する

ユース ケースですぐに応答する必要がない場合は、非同期パターンの使用を検討してください。

  • 要求をキューに入れ、制御されたレートで処理します。
  • 複数のデプロイを使用して、単一のデプロイのレート制限を超えずに処理を並列化します。

429 スロットリングエラーと対処方法

429 エラー ("要求が多すぎます") は、レート制限を超えたか、現時点でシステムが要求を処理できないために、システムが要求を拒否したことを意味します。 すべての 429 エラーに同じ根本原因があるわけではありません。正しいアクションは、429 が発生した理由によって異なります。

429 エラーの種類

シナリオ エラー メッセージ インジケーター 根本原因 推奨されるアクション
レート制限を超えました "要求先 … 制限されている」または「レート制限を超えています」 要求が、デプロイの割り当てられたクォータの TPM または RPM レート制限を超えました。 デプロイの TPM 割り当てを増やすか、デプロイ間でクォータを再調整するか、 クォータの引き上げを要求します。
システム容量の調整 "サービスが一時的に要求を処理できない" または "システムで需要が高い" バックエンドの容量は制約されます。 多くの場合、この状態は一時的なものです。 retry-after-ms遅延後に再試行してください。 永続的な場合は、容量が保証 されるようにプロビジョニング スループット (PTU) にアップグレードすることを検討してください。
一時的なレート制限の調整 429 件の応答が発生しますが、構成済みのクォータは変更されていません。応答ヘッダーの x-ratelimit-limit-tokens が、デプロイの構成済み TPM よりも低い Standard (従量課金制) デプロイは、リソース プールを共有します。 需要が容量制限に近づくと、システムはデプロイの有効なレート制限を一時的に減らして、すべての顧客の信頼性を維持します。 この削減は保護と一時的です。 retry-after-ms バックオフで再試行してください。 通常、調整は数時間以内に解決されます。 一貫性のあるスループットを必要とするワークロードの場合は、 プロビジョニングスループット (PTU) を検討してください。
要求パラメーターによってトークンの予算が超過しました レート制限がトリガーされるが、トークンの使用状況メトリックが低く表示される レート制限の計算には、課金されたトークンだけでなく、 max_tokens とプロンプトの見積もりが含まれます。 max_tokens値が高い要求では、実際の応答が小さい場合でもレート制限の予算が消費される可能性があります。 予想される応答サイズに合わせて max_tokens を減らします。

重要

多くのお客様は、容量関連の 429 をクォータの問題と誤って解釈し、正しくない修復を行います (たとえば、問題が一時的な容量の負荷である場合にクォータの増加を要求するなど)。 アクションを実行する前に、必ずエラー メッセージと応答ヘッダーを確認して根本原因を特定してください。

トークン使用状況メトリックがクォータを下回っていても 429 が表示される理由

Azure OpenAI rate limiting と usage metrics は同じではありません。

  • Azure Monitorのトークン使用状況メトリックは、正常に処理された要求からの請求されたトークンを示します。
  • レート制限 は、後で拒否された要求や課金されない要求など、 受信時の API 要求に適用されます。

この違いにより、トークンの使用状況メトリックがクォータを十分に下回っている場合でも、429 件の応答を受け取ることができます。 一般的な理由は次のとおりです。

  • max_tokens 過大評価: レート制限は、生成された実際のトークンではなく、 推定最大 トークン数 (プロンプト + max_tokens) を使用して計算されます。
  • 拒否された要求: 入力長の制限 (HTTP 400) によって拒否された要求は、レート制限にカウントされる可能性がありますが、課金されるトークン メトリックには表示されません。
  • バースト パターン: RPM 強制は、要求を小さな時間枠 (1 ~ 10 秒) で評価します。 短いウィンドウで要求が急増すると、1 分あたりの合計が制限内にある場合でも、調整がトリガーされます。
  • サービスの信頼性に関する一時的なレート制限調整: Standard (従量課金制) デプロイは、顧客間で共通のリソース プールを共有します。 サービスの信頼性と公平性を維持するために、システムはこの共有プール全体の需要を継続的に監視します。 デプロイからの需要が容量制限に近づいたり、容量制限を超えたりすると、システムはそのデプロイ の有効なレート制限を一時的に減らす 可能性があります。 この調整期間中、通常の条件下で受け入れられた要求は、構成されたクォータが変更されなかった場合でも、429 応答を返します。 この保護対策により、リソース プールを共有しているすべてのお客様のサービスの低下を防ぐことができます。 調整は 一時的 なもので、通常はトラフィックが安定すると数時間以内に解決されます。 この状態を監視するには、有効なレート制限 ( x-ratelimit-limit-tokens 応答ヘッダーに表示されます) が、構成されている TPM 割り当てよりも低いかどうかを確認します。
  • 分散適用: 分散インフラストラクチャ全体でのレート制限の適用は、完全に正確ではないか、集計されたメトリックにすぐに反映されない場合があります。

ヒント

一時的なレート制限調整期間中に 429 件の応答が表示される場合:

  1. バックオフを使用して再試行 する - retry-after-ms ヘッダーを優先します。 調整は一時的であり、需要が安定すると解決します。
  2. トラフィックを分散 する — 可能であれば、複数のデプロイまたはリージョンに要求を分散します。
  3. トラフィック パターンを確認します 。持続する大量のバーストが最も一般的なトリガーです。 ワークロードを徐々に増やすと、調整の可能性が低くなります。
  4. プロビジョニング済みスループット (PTU) を検討 します。共有プールの変動なしに一貫性のあるスループットを必要とする運用ワークロードの場合、 プロビジョニングスループット はレート制限が保証された専用容量を提供します。

依存する対象:

  • トークン使用量メトリックを使用して、課金される使用量を把握します。
  • HTTP 応答コード (429) と応答ヘッダー (x-ratelimit-remaining-*、x-ratelimit-limit-*) を使用して、レート制限の適用をリアルタイムで検出して応答します。
  • 応答ヘッダーの x-ratelimit-limit-tokens を構成済みの TPM と比較して、一時的な調整がアクティブかどうかを検出します。

再試行するタイミングとエスカレートするタイミング

状況 アクション
retry-after-ms バックオフによって解決される不定期な 429 エラー 再試行 — この動作は通常の動作であり、共有 (Standard) デプロイで想定されます。
開発またはテスト中の 429s 多くの場合、許容されます — 非運用環境の 429 は、意図的なコスト ガードレールである可能性があります。
承認されたクォータを下回る、継続的な 429 の運用環境 エスカレート — エンジニアリング調査の サポート リクエスト を開きます。
レート制限の引き上げが有効な制限に反映されない エスカレート — 最初にデプロイ レベルでクォータの割り当てを確認し、問題が解決しない場合はエスカレートします。
待機時間の影響を受けやすい、またはミッション クリティカルな運用ワークロードで 429 が頻繁に発生する アップグレード — 保証された容量と待機時間の SLA については 、プロビジョニングスループット (PTU) を検討してください。

メモ

Standard (従量課金制) デプロイでは、共有リソース プールが使用されます。 スロットリングによって、すべてのユーザーに対する全体的なサービス信頼性が保護されます。 一時的な 429 は、サービスの欠陥ではなく、予期される動作です。 予測可能な待機時間と保証スループットを必要とするワークロードの場合、推奨されるデプロイの種類はプロビジョニング スループット (PTU) です。

デプロイの自動化

このセクションには、クォータを使用して TPM レート制限を設定するデプロイのプログラム作成を開始するための簡単なサンプル テンプレートが含まれています。 クォータの導入により、リソース管理関連のアクティビティに API バージョンの 2023-05-01 を使用する必要があります。 この API バージョンはリソースを管理するためのものであり、入力候補、チャットの完了、埋め込み、イメージの生成などの呼び出しの推論に使用される API バージョンには影響しません。

デプロイ

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/deployments/{deploymentName}?api-version=2023-05-01

パス パラメーター

パラメーター タイプ 必須。 説明
accountName 文字列 必須 Azure OpenAI リソースの名前。
deploymentName 文字列 必須 既存のモデルをデプロイしたときに選択したデプロイ名、または新しいモデルのデプロイに使用する名前。
resourceGroupName 文字列 必須 このモデル デプロイに関連付けられているリソース グループの名前。
subscriptionId 文字列 必須 関連付けられているサブスクリプションのサブスクリプション ID。
api-version 文字列 必須 この操作に使用する API バージョン。 これは、YYYY-MM-DD 形式に従います。

サポートされているバージョン

リクエストボディ

これは、使用可能な要求本文パラメーターのサブセットにすぎません。 パラメーターの完全な一覧については、 REST API リファレンス ドキュメントを参照してください。

パラメーター タイプ 説明
sku SKU SKU を表すリソース モデル定義。
キャパシティ 整数 これは、このデプロイに割り当てるクォータの量を表します。 値 1 は、1 分あたり 1,000 トークン (TPM) です。 10 の値は、1 分あたり 10,000 トークン (TPM) です。

要求の例

curl -X PUT https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resource-group-temp/providers/Microsoft.CognitiveServices/accounts/docs-openai-test-001/deployments/gpt-4o-test-deployment?api-version=2023-05-01 \
  -H "Content-Type: application/json" \
  -H 'Authorization: Bearer YOUR_AUTH_TOKEN' \
  -d '{"sku":{"name":"Standard","capacity":10},"properties": {"model": {"format": "OpenAI","name": "gpt-4o","version": "2024-11-20"}}}'

メモ

承認トークンを生成する方法は複数あります。 初期テストの最も簡単な方法は、Azure ポータルからCloud Shellを起動することです。 次に、 az account get-access-tokenを実行します。 このトークンは、API テスト用の一時的な承認トークンとして使用できます。

詳細については、使用方法とデプロイに関する REST API リファレンス ドキュメント を 参照 してください。

使用法

特定のサブスクリプションについて、特定のリージョンのクォータ使用量を照会するには

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/locations/{location}/usages?api-version=2023-05-01

パス パラメーター

パラメーター タイプ 必須。 説明
subscriptionId 文字列 必須 関連付けられているサブスクリプションのサブスクリプション ID。
location 文字列 必須 使用状況を表示する場所例: eastus
api-version 文字列 必須 この操作に使用する API バージョン。 これは、YYYY-MM-DD 形式に従います。

サポートされているバージョン

要求の例

curl -X GET https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.CognitiveServices/locations/eastus/usages?api-version=2023-05-01 \
  -H "Content-Type: application/json" \
  -H 'Authorization: Bearer YOUR_AUTH_TOKEN'

リソースの削除

Azure ポータルから Azure OpenAI リソースを削除しようとすると、関連付けられているデプロイが削除されるまで、すべてのデプロイがまだ削除されない場合はブロックされます。 最初にデプロイを削除すると、クォータの割り当てを適切に解放して、新しいデプロイで使用できるようになります。

ただし、REST API またはその他のプログラムによる方法を使用してリソースを削除すると、まずデプロイを削除する必要が回避されます。 この場合、関連付けられているクォータの割り当ては、リソースが消去されるまで 48 時間、新しいデプロイに割り当てられないままになります。 削除されたリソースの即時消去をトリガーしてクォータを解放するには、 削除されたリソースの消去の手順に従います。

次の手順

  • Last updated on