パフォーマンスと待機時間

この記事では、Azure OpenAI で待機時間とスループットがどのように機能するか、およびパフォーマンスを向上させるために環境を最適化する方法に関する背景情報について説明します。

スループットと待機時間について

アプリケーションのサイズを設定する際に考慮する必要がある 2 つの重要な概念があります。(1) 1 分あたりのトークン単位で測定されたシステムレベルのスループット (TPM) と (2) 呼び出しごとの応答時間 (待機時間とも呼ばれます) です。

システムレベルのスループット

このメトリックは、デプロイの全体的な容量 (1 分あたりの要求数と、処理できるトークンの合計数) を示します。

標準デプロイの場合、デプロイに割り当てられたクォータによって、達成できるスループットの量が部分的に決まります。ただし、クォータはデプロイの呼び出しのアドミッションロジックのみを決定し、スループットを直接適用しません。呼び出しごとの待機時間の変動により、クォータほど高いスループットを実現できない場合があります。

プロビジョニングされたデプロイでは、一定の量のモデル処理能力をエンドポイントに割り当てます。エンドポイントで達成できるスループットの量は、入力トークンの量、出力量、呼び出しレート、キャッシュの一致率など、ワークロードの形状によって異なります。同時呼び出しの数と処理されるトークンの合計数は、これらの値によって異なる場合があります。

すべての展開の種類について、システムレベルのスループットを理解することは、パフォーマンスを最適化するための重要なコンポーネントです。これらの要因によってスループットが異なるため、特定のモデル、バージョン、ワークロードの組み合わせに対するシステムレベルのスループットを検討してください。

システムレベルのスループットの見積もり

Azure Monitor メトリックを使用した TPM の推定

特定のワークロードのシステムレベルのスループットを見積もる方法の 1 つは、トークン使用状況の履歴データを使用することです。 Azure OpenAI ワークロードでは、Azure OpenAI 内で提供されるネイティブな監視機能を使用して、すべての履歴使用データにアクセスし、視覚化できます。 Azure OpenAI ワークロードのシステムレベルのスループットを見積もるために、(1) Processed Prompt Tokens と (2) Generated Completion Tokens の 2 つのメトリックが必要です。

処理 されたプロンプトトークン (入力 TPM) メトリックと 生成された完了トークン (出力 TPM) メトリックを組み合わせると、実際のワークロードトラフィックに基づいてシステムレベルのスループットの推定ビューが提供されます。この方法では、プロンプトキャッシュの利点は考慮されないため、保守的なシステムスループットの見積もりになります。これらのメトリックは、複数週にわたる 1 分間のウィンドウで、最小、平均、最大の集計を使用して分析できます。評価するのに十分なデータポイントがあることを確認するために、このデータを複数週間の期間にわたって分析することをお勧めします。次のスクリーンショットは、Azure Monitorで視覚化された Processed Prompt Tokens メトリックの例を示しています。メトリックは、Azure ポータルから直接使用できます。

Azure Monitor グラフのスクリーンショットで、モデルとバージョンごとに分割された処理済みプロンプトトークンのメトリックを示します。

要求データからの TPM の推定

システムレベルの推定スループットに対する 2 つ目のアプローチでは、API 要求データからトークン使用状況情報を収集します。この方法では、要求ごとのワークロードの形状を理解するためのより詳細なアプローチが提供されます。要求ごとのトークン使用状況情報と、1 分あたりの要求数 (RPM) で測定された要求ボリュームを組み合わせると、システムレベルのスループットの見積もりが提供されます。要求と要求ボリューム全体でトークン使用状況情報の一貫性を確保するために行われた前提条件は、システムのスループットの見積もりに影響を与える点に注意してください。特定の Azure OpenAI 向けに Microsoft Foundry Models のチャット完了要求を行うと、その API 応答の詳細にトークン使用状況の出力データが見つかります。

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

特定のワークロードのすべての要求が一様であると仮定して、API 応答データからのプロンプトトークンと完了トークンに推定 RPM を乗算して、特定のワークロードの入力 TPM と出力 TPM を識別します。

システムレベルのスループット見積もりを使用する方法

特定のワークロードのシステムレベルのスループットを見積もった後、これらの見積もりを使用して Standard デプロイとプロビジョニング済みデプロイのサイズを設定します。 Standard デプロイの場合は、入力 TPM 値と出力 TPM 値を組み合わせて、特定のデプロイに割り当てる TPM の合計を見積もります。プロビジョニング済みデプロイの場合は、要求トークンの使用状況データまたは入力と出力の TPM 値を使用して、デプロイ容量計算ツールエクスペリエンスを使用して、特定のワークロードをサポートするために必要な PTU の数を見積もります。

GPT-4o ミニモデルの例をいくつか次に示します。

