llama.cpp を使用した 16GB VRAM における LLM ベンチマーク（速度とコンテキスト）

16GB VRAM における llama.cpp のトークン生成速度（表）。

目次

ここでは、16GB の VRAM を持つ GPU で動作するいくつかの LLM の速度を比較し、セルフホスティングに適した最適なモデルを選定しています。

私は llama.cpp を使用して、これらの LLM を 19K、32K、および 64K トークンのコンテキストウィンドウで実行しました。

Stylized GPU with VRAM blocks and benchmark-style charts

この投稿では、可能な限り高速化という観点から、最大のパフォーマンスを引き出すための私の試みを記録しています。

LLM 速度比較表（秒間トークン数と VRAM）

モデル サイズ 19K VRAM 19K GPU/CPU 19K T/s 32K VRAM 32K Load 32K T/s 64K VRAM 64K Load 64K: T/s
Qwen3.5-35B-A3B-UD-IQ3_S 13.6 14.3GB 93%/100% 136.4 14.6GB 93%/100% 138.5 14.9GB 88%/115% 136.8
Qwen3.5-27B-UD-IQ3_XXS 11.5 12.9 98/100 45.3 13.7 98/100 45.1 14.7 45/410 22.7
Qwen3.5-27B-IQ4_XS.gguf 15.0 14.6 49/406 20.5 14.7 37/465 17.4 14.7 23/533 13.3
Qwen3.5-122B-A10B-UD-IQ3_XXS 44.7 14.7 30/470 22.3 14.7 30/480 21.8 14.7 28/490 21.5
Qwen3.5-122B-A10B-UD-IQ3_S 46.5 14.7 25/516 19.4 14.7 24/516 19.5 14.7 24/516 19.6
nvidia Nemotron-Cascade-2-30B IQ4_XS 18.2 14.6 60/305 115.8 14.7 57/311 113.6 14.7 55/324 103.4
gemma-4-26B-A4B-it-UD-IQ4_XS 13.4 14.7 95/100 121.7 14.9 95/115 114.9 14.9 75/190 96.1
gemma-4-31B-it-UD-IQ3_XXS 11.8 14.8 68/287 29.2 14.8 41/480 18.4 14.8 18/634 8.1
GLM-4.7-Flash-IQ4_XS 16.3 15.0 66/240 91.8 14.9 62/262 86.1 14.9 53/313 72.5
GLM-4.7-Flash-REAP-23B IQ4_XS 12.6 13.7 92/100 122.0 14.4 95/102 123.2 14.9 71/196 97.1

19K、32K、64K はコンテキストサイズを示します。

上記の load は GPU Load（GPU 負荷）です。 この列の数値が低い場合、モデルは主に CPU で実行されており、このハードウェアでは十分な速度が出せないことを意味します。このパターンは、GPU にモデルの容量が十分に収まらない場合、またはコンテキストがホスト側への処理を押し戻す場合に、人々が観察する現象と一致します。

llama.cpp、LLM パフォーマンス、OpenCode および他の比較について

インストールパス、llama-cli および llama-server の例、VRAM と秒間トークン数（コンテキストサイズ、バッチ処理、-ngl）に影響するフラグについては、まず llama.cpp クイックスタート（CLI とサーバー） から始めることをお勧めします。

より広範なパフォーマンスの全体像（スループット対レイテンシ、VRAM 制限、並行リクエスト、およびハードウェアとランタイム全体でのベンチマークの統合方法）については、2026 年の LLM パフォーマンス：ベンチマーク、ボトルネック、および最適化 を参照してください。

レスポンスの質については、他の記事で分析されています。例えば：

私は Ollama 上の LLM についても同様のテストを行いました：16GB VRAM GPU 向けの最適な Ollama LLM。

コンテキスト長が秒間トークン数に影響する理由

19K から 32K や 64K トークンへ移行すると、KV キャッシュが成長し、VRAM への圧力が高まります。一部の行では 64K で秒間トークン数が大きく低下するのに対し、他の行では一定のままです。これは、モデルが一般的に「遅い」という仮定をするのではなく、量子化（クォント）、コンテキスト制限、またはレイヤーオフロードを見直す必要があるというシグナルとなります。

私がテストのために選んだモデルと量子化は、私が自分で実行し、この装置でコスト対効果的に良いパフォーマンスを得られるかどうかを確認するためです。したがって、ここでは 20 万コンテキストを持つ q8 量子化はありません :) …

GPU/CPU は nvitop で測定される負荷です。

llama.cpp が GPU へのレイヤーのアンロードを自動設定する際、1GB 分の空き容量を確保しようとします。 このパラメータはコマンドラインパラメータ -ngl で手動で指定可能ですが、ここでは微調整を行いません。 32k から 64k までコンテキストウィンドウサイズを増加させた際にパフォーマンスが著しく低下する場合は、アンロードされたレイヤー数を微調整することで 64k での速度向上を試みることができます。

テストハードウェアと llama.cpp の設定

以下の構成を持つ PC で LLM の速度をテストしました：

  • CPU: i-14700
  • RAM: 64GB 6000Hz (2x32GB)
  • GPU: RTX-4080
  • Ubuntu (Nvidia ドライバー搭載)
  • llama.cpp/llama-cli、アンロードされたレイヤーは指定なし
  • llama-cli 開始前の初期 VRAM 使用量：300MB

128K コンテキストでの追加実行（Qwen3.5 27B および 122B）

モデル 128K Load 128K: T/s
Qwen3.5-27B-UD-IQ3_XXS 16/625 9.6
Qwen3.5-122B-A10B-UD-IQ3_XXS 27/496 19.2

微調整された実行

興味深いモデルと量子化については、VRAM をより効果的に利用するための特別な llama-cpp コマンドラインパラメータを検索して試みました。 私が達成できた結果は以下の通りです：

モデル コンテキスト GPU 上のレイヤー数 CPU/CPU 負荷 速度
Qwen3.5-27B-IQ4_XS.gguf 18k 65 98%/100% 38.0
Qwen3.5-27B-IQ4_XS.gguf 64k 53 33%/488% 15.7

16 GB VRAM ビルドの教訓

  • 現在の私の最爱の Qwen3.5-27B-UD-IQ3_XXS は、スイートスポットである 50k コンテキストで良好な結果を示しています（約 36t/s を得ています）。
  • Qwen3.5-122B-A10B-UD-IQ3_XXS は、64K 以上のコンテキストにおいて、Qwen3.5 27B をパフォーマンス面で凌駕しています。
  • Qwen3.5-35B-A3B-UD-IQ3_S は 10 万トークンのコンテキストを処理できるよう押し上げることができ、VRAM に収まるため、パフォーマンスの低下はありません。
  • 16GB VRAM では gemma-4-31B は使用しません。gemma-4-26B は「まあまあ」かもしれませんが、テストが必要です。
  • Nemotron cascade 2 と GLM-4.7 Flash REAP 23B がどの程度機能するかテストする必要があります。Qwen3.5-35B q3 よりも優れているでしょうか？疑わしいですが、それでも疑念を確認するためにテストするかもしれません。