Ollama・llama.cpp・vLLM の同時利用を実測：16人で使うと全体の出力は175〜1,404トークン/秒（Ollama と llama.cpp は並列数16）、並列数を64に増やすと約半分に下がった【2026年11月】

社内で LLM を複数人に配る時は、サーバーのソフトと設定で、同じ GPU から出せる速さが大きく変わります。AIコンパスを運営する ALLFORCES の編集部は、Qwen3 14B を H200 1 基で動かし、Ollama・llama.cpp の llama-server・vLLM の 3 つで、同時に使う人数を 1〜128 人に増やして測りました。

利用者は「返事を受け取ったらすぐ次を送る」動きで、依頼は約 640 トークンの文書（800 字前後）の要約です。60 秒の測定を、全設定で 2 巡しました。vLLM だけ重みが違い（元の重み。Ollama と llama-server は 4 ビット量子化の Q4_K_M）、サーバーの差に重みの差が混ざっています。 効果は測りましたが、原因は確認していません。原因に触れる所には「（推定）」と付けています。結論は 5 つです。

• 1 人で使う時：1 人あたりの速さは、llama-server が 149〜153、vLLM が 116、Ollama が 84〜94 トークン/秒でした。Ollama と llama-server は同じファイルですが、llama-server が Ollama の 1.58〜1.73 倍でした（同じ枠の数の設定どうしを、回ごとに比べた 6 組の幅）。原因は確認していません。
• 人数を増やした時：vLLM は同時 128 人で、全体の出力が 3,459〜3,462 トークン/秒、1 人あたり 27.9 トークン/秒でした。同時 128 人を超えると伸びなくなり、256 人で編集部の線を割りました（追加の測定）。llama-server（-np 16）は同時 16 人で 404〜413（1 人あたり 26.4〜27.1）、Ollama（並列 16）は 175〜179（11.3〜11.6）です。
• 枠の数：枠を超えた依頼は順番待ちになりました。逆に、同時 16 人と 32 人では、枠を 64 に増やすと全体の出力が枠 16 の約半分に下がり、同時 16 人で llama-server は 404〜413 から 178〜195、Ollama は 175〜179 から 84〜95 トークン/秒になりました。GPU メモリも 19GiB 台から 49GiB 台に増えました。llama-server の -np 16 は、同時 8 人で --kv-unified を付けると全体の出力が 1.62〜1.69 倍、-np を 8 に合わせると 1.54〜1.58 倍になりました（追加の測定。別の GPU）。
• 数秒の遅れ：llama-server の既定は、同時 4 人以下で、新しく処理する依頼文が 512 トークンを少し超えると、最初の文字まで数秒かかることがありました（この測定では、依頼文が 580〜599 トークンの依頼）。計算の単位（-ub。1 回の計算で処理するトークン数の上限で、既定は 512）を -b 2048 -ub 2048 に上げた設定では、この長さの依頼のうち遅い依頼（最初の文字まで 1 秒を超えた依頼）は 30 件中 1 件でした。既定のままの 3 設定の合計は 93 件中 50 件です（追加の測定）。
• 量子化：Q4_K_M・Q5_K_M・Q6_K・Q8_0 と元の重みで、日本語の正答率は JCommonsenseQA が 94.0〜94.5%、MGSM が 82.8〜85.2%、文章校正で直せた文が 54.0〜60.5% でした。Q8_0 と比べて、補正後に差があるとは言えませんでした。

用語は次の意味で使います。

