llama.cppの推奨スペック — 何が動くかをデータで確認する（2026年10月）
ローカルLLMの土台。OllamaもLM Studioも内部でこれを使う
どんなツールか
C++で書かれたローカル推論エンジンで、GGUF形式のモデルを動かします。OllamaとLM Studioはどちらもこれを内部で使っているため、実質的にローカルLLMの標準実装です。コマンドラインで細かく制御でき、KVキャッシュの量子化、GPUに載せる層数、バッチサイズなどを自分で調整できます。当サイトが速度推定の補正に使っている公開ベンチマークも、このツールの `llama-bench` によるものです。
動作に必要なもの
ビルド済みバイナリが配布されているので、コンパイルは必須ではありません。CUDA、Metal、Vulkan、ROCmなど複数のバックエンドがあり、GPUの種類に応じて選びます。ツール自体は軽量で、消費するメモリはほぼモデル分だけです。
機種別に何本のモデルが動くか
当サイト収録の204モデルのうち、4bit以上の量子化でメモリに収まる数です。llama.cppが使うのはGGUF形式なので、この数字がそのまま「llama.cppで動くモデル数」になります。
| 機種 | メモリ | 動くモデル | 快適に動く | この機種で動く最大 |
|---|---|---|---|---|
| GeForce RTX 5060 | 8GB | 87 / 204 | 87 | Nemotron Nano 12B v2（12.31B） |
| GeForce RTX 5070 | 12GB | 100 / 204 | 100 | ABEJA Qwen3 14B Agentic（14.77B） |
| GeForce RTX 5070 Ti | 16GB | 111 / 204 | 111 | Qwen3.8 27B（27.32B） |
| GeForce RTX 4090 | 24GB | 158 / 204 | 158 | Seed-OSS 36B（36.15B） |
| GeForce RTX 5090 | 32GB | 162 / 204 | 162 | Kimi Linear 48B-A3B（49.12B） |
| Apple M4（24GB） | 24GB | 118 / 204 | 43 | North Mini Code 1.0（30.48B） |
| Apple M4 Pro（48GB） | 48GB | 163 / 204 | 112 | Kimi Linear 48B-A3B（49.12B） |
| Apple M4 Max（128GB） | 128GB | 188 / 204 | 139 | Step-3.7-Flash（196.96B） |
| 一般的なデスクトップ/ノートPC（DDR5-5600・GPUなし）（メモリ32GB） | 32GB | 158 / 204 | 13 | Seed-OSS 36B（36.15B） |
手持ちのPCで判定すると、あなたの機種で動くモデルの一覧と推定速度が出ます。
導入と、最初に詰まるところ
配布されているビルド済みバイナリを使うか、自分でビルドします。ここで重要なのは、CUDA版・Metal版・Vulkan版といったバックエンドの違いで、環境に合わないものを取ると GPU が使われません。NVIDIA なら CUDA 版、Apple Silicon なら Metal 版、AMD や Intel の GPU なら Vulkan 版が素直です。
自分でビルドする場合も、対応するフラグを立て忘れるとCPUだけで動く状態になります。GPUが使われているかどうかは、起動時のログに出る層の割り当てを見れば分かります。
最初の30分でやること
- 環境に合うバックエンド（CUDA / Metal / Vulkan）のビルドを用意する
- GGUFファイルを1つ用意する。Hugging Faceから直接取得できる
- 起動して、ログでGPUに割り当てられた層数を確認する。ここが0なら、バックエンドが効いていない
- GPUに載せる層数、コンテキスト長、スレッド数を順に調整して、速度の変化を見る
- 外から呼び出す予定があるなら、付属のサーバを起動してエンドポイントを確認する
つまずきやすい点
- KVキャッシュをq8_0に量子化すると、長いコンテキストで必要なメモリがおおむね半分になります。品質への影響は小さいとされます
- GPUに載せる層数（-ngl）を調整すると、VRAMに収まらないモデルも部分的にGPUで動かせます
- フラッシュアテンションを有効にすると、長いコンテキストでメモリと速度が改善します
- モデルの入手は自分で行います。Hugging Faceから対象の量子化ファイルをダウンロードしてください
速度が出ないときに見る場所
調整できる項目が多いぶん、効くところもはっきりしています。GPUに載せる層数を指定するオプションが最も大きく、全層を載せられれば最速です。コンテキスト長は必要なぶんだけに絞ると、KVキャッシュの消費を抑えられます。KVキャッシュ自体を8bitに量子化するオプションもあり、長いコンテキストを扱うときに効きます。
CPU側で動かす場合はスレッド数が効き、物理コア数に合わせるのが基本です。バッチサイズはプロンプトの処理速度に効き、長い入力を投げる用途では調整の価値があります。
他のツールや自動化との組み合わせ
付属のサーバを起動すると、OpenAI互換のエンドポイントとして使えます。OllamaやLM Studioの内部で動いているのもこれで、直接使えばその上の層を挟まずに済みます。新しいモデル形式や量子化への対応も、ここが最も早い。GGUFの仕様そのものがこのプロジェクト由来なので、対応の起点になります。
よくあるエラーと対処
| 症状 | 見るところ |
|---|---|
| GPUが使われない | バックエンドの選択かビルドのフラグが合っていません。起動ログの層の割り当てを見れば判断できます |
| メモリ不足で落ちる | コンテキスト長を短くするか、KVキャッシュを8bitに量子化します。それでも足りなければ量子化を1段落とします |
| モデルが読み込めない | GGUFの仕様が更新されていることがあります。ビルドを新しくするか、モデル側の再変換版を探しましょう |
| CPUだけで遅い | スレッド数が物理コア数と合っていない可能性があります。論理コア数まで上げても速くならないことが多い箇所です |
乗り換えを考えるとき
手軽さを求めるなら Ollama か LM Studio に戻るのが正解です。オプションが多いことは、決めるべきことが多いことでもあります。このツールが向くのは、速度を詰めたい、新しいモデルを公開直後に試したい、組み込み先の制約が厳しい、といった場面です。
他のツールと比べる
| ツール | 向いている使い方 |
|---|---|
| Ollama | コマンド1行でローカルLLMを動かす。他のツールから呼び出す用途の定番 |
| LM Studio | 画面で操作するローカルLLM。モデル探しから会話まで完結する |
| llama.cpp（このページ） | ローカルLLMの土台。OllamaもLM Studioも内部でこれを使う |
| ComfyUI | ノードをつないで画像・動画生成を組み立てる。VRAM管理が細かい |
| Stable Diffusion WebUI（AUTOMATIC1111 / Forge） | 画像生成の定番インターフェース。決まった手順で描くなら最短 |
よくある質問
OllamaやLM Studioとの違いは？
同じエンジンを、コマンドで直接使うか、包んだツールで使うかの違いです。細かい調整をしたい、あるいは自動化に組み込みたい場合はllama.cppを直接使います。
ビルドは必要ですか？
公式にビルド済みのバイナリが配布されているため、多くの場合は不要です。特殊な最適化を入れたい場合だけ自分でビルドします。
OllamaやLM Studioと動くモデルは同じですか
同じです。どちらも内部でllama.cppを使っており、扱うのはGGUF形式のファイルです。違うのは操作の手数と、新しい機能が使えるようになる時期で、llama.cppを直接使うほうが早く対応が入ります。当サイトの必要メモリと推定速度も、このllama.cppでの動作を前提に計算しています。
ビルドは自分でやる必要がありますか
必須ではありません。主要な環境向けにビルド済みのバイナリが配布されています。自分でビルドする理由があるとすれば、特定のバックエンドを有効にしたい、最新のコミットを試したい、といった場面です。まず配布版で動くかを確かめて、必要になってから自分でビルドする順番で構いません。