推論スループットとは？

これはシステムの処理能力を示す指標です。1件のリクエストがどれだけ速く開始または完了するかは示しません。

推論スループットの仕組み

基本的な計算式は次のとおりです。

スループット = 完了した処理量 ÷ 経過時間

ここで「処理量」が重要になります。画像分類器では、処理した画像数を意味する場合があります。言語モデルでは、完了したリクエスト数や処理したトークン数を意味する場合があります。「1秒あたり2,000」という結果は、何を数えたのかが分からなければ意味を持ちません。

トークンスループットには、別のラベルが必要です。入力トークンスループットはプロンプトの処理量を測定します。出力トークンスループットは生成されたトークンを測定します。合計トークンスループットはその両方を組み合わせたものです。これらは異なる処理を表すため、同じ指標であるかのように比較してはいけません。

測定範囲も重要です。結果が1台のアクセラレータ、1台のサーバー、または多数のレプリカで構成されるデプロイメント全体を対象としている場合があります。デプロイメント全体の結果をアクセラレータ数で割ると、アクセラレータあたりの処理能力を比較するのに役立ちます。ただし、モデルとワークロードがそれ以外の点で同等である場合に限ります。

通常、同時に実行するリクエスト数を増やすとスループットは向上します。サービングシステムは処理をまとめてバッチ化できるため、各処理ステップでハードウェアをより多く活用できます。言語モデルでは、連続バッチ処理により、最も長いシーケンスが終了するまでバッチ全体を待機させるのではなく、完了したシーケンスを待機中のシーケンスに置き換えられます。

ただし、この改善には限界があります。計算資源、メモリ、その他の共有リソースが飽和すると、追加のリクエストはキューで待機します。到着率は上昇し続けても、完了率はそれに伴って上昇しなくなります。その結果、実効スループットがほとんど変わらなくても遅延は悪化します。

このため、実用的な処理能力の結果は、多くの場合遅延目標下で持続可能なスループットです。ベンチマークでは負荷を増やし、完了した処理量を測定するとともに、応答時間の制限が維持されているかを確認します。最後に合格した負荷の値は、制約のないピーク値よりも、オンラインサービスの計画に役立ちます。

計算例

あるベンチマークで、同じプロンプト構成を1台のモデルサーバーに60秒間送信するとします。そのサーバーは1,200件のリクエストを完了し、180,000個の出力トークンを生成しました。

• リクエストスループット：1,200 ÷ 60 = 1秒あたり20件のリクエスト
• 出力トークンスループット：180,000 ÷ 60 = 1秒あたり3,000個の出力トークン

これらは同じ実行についての2つの見方です。リクエスト率は、サーバーが完了できるインタラクション数の推定に役立ちます。トークン率は、リクエスト数だけでは分からない応答長の違いを捉えます。

次に、到着負荷を1秒あたり30件のリクエストまで引き上げます。サーバーが完了できるのは1秒あたり22件ですが、さらに1秒あたり8件のリクエストがキューに入り、遅延目標を満たせなくなります。到着負荷は1秒あたり30件のリクエストです。観測された完了スループットは1秒あたり22件のリクエストです。どちらも、そのサービスが1秒あたり30件のリクエストを持続的に処理できることの証明にはなりません。

1秒あたり20件のリクエストが、キューを安定させ、遅延目標を満たせたテスト済み負荷の最高値だった場合、そのワークロードと目標に対して、20件という値が妥当な処理能力の指標になります。

推論スループットが重要な理由

スループットは、予想される需要に対してどれだけのハードウェアが必要かを運用担当者に示します。また、1ドルあたりの完了リクエスト数や、アクセラレータ時間あたりの出力トークン数といったコスト指標にも役立ちます。

オフラインジョブでは、スループットが高いほど全体の処理時間を短縮できます。オンラインサービスでは、システムが完了できる速度を超えてリクエストが蓄積するのを防ぐために、十分なスループットが必要です。

目標は製品によって異なります。バッチパイプラインでは、総処理量を最大化するために長い待ち時間を許容できます。インタラクティブアプリケーションでは、個々のリクエストへの応答性を維持しながら、十分なスループットが必要です。より厳格な指標であるグッドプットは、サービスの遅延目標も満たす処理だけを数えます。

よくある誤解

スループットが高いほど、すべての応答が速い

必ずしもそうではありません。より多くのリクエストをバッチ化すると、サーバー全体の出力は増加しても、各リクエストの待ち時間が長くなったり、トークンの受信速度が遅くなったりすることがあります。スループットはシステム全体を表し、遅延は個々のリクエストの待ち時間を表します。

1秒あたりのトークン数は常にスループットを意味する

「1秒あたりのトークン数」は、トークン全体の集約スループットを表す場合もあれば、1人のユーザーが体験する生成速度を表す場合もあります。その数値が1件のリクエストを対象としているのか、同時実行中のすべてのリクエストを対象としているのか、また入力、出力、またはその両方を数えているのかを確認してください。

リクエスト率がスループットである

リクエスト率は到着する量です。スループットは完了する量です。システムが処理に追いついている間だけ、両者は近い値になります。到着数が完了数を上回ると、リクエストが遅延、拒否、または破棄されるまでキューが増え続けます。

システムを比較するには、1つのスループット値で十分である

スループットは、モデル、入力と出力のサイズ、バッチまたは同時実行のパターン、ハードウェアの範囲、測定時間、遅延制限に依存します。ワークロードを変えると、システム自体が変わっていなくても値は変化します。

次に読む項目

処理能力としてのスループットが測定するプロセスについては、AIにおける推論とは？を読んでください。待ち時間を測定する推論遅延や、生成速度を表すことが多い1秒あたりのトークン数と比較してください。完全な違いについては、遅延、TTFT、1秒あたりのトークン数、スループットの違いを参照してください。