CNCF：GoodputメトリクスがThroughput最適化されたLLMサービングでp95レイテンシがほぼ10倍悪化することを明らかに

goodputとは何か、なぜthroughputと異なるのか？

goodputは、あらかじめ定めた目標レイテンシを満たしつつ完了したリクエスト数（1秒あたり）を測定するのに対し、throughputは十分に速いかどうかにかかわらず、処理されたすべてのリクエストをカウントします。AkamasのエンジニアであるGraziano CastoはCNCFブログで、throughputが高いことが必ずしも優れたサービスを意味しないことを示しています。ある構成は全体としてより多くのリクエストを処理できても、その一部はエンドユーザーにとって受け入れがたいほど長いレイテンシを伴うことがあるのです。

ベンチマーク：throughputが50%高くても、レイテンシはほぼ10倍悪化

EKS（Amazon Elastic Kubernetes Service）クラスタ内の1基のNVIDIA A10G GPU上で、vLLMサービングエンジンとGuideLLM負荷シミュレーションツールを使い、Qwen2.5-7Bモデルでテストを行ったところ、合計throughputが50%高い構成は、p95のtime-per-output-token——95%のリクエストが収まるレイテンシ——が、約50ミリ秒から約494ミリ秒へと、ほぼ10倍悪化することが示されました。テストでは3種類のワークロードが検証されました。TTFT（time-to-first-token、最初のトークンまでの時間）に厳しい要件を持つチャットボット、約4,000トークンの出力を伴うreasoning、そして短い連鎖呼び出しを伴うagenticです。

推奨事項：パラメータの自動探索

Castoは、サービング構成をgoodputに対して直接最適化するために、gpu_memory_utilization、max_num_batched_tokens、max_num_seqsといったパラメータの自動探索を推奨しています。チャットボット、reasoning、agenticのシナリオはそれぞれ異なる目標レイテンシと許容範囲を持つため、このアプローチにはワークロードタイプごとの個別テストが必要であり、単一の万能な構成ではすべてのケースを同等にカバーできません。

モデルとGPUの組み合わせごとにパラメータの組み合わせを手動で探索することは、可能な設定数が膨大なため現実的ではありません。そのためCastoは、構成を体系的にテストし、目標のワークロードタイプに対して最良のgoodputを示すものを選ぶ自動化プロセスを提唱しています。本番環境でLLMをサービングするチームは、これによりthroughputのみを最適化する罠——ベンチマークではエンドユーザーのp95レイテンシがほぼ10倍悪化するという結果につながった罠——を回避する具体的な手法を手にすることになります。