次の方法で共有

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

  • [アーティクル]

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

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

アプリケーションのサイズを設定する際に考慮すべき主な概念には、(1) システム レベルのスループットと (2) 呼び出しごとの応答時間 (待機時間とも呼ばれます) の 2 つがあります。

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

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

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

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

  1. サイズの見積もりには容量計算ツールを使用します。

  2. 実際のトラフィック ワークロードを使用して負荷のベンチマークを実行します。 Azure Monitor から使用状況と処理されたトークンのメトリックを測定します。 長時間実行します。 Azure OpenAI ベンチマーク リポジトリには、ベンチマークを実行するためのコードが含まれています。 最後に、最も正確な方法は、独自のデータとワークロードの特性を使用してテストを実行することです。

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

プロンプト サイズ (トークン) 生成サイズ (トークン) 1 分あたりの呼び出し数 必要な PTU
800 150 30 100
1000 50 300 700
5000 100 50 600

ワークロードの分散が一定のままであれば、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 ループのようなものであることを忘れないでください。 生成されるトークン数を減らすと、それに応じて全体的な応答時間が向上します。

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

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