次の方法で共有

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

  • [アーティクル]

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

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

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

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

システム レベルのスループットは、デプロイの全体的な容量、つまり 1 分あたりの要求数と、処理できるトークンの合計数です。

標準的なデプロイの場合、デプロイに割り当てられたクォータによって、達成できるスループットがある程度決まります。 ただし、クォータはデプロイの呼び出しの受付ロジックのみを左右し、これによりスループットが直接決まるわけではありません。 呼び出しごとの待機時間の変動により、クォータほど高いスループットを実現できない場合があります。 クォータの管理に関する詳細をご覧ください。

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

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

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

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

特定のワークロードに対するシステム レベルのスループットを推定する方法の 1 つは、トークンの使用状況の履歴データを使うことです。 Azure OpenAI のワークロードの場合、Azure OpenAI 内で提供されるネイティブ監視機能を使って、すべての履歴使用状況データにアクセスして視覚化できます。 Azure OpenAI ワークロードのシステム レベルのスループットを推定するために必要なメトリックは、(1) 処理されたプロンプト トークン数と (2) 生成された完了トークン数の 2 つです。

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

モデルとバージョンで分けられた、処理されたプロンプト トークン数メトリックを示す Azure Monitor グラフのスクリーンショット。

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

システム レベルのスループットを推定する 2 つ目のアプローチでは、API 要求データからトークン使用状況の情報を収集します。 この方法では、要求ごとのワークロードの様態を理解するためのより詳細なアプローチが提供されます。 要求ごとのトークン使用状況情報と、1 分あたりの要求数 (RPM) で測定される要求ボリュームを組み合わせると、システム レベルのスループットの推定が得られます。 要求と要求ボリュームに関するトークン使用状況情報の一貫性について行われた仮定が、システムのスループットの推定に影響を与えることに注意してください。 トークン使用状況の出力データは、特定の Azure OpenAI Service チャット入力候補要求に対する 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 の値を使って、デプロイ容量計算ツールのエクスペリエンスで特定のワークロードをサポートするために必要な PTU の値を推定できます。

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

プロンプト サイズ (トークン) 生成サイズ (トークン) 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 の値は呼び出し速度に応じてほぼ直線的に増減します。

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

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

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

パフォーマンスの向上

アプリケーションの呼び出しごとの待機時間を改善するために、制御できる要因がいくつかあります。

モデルの選択

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

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

Azure OpenAI エンドポイントに完了要求を送信する場合、入力テキストはトークンに変換され、デプロイされたモデルに送信されます。 モデルで入力トークンが受信されると、応答の生成が開始されます。 これは、反復的なシーケンシャル プロセスであり、一度に 1 つのトークンが処理されます。 別の考え方をすると、n tokens = n iterations を使用した for ループのようなものです。 ほとんどのモデルでは、応答の生成がプロセスの中で最も時間のかかるステップです。

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

  • 各呼び出しで可能な限り小さく max_tokens パラメーターを設定する。
  • 余分なコンテンツの生成を防ぐため、停止シーケンスを含める。
  • 生成する応答を減らす: best_of と n パラメーターは、複数の出力を生成するため、待機時間を大幅に増加させる可能性があります。 最も高速な応答を実現するには、これらの値を指定しないか、1 に設定します。

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

ストリーム

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

ストリーミングは、処理に時間がかかる大規模な呼び出しでも有効です。 多くのクライアントと中間レイヤーでは、個々の呼び出しに対しタイムアウトが設定されています。 クライアント側のタイムアウトにより、生成に時間がかかる呼び出しは取り消される可能性があります。 データをストリーミングで返すことで、徐々にデータを提供できます。

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

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

ストリーミングは、認識される待機時間に影響します。 ストリーミングを有効にしている場合、トークンが利用可能になるとすぐにチャンクで返されます。 通常この方法は、要求が完了するまでの全体的な時間は同じであっても、エンドユーザーにとってモデルの応答が速いように感じられます。

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

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

リアルタイムの応答ではなく、最終的な結果のみが重要な一括タスクを実行するユース ケースが数多くあります。 ストリーミングが無効になっている場合、モデルで応答全体が完了されるまでトークンは返されません。

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

Azure OpenAI には、コア モデルと共に動作するコンテンツ フィルタリング システムが含まれています。 このシステムは、プロンプトと入力候補の両方において、有害なコンテンツ出力の検出と防止を目的とした、分類モデルのアンサンブルを経由して実行することで機能します。

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

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

既定値の変更が必要な場合の詳細については、コンテンツ フィルタリング ポリシーに関するページを参照してください。

ワークロードの分離

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

プロンプト サイズ

プロンプト サイズは、生成サイズよりも待機時間に与える影響は少ないですが、特にサイズが大きくなると、全体的な時間に影響を与えます。

バッチ処理

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

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

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

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

Azure OpenAI Service の監視に関する詳細をご覧ください。

呼び出しごとの待機時間を測定する方法

各呼び出しにかかる時間は、モデルの読み込み、出力の生成、コンテンツ フィルターの適用にかかる時間によります。 ストリーミングを使用しているかによって、時間を測定する方法が異なります。 それぞれのケースで、推奨される測定方法が異なります。

Azure OpenAI Service の監視に関する詳細をご覧ください。

ストリーミングを使用しない場合:

  • エンドツーエンドの要求時間: API ゲートウェイによって測定された、非ストリーミング要求に対する応答全体の生成にかかった合計時間。 この数字は、プロンプトと生成サイズが増えるにつれ大きくなります。

ストリーミング:

  • 応答までの時間: ストリーミング要求に推奨される待機時間 (応答性) の測定方法。 PTU と PTU で管理されるデプロイに適用されます。 API ゲートウェイによって測定された、ユーザーがプロンプトを送信した後に最初の応答が表示されるまでの所要時間として計算されます。 この数字は、プロンプト サイズが増えたりヒット サイズが減ったりすると、大きくなります。
  • API ゲートウェイによって測定された、最初のトークンから最後のトークンまでの平均トークン生成時間を、生成されたトークンの数で割った値です。 これにより、応答の生成速度が測定され、システム負荷が増えるにつれ増加します。 ストリーミング要求に推奨される待機時間の測定方法。

まとめ

  • モデルの待機時間: モデルの待機時間が重要な場合は、GPT-4o mini モデルを試してみることをお勧めします。

  • 最大トークン数の削減: OpenAI では、生成されるトークンの合計数が同じような場合でも、max_tokens パラメータに設定された値が大きい要求の方が、待機時間が長いことがわかっています。

  • 生成される合計トークン数の削減: 生成されるトークンの数が少ないほど、全体的な応答が速くなります。 これは、n tokens = n iterations を使用する for ループのようなものであることを忘れないでください。 生成されるトークン数を減らすと、それに応じて全体的な応答時間が向上します。

  • ストリーミング: ストリーミングを有効にすると、ユーザーは最後のトークンの準備ができるまで待つ必要がなく、生成中のモデル応答を確認できるため、特定の状況でのユーザーの期待を管理するのに役立ちます。

  • コンテンツのフィルター処理を使用すると、安全性は向上しますが、待機時間にも影響します。 コンテンツ フィルタリング ポリシーの変更がワークロードに有効であるかどうかを評価します。