• 枠：サーバーが同時に処理できる依頼の数。Ollama は並列数（OLLAMA_NUM_PARALLEL）、llama-server は -np、vLLM は --max-num-seqs。記事の「枠 16」は、Ollama の並列 16 と llama-server の -np 16 を指す。
• 同時利用：負荷の道具が模した利用者の数。「同時 16 人」のように書く。
• 順番待ち：枠を超えた依頼が、空きができるまでサーバーで待つこと。
• 全体の出力：測る 60 秒の間に届いた出力トークンの数 ÷ 60（トークン/秒）。
• 1 人あたりの速さ：依頼ごとの（出力トークン − 1）÷（最初の文字から最後の文字までの秒）の中央値（トークン/秒）。順番待ちの時間を含まない。
• 最初の文字までの時間（英語では TTFT）：送信から最初の出力が届くまでの時間。順番待ちの時間を含む。
• 95% 点：全依頼を短い順に並べて 95% 目の値。遅い方から 5% の依頼は、この値より時間がかかった。
• 遅い依頼：最初の文字まで 1 秒を超えた依頼。送信が測定の開始 5 秒より後の依頼を数える（集計の対象外の、助走の依頼を含む）。
• 計算の単位（-ub）：llama-server が 1 回の計算で処理するトークン数の上限。既定は 512。
• KV キャッシュ：処理済みの文脈を GPU に保存する領域。
• 本走：実測表の元になった測定（9 設定・53 測定を 2 巡）。
• 追加の測定：本走とは別の GPU（同じ型の H200）で別の日に、設定を足して測った補足。本走の値と同じ表・同じ棒に並べない。
• 対照：追加の測定で、比べる基準にした設定（llama-server の -np 16。本走と同じ引数）。
• 編集部の線：最初の文字まで 95% 点が 2 秒以内で、かつ 1 人あたりの速さの中央値が毎秒 10 トークン以上。編集部が置いた線で、実測表の ○ はこの線を 2 巡とも満たした測定を示す。

用途別の候補

根拠は、実測表以降の各節にあります。

1 人で試す

• 候補：Ollama の既定（並列 1）か、llama-server
• 根拠：1 人あたりの速さは llama-server が 149〜153、Ollama が 84〜94 トークン/秒。Ollama の並列 1 は同時 1 人で線を満たした
• 向かない場面：Ollama の並列 1 は、2 人が同時に使うと最初の文字まで 95% 点が 2.9〜3.0 秒になり、線を割った

数人〜十数人で共有する

• 候補：llama-server の -np 16（Q4_K_M）か、Ollama の並列 16
• 根拠：同時 16 人で、どちらも線を満たした。全体の出力は llama-server が 404〜413、Ollama が 175〜179 トークン/秒、1 人あたりは 26.4〜27.1 と 11.3〜11.6
• 設定の注意：llama-server は、-np を同時利用の人数に合わせるか --kv-unified を付ける（-np 16 の同時 8 人で、全体の出力が 1.54〜1.69 倍。追加の測定）。既定の計算の単位（-ub 512）では、同時 4 人以下で、新しく処理する依頼文が 512 トークンを少し超えると数秒の遅れが出ることがあり、-b 2048 -ub 2048 にした設定では、この長さの依頼の遅れは 30 件中 1 件だった（既定のままの 3 設定の合計は 93 件中 50 件。追加の測定）
• 向かない場面：枠を超える同時 32 人では、最初の文字まで 95% 点が llama-server で 6.5〜6.8 秒、Ollama で 13.1〜13.6 秒になった。枠を 64 に増やすと順番待ちは短くなるが、1 人あたりの速さが毎秒 10 トークンの線を下回り、全体の出力も約半分になった。Ollama の 1 人あたりの速さは、毎秒 10 トークンの線に近い。llama-server の -np 16 は、同時 4 人の 2 巡目で最初の文字まで 95% 点が 3.2 秒になった（数秒の遅れの節を参照）

数十人以上で使う・API として配る

• 候補：vLLM（元の重み）
• 根拠：同時 128 人まで、2 巡とも線を満たした（別の GPU の追加の測定では 192 人まで満たした）。同時 128 人で全体の出力が 3,459〜3,462 トークン/秒、最初の文字まで 95% 点が 0.21〜0.24 秒
• 向かない場面：1 人あたりの速さは、1 人の時の 116 から同時 128 人の 27.9 トークン/秒まで下がる。1 人で使うなら llama-server の方が速かった。GPU メモリを 49.4GiB 確保した（--gpu-memory-utilization 0.35）。同時 256 人では最初の文字まで 95% 点が 3.6〜3.8 秒になり、線を割った（追加の測定）

