llama.cpp を用いた 16 GB VRAM LLM ベンチマーク（速度とコンテキスト）

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

目次

ここでは、VRAM 16GB を搭載した GPU で動作する複数の LLM の速度を比較し、セルフホスティングに適したモデルを選択しています。

これらの LLM を llama.cpp で、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-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
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 負荷 を指します。 この列の値が低い場合、モデルは主に CPU で実行されており、このハードウェアでは十分な速度が得られていないことを意味します。このパターンは、GPU に収まるモデルの部分が少なすぎる場合や、コンテキストの処理がホスト（CPU）に押し戻される場合に観察される現象と一致します。

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

16GB 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 よりも優れているでしょうか？疑わしいですが、それでも疑念を確認するためにテストするかもしれません。