プロンプトサイズ (トークン)	生成サイズ (トークン)	1 分あたりの要求数	TPMを入力	出力 TPM	TPM の合計	PTU が必要
800	150	30	24,000	4,500	28,500	15
5,000	50	1,000	5,000,000	50,000	5,050,000	140
1,000	300	500	500,000	150,000	650,000	30

ワークロードの分散が一定のままである場合、PTU の数は呼び出し速度でほぼ直線的にスケーリングされます。

待機時間: 呼び出しごとの応答時間

このコンテキストでの待機時間の大まかな定義は、モデルから応答を取得するのにかかる時間です。完了要求とチャット完了要求の待機時間は、モデルの種類、プロンプト内のトークンの数、生成されたトークンの数によって大きく異なります。一般に、各プロンプトトークンは、生成された各増分トークンと比較して少し時間を追加します。

TTLT = TTFT + (TBT × Tokens Generated)リレーションシップを使用すると、予想されるトークンドリブン待機時間を実際の回帰から分離できます。詳細な内訳については、「Azure OpenAI 待機時間を確認してください。

これらのモデルでは、予想される呼び出しごとの待機時間の見積もりは困難な場合があります。完了要求の待ち時間は、(1) モデル、(2) プロンプト内のトークンの数、(3) 生成されたトークンの数、(4) デプロイとシステムの全体的な負荷の 4 つの主な要因によって異なります。多くの場合、要因 1 と 3 は合計時間に最も影響します。次のセクションでは、大規模な言語モデル推論呼び出しの構造について詳しく説明します。

Azure OpenAI の遅延を理解する

Azure OpenAI 要求の待機時間は、予測可能な数式に従います。この式を知ることで、実際のパフォーマンスの回帰から予想されるトークン駆動型の応答時間を把握できます。

待機時間の数式

応答を生成する合計時間は次のとおりです。

TTLT = TTFT + (TBT × トークン生成)

どこ：

TTFT (最初のトークンへの時間) は、プロンプトの送信から最初のトークンが返されるまでの時間 (ミリ秒単位) です。
TBT (トークン間の時間) は、連続して生成されたトークン間の平均時間 (ミリ秒単位) です。
生成されたトークン は、応答の出力トークンの合計数です。
TTLT (Time to Last Token) は、エンドツーエンドの合計応答時間です。

TTLT は生成されたトークンの数に応じてスケーリングされるため、TTLT の増加は、多くの場合、システムパフォーマンスの問題ではなく、出力トークンの増加によって完全に説明されます。待機時間の回帰があると判断する前に、必ずトークン数を確認してください。

主要な待機時間メトリック

応答をストリーミングするかどうかに関係なく、待機時間を調査するには、次のAzure Monitorメトリックを使用します。

表示名	REST API名	測定対象	使用するタイミング
最終バイト到達時間	`AzureOpenAITTLTInMS`	API ゲートウェイによって測定された、プロンプトの送信から最後のトークンまでの合計時間。 TTLT にマップされます。	ストリーミング以外の要求、または全体的な応答時間が必要な場合。
対応の時期	`AzureOpenAITimeToResponse`	プロンプト送信から最初の応答チャンクまでの時間。 TTFT にマップされます。	ストリーミング要求、または最初のトークンの応答性が必要な場合。
トークン間の時間	`AzureOpenAINormalizedTBTInMS`	連続して生成されたトークン間の平均ミリ秒。 TBT にマッピングします。平均トークン生成率と呼ばれることもあります。	ストリーミング要求、または生成スループットの診断。
正規化された初回バイト到達時間	`AzureOpenAINormalizedTTFTInMS`	プロンプトトークン数で割った 1 バイト目の待機時間。	異なるプロンプトサイズ間で最初のトークンの効率を比較する。絶対待機時間の診断には、このメトリックを使用しないでください。
生成された完了トークン	`GeneratedTokens`	要求あたりの出力トークン数。	常に待機時間メトリックとペアリングします。出力トークンは TTLT の主要なドライバーです。
処理プロンプトトークン	`ProcessedPromptTokens`	要求あたりの入力トークン数。	プロンプトが大きいほど、TTFT と全体的な処理時間が増加します。

メモ

待機時間の数式では TTFT を使用しますが、Azure Monitorには 2 つの TTFT 関連のメトリックが用意されています。お客様が経験する絶対待機時間を診断するには、 Time to Response (AzureOpenAITimeToResponse) を使用します。 Normalized Time to First Byte（正規化された最初のバイト） (AzureOpenAINormalizedTTFTInMS) は、サイズの異なるプロンプト間で最初のトークンの効率を比較する必要がある場合にのみ使用します。

