4種類の異なるレイテンシシグナルを測定する
単一のレイテンシ値では、ユーザーがどの時点で待機しているのかが分かりません。ストリーミングチャットでは、完全な生成結果の取得に時間がかかる場合でも、TTFTが低ければ高速に感じられます。一方、バッチ抽出ではエンドツーエンドの所要時間だけが重要になることがあります。
- Time to first token：リクエスト開始からストリーミングされた最初のトークンを受信するまでの時間。
- 生成スループット：出力トークン数を生成時間で割った値。
- エンドツーエンドの所要時間：リクエスト開始からレスポンスの完了までの時間。
- 信頼性：成功したレスポンス数を試行総数で割った値。
ベンチマークのワークロードを統制する
想定するワークロードを代表する固定プロンプトセットを使用します。モデルID、プロバイダーのルート、リージョン、リクエストパラメーター、入力トークン数、要求した出力長を記録します。
- 測定値を記録する前に、ウォームアップ用のリクエストを実行します。
- 時間帯による偏りを抑えるため、プロバイダーの実行順序をランダム化します。
- 複数のトラフィック時間帯にわたってテストを繰り返します。
- ストリーミングと非ストリーミングの結果を分けて扱います。
リーダーボードのスクリーンショットではなく分布を使用する
サンプル数と併せて、中央値、p90値、p95値を報告します。中央値が最速でも極端な遅延が頻発するルートは、わずかに遅くてもより安定したルートより、実稼働環境でのユーザー体験が悪くなる可能性があります。
{
"sample_size": 100,
"ttft_ms": { "median": 640, "p95": 1840 },
"output_tokens_per_second": { "median": 42.1 },
"end_to_end_ms": { "median": 5120, "p95": 9080 },
"success_rate": 0.98
}上記の値は報告形式の例であり、実際のCometAPIベンチマーク結果ではありません。
すべてのレポートで方法論を公開する
ベンチマークは、何を測定したのかを読者が理解し、その手法を再現できる場合にのみ有用です。制約事項を含め、プロバイダーのルートを固定したのか、自動的に選択したのかを説明します。