モデルとモダリティの実践ガイド2026年11月6日Flatkey Team

vLLMベンチマーク：デプロイ前にレイテンシ、スループット、GPUコストを再現する

再現可能なvLLMサービングベンチマークを実行し、現実的なリクエストレートでレイテンシとスループットを比較して、受理済み処理あたりのコストでクラウドGPU容量を選定します。

vLLMベンチマークが有用なのは、アプリケーションが実際に送信するトラフィックに似ている場合だけです。見出しのトークン毎秒という数値は、遅い最初のトークン、過負荷のキュー、または本番環境では決して現れないプロンプト分布を隠してしまう可能性があります。このガイドでは、再現可能なサービングベンチマークを示します。ワークロードを選択し、提示負荷をスイープし、レイテンシ分布とスループットを同時に記録し、同じ品質目標でGPU構成を比較します。

簡潔な回答： 専用GPUサーバーで、固定したvLLMバージョンおよびモデルに対してvllm bench serveを使用します。モデル、精度、プロンプトと出力の長さ、サンプリング設定、キャッシュ状態、クライアントの場所を固定します。複数のリクエストレートを実行し、TTFT、TPOT、エンドツーエンドレイテンシ、成功リクエストレート、出力トークン毎秒を取得したうえで、ピーク負荷時にサービス目標を満たす最も低コストの構成を選びます。最大スループットを測る1回の実行は、キャパシティ計画ではありません。

vLLMベンチマークで測定する項目

指標	分かること	よくある誤り
最初のトークンまでの時間（TTFT）	最初のストリーミング出力がベンチマーククライアントに届くまでの遅延	p95またはp99のユーザーがキューで待機しているにもかかわらず、平均レイテンシだけを報告すること
出力トークンあたりの時間（TPOT）	最初のトークン以降のリクエストごとのデコード時間を、リクエスト全体で平均したもの	投機的デコーディングにおいて、すべてのトークン間ギャップと同一のものとして扱うこと
エンドツーエンドレイテンシ	リクエスト送信から最終出力までの時間	出力長が異なる実行を比較すること
成功リクエスト毎秒	提示負荷において完了した処理量	タイムアウトまたは失敗したリクエストをキャパシティとして数えること
出力トークン毎秒	生成トークンの集約スループット	レイテンシ目標を確認せずにGPU価格で割ること
GPUメモリと使用率	選択したバッチ、KVキャッシュ、モデルが余裕を持って収まるかどうか	キューとテールレイテンシがすでに要件を満たしていないときに、高い使用率を良いものとみなすこと

vLLMベンチマークドキュメントでは、TTFT、トークン間レイテンシ、TPOTをそれぞれの測定点によって定義しています。ツールを比較する際は、これらの定義を使用してください。特に、クライアントTTFTには転送処理とフロントエンド処理が含まれます。任意のサーバー側メトリクスによりスケジューラ待機とモデル実行を分離できますが、有効化するとオーバーヘッドが加わります。診断目的の実行は、見出しとなる結果とは分けてください。

実行前に公正な比較条件を固定する

モデルのリビジョンとトークナイザー、vLLMバージョン、GPUタイプと台数、テンソル並列サイズ、サービングフラグ、量子化形式、コンテキスト長、ソフトウェア環境を書き留めます。すべての候補で同じプロンプトと出力目標を使用します。モデル、精度、GPUを一度に変更すると、どの変更が効果をもたらしたのか結果から判断できません。

少なくとも2種類のワークロードを選択します。合成の固定長ワークロードは制御されたスイープに役立ちます。一方、本番判断には、実際のリクエスト長をサニタイズしたトレースの方が適しています。長いプロンプト、短い回答、バーストの分布を保持してください。チャット製品では、対応するベンチマークバックエンドでチャットエンドポイントを測定します。completionsワークロードでは、completionsバックエンドを使用します。リクエスト形式が同一であるかのように、それらの数値を比較してはいけません。

実行前に合格基準を決定します。たとえば、自身のワークロードに対して、必要な成功リクエストレートと、p95 TTFTおよびp95エンドツーエンドレイテンシの最大値を定めます。普遍的な閾値は提示しません。これはユーザー体験と出力サイズに依存するためです。閾値、測定結果、合格／不合格の理由を含む受け入れ表は、単一のパフォーマンススコアよりも有用です。

制御されたサービングテストを実行する

現行のvLLM CLIガイドには、オンラインサービングの測定用としてvllm bench serveが記載されており、その依存関係にはbench extraの使用が推奨されています。以下の概要では、vLLMがドキュメントで示しているcompletionsの例を使用します。モデルとデータセットは、実行するライセンスを保有し、ハードウェアに収まるアセットに置き換えてください。これらのコマンドは再現可能なテンプレートであり、Flatkeyで測定された結果ではありません。

python -m pip install 'vllm[bench]'
vllm serve YOUR_MODEL_ID

サーバーの準備ができた後、2つ目のシェルで次を実行します：

vllm bench serve \
  --backend vllm \
  --model YOUR_MODEL_ID \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 1000 \
  --request-rate 1 \
  --save-result \
  --save-detailed