常にレイテンシ指標とトークン数指標を組み合わせてください。 2,000 個のトークンを生成する 5 秒の TTLT は、50 個のトークンを生成する 5 秒の TTLT とは大きく異なります。トークンコンテキストのない待機時間は、操作できません。

ディメンションと集計のガイダンスを含む完全なメトリックカタログについては、Azure OpenAI 監視データリファレンスを参照してください。

待機時間を 10 分で評価する

ワークロードに一致するパスを使用して、デプロイの待機時間が予想どおりに動作しているかどうかを評価します。どちらのパスも、Key 待機時間メトリックテーブルのAzure Monitorメトリックを使用します。

ストリーミング以外のワークロード

Azure ポータルで、Azure OpenAI リソースを開き、Monitoring>Metrics を選択します。
Time to Last Byte (AzureOpenAITTLTInMS) を追加し、ModelDeploymentNameで分割してデプロイごとの動作を分離します。
生成された完了トークン (GeneratedTokens) の 2 つ目のグラフを同じ時間範囲に追加します。
2 つのグラフを比較します。
- TTLT と生成されたトークンが同時に増加した場合、待機時間の変化はトークンボリュームによって説明されます。このパターンは、回帰ではなく期待される動作です。
- TTLT がトークン数の増加なしで上昇する場合は、容量の負荷を確認します。 PTU で管理されるデプロイでは、 プロビジョニングされたマネージド使用率 V2 (AzureOpenAIProvisionedManagedUtilizationV2) をグラフ化します。従量課金制のデプロイでは、429 によるスロットリングと同時リクエスト数を確認するために、Azure OpenAI Requests (AzureOpenAIRequests) を確認します。

ストリーミングワークロード

Azure ポータルで、Azure OpenAI リソースを開き、Monitoring>Metrics を選択します。
Time to Response (AzureOpenAITimeToResponse) を追加し、最初のトークン待機時間のためにModelDeploymentNameで分割します。
トークンごとの生成スループットのために 、トークン間の時間 (AzureOpenAINormalizedTBTInMS) を追加します。
処理されたプロンプトトークンの追加 (ProcessedPromptTokens)。プロンプトが大きいほど、TTFT が増加します。
グラフを比較します。
- プロンプトサイズがフラットなままの状態で Time to Response が増加した場合は、デプロイの使用率と同時要求量を確認します。
- トークン間の時間が増加した場合、デプロイは負荷がかかっている可能性があります。

観察された値が予期しない場合は、サポートケースを開く前に、それらをレイテンシーの数式に戻して、正常性を確認してください。

パフォーマンスの向上

いくつかの要因により、アプリケーションの呼び出しごとの待機時間が向上する可能性があります。

モデルの選択

待機時間は、使用しているモデルによって異なります。同じ要求の場合は、チャット完了呼び出しの待機時間が異なるモデルが異なっていることを想定してください。ユースケースで最も短い応答時間の待機時間モデルが必要な場合は、最新の GPT-4o ミニモデルをお勧めします。

生成サイズと最大トークン数

Azure OpenAI エンドポイントに完了要求を送信すると、サービスによって入力テキストがトークンに変換され、デプロイされたモデルに送信されます。モデルは入力トークンを受け取り、応答の生成を開始します。これは反復的なシーケンシャルプロセスであり、一度に 1 つのトークンです。これを考えるもう 1 つの方法は、 n tokens = n iterationsを含む for ループのようなものです。ほとんどのモデルでは、応答の生成がプロセスの最も遅いステップです。

要求時に、要求された生成サイズ (max_tokens パラメーター) が生成サイズの初期見積もりとして使用されます。フルサイズを生成するためのコンピューティング時間は、要求が処理されるときにモデルによって予約されます。生成が完了すると、残りのクォータが解放されます。トークンの数を減らす方法:

各呼び出しで max_tokens パラメーターをできるだけ低く設定します。
追加のコンテンツが生成されないように、停止シーケンスを含めます。
生成される応答が少なくなります。 n パラメーターを使用すると、要求ごとに複数の出力が生成されるため、待機時間が長くなる可能性があります。最も高速な応答を得るために、 n を設定しないでください (または、 1に設定します)。

要約すると、要求ごとに生成されるトークンの数を減らすと、各要求の待機時間が短縮されます。

メモ

max_tokens パラメーターでは応答の長さのみが変更され、場合によっては切り捨てられる場合があります。パラメーターは応答の品質を変更しません。

ストリーミング

要求で stream: true を設定すると、トークンの完全なシーケンスが生成されるのを待つのではなく、使用可能になるとすぐにサービスからトークンが返されます。すべてのトークンを取得する時間は変更されませんが、最初の応答の時間が短縮されます。エンドユーザーは生成された応答を読み取ることができるため、この方法ではユーザーエクスペリエンスが向上します。

