プロビジョニングされたスループットの 1 秒あたりのトークン数の範囲とはどういう意味ですか?

この記事では、Databricks が基盤モデルAPIのプロビジョニングされたスループットワークロードの 1 秒あたりのトークンを測定する方法とその理由について説明します。

大規模言語モデル (LLM) のパフォーマンスは、多くの場合、1 秒あたりのトークン数で測定されます。本番運用モデルサービングエンドポイントを設定するときは、アプリケーションがエンドポイントに送信するリクエストの数を考慮することが重要です。これにより、レイテンシーに影響を与えないようにエンドポイントをスケーリングするように設定する必要があるかどうかを理解できます。

プロビジョニングされたスループットでデプロイされたエンドポイントのスケールアウト範囲を設定すると、Databricks はトークンを使用してシステムに入る入力について推論するのが簡単であることがわかりました。

トークンとは?

LLMは、 トークンと呼ばれるものの観点からテキストを読み取って生成します。トークンは単語またはサブワードであり、テキストをトークンに分割するための正確なルールはモデルごとに異なります。たとえば、オンラインツールを使用して、 Llamaのトークナイザーが単語をトークンに変換する方法を確認できます。

次の図は、Llama トークナイザーがテキストを分割する例を示しています。

なぜLLMのパフォーマンスをトークン/秒で測定するのですか?

従来、配信エンドポイントは、1 秒あたりの並列要求数 (RPS) に基づいて設定されていました。ただし、LLM 推論要求にかかる時間は、渡されるトークンの数と生成されるトークンの数によって異なり、要求間で不均衡になる可能性があります。したがって、エンドポイントに必要なスケールアウトの量を決定するには、リクエストの内容 (トークン) の観点からエンドポイントのスケールを測定する必要があります。

ユースケースが異なれば、入力トークンと出力トークンの比率も異なります。

入力コンテキストの長さのばらつき: 短い質問など、少数の入力トークンのみを含むリクエストもあれば、要約用の長いドキュメントのように、数百または数千のトークンが含まれるリクエストもあります。この変動性により、RPS のみに基づくサービスエンドポイントの設定は、さまざまな要求のさまざまな処理要求に対応しないため、困難になります。
ユースケースによって出力の長さが異なる: LLM のユースケースが異なると、出力トークンの長さが大きく異なる可能性があります。出力トークンの生成は、LLM 推論の最も時間のかかる部分であるため、スループットに大きく影響する可能性があります。たとえば、要約には短くて辛辣な回答が含まれますが、記事や製品の説明を書くなどのテキスト生成では、はるかに長い回答が生成される可能性があります。

エンドポイントのトークン/秒の範囲を選択するにはどうすればよいですか?

プロビジョニングされたスループットサービングエンドポイントは、エンドポイントに送信できる 1 秒あたりのトークンの範囲で構成されます。エンドポイントは、本番運用アプリケーションの負荷を処理するためにスケールアップおよびスケールダウンします。エンドポイントがスケーリングされる 1 秒あたりのトークンの範囲に基づいて、1 時間ごとに課金されます。

プロビジョニングされたスループットサービスエンドポイントの 1 秒あたりのトークン範囲がユースケースに適しているかどうかを確認する最善の方法は、代表的なデータセットを使用して負荷テストを実行することです。「独自の LLM エンドポイントベンチマークの実施」を参照してください。

考慮すべき2つの重要な要素があります。

Databricks が LLM の 1 秒あたりのトークンパフォーマンスを測定する方法。
オートスケールの仕組み。

Databricks が LLM の 1 秒あたりのトークンパフォーマンスを測定する方法

Databricks は、取得拡張生成のユースケースに共通する要約タスクを表すワークロードに対してエンドポイントをベンチマークします。具体的には、ワークロードは次のもので構成されます。

2048入力トークン
256 出力トークン

表示されるトークン範囲は、入力トークンと出力トークンのスループット を組み合わせ 、デフォルトでは、スループットとレイテンシのバランスを取るために最適化されます。

Databricks ベンチマークでは、ユーザーは 1 秒あたりにその数のトークンを、要求ごとに 1 のバッチサイズでエンドポイントに同時に送信できます。これは、複数のリクエストが同時にエンドポイントに到達することをシミュレートし、本番運用でエンドポイントを実際にどのように使用するかをより正確に表します。

たとえば、プロビジョニングされたスループットサービスエンドポイントのレートが 2304 トークン/秒 (2048 + 256) に設定されている場合、入力が 2048 トークンで、期待出力が 256 トークンの 1 つのリクエストの実行には約 1 秒かかることが予想されます。
同様に、レートが 5600 に設定されている場合、上記の入力トークン数と出力トークン数を使用した 1 つの要求の実行には約 0.5 秒かかることが予想されます。つまり、エンドポイントは 2 つの同様の要求を約 1 秒で処理できます。

ワークロードが上記と異なる場合、レイテンシーは、リストされているプロビジョニングされたスループットレートに対して異なることが予想されます。前述のように、より多くの出力トークンを生成することは、より多くの入力トークンを含めるよりも時間がかかります。バッチ推論を実行していて、完了するのにかかる時間を見積もる場合は、入力トークンと出力トークンの平均数を計算し、上記の Databricks ベンチマークワークロードと比較できます。

たとえば、1000 行があり、平均入力トークン数が 3000、平均出力トークン数が 500、プロビジョニングスループットが 1 秒あたり 3500 トークンの場合、平均トークン数がベンチマークよりも大きいため、合計 1000 秒 (1 行あたり 1 秒) より長くDatabricks かかる可能性があります。
同様に、1000 行、平均入力が 1500 トークン、平均出力が 100 トークン、プロビジョニングスループットが 1600 トークン/秒の場合、平均トークン数がベンチマークよりも少ないため、合計 1000 秒 (1 行あたり 1 秒) 未満で完了 Databricksする可能性があります。

バッチ推論ワークロードを完了するために必要な理想的なプロビジョニング済みスループットを見積もるには、バッチ LLM 推論の実行 (「バッチ LLM 推論の実行)」のノートブックを使用できますai_query

オートスケールの仕組み

モデルサービングは、アプリケーションのトークン/秒の要求を満たすために基礎となるコンピュートをスケーリングするラピッドオートスケールシステムを備えています。 Databricks は、プロビジョニングされたスループットを 1 秒あたりのトークンのチャンクでスケールアップするため、プロビジョニングされたスループットの追加ユニットに対しては、それらを使用している場合にのみ課金されます。

次のスループットレイテンシーグラフは、並列リクエストの数が増加しているテスト済みのプロビジョニング済みスループットエンドポイントを示しています。最初のポイントは 1 つの要求、2 番目のポイントは 2 つの並列要求、3 番目のポイントは 4 つの並列要求などを表します。リクエストの数が増え、次に 1 秒あたりのトークンの需要が増えると、プロビジョニングされたスループットも増加することがわかります。この増加は、オートスケールが利用可能なコンピュートを増やすことを示しています。ただし、スループットが横ばいになり始め、並列要求が増えるにつれて 1 秒あたり ~8000 トークンの制限に達する場合があります。割り当てられたコンピュートが同時に使用されているため、処理される前にキューで待機する必要がある要求が増えると、合計レイテンシが増加します。

注：

スループットを一定に保つには、スケールツーゼロをオフにし、サービスエンドポイントで最小スループットを構成します。これにより、エンドポイントがスケールアップするのを待つ必要がなくなります。

また、モデルサービングエンドポイントから、需要に応じてリソースがどのようにスピンアップまたはスピンダウンされるかを確認することもできます。