実測表：全体の出力と、編集部の線を満たした範囲

線を満たした範囲は、設定で大きく違いました。vLLM は測った同時 128 人までの全部で満たしました。llama-server の -np 16 と Ollama の並列 16 は同時 16 人まで、枠を 64 にした設定は、満たす最大の人数が llama-server で 16 人、Ollama で 8 人でした。人数が少なくても線を割る例外があります。llama-server の -np 16 は、同時 4 人の 2 巡目で最初の文字まで 95% 点が 3.2 秒になって線を割り、同時 8 人と 16 人では満たしました。そのため「最大で何人」は 1 つの数字で言い切らず、○ を付けた測定の表で見てください。

1 人で使う時は、同じファイルでも llama-server が Ollama の 1.58〜1.73 倍速かった

Ollama と llama-server は、同じ GGUF（llama.cpp の重みの形式）のファイル（Ollama の qwen3:14b の blob、Q4_K_M）を読ませました。Ollama は中で llama.cpp のサーバー（llama-server）を起動することを、起動のログで確認しています。それでも 1 人あたりの速さは 1.58〜1.73 倍違い、原因は確認していません。Ollama が中で起動する llama-server は、単体の llama-server と版・起動の引数・チャットのテンプレートが違い（測定の条件を参照）、どれが効いているかは分かっていません。vLLM（116）は元の重みのため、この 2 つとは並べて順位を付けません。llama-server の Q8_0 は 138.8〜139.7 で、Q4_K_M の 0.91〜0.92 倍でした。

人数を増やすと、vLLM は同時 128 人まで全体の出力が伸びた

vLLM の全体の出力は、同時 1 人の 113 から同時 128 人の 3,459〜3,462 トークン/秒まで、測った範囲で人数とともに伸び続けました。llama-server（枠 16）は同時 16 人を超えると伸びなくなり、同時 32 人で 400〜405、64 人で 367〜371 でした。Ollama（並列 16）は同時 64 人でも 192〜197 です。

1 人あたりの速さは、vLLM が同時 128 人でも 27.9 トークン/秒で、毎秒 10 トークンの線を上回りました。llama-server と Ollama は、枠の数を超えた人数で使っても 1 人あたりの速さは大きくは変わりません。1 人あたりの速さは最初の文字から最後の文字までで測るので、順番待ちの時間を含まないためです。同時 16・32・64 人の 1 人あたりは、llama-server（-np 16）が 26.4〜27.1・26.7〜27.2・24.0〜24.3、Ollama（並列 16）が 11.3〜11.6・12.4〜12.6・12.5〜13.7 トークン/秒です。枠を超えた時に伸びたのは、最初の文字までの時間だけでした。同時 32 人の最初の文字まで 95% 点は、llama-server が 6.5〜6.8 秒、Ollama が 13.1〜13.6 秒でした（次の節）。

vLLM は同時 128 人を超えると全体の出力が伸びなくなり、256 人で線を割った

本走の vLLM は同時 128 人までの測定でした。上限を探すため、別の GPU で同時 64・128・192・256 人を測り直しました（追加の測定。本走の値と同じ表には混ぜません）。192 人までは 2 巡とも編集部の線を満たし（最初の文字まで 95% 点 0.81〜0.82 秒、1 人あたり 19.3 トークン/秒）、256 人は最初の文字まで中央値が 3.1 秒で、線を割りました。

全体の出力が伸びなくなった原因は確認していません。起動のログの KV キャッシュは 122,160 トークン分で、依頼 1 件が約 780 トークン（依頼文 約 640 ＋ 出力 約 138）なので、KV キャッシュに載る依頼は約 156 件です。全体の出力が伸びなくなった同時 128 人超に近い値です（推定）。--gpu-memory-utilization 0.35 の指定での結果で、指定を上げた時の上限は測っていません。