ストリーミングは、処理に時間がかかる大規模な呼び出しにも価値があります。多くのクライアント層と中間層では、個々の呼び出しでタイムアウトが発生します。長時間の生成リクエストは、クライアント側のタイムアウトによりキャンセルされる場合があります。データをストリーミングバックすることで、増分データを確実に受信できます。

ストリーミングを使用する場合の例:

チャットボットと会話インターフェイス。

ストリーミングは、認識される待機時間に影響します。ストリーミングを有効にすると、利用可能になったトークンをチャンク単位で順次受け取れます。エンドユーザーにとって、このアプローチは、要求を完了するまでの全体的な時間が変わらない場合でも、モデルの応答が速いように感じることがよくあります。

ストリーミングの重要度が低い場合の例:

感情分析、言語翻訳、コンテンツ生成。

リアルタイムの応答ではなく、完了した結果のみを考慮する一括タスクを実行するユースケースは多数あります。ストリーミングが無効になっている場合、モデルが応答全体を完了するまでトークンを受け取りません。

コンテンツのフィルター処理

Azure OpenAI には、コアモデルと共に動作する content フィルターシステムが含まれています。このシステムは、有害なコンテンツの出力の検出と防止を目的とした分類モデルのアンサンブルを通じて、プロンプトと完了の両方を実行します。

コンテンツフィルタリングシステムは、入力プロンプトと出力入力候補の両方で、有害な可能性があるコンテンツの特定のカテゴリを検出してアクションを実行します。

コンテンツフィルター処理の追加には、安全性の向上が伴いますが、待機時間も伴います。パフォーマンスのこのトレードオフが必要なアプリケーションは多数ありますが、パフォーマンスを向上させるためにコンテンツフィルターを無効にすることは検討する価値があるリスクの低いユースケースがいくつかあります。

既定のコンテンツフィルターポリシーに変更を要求する方法について説明します。

ワークロードの分離

同じエンドポイントで異なるワークロードを混在すると、待機時間に悪影響を及ぼす可能性があります。これは、(1) 推論中に一緒にバッチ処理され、短い呼び出しが長い完了を待つ可能性があり、(2) 呼び出しを混在させると、両方が同じ領域で競合するため、キャッシュヒット率が低下する可能性があるためです。可能であれば、ワークロードごとに個別のデプロイを行うことをお勧めします。

プロンプトサイズ

プロンプトサイズは生成サイズよりも待機時間に与える影響は小さくなりますが、サイズが大きくなる場合は特に全体的な時間に影響します。

バッチ処理

同じエンドポイントに複数の要求を送信する場合は、要求を 1 回の呼び出しにバッチ処理できます。これにより、行う必要がある要求の数が減り、シナリオによっては全体的な応答時間が向上する可能性があります。このメソッドをテストして、役に立つかどうかを確認することをお勧めします。

スループットを測定する方法

デプロイでの全体的なスループットは、次の 2 つの方法で測定することをお勧めします。

1 分あたりの呼び出し数: 1 分あたりに行っている API 推論呼び出しの数。これは、Azure OpenAI 要求メトリックを使用して Azure モニターで測定し、ModelDeploymentName で分割できます
1 分あたりの合計トークン数: デプロイによって 1 分あたりに処理されるトークンの合計数。これには、プロンプトと生成されたトークンが含まれます。これは、多くの場合、デプロイのパフォーマンスをより深く理解するために、両方を測定するためにさらに分割されます。これは、処理された推論トークンメトリックを使用して Azure-Monitor で測定できます。

監視メトリック、ディメンション、およびリソースログの完全な一覧については、「Azure OpenAI 監視データリファレンスを参照してください。

概要

モデルの待機時間: モデルの待機時間が重要な場合は、 GPT-4o ミニモデルを試してみることをお勧めします。
最大トークン数が少ない: OpenAI では、生成されたトークンの合計数が類似している場合でも、max token パラメーターに設定された値が大きい要求の待機時間が長くなることが判明しました。
生成されるトークンの合計数が少なくなります。生成されるトークンの数が少ないほど、全体的な応答が速くなります。これは、 n tokens = n iterationsを持つ for ループのようなものであることを覚えておいてください。生成されるトークンの数を減らすと、全体的な応答時間がそれに応じて向上します。
ストリーミング: ストリーミングを有効にすると、最後のトークンの準備ができるまで待つ必要なく、生成中のモデル応答をユーザーが確認できるようにすることで、特定の状況でのユーザーの期待を管理するのに役立ちます。
コンテンツフィルターは安全性を 向上させますが、待機時間にも影響します。変更されたコンテンツフィルターポリシーの恩恵を受けるワークロードがあるかどうかを評価します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-05-14