道具の名前より先に測定契約を固定する

一言でいうと

モデルサーバーには、普遍的な勝者がいません。同じモデル・ハードウェア・ワークロードで測定し、必要な機能と運用コストをいっしょに比較する必要があります。

なぜ必要なのか

「どのサーバーを使えばよいですか」という質問に、ベンチマークの表1つで答えることはできません。同じツールが、ワークロードによって最善になることもあれば、不適切になることもあるからです。

基準を先に決める必要があります。対話型かバッチか、入力・出力の長さの分布はどうか、プロンプトに共通プレフィックスが多いか、同時実行数のピークはどれくらいか、構造化出力や特定の量子化に対応する必要があるか、エンジンのビルドとバージョンアップのコストを負担できるかを、書き出します。

どう動くのか

比較を再現できるようにするには、まず測定の契約を固定します。

モデル名だけでなく、正確なリビジョン、トークナイザー、dtype・量子化方式、サーバーのバージョンを記録します。
GPUのモデル・数量、ドライバーとランタイムのバージョン、メモリの上限、コンテナイメージを同じにします。
実際のトラフィックから、入力・出力のトークン長、共通プレフィックスの比率、同時実行数、到着間隔を抽出して、再生します。
ウォームアップのあとで複数回繰り返し、TTFT・ITL・エンドツーエンドのレイテンシのp50/p95/p99、処理したトークン数、エラー率、GPUメモリ、プリエンプション率を、いっしょに記録します。
同じ品質設定かを確認します。1つの候補だけが、より積極的な量子化や短い最大出力を使っていれば、速度の比較ではありません。

そのあとで、機能と運用上の制約を見ます。vLLMのブロックベースのKVキャッシュ管理、SGLangのプレフィックス再利用機能、TensorRT-LLMの事前ビルドのエンジン、TGIの対応モデルとデプロイ統合、Ollamaのローカル実行の手軽さは、それぞれ候補を絞る手がかりにすぎず、性能の順位を保証しません。機能の名前が同じでも、リリース、モデル、リクエストの分布によって、得になる程度が変わるので、実際に使う組み合わせのドキュメントと測定結果で決めます。

現場での姿

選択より重要なのは、結果を再び作れることです。ベンチマークのレポートには、実行コマンド、イメージとモデルのリビジョン、ワークロードのデータの生成方法、同時実行数、ウォームアップ・繰り返し回数、生の結果を残します。平均スループットだけがよくても、p99のTTFTやエラー率が、製品のSLOを超えれば、採用できません。

そして、サーバーの選択より前に来る決定があります。モデルのサイズと量子化です。7Bのfp16の重みが入らないGPUで、サーバーだけを変えても、意味がありません。AWQやGPTQで重みを4ビットに量子化すると、重みのメモリは、fp16に比べて理論上は約4分の1ですが、KVキャッシュ・ランタイムの作業領域・量子化のメタデータまで含めた、GPUメモリ全体が4分の1になるわけではありません。実際の削減幅と品質の損失は、対応しているモデルとサーバーの組み合わせで測定する必要があります。

サーバーが実際にしていること

vLLM・TGI・TensorRT-LLMの名前は違っても、性能を作る仕組みは、おおむね同じです。それを知っていれば、設定の名前が違っても、何を調整するのかがわかります。

連続バッチ(continuous batching)。リクエストが終わるまで待たず、ステップごとに、終わったものを外して、新しいものを入れます。静的バッチより、スループットが数倍上がります。これがオンになっているかが、最初の確認事項です。

PagedAttention。KVキャッシュをページ単位で管理して、断片化をなくします。以前は、最大長の分だけ先に確保して、実際の使用量の2、3倍を無駄にしていました。

プレフィックスキャッシュ。システムプロンプトのように、前の部分が同じリクエストのKVを再利用します。精度に影響がなく、TTFTを減らせるので、最初にオンにするものです。

量子化。重みを4–8ビットに減らして、メモリと帯域幅を節約します。品質の損失があるので、評価セットで確認してからオンにします。

メモリをどう分けるのか

GPUメモリは、3つの取り分に分かれます。

전체 24GB
 ├ 가중치         16.2GB   ← 모델 크기 × 비트수/8
 ├ KV 캐시         6.5GB   ← 나머지의 대부분. 동시 요청 수를 정한다
 └ 활성화·여유     1.3GB

このコードブロックの韓国語の図は、全体24GBの内訳として、重みが16.2GB(モデルサイズ×ビット数/8)、KVキャッシュが6.5GB(残りの大部分で、同時リクエスト数を決める)、アクティベーションと余裕が1.3GBだ、という意味です。

gpu_memory_utilizationを上げると、KVキャッシュが大きくなって同時スループットが増えますが、上げすぎると、アクティベーションの余裕が足りなくなって、OOMが起きます。0.90–0.93が実用的な範囲です。

KVキャッシュのサイズは、同時リクエスト数とコンテキスト長の積に比例します。

KV 바이트 ≈ 2 × 레이어 × 헤드 × 헤드차원 × 문맥길이 × 배치 × 정밀도바이트

このコードブロックの韓国語の式は、KVのバイト数がおよそ、2×レイヤー数×ヘッド数×ヘッド次元×コンテキスト長×バッチ×精度のバイト数だ、という意味です。

そのため、コンテキストを16Kから32Kに延ばすと、同時に処理できるリクエスト数が半分になります。「コンテキストを長く開けておこう」は、タダではありません。

何をどう測るのか

ツールを選ぶ前に、測り方を固定します。そうしないと、比較が成り立ちません。

指標	定義	落とし穴
TTFT	リクエスト → 最初のトークン	プレフィックスキャッシュをオンにすると、劇的によくなります
TPOT	トークン間の平均間隔	バッチが大きいと悪くなります
スループット	毎秒の出力トークン(全体)	同時リクエスト数をいっしょに書いて初めて意味があります
p95レイテンシ	上位5%	平均だけを見ると見逃します

3つ目が重要です。「138 tok/s」は、同時4リクエストの合算なのか、単一のリクエストなのかによって、まったく違う数字です。ベンチマークを書くときは、同時実行数・入力長・出力長をいっしょに書きます。この3つがなければ、再現できません。

次の確認で見ること

クイズで、ワークロードの条件に合ったサーバーの選択基準を確認したあと、次のモジュールで、その判断の根拠になるGPUメモリの算定を、計算機で自分で作ります。