枠を超えた依頼は順番待ちになり、枠を 64 に増やすと順番待ちは短くなったが 1 人あたりの速さが線を下回った

Ollama は、並列数を超えた依頼を断らずに順番待ちにしました（失敗は 0）。順番待ちの時間は、同時利用が枠の 2 倍、4 倍になるにつれて伸びました。llama-server も同じ形で、-np 4 に 16 人が来ると最初の文字まで中央値が 6.9〜7.1 秒でした。

同時 32 人で枠を 16 から 64 に増やすと、順番待ちは短くなりました。最初の文字まで 95% 点は、llama-server が 6.5〜6.8 秒から 1.5〜1.7 秒、Ollama が 13.1〜13.6 秒から 1.7〜1.8 秒です。一方で 1 人あたりの速さは、llama-server が 26.7〜27.2 から 5.8〜6.8、Ollama が 12.4〜12.6 から 2.4〜2.9 トークン/秒に下がり、毎秒 10 トークンの線を下回りました。全体の出力も llama-server が 400〜405 から 201〜211、Ollama が 182〜190 から 93〜105 に下がり、編集部の線は満たしませんでした。

同時 16 人と 32 人では、枠を 64 に増やすと全体の出力が枠 16 の約半分に下がった

同時 16 人で枠の数だけを変えると、枠が 16 の時が最も高くなりました。枠 64 は枠 16 の約半分で、同時 16 人と 32 人の 8 つの比（2 つのサーバー × 2 つの人数 × 2 巡）は、全部が 0.4〜0.6 に入ります（図の倍率は同時 16 人、同時 32 人は上の節の数字）。

ほかの人数では、同じ形になりません。同時 64 人では llama-server の -np 64 が -np 16 を上回り（439〜445 と 367〜371）、Ollama は並列 64 の方が低いままでした（153〜187 と 192〜197）。同時 8 人以下は、2 巡の幅が重なる設定と重ならない設定があるので、図に任せます。

llama-server の -np 16 を同時 8 人で使う時は、–kv-unified を付けるか -np を 8 にすると全体の出力が 1.54〜1.69 倍になった

本走で llama-server の -np 16 は、同時 8 人と 16 人で 1 人あたりの速さがほぼ同じ（8 人 23.0〜26.6、16 人 26.4〜27.1 トークン/秒）なのに、全体の出力は 16 人（404〜413）が 8 人（162〜198）の 2 倍以上でした。-np 4 の同時 8 人は 234〜241 で、-np 16 の同時 8 人より高い値です。-np 64 の同時 32 人と 64 人、Ollama の並列 16 の同時 8 人と 16 人でも、人数が枠に近づくと全体の出力が大きく上がります。そこで同じ llama-server を別の GPU で、設定を 1 つずつ変えて測りました（追加の測定）。

同時 8 人では、--kv-unified を付けると全体の出力が対照の 1.62〜1.69 倍、-np を 8 にすると 1.54〜1.58 倍になりました。全部の枠が埋まる同時 16 人では、--kv-unified を付けても対照の 0.98〜1.01 倍で、差は見えませんでした。同時 16 人で差が出ないことと、-np を 8 に下げると同時 8 人で同じ効果が出ることは、次のソースコードの 3 つの処理と整合します。スレッド数（-t 8）は全体の出力を増やしませんでした（同時 8 人で 0.93〜0.96 倍、16 人で 1.01〜1.04 倍）。llama.cpp の commit 3b4d6ab3f（測ったイメージの版）で確認した処理を説明する前に、2 つの語を補います。llama-server の枠には 0 から順に番号が付いています（コードでは枠を sequence と呼びます）。1 回の計算（コードでは ubatch）は、複数の枠の依頼をまとめて処理します。

