概念図：出力開始までの待ち時間、ストリーミングの間隔、全体のスループットは、サービスの異なる側面を表します。実測データではありません。
サーバーが 1 秒あたりに生成するトークンは増えたのに、チャット画面にはなかなか回答が表示されない。この二つは同時に起こり得ます。推論基盤のアップグレードを承認する前に、実務的な問いを立てましょう。ユーザーの待ち時間のうち、どの部分を短くしたいのでしょうか。
一つの評価表にある二つの「速さ」
10 月 6 日にマージされた vLLM PR #60140 では、GLM-5.3 の KV キャッシュを FP8 に切り替えた結果が報告されています。TP4、入力 8,000 トークン、出力 1,000 トークン、同時実行数 1、4、16 という条件で、表に示されたスループットの改善幅は 2.3%〜5.5% でした。一方、最初のトークンまでの時間（TTFT）の中央値は 6.9%〜11.1% 増加しています。総レイテンシの中央値は 3.1%〜6.3% 減少しており、回答の開始は遅くなったものの、完了は早くなりました。出典：PR #60140
これはコントリビューターによる報告値であり、私たちは追試していません。より長い入力にわたる検証も含まれていません。その後のパッチでは、このデフォルト動作の適用範囲が NVIDIA SM100 に限定されました。これらの結果をすべての GLM デプロイ環境に当てはめることは、証拠の範囲を超えます。出典：PR #60281
待ち時間を区間ごとに分ける
ユーザーはまず最初の出力を待ち、次に続く内容を待ち、最後に完全な回答を受け取ります。サーバーのスループットは全体の出力量を測り、TTFT は出力開始までの遅延を測ります。トークン間レイテンシ（ITL）は連続するストリーミング出力の間隔を表し、完了までの時間はリクエスト全体を対象にします。vLLM のサーバー側 TTFT には入力処理も含まれるため、GPU の計算時間だけを測る指標ではありません。ネットワーク、ゲートウェイ、画面表示のオーバーヘッドも、クライアント側で観測する必要があります。出典：メトリクスの設計
スケジューリングにはトレードオフがあります。vLLM のチャンク化プリフィル（chunked prefill）は、長い入力を分割し、すでに生成中のリクエストと組み合わせてスケジュールします。公式ドキュメントによると、バッチ内のトークン数の上限を小さくすると ITL に有利で、大きくすると TTFT に有利です。これは、レイテンシ指標が異なる方向に動く仕組みの一般的な説明です。上記の PR は、この仕組みが FP8 への変更に伴う TTFT 悪化の原因であることを立証していません。出典：最適化ガイド
キャッシュも、どの段階の処理を減らすのかが重要です。プレフィックスキャッシュは、共通する入力プレフィックスの計算結果を再利用し、プリフィルを効率化します。ただし、新しいトークンを生成するデコード処理を直接短縮するわけではありません。そのため、一つの長い文書について繰り返し質問する場合と、長い回答の生成が中心のワークロードでは、得られる効果が異なり得ます。出典：プレフィックスキャッシュとその制限
アップグレード前に受け入れ基準を決める
以下は私たちが提案するテスト計画であり、実施済みの実験結果ではありません。
-
比較条件をそろえる。GPU、モデルのバージョン、推論フレームワークのコミット、量子化方式、並列化方式、投機的デコーディング、サンプリング設定を記録します。改善の原因を特定できるよう、一度に変更するのは評価対象の項目だけにします。
-
小さなテストマトリクスを作る。実際のタスクから、短い会話、長い文書についての短い回答、長い出力の 3 種類を選びます。それぞれを新規プレフィックスと再利用可能なプレフィックスで、低負荷、通常負荷、処理能力の上限に近い負荷の 3 段階でテストします。合計 18 条件です。入力はモデルの対応範囲に収め、負荷の水準は自分たちのトラフィックに基づいて決めます。
-
突発的なトラフィックも加える。実際の到着レート、実際の同時実行数、キュー待ち、失敗したリクエストを記録します。同時実行数を固定したテストと、ユーザーが一斉に流入する状況では、かかる負荷が異なります。レート制限によって待ち時間がクライアント側に移る場合もあります。vLLM のベンチマークツールは、リクエストレートと最大同時実行数を分けて設定でき、クライアント側のキューに関する指標も提供します。出典：ベンチマークのパラメーター
-
すべての条件で評価項目を漏れなく記録する。最低限、TTFT、ITL、総レイテンシの p50/p95/p99 に加え、スループット、キャッシュヒット、プリエンプション、タイムアウト、エラー率を記録します。テストは独立した試行として繰り返し、ウォームアップ方法とサンプル数を明示します。サンプルが少ない場合は、特に裾のパーセンタイル値を慎重に解釈します。量子化を変更する場合は、別途タスク品質の確認も必要です。速度だけでは正しさを確認できません。
-
改善幅を比べる前にしきい値を決める。対話型アシスタントでは、最初の出力までの時間やストリーミングの中断時間を優先するかもしれません。オフラインのバッチ処理では、完了した処理量を重視するかもしれません。実際のしきい値は製品要件に基づいて決めるべきです。成功し、かつレイテンシ目標も満たしたリクエストを数えると、サービスの処理能力をより実用的に評価できます。vLLM は、TTFT、出力トークンあたりの時間、エンドツーエンドのレイテンシに対する goodput のしきい値をサポートしています。出典：goodput オプション
結果をユーザーの体験につなげる
役に立つ受け入れ評価レポートは、次の具体的な問いに答える必要があります。「自分たちのトラフィックと品質要件の下で、1 時間あたり何件多くリクエストを完了でき、最も待たされるユーザーの待ち時間はどれくらいになるのか？」
スループットの向上は歓迎すべきことです。待ち時間、品質、失敗と併せて読み解くことで、そのアップグレードが何を改善するのかが明確になります。
出典の確認日：2026 年 10 月 19 日。本稿は、コントリビューターが公開したベンチマークと公式ドキュメントに基づく技術分析です。テストマトリクスは私たちの提案であり、独立した性能テストや品質テストは実施していません。ドキュメントの latest ページは更新される場合があります。実際にデプロイするバージョンを確認してください。