最近話題の国産LLM「llm-jp-4-32b-a3b」をローカル環境で動かしてみました。このモデルはMoE（Mixture of Experts）という構造のおかげで、非常に高速かつ高性能です。
今回は、私のPC環境で「GPUオフロード（--gpu-layers）」の設定値を変えることで、生成速度（tok/s）がどう変化するのかを検証しました。
環境
- OS: Microsoft Windows 11 Home (x64)
- CPU: Intel Core Ultra 7 265F
- GPU: NVIDIA GeForce RTX 5070 Ti (VRAM 16GB)
- RAM: DDR5 32GB 5600 MT/s
- モデル: llm-jp-4-32b-a3b-thinking-Q4_K_M.gguf
なぜGPUレイヤー設定が重要なのか？
llama.cppの --gpu-layers オプションは、モデルの計算処理を「CPUで行うか、GPUで行うか」を決定します。
- 少ない場合: CPUがメインで計算するため、メモリ帯域に依存し、速度が伸び悩む（またはCPU負荷が激増する）
- 最適値: GPUにモデルを載せることで、GPUの高速な演算器とメモリ帯域をフル活用し、速度が劇的に向上する
検証方法
以下のコマンドで、GPUレイヤーの数値を 10, 20, 30 と変更して比較しました。
.\llama-server.exe -m [モデルパス] -c 4096 --gpu-layers [数値]
※計測は、出力されたログの eval rate = XX tok/s を採用しました。
プロンプトはすべて同じものを使用します。
検証結果
| GPUレイヤー数 | 生成速度 (tok/s) | 備考 |
|---|---|---|
| 10 | 27.78 | 速い |
| 20 | 45.88 | GPUの恩恵が出た |
| 30 | 6.98 | 遅くなった！ |
私の環境では20が最適でしたが、この数値はモデルの量子化サイズやモデル自体のパラメータ数に依存します。
学びと気づき
今回の検証で分かったことは以下の通りです：
-
「専用メモリ」と「共有メモリ」の壁
GPUのレイヤー数が多ければ多いほどVRAMの消費量が増えて、結果的に共有メモリまで侵食していました。その結果、速度の低下が起きたようです。
ハードウェアの限界（VRAM容量）と、処理のオーバーヘッド（メモリ転送コスト）の境界線を見極めることがとても重要だとわかりました。 -
CPUとGPUをどっちも使う
私の環境では、GPUにすべてを任せるのではなくCPUとGPUを一緒に推論させることでよい結果を得ることができました。
まとめ
もしあなたがローカルLLMを動かしていて『遅いな』と感じたら、単にモデルを小さくするのではなく、ぜひ --gpu-layers を少しずつ調整し、自分のPCのVRAM容量と相談してみてください。あなたの環境にとっての『黄金比』を見つけた瞬間、ローカルLLMの世界がもっと面白く開けるはずです！