• tools/server/server.cpp 126〜130 行：-np を指定しない（自動）時だけ、4 枠で kv_unified = true（KV キャッシュを全部の枠で 1 つにする）にする。-np を指定すると枠ごとに分かれ、起動のログも kv_unified = 'false' だった。
• src/llama-kv-cache.cpp 762 行とsrc/llama-batch.cpp 686〜689 行：枠ごとに分かれている時、1 回の計算にまとめる枠は番号が連続したものだけ（コメントは accept only increasing sequence ids）。
• tools/server/server-context.cpp 1819〜1861 行・1870〜1877 行・2655〜2668 行：空き枠は、依頼文の先頭が似ている枠を先に選ぶ（slot_prompt_similarity、既定 0.1）。無ければ最も長く使われていない枠を選ぶ。番号が連続するようには選ばれない。

枠が飛び飛びに埋まると、1 回の計算にまとめられる依頼が減る（推定）。1 回の計算の時間の内訳は測っていないので、確認できたのは「ソースコードの処理と測定結果が整合する」ところまでです。確認したのは効果（--kv-unified で 1.62〜1.69 倍、-np 8 で 1.54〜1.58 倍）で、原因は推定です。設定を決める時の要点と、確認していない範囲を次に並べます。

• llama-server を枠より少ない人数で使う時は、-np を同時利用の人数に合わせるか、--kv-unified を付ける（効果を確認したのは -np 16・同時 8 人）。
• --kv-unified を付けると、起動のログで枠ごとの上限（n_ctx_slot）が 4,096 から 40,960 トークンに変わり、65,536 トークン分を全部の枠で分け合う形になった。長い依頼が混ざった時の動きは測っていない。
• Ollama は中の llama-server を -np <並列数> で起動し、kv_unified = false だった。Ollama から kv_unified を変更できるかは確認していない。
• 効果を確認したのは -np 16・同時 8 人だけ。-np 64 の同時 16 人と Ollama の並列 64 が下がった原因にも、同じ処理が当てはまると考えられる（推定）が、設定を変えて確認していない。

llama-server は、同時 4 人以下で新しく処理する依頼文が 512 トークンを少し超えると最初の文字まで数秒かかることがあり、-ub 2048 にした設定では遅い依頼が 30 件中 1 件だった

実測表で、人数が少ないのに ○ が抜ける測定があります。本走の llama-server で、同時 4 人以下の最初の文字まで 95% 点が、どちらかの回で 2 秒を超えたマスは 4 つあります（1 巡目/2 巡目の順）。

• -np 4 の同時 1 人：2.69/0.22 秒
• -np 4 の同時 2 人：3.68/2.53 秒
• -np 16 の同時 4 人：0.50/3.22 秒
• -np 64 の同時 2 人：0.46/2.20 秒

遅い依頼の多くは、依頼文が 580〜599 トークンの時でした。この時、先頭の共通部分（約 67 トークン）は前の依頼の計算が残っていて、新しく処理するのは 513〜530 トークンです。これが計算の単位 512 をわずかに超えます。以後は「580〜599 トークンの依頼」と書きます。-np 4 の同時 1 人の 1 巡目では遅い依頼 4 件が全部、-np 16 の同時 4 人の 2 巡目では 4 件中 3 件が 580〜599 トークンの依頼でした（もう 1 件は 690 トークン）。

本走の記録では、llama-server の同時 1・2 人で、580〜599 トークンの依頼 50 件のうち 31 件が最初の文字まで 1 秒を超え（2.1〜11.6 秒）、それ以外の長さは 667 件中 5 件でした。Ollama は同時 1 人で 287 件中 3 件で、3 件とも 580〜599 トークンの依頼です（580〜599 トークンの依頼は 20 件中 3 件、それ以外は 267 件中 0 件）。vLLM は同時 1 人で 114 件中 0 件です。

Ollama の遅い依頼 3 件は、全部が -ub 512 で起動した並列 1 で起きました。Ollama が中で起動する llama-server の -b・-ub は並列数で変わり（並列 1 は 512、並列 4 は 1024、並列 16 と 64 は 2048）、-ub が 1024・2048 の 3 設定は、同時 1 人で、580〜599 トークンの依頼 15 件中 0 件です（全部の長さでは 222 件中 0 件）。件数は少ないですが、llama-server の結果と整合します。