次に、他の入力を固定したまま、より高い--request-rate値を短い系列で繰り返します。少数のリクエストをテールレイテンシ分布と誤って解釈しないよう、十分な数のプロンプトを使用してください。各実行の生結果と正確なコマンドを保存します。公式のオンラインベンチマークの例では、出力フィールドを示し、--save-resultと--save-detailedがどのように証拠を保持するかを説明しています。チャットリクエストには、チャット形式をサポートするデータセットとモデルで、文書化されたopenai-chatバックエンドおよび/v1/chat/completionsエンドポイントを使用してください。

トラフィック計画なしに、共有の本番エンドポイントに対してこのベンチマークを実行しないでください。意図的に負荷を発生させます。分離されたテストデプロイメントまたは制御されたメンテナンス時間帯を使用し、結果に影響しうるバックグラウンド処理を記録してください。

レイテンシの屈曲点が見つかるまでスイープする

横軸に提示リクエストレートをプロットします。完了リクエスト数/秒、p95 TTFT、p95エンドツーエンドレイテンシ、出力トークン数/秒を別々の系列としてプロットします。最初は、スループットが提示負荷にほぼ比例して上昇する場合があります。持続可能な領域を超えると、キューが増大し、テールレイテンシが上昇し、成功スループットは横ばいになることがあります。この転換点は、1回の実行で表示される最大値より重要です。

ウォームアップ実行は分けておいてください。vLLMは、同じサーバーに対してベンチマークを繰り返すと、キャッシュされたプレフィックスが再利用され、スループットが水増しされる可能性があると警告しています。キャッシュ再利用が製品ワークロードの一部でない場合は、公式ベンチマークのガイダンスに従ってシードを変えるか、サーバーまたはキャッシュをリセットしてください。キャッシュ再利用が現実的である場合は、キャッシュヒット率を報告し、コールドキャッシュとの比較を含めてください。キャッシュポリシーが明記されていないベンチマークは再現が困難です。

実行が目標を満たさない場合は、順序を調べてください。キューの増大とともにTTFTが増加する場合、飽和またはアドミッション制御を示している可能性があります。キュー時間が安定しているにもかかわらずTPOTが低い場合、デコード、メモリ帯域幅、並列性、または非効率な精度選択を示している可能性があります。失敗が増える場合は、モデル設定を調整する前に、タイムアウト、OOM、サーバーログを確認してください。一度に複数の変数を変更すると、原因が見えなくなります。

生の速度ではなく、受理された処理量でGPUオプションを比較する

より大きなGPUは1秒あたりにより多くの出力トークンを生成できますが、受理されたリクエストあたりのコストは高くなる場合があります。構成ごとに概算コストを計算してください。

成功したリクエスト1,000件あたりのGPUコスト = 時間あたりのGPUコスト ÷ 1時間あたりの成功リクエスト数 × 1,000

正確なリージョンと契約条件について最新の見積もりを使用し、重要であればGPU以外のインフラストラクチャや最小課金単位も含めてください。レイテンシとエラーの目標を満たす実行のみを比較してください。p95 TTFTを満たさない安価な構成は、同じサービスを提供するための安価な方法ではありません。

初期のクラウド比較では、GPU形状のみを変更し、モデルとサービング構成は固定してください。その後、バッチやメモリ設定などの少数のチューニング変更を、一度に1つずつテストします。使用率、VRAMの余裕、キュー深度、リクエスト成功率、ベンチマーク成果物を記録してください。Flatkey Computeは評価対象となるキャパシティオプションの1つです。コスト比較に使用する前に、提供されるGPU、リージョン、最新の見積もりを確認してください。このガイドは、特定のGPUが常に高速または低コストであるとは主張しません。

レビュー担当者に渡せるvLLMベンチマーク結果

各実行について、以下を記録します。モデルとリビジョン、vLLMとドライバーのバージョン、GPUとトポロジー、コマンドとデータセットのチェックサム、入力/出力長の分布、クライアントの場所、キャッシュポリシー、リクエストレート、完了および失敗したリクエスト、p50/p95/p99 TTFT、p50/p95/p99エンドツーエンドレイテンシ、出力トークンスループット、GPU使用率とVRAM、時間あたりの見積もり、受理リクエストあたりのコスト、事前に定めた目標に対する合格/不合格。

この時点で、セキュリティと品質も可視化しておく必要があります。ベンチマーク用プロンプトからは顧客データを除去し、量子化モデルや異なるモデルリビジョンを比較する際には出力品質を確認してください。タスク品質を変えてしまう見かけ上の速度向上は、同等条件での勝利ではありません。

よくある質問

`vllm bench throughput`は`vllm bench serve`と同じですか？

いいえ。前者はオフライン推論スループットを対象とし、後者は稼働中のサーバーにオンラインリクエストを送信して、クライアント向けのサービング動作を測定します。APIデプロイのレイテンシとキャパシティ計画にはbench serveを使用してください。vLLM CLIリファレンスには、両方のコマンドが記載されています。