独自の LLM エンドポイント ベンチマークを実施する
この記事では、LLM エンドポイントのベンチマーク用に Databricks が推奨するノートブックの例を示します。 また、Databricks が LLM 推論を実行し、エンドポイント パフォーマンス メトリクスとしてレイテンシとスループットを計算する方法についての簡単な紹介も含まれています。
Databricks での LLM 推論は、基盤APIsのプロビジョニングされたスループット モードの 1 秒あたりのトークンを測定します。 「プロビジョニングされたスループットにおける 1 秒あたりのトークンの範囲は何を意味しますか?」を参照してください。
LLM 推論の概要
LLM は、次の 2 段階のプロセスで推論を実行します。
Prefill : 入力プロンプト内のトークンが並行して処理されます。
デコード: テキストが自動回帰方式で一度に 1 トークンずつ生成されます。 生成された各トークンは入力に追加され、モデルにフィードバックされて次のトークンが生成されます。 LLM が特別な停止トークンを出力するか、ユーザー定義の条件が満たされると、生成は停止します。
ほとんどの本番運用アプリケーションにはレイテンシ バジェットがあり、Databricks では、そのレイテンシ バジェットを考慮してスループットを最大化することをお勧めします。
入力トークンの数は、リクエストの処理に必要なメモリに大きな影響を与えます。
出力トークンの数は、全体的な応答遅延を支配します。
Databricks は、LLM 推論を次のサブメトリクスに分割します。
最初のトークンまでの時間(TTFT): これは、ユーザーがクエリを入力してからモデルの出力を表示し始めるまでの時間です。 応答までの待ち時間が短いことは、リアルタイムの対話では不可欠ですが、オフラインのワークロードではそれほど重要ではありません。 このメトリクスは、プロンプトを処理して最初の出力トークンを生成するのに必要な時間によって決まります。
出力トークンごとの時間(TPOT): システムにクエリを実行する各ユーザーの出力トークンを生成する時間。 このメトリクスは、各ユーザーがモデルの「速度」をどのように認識するかに対応します。 たとえば、1 回あたり 100 ミリ秒の TPOT は、1 秒あたり 10 トークン、つまり 1 分あたり約 450 ワードに相当し、これは一般的な人が読むことができる速度よりも高速です。
これらのメトリクスに基づいて、合計レイテンシとスループットは次のように定義できます。
レイテンシー= TTFT + (TPOT) * (生成されるトークンの数)
スループット= すべての同時実行リクエストにわたる 1 秒あたりの出力トークンの数
Databricks では、LLM サービング エンドポイントは、複数のライブラリ リクエストを持つクライアントによって送信される負荷に合わせて拡張できます。 レイテンシとスループットの間にはトレードオフがあります。 これは、エンドポイントを提供する LLM では、ライブラリ リクエストが同時に処理される可能性があるためです。 ドメイン要求の負荷が低い場合、レイテンシは可能な限り低くなります。 ただし、リクエストの負荷を増やすと、レイテンシーは増加する可能性がありますが、スループットも増加する可能性があります。 これは、1 秒あたり 2 つのトークンに相当するリクエストを 2 倍未満の時間で処理できるためです。
したがって、システムへの並列リクエストの数を制御することは、レイテンシーとスループットのバランスを取る上で重要です。 待ち時間が短いユースケースの場合は、待ち時間を低く保つために、エンドポイントに送信するライブラリ リクエストの数を減らしたいと考えます。 高スループットのユースケースでは、レイテンシーを犠牲にしてもスループットの向上には価値があるため、エンドポイントを大量の同時実行リクエストで飽和させる必要があります。
Databricks ベンチマーク ハーネス
以前に共有されたベンチマーク サンプル ノートブックは、 Databricks のベンチマーク ハーネスです。 このノートブックには、レイテンシとスループットのメトリクスが表示され、さまざまな数の並列リクエストにわたるスループット対レイテンシの曲線がプロットされます。 Databricks エンドポイント オートスケールは、レイテンシーとスループットの間の「バランスの取れた」戦略に基づいています。 ノートブックでは、より多くのユーザーがエンドポイントにクエリを実行するにつれて、スループットだけでなくレイテンシーも増加していることがわかります。
LLM パフォーマンス ベンチマークに関する Databricks の哲学の詳細については、「LLM 推論パフォーマンス エンジニアリング: ベスト プラクティス」ブログで説明されています。