条件を絞るため、別の GPU で llama-server の設定を 1 つずつ変えて、同じ数え方で数えました（追加の測定）。

遅い依頼が出るのは、同時利用が少ない時です。追加の測定の同時 16 人では、既定の -ub 512 でも該当の帯はほぼ遅くならず（対照 0/33、--kv-unified 0/35、-t 8 0/35、--cache-ram 0 1/40）、同時 8 人は設定で割れました（対照 7/16、-np 8 3/21、-t 8 6/14、--kv-unified 0/27）。この違いの原因は確認していません。

サーバーのログでは、遅いのは依頼文の処理（prompt eval time）の時間でした。枠を選んでから処理を始めるまでは、設定ごとの中央値が 0.04〜0.05 秒（--cache-ram 0 の設定は 0.001 秒未満）、最大 0.24 秒です。次の条件に当てはまる回について、依頼文の処理が 1 秒を超えた数を数えました。

• 処理を始めた時に、処理中の枠が自分を含めて 2 つ以下
• 新しく処理するトークンが 513〜530

結果は、--kv-unified の設定で 13/26、--cache-ram 0 で 7/8、-ub 2048 で 0/10 でした。llama-server の計算の単位（-ub）の既定は 512 で（出典は llama.cpp の同じ commit の common/common.h 473 行と tools/server/README.md 53 行）、新しく処理する部分が 512 を少し超えた依頼文は、512 トークンと数トークンの 2 回に分けて処理される（推定）。512 を超えた数トークンだけの処理が、なぜ 2 秒以上かかるかは確認していません。

-b 2048 -ub 2048 で動かすと、同時 4 人以下で、580〜599 トークンの依頼のうち 1 秒を超えたのは 30 件中 1 件で、0 にはなっていません（--kv-unified・--cache-ram 0・-np 8 の 3 設定は 93 件中 50 件）。追加の測定では、既定のままの対照を同時 4 人以下で測っていないので、比べる相手はこの 3 設定の合計です。同時 1 人の最初の文字まで 95% 点は 0.22〜0.23 秒、GPU メモリは 19.5GiB（対照は 19.1GiB）でした。ただし同時 16 人では、遅い依頼が対照より多く（該当の帯で 4/35 と、対照の 0/33）、全体の出力は対照の 0.94〜1.04 倍で、差は見えませんでした。

依頼文のキャッシュをメモリに退避する機能（--cache-ram）を切っても、遅い依頼は残りました（同時 1 人の最初の文字まで 95% 点が 2 巡で 0.19〜2.99 秒）。切っても残ったので、退避が主な原因とは言えません。

なお同時 16 人の全体の出力は、--cache-ram 0 が 452〜454 トークン/秒で、対照の 368〜384 の 1.18〜1.24 倍、1 人あたりは 29.4〜29.9 対 24.6〜25.3 でした。この測定は依頼ごとに先頭の行を変えていて、退避したキャッシュが使われない条件です。退避の処理の時間が全体の出力を下げていた可能性があります（推定）。会話の続きのようにキャッシュが効く使い方では逆になりうるので、この結果は依頼文が毎回違う使い方に限ります。

GPU メモリは、枠を増やすほど増えた

GPU メモリが増えたのは、Ollama も llama-server も 1 依頼あたりのコンテキスト長を 4,096 に固定していて、枠の数に応じて KV キャッシュ（処理済みの文脈を GPU に保存する領域）が増えるためと考えられます（推定）。枠 16 から 64 に増やすと、llama-server は 19.1 から 49.1GiB、Ollama は 19.5 から 49.5GiB で、どちらも 2.5〜2.6 倍です。枠の数に比例して 4 倍にはなっておらず、増え方の内訳は確認していません。

量子化は、Q4_K_M でも日本語の正答に差があるとは言えなかった

Q8_0 を基準に、問いごとの対の検定をしました。補正前の p（小さいほど、差が測定の揺れでは説明しにくい）が 0.05 を下回ったのは、校正で直せた文の Q4_K_M だけです（0.041〜0.049）。補正後（4 つの比較をしたことの補正）は 0.17〜0.20 で、差があるとは言えません。なお校正で直せた文の Q4_K_M は、Q8_0 より 4.5〜5.0 ポイント低い値でした。

温度 0 でも、同じ問いの答えは 2 回で完全には一致しませんでした。1 回だけの測定では揺れが分からないため、この実測表は 2 回の範囲で読んでいます。

測っていない対象と理由

• SGLang・TGI・LM Studio：今回は Ollama・llama-server・vLLM の 3 つに絞った。TGI はリポジトリが 2026年3月21日からアーカイブ（読み取り専用）で、README にはメンテナンスモードと書かれている。最新のリリースは v3.3.7（2025年12月19日）。
• 複数の GPU：H200 1 基だけを測った。
• 長い文脈：1 依頼あたり 4,096 トークンに固定した。長い文書では、枠あたりのメモリが変わる。
• ほかのモデル：Qwen3 14B だけを測った。
• AWQ・GPTQ などの量子化：vLLM の元の重みと、llama-server の GGUF だけを測った。
• 会話の続きのように、依頼文のキャッシュが効く使い方：依頼ごとに先頭の行を変え、文書の部分にはキャッシュが効かない条件にした（先頭の共通部分 約 67 トークンには効く）。
• 開ループの負荷：利用者が返事を受け取ってから次を送る方式（閉ループ）だけを測った。人数とは別に、決まった頻度で依頼が届く方式（開ループ）は測っていない。

ほかの実測表は実測表の一覧、モデルごとの日本語の性能はローカル LLM の実測表、文章校正の問いは文章校正の実測表にあります。

測定の条件

下の欄を開くと、版・起動の引数・依頼文・測り方・差の判定・2 巡で大きく違った測定が表示されます。

この実測表で分からないこと

• GPU と環境：共用ノードの H200 1 基だけの結果。ほかの GPU、複数の GPU、ほかの利用者の負荷が違う時の値は、この表から言えません。
• モデルと重み：Qwen3 14B 1 種。vLLM だけ元の重みで、サーバーの差と重みの差を分けられません。
• 追加の測定：別の GPU で別の日に測ったため、本走の値とは直接比べていません。追加の測定の中の設定どうしを比べました。
• 使い方：約 640 トークンの文書の要約を、文書の部分にはキャッシュが効かない条件で、返事を受け取ったらすぐ次を送る利用者が続ける使い方。会話の続き、長い文脈、決まった頻度で依頼が届く使い方では結果が変わりうる。
• 少ない人数の値：2 巡で 2 割以上違った測定が 18 件あり、対象の依頼が 25〜99 件の測定でした。順位を言い切らず、範囲で読んでください。
• vLLM の上限：追加の測定で同時 256 人まで測り、128 人を超えると全体の出力が伸びなくなった。--gpu-memory-utilization を上げた時の上限は測っていません。
• 枠を 64 にして下がった原因：-np 16・同時 8 人は --kv-unified で効果を確認しました。-np 64 の同時 16 人と Ollama の並列 64 は、同じ処理が当てはまると考えられます（推定）が、設定を変えて確認していません。
• --kv-unified と長い依頼：枠ごとの上限が 40,960 トークンに変わります。長い依頼が混ざった時の動きは測っていません。
• 新しく処理する部分が 512 トークンを少し超えた依頼文が遅い原因：512 を超えた数トークンだけの処理に、なぜ 2 秒以上かかるかは確認していません。
• 1 人で使った時に Ollama が遅い原因：同じファイルで 1.58〜1.73 倍違いましたが、版・起動の引数・テンプレートが違い、どれが効いているかは確認していません。
• 量子化の差：校正（直せた）は問いが 200 文で、Q4_K_M の差が無いとは確認できていません。速さは Q8_0 を同時 1・8・16 人で測っただけです。