llama.cppは、ローカル環境で大規模言語モデル(LLM)を高速に動かすためのC/C++製推論エンジンです。Ollama、LM Studio、KoboldCpp、text-generation-webuiといった人気ツールの内部エンジンとしても採用されており、ローカルLLM界隈の事実上の中核ライブラリになっています。本記事では、2026年5月時点の最新版b9085をベースに、llama.cppのインストールからGGUFモデルの量子化、llama-serverによるOpenAI互換APIの構築、CUDA/Vulkan/ROCm/Metalによるアクセラレーション、Q4_K_MやQ5_K_Mといった量子化形式の使い分けまで、運用に必要な情報を1記事で完結する決定版として整理しました。
本記事の最終更新は2026年5月時点(リリースタグ b9085 / 2026年5月9日リリース)です。llama.cppは1日に十数本の頻度でリリースが続くプロジェクトのため、新機能はマージ直後から記事に反映するように調査しています。
- llama.cppとは何か
- 2026年最新リリース情報
- 他のローカルLLM推論ツールとの比較
- llama.cppのメリット・デメリット
- 動作要件
- インストール手順
- 初期設定とモデルの入手
- 基本的な使い方
- 実践的な使い方
- 応用・カスタマイズ
- パフォーマンス最適化
- よくあるエラーとトラブルシューティング
- エラー1: error loading model: unable to allocate backend buffer
- エラー2: llama_model_load: error loading model: tensor 'XXX' has wrong shape
- エラー3: CUDA error: out of memory
- エラー4: 日本語が文字化けする / おかしな繰り返しが出る
- エラー5: libcuda.so.1: cannot open shared object file (Linux)
- エラー6: 推論速度が異常に遅い(CPUで動いている可能性)
- エラー7: error: invalid option '-hf'
- おすすめの組み合わせ・連携
- 推奨PCスペック(2026年5月時点)
- まとめ
- 📦 この記事で紹介した商品
llama.cppとは何か
llama.cppは、Georgi Gerganov氏(GitHub ID: ggerganov)が2023年3月に公開したC/C++実装のLLM推論エンジンです。当初はMeta社のLLaMAモデルをMacBookで動かすことを目的に書かれましたが、現在ではggml-org組織に移管され、LLaMA系列以外の数十のモデルアーキテクチャに対応する汎用推論エンジンへと進化しました。
llama.cppの基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | llama.cpp |
| 開発元 | ggml-org(Georgi Gerganov氏ほかコミュニティ) |
| ライセンス | MITライセンス |
| 初回リリース | 2023年3月 |
| 最新リリース | b9085(2026年5月9日) |
| 言語 | C / C++(GGMLライブラリベース) |
| 主要バックエンド | CUDA / Metal / ROCm / Vulkan / SYCL / Hexagon / CPU(BLAS) |
| 公式リポジトリ | github.com/ggml-org/llama.cpp |
llama.cppでできること
- LLaMA 2 / LLaMA 3 / Mistral / Mixtral / Qwen / Phi / Gemma / Deepseek / Yi / Falcon / StableLM / Mamba / Grok-1 など主要なオープンモデルのローカル実行
- LLaVA / BakLLaVA / ShareGPT4V / Qwen2-VL などのマルチモーダル(画像入力)モデルの実行
- 1.5bit〜8bitまでの整数量子化(Q4_K_M、Q5_K_M、Q8_0、IQ2、IQ3など)
- HuggingFaceで配布されているSafeTensorsモデルからGGUF形式への変換
- OpenAI互換APIサーバ(llama-server)によるバックエンド構築
- llama-cliによる対話型実行と文法制約(GBNF)に基づく構造化出力
- スペキュレーティブデコーディングによる推論高速化
- マルチGPUテンソル並列(2026年4月以降のbuild b8738以降で対応)
なぜllama.cppがローカルLLMの中核なのか
OllamaやLM Studio、KoboldCppといった有名なフロントエンドは、内部の推論エンジンとしてllama.cppまたはそのフォークを利用しています。つまり、これらのツールで使えるGGUF形式のモデルは、すべてllama.cpp由来です。llama.cppを直接扱えるようになると、フロントエンドに依存せず最新機能を即座に試せるうえ、コマンドライン1本で動かせるためサーバー運用やDocker化も容易になります。
2026年最新リリース情報
llama.cppはほぼ毎日リリースタグが切られる超高速開発プロジェクトです。2026年4月だけで170以上の増分リリースが行われ、ローカルLLMに直結する大きな機能が次々と追加されています。最新版であるb9085(2026年5月9日)と、ここ数か月の主要アップデートを時系列で整理します。
2026年5月の主な更新
- b9085(2026-05-09): MiMo-V2.5モデル向けにフラッシュアテンションのMMA(Matrix Multiply Accumulate)/Tilesカーネルを追加(d_kq=192、d_v=128対応)
- b9084(2026-05-09): Qualcomm HexagonバックエンドにGated Delta Net演算のHTMカーネルを実装。PP(Prefill)とTG(Token Generation)の両パスで最適化
- b9082(2026-05-08): Hexagonバックエンド向けにL2_NORM(L2正規化)のHVXカーネルを追加
- b9080(2026-05-08): Gemma4_26B_A4B_NVFP4モデルのGGUF変換に対応
2026年4月の主な更新
- テンソル並列の正式対応(build b8738): 複数GPU間でレイヤーを分割するパイプライン並列ではなく、各GPUがすべてのトークン生成に参加するテンソル並列を導入。NVIDIA以外のGPUでも動作するベンダー非依存実装
- 1ビット量子化(Q1_0): 究極的に制約のあるエッジデバイス向けの1ビット量子化を追加。エッジAIや組込み用途を想定
- Gemma 4 day-one対応: 2026年4月2日のGoogle Gemma 4リリース当日にビジョン入力とMoEを含む全バリアント(E2B、E4B、26B MoE、31B Dense)に対応
- Qualcomm Hexagon NPU対応(build b8755、4月11日): Snapdragon搭載ノートPCやエッジデバイスのHexagon NPUバックエンドをLinuxで正式サポート
- AMD CDNA4対応(build b8739、4月9日): AMD Instinct MI350X/MI355Xの新しいMFMA命令にチューニングしたカーネルを追加
過去バージョンからの破壊的変更
- 2024年に廃止された旧convert.pyは、現在
convert_hf_to_gguf.pyに統合済み。旧スクリプト名でのドキュメントは無効 - サーバの起動コマンドはかつての
./serverから./llama-serverに統一済み(同様にmainはllama-cli、quantizeはllama-quantizeに変更) - サブモジュールとして同梱されていたGGMLは2024年にggml-org/ggmlとしてリポジトリ分離、現在は同じggml-org組織下で開発が続いている
最新の差分は公式リリースページで確認できます。GitHub Actionsで自動ビルドされたWindows / Linux / macOS用のプリビルドバイナリも各リリースから直接ダウンロードできるため、自前でビルドしたくない場合はそちらを推奨します。
他のローカルLLM推論ツールとの比較
2026年5月時点で、ローカルLLM推論の主要ツールは大きく分けて以下のような立ち位置になっています。すべて記事公開時点の最新メジャーバージョンで比較しました。
| 項目 | llama.cpp | Ollama | LM Studio | vLLM | KoboldCpp | text-generation-webui |
|---|---|---|---|---|---|---|
| 2026年5月時点バージョン | b9085 | v0.23.2 | 0.4.12 | v0.20.1 | v1.112.2 | v4.8 |
| ライセンス | MIT | MIT | プロプライエタリ(個人無料) | Apache 2.0 | AGPL 3.0 | AGPL 3.0 |
| UI | CLI / 内蔵Web UI | CLI / 公式GUI | デスクトップGUI | CLI / API中心 | Web UI | Web UI |
| モデル形式 | GGUF | GGUF(内部はllama.cpp) | GGUF / MLX | SafeTensors / HF | GGUF(llama.cppフォーク) | GGUF / SafeTensors / EXL2 |
| 強み | 軽量・高速・全機能アクセス | 1コマンド導入とモデル管理 | GUIで完結、初心者向け | 大規模並列推論、本番運用 | RP/小説特化、低スペック対応 | 複数バックエンド統合UI |
| 弱み | 初学者にはCLIの敷居 | カスタマイズ性が低め | クローズドソース | VRAM要求が高い、GGUF未対応 | 本流からは派生フォーク | 初期セットアップが重い |
| 推奨用途 | サーバ運用・実験・学習 | カジュアル利用・開発 | 個人ユース・モデル試用 | 本番API・高並列 | ロールプレイ・低VRAM | 多様なモデルを試したい人 |
llama.cppを直接使うべき人
- OllamaやLM Studio経由では使えない最新機能(テンソル並列、Hexagon NPU、新モデル対応など)を即座に試したい
- モデルのGGUF変換や量子化を自分で行いたい
- OpenAI互換APIサーバを軽量に立ててDockerで運用したい
- Raspberry PiやAndroid、Hexagon搭載デバイスなど特殊なハードで動かしたい
- GBNF文法による構造化出力を細かく制御したい
OllamaやLM Studioを選んだほうが良い人
- とにかくすぐにLLMを動かしたい(Ollamaが最速)
- GUI操作で完結させたい(LM Studio)
- モデルファイルの場所やバージョン管理を意識したくない
llama.cppのメリット・デメリット
メリット
- 純粋C/C++実装で依存が最小: PythonランタイムやCUDAライブラリの差異に振り回されにくい
- あらゆるハードウェアで動く: NVIDIA、Apple Silicon、AMD(ROCm)、Intel(SYCL/Vulkan)、Qualcomm(Hexagon)、CPU単体までカバー
- 軽量で高速: M2 MacBookで7Bモデルが30 tokens/sec前後、RTX 4060(8GB)で7B Q4_K_Mが80〜100 tokens/sec前後で動作
- GGUFという統一フォーマット: 一度GGUFに変換すれば、Ollama、LM Studio、KoboldCpp、text-generation-webuiでも同じファイルがそのまま動く
- OpenAI API互換サーバ標準搭載: 既存のOpenAI SDKコードをエンドポイントURLだけ差し替えてローカルに切り替え可能
- マルチモーダル対応: LLaVAやQwen2-VLなど、画像入力可能なモデルを公式対応
- 2025年以降は商用GPU(MI355X、Hexagon NPU)対応も活発
デメリット
- CLI中心で初学者にはハードルが高い: 内蔵Web UIはあるが、最初はコマンドラインの理解が必要
- SafeTensorsを直接読み込めない: HuggingFaceのモデルはGGUFに変換が必要(変換スクリプトは同梱)
- 本格的な高並列(数十並列以上)はvLLM等が有利: バッチ処理やKVキャッシュ最適化の点で本番向けにはvLLMが選ばれることも多い
- 更新が早すぎる: 1日10本以上のリリースが珍しくないため、追従するのが大変
- ドキュメントが分散している: README、docs/、Wiki、各ツールのREADMEが分かれており、検索の手間がある
動作要件
llama.cppはCPUだけでも動作するため、敷居は非常に低いツールです。ただし実用速度を出すにはGPU(またはApple Silicon)が現実的に必要です。
最小・推奨スペック
| 項目 | 最小(動くだけ) | 推奨(7B〜13B運用) | 本格(70B運用) |
|---|---|---|---|
| OS | Windows 10 / macOS 12 / Ubuntu 20.04 | Windows 11 / macOS 14 / Ubuntu 22.04 | Ubuntu 24.04 LTS |
| CPU | x86_64またはARM64の任意のCPU | AVX2対応 / 8コア以上 | AVX-512対応 / 16コア以上 |
| RAM | 8GB | 32GB | 128GB以上 |
| GPU | 不要(CPUのみ可) | VRAM 8GB以上(RTX 4060 / RX 7600以上) | VRAM 24GB以上 ×複数 |
| ストレージ | SSD 50GB | NVMe SSD 500GB以上 | NVMe SSD 2TB以上 |
| 想定モデルサイズ | 1B〜3B(Q4_K_M) | 7B〜13B(Q4_K_M / Q5_K_M) | 70B(Q4_K_M)、Mixtral 8x22B |
GPUベンダー別の対応バックエンド
| GPU | 推奨バックエンド | ビルドフラグ | 備考 |
|---|---|---|---|
| NVIDIA(GeForce / RTX / Tesla) | CUDA | -DGGML_CUDA=ON | 最も高速。CUDA 12.2以上推奨 |
| NVIDIA(複数GPU) | CUDA + テンソル並列 | -DGGML_CUDA=ON | 2026年4月以降公式対応 |
| Apple(M1/M2/M3/M4シリーズ) | Metal | (デフォルト有効) | 追加フラグ不要 |
| AMD Radeon(RDNA2以降) | ROCm / Vulkan | -DGGML_HIP=ON または -DGGML_VULKAN=1 | RX 7000シリーズはROCm 6.x推奨 |
| AMD Instinct MI300以降 | ROCm | -DGGML_HIP=ON | 2026年4月にCDNA4対応追加 |
| Intel Arc | SYCL / Vulkan | -DGGML_SYCL=ON | oneAPI 2025以降が必要 |
| その他(GPUベンダー横断) | Vulkan | -DGGML_VULKAN=1 | 幅広いGPUで動くが速度は中程度 |
| Qualcomm Snapdragon | Hexagon | -DGGML_HEXAGON=ON | 2026年4月以降のLinux対応 |
| GPU無し | CPU(BLAS/BLIS) | (デフォルト) | OpenBLASやIntel MKL併用で高速化 |
インストール手順
llama.cppには大きく分けて「プリビルドバイナリ版」と「ソースからのビルド」の2通りがあります。最新機能を試したいならソースビルド、すぐ動かしたいならプリビルドバイナリを推奨します。
プリビルドバイナリで導入(全OS共通・初心者推奨)
2026年現在、llama.cppは全リリースに対してWindows / Linux / macOS用のプリビルドバイナリをGitHub Actionsで自動公開しています。最も手軽な導入方法です。
- 公式リリースページを開く
- 最新タグ(b9085など)のAssetsから自分の環境に合うアーカイブをダウンロード
- Windows + NVIDIA:
llama-bXXXX-bin-win-cuda-x64.zip - Windows + CPU only:
llama-bXXXX-bin-win-cpu-x64.zip - Windows + Vulkan:
llama-bXXXX-bin-win-vulkan-x64.zip - macOS Apple Silicon:
llama-bXXXX-bin-macos-arm64.zip - Linux x86_64:
llama-bXXXX-bin-ubuntu-x64.zip
- Windows + NVIDIA:
- 任意のフォルダに展開
- 展開先で
llama-cli、llama-server、llama-quantizeなどが使える
Windows(CUDA)でソースビルド
NVIDIA GPUで最高速を狙う場合のビルド手順です。Visual Studio 2022 Communityの「C++によるデスクトップ開発」ワークロードと、CUDA Toolkit 12.x以上が事前に必要です。
# 1. リポジトリをクローン
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
# 2. ビルド用ディレクトリを作成し、CUDA有効でCMake構成
cmake -B build -DGGML_CUDA=ON
# 3. Releaseビルド(並列ビルドで高速化)
cmake --build build --config Release -j 8
# 4. 実行ファイルを確認
dir build\bin\Release\ビルドが成功すると、build\bin\Release\配下にllama-cli.exe、llama-server.exe、llama-quantize.exeなどが生成されます。
Windows(CPU only)でソースビルド
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build
cmake --build build --config Release -j 8macOS(Metal)でソースビルド
Apple SiliconではMetalがデフォルトで有効になり、追加フラグは不要です。Xcodeコマンドラインツールが事前に必要です(xcode-select --install)。
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build
cmake --build build --config Release -j $(sysctl -n hw.ncpu)Apple SiliconでGPUを意図的に無効化したい場合は、実行時に-ngl 0を指定することでCPU実行に切り替わります。
Linux(CUDA)でソースビルド
sudo apt install build-essential cmake git
# CUDA Toolkitのインストール(Ubuntu 22.04の場合)
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install cuda-toolkit-12-6
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j $(nproc)Linux(ROCm / AMD GPU)でソースビルド
AMD Radeon RX 6000/7000シリーズや、Instinct MI200/MI300/MI350シリーズで使う場合の手順です。GPU_TARGETSは使うGPU世代に合わせて指定します(RX 6800 XT/6900 XTならgfx1030、RX 7900 XT/XTXならgfx1100、MI300Xならgfx942)。
HIPCXX="$(hipconfig -l)/clang" HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build -DGGML_HIP=ON -DGPU_TARGETS=gfx1100
cmake --build build --config Release -j $(nproc)Linux(Vulkan / クロスベンダー)でソースビルド
NVIDIA / AMD / Intel問わず動作するVulkanバックエンドです。CUDAやROCmのインストールが面倒な場合や、Steam Deckのような環境で動かす場合に向いています。
sudo apt install libvulkan-dev glslc
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_VULKAN=1
cmake --build build --config Release -j $(nproc)Docker(Linux + NVIDIA)で利用
本番運用ならDocker版が最も再現性が高くおすすめです。公式コンテナはGHCRで配布されています。
docker run --rm --gpus all \
-v $(pwd)/models:/models \
-p 8080:8080 \
ghcr.io/ggml-org/llama.cpp:server-cuda \
-m /models/llama-3.1-8b-q4_k_m.gguf \
--host 0.0.0.0 --port 8080 -ngl 99初期設定とモデルの入手
llama.cppはGGUF形式のモデルファイルを直接読み込みます。GGUFはGGML派生のコンテナフォーマットで、テンソルデータとメタデータ(モデル名、コンテキスト長、トークナイザーなど)を1ファイルにまとめた形式です。
方法1: HuggingFaceから直接ダウンロード(2026年最新の推奨方法)
llama.cppは-hfオプションでHuggingFaceから直接GGUFモデルを引っ張ってこられるようになっています。以下のコマンド一発で動きます。
# 軽量モデルでお試し(Gemma 3 1B)
./llama-cli -hf ggml-org/gemma-3-1b-it-GGUF
# 7B級の実用モデル
./llama-cli -hf bartowski/Meta-Llama-3.1-8B-Instruct-GGUF
# サーバとして起動
./llama-server -hf ggml-org/gemma-3-1b-it-GGUF初回実行時にモデルが自動ダウンロードされ、デフォルトキャッシュ(~/.cache/llama.cpp)に保存されます。以降はキャッシュから読み込みます。
方法2: 既存のGGUFファイルをローカルに用意
HuggingFaceのモデルページ(例: bartowski氏の量子化リポジトリ)から.ggufファイルを直接ダウンロードして使うこともできます。
mkdir -p models
cd models
wget https://huggingface.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/resolve/main/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
# 起動
cd ..
./llama-cli -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p "こんにちは" -n 100方法3: 自分でGGUFに変換(中級者向け)
HuggingFaceで配布されているSafeTensors形式のオリジナルモデルを、自分でGGUFに変換するパターンです。
# 変換に必要なPython依存をインストール
pip install -r requirements.txt
# HuggingFaceからモデルをクローン(SafeTensors形式)
git lfs install
git clone https://huggingface.co/meta-llama/Meta-Llama-3.1-8B-Instruct models/llama-3.1-8b
# F16のGGUFに変換
python convert_hf_to_gguf.py models/llama-3.1-8b --outfile models/llama-3.1-8b-f16.gguf --outtype f16
# Q4_K_Mに量子化
./build/bin/llama-quantize models/llama-3.1-8b-f16.gguf models/llama-3.1-8b-q4_k_m.gguf Q4_K_M基本的な使い方
llama-cliによる対話実行
もっともシンプルな使い方はllama-cliです。プロンプトを与えてテキストを生成します。
# シンプルな1ショット生成
./llama-cli -m models/gemma-3-1b-it-q4_k_m.gguf -p "日本の首都を教えてください" -n 200 -ngl 99
# インタラクティブ対話モード
./llama-cli -m models/llama-3.1-8b-instruct-q4_k_m.gguf -cnv -ngl 99
# システムプロンプト指定
./llama-cli -m models/llama-3.1-8b-instruct-q4_k_m.gguf \
-cnv -ngl 99 \
-sys "あなたは日本語で簡潔に答えるアシスタントです"主要なllama-cliオプション
| オプション | 用途 |
|---|---|
-m PATH | GGUFモデルファイルのパス |
-p "TEXT" | プロンプト(1ショット) |
-cnv | 対話モード(チャット形式) |
-sys "TEXT" | システムプロンプト |
-n N | 生成する最大トークン数 |
-c N | コンテキスト長(0で自動) |
-ngl N | GPUへオフロードする層数(99で全層) |
-t N | CPUスレッド数 |
--temp X | サンプリング温度(0.0〜2.0) |
--top-p X | nucleus sampling閾値 |
--repeat-penalty X | 繰り返し抑制ペナルティ |
-fa | FlashAttentionを有効化(高速化) |
--jinja | Jinjaテンプレートでチャットフォーマット指定 |
llama-serverによるOpenAI互換APIサーバ起動
llama.cppにはOpenAI互換APIサーバが標準同梱されています。これがllama.cppの真の威力で、既存のOpenAI SDKコードをエンドポイントURLだけ差し替えてローカル実行に切り替え可能です。
# 最小起動(127.0.0.1:8080でリッスン)
./llama-server -m models/llama-3.1-8b-instruct-q4_k_m.gguf -ngl 99
# 公開IPで起動・APIキー認証付き
./llama-server -m models/llama-3.1-8b-instruct-q4_k_m.gguf \
--host 0.0.0.0 --port 8080 \
-ngl 99 -c 8192 \
--api-key "your-secret-key" \
-np 4起動後、ブラウザでhttp://localhost:8080にアクセスすると内蔵Web UIが表示されます。CLIで叩く場合は以下のように標準OpenAI APIフォーマットで通信できます。
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer your-secret-key" \
-d '{
"model": "local-model",
"messages": [
{"role": "system", "content": "あなたは日本語アシスタントです"},
{"role": "user", "content": "llama.cppとは?"}
],
"temperature": 0.7,
"max_tokens": 300
}'OpenAI Python SDKからの利用
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8080/v1",
api_key="your-secret-key"
)
response = client.chat.completions.create(
model="local-model",
messages=[
{"role": "user", "content": "C言語のメリットを3つ教えて"}
],
temperature=0.7,
max_tokens=500
)
print(response.choices[0].message.content)実践的な使い方
ユースケース1: 自前のRAG(検索拡張生成)バックエンドを構築する
llama-serverは埋め込み(embeddings)エンドポイントもOpenAI互換で提供しています。これを使うと、外部ベクターDB(Qdrant、Chromaなど)と組み合わせてフルローカルなRAGを構築できます。
# 埋め込み専用モデルでサーバを起動
./llama-server \
-hf nomic-ai/nomic-embed-text-v1.5-GGUF \
--embedding \
--port 8081 \
-ngl 99from openai import OpenAI
embed_client = OpenAI(base_url="http://localhost:8081/v1", api_key="dummy")
vector = embed_client.embeddings.create(
model="local-embed",
input="検索したい文章"
).data[0].embedding
print(len(vector)) # 768など、モデルにより異なるユースケース2: Visual Studio Codeのコード補完バックエンドにする
Continueなどの拡張機能はOpenAI互換APIをそのままバックエンドにできます。~/.continue/config.jsonを以下のように設定するだけです。
{
"models": [
{
"title": "Local llama.cpp",
"provider": "openai",
"model": "local-model",
"apiBase": "http://localhost:8080/v1",
"apiKey": "your-secret-key"
}
]
}ユースケース3: GBNF文法によるJSON強制出力
llama.cppはGBNF(GGML Backus-Naur Form)という独自文法で出力フォーマットを確定的に制約できます。
cat > person.gbnf <<'EOF'
root ::= "{" ws "\"name\":" ws string "," ws "\"age\":" ws number "}"
string ::= "\"" [a-zA-Zあ-んア-ン一-龥]+ "\""
number ::= [0-9]+
ws ::= [ \t\n]*
EOF
./llama-cli -m models/llama-3.1-8b-instruct-q4_k_m.gguf \
-p "田中さん35歳の情報をJSONで:" \
--grammar-file person.gbnf \
-n 100 -ngl 99これにより、出力が必ず指定スキーマの有効JSONになることが保証されます。リトライやバリデーションが不要になり、エージェント開発やツール呼び出しに極めて有用です。
応用・カスタマイズ
マルチGPUテンソル並列(2026年新機能)
2026年4月のbuild b8738以降、ベンダー非依存のテンソル並列が公式対応しました。例えばRTX 4090を2枚使う場合、--tensor-splitでVRAM配分を制御します。
./llama-server -m models/llama-3.3-70b-q4_k_m.gguf \
-ngl 99 \
--tensor-split 1,1 \
--main-gpu 0 \
--port 8080スペキュレーティブデコーディングで2〜3倍高速化
大きい本命モデル(例: 70B)と小さいドラフトモデル(例: 1B)を組み合わせ、ドラフトが先回りに予測した結果を本命が一括検証することで、スループットを大幅に上げる手法です。
./llama-server \
-m models/llama-3.3-70b-q4_k_m.gguf \
-md models/llama-3.2-1b-q4_k_m.gguf \
--draft-max 16 --draft-min 4 \
-ngl 99コンテキスト長の拡張(RoPEスケーリング)
長文を扱いたい場合、RoPEスケーリングで実効コンテキストを延ばせます。ただし精度低下とのトレードオフです。
./llama-server -m models/llama-3.1-8b-instruct-q4_k_m.gguf \
-c 32768 \
--rope-scaling linear --rope-freq-scale 0.5 \
-ngl 99マルチモーダル(画像入力)モデル
LLaVAやQwen2-VLのようなマルチモーダルモデルも--mmprojで投影モデルを併指定するだけで動きます。
./llama-server \
-hf ggml-org/Qwen2-VL-7B-Instruct-GGUF \
--mmproj-hf ggml-org/Qwen2-VL-7B-Instruct-GGUF \
-ngl 99パフォーマンス最適化
量子化形式の使い分け(Q4_K_M / Q5_K_M / Q8_0など)
2026年5月時点で、最も実用的な量子化形式の使い分けは以下の通りです。
| 量子化 | サイズ目安(7Bモデル) | 品質劣化(perplexity増加) | 推奨用途 |
|---|---|---|---|
| Q2_K | 2.6GB | 大(+0.5以上) | VRAM 4GBの極小環境のみ |
| IQ3_XS / IQ3_M | 3.0〜3.3GB | 中(+0.25前後) | importance matrix採用で品質維持 |
| Q4_K_M | 4.5GB前後 | 小(+0.18) | 万人向けの標準。8GB VRAMで快適に動く |
| Q5_K_M | 5.3GB前後 | 非常に小(+0.06) | 品質を重視する場合の標準 |
| Q6_K | 6.1GB前後 | ほぼ無し | F16の代替として精度ほぼ不変 |
| Q8_0 | 8.0GB前後 | ほぼ無し | 事実上のリファレンス品質 |
| F16 | 14GB前後 | 無し(原本) | 追加学習用途・ベンチ用 |
結論としては、「迷ったらQ4_K_M、品質重視ならQ5_K_M、ハイエンドGPUがあればQ6_KかQ8_0」が2026年時点のベストプラクティスです。Q1_0は2026年4月に追加された極限量子化で、エッジデバイス用途に限定されます。
FlashAttentionでさらに高速化
2024年以降、llama.cppにはFlashAttention実装が組み込まれています。FlashAttentionは推論を10〜30%高速化しつつVRAM使用量も削減します。2026年5月のb9085では、d_kq=192/d_v=128構成のMMA/Tilesカーネルが追加され、MiMo-V2.5などの非標準Attentionを持つモデルでも有効化可能になりました。
./llama-server -m models/llama-3.1-8b-instruct-q4_k_m.gguf \
-ngl 99 -faKVキャッシュの量子化
長文コンテキストではKVキャッシュがVRAMを圧迫します。これを量子化することで利用可能なコンテキスト長を倍増できます。
./llama-server -m models/llama-3.1-8b-instruct-q4_k_m.gguf \
-ngl 99 -fa \
--cache-type-k q8_0 --cache-type-v q8_0 \
-c 32768並列スロットによるバッチ処理
複数ユーザーから同時にAPIアクセスがある場合、-npで並列スロットを増やすとスループットが大幅に上がります。
./llama-server -m models/llama-3.1-8b-instruct-q4_k_m.gguf \
-ngl 99 -np 8 -c 16384よくあるエラーとトラブルシューティング
エラー1: error loading model: unable to allocate backend buffer
原因: GPUにオフロードしようとした層がVRAMに収まらない。
対処: -nglの値を下げる(例: 99 → 30)、または量子化レベルを下げる(Q5_K_M → Q4_K_M)。VRAM 8GBで7Bならcontext sizeを-c 4096程度に絞ると安定します。
エラー2: llama_model_load: error loading model: tensor 'XXX' has wrong shape
原因: モデルファイルとllama.cppのバージョンが古い、またはGGUFのバージョン不一致。
対処: llama.cppを最新版に更新するか、convert_hf_to_gguf.pyでモデルを再変換する。古いconvert.pyで作ったGGUFは2026年現在動作しないことが多いです。
エラー3: CUDA error: out of memory
原因: 同一GPU上で他プロセスがVRAMを占有している。
対処: 他のCUDAアプリ(Stable DiffusionやChromeのGPU加速)を終了する。nvidia-smiで占有プロセスを確認できます。あるいは--main-gpuで別GPUを指定。
エラー4: 日本語が文字化けする / おかしな繰り返しが出る
原因: チャットテンプレートの不一致、またはトークナイザーの不整合。
対処: --jinjaを有効化してJinjaテンプレートでフォーマットする。または--repeat-penalty 1.1程度を指定。Llama 3系モデルでは公式チャットテンプレートを使うと文字化けが解消することが多いです。
エラー5: libcuda.so.1: cannot open shared object file (Linux)
原因: NVIDIAドライバがインストールされていない、またはLD_LIBRARY_PATHの設定不備。
対処: nvidia-smiでドライバを確認。sudo ldconfigを実行、またはexport LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATHを追加。Docker利用時は--gpus allとnvidia-container-toolkitのインストールが必要です。
エラー6: 推論速度が異常に遅い(CPUで動いている可能性)
原因: -nglが0、もしくはCUDAなしでビルドされている。
対処: 起動時のログにllm_load_tensors: offloaded N/N layers to GPUと表示されているか確認。表示されない場合はビルド時のフラグ(-DGGML_CUDA=ONなど)が抜けています。./llama-cli --versionでビルド情報を再確認します。
エラー7: error: invalid option '-hf'
原因: 古いllama.cppバージョンを使っている。
対処: HuggingFace直接ダウンロード機能は2024年後半に追加された機能のため、最新のリリース(b9000以降)に更新してください。
おすすめの組み合わせ・連携
Ollamaとの併用
OllamaはモデルのバージョンマネージャやModelfileによるカスタマイズが優秀ですが、内部エンジンはllama.cppです。カジュアル利用はOllama、最新機能の検証はllama.cppという棲み分けが現実的です。Ollamaが未対応の最新モデルは、llama.cppのGGUFを~/.ollama/models/blobs/に手動でリンクすることで認識させる裏技もあります。
LM Studioとの併用
LM Studio 0.4.12はモデル探索GUIが優秀で、HuggingFaceのモデル一覧から直接ダウンロードできる利便性があります。LM Studioで動作確認してから、本番運用としてllama.cppでサーバ化、というワークフローが安定します。
Open WebUIとの連携
llama-serverのOpenAI互換APIをそのままOpen WebUIのバックエンドに指定できます。ChatGPT風の高機能UIをローカルで完結したい場合の鉄板構成です。
Continue / Aider / LangChainとの連携
すべてOpenAI互換APIに対応しているため、OPENAI_API_BASE=http://localhost:8080/v1を環境変数で設定するだけでローカルLLMに切り替わります。Aiderでローカルコーディングエージェントを動かす場合も同様です。
Difyとの連携
RAGアプリケーションプラットフォームのDifyは、OpenAI互換LLMプロバイダ設定からllama-serverをそのまま登録できます。フルローカルRAGの構築が30分で完成する組み合わせです。
推奨PCスペック(2026年5月時点)
llama.cppで動かしたいモデルサイズに応じて、3段階の推奨構成を整理しました。GPUは消費電力と価格のバランスが取れた現行モデルを基準にしています。
入門構成: 1B〜8Bモデルを快適に動かす
| パーツ | 推奨 | 備考 |
|---|---|---|
| CPU | Ryzen 5 7600 / Core i5-13400以上 | AVX2必須 |
| GPU | RTX 4060 / RTX 4060 Ti(8GB / 16GB) | VRAM 8GBで7B Q4_K_Mが快適 |
| RAM | 32GB DDR5(2枚組) | OS + モデル + 余裕 |
| SSD | 1TB NVMe SSD | モデル数本を持ち回せる |
| 電源 | 650W 80PLUS Gold | 余裕を持って |
| 想定用途 | 個人用チャットボット、軽量RAG、学習用 | 速度: 7B Q4_K_Mで80〜100 t/s前後 |
標準構成: 13B〜32Bモデルや軽量MoEを動かす
| パーツ | 推奨 | 備考 |
|---|---|---|
| CPU | Ryzen 7 7700X / Core i7-14700 | マルチスレッド有効 |
| GPU | RTX 4070 Ti SUPER(16GB) | 13B Q5_K_Mが快適、32Bも条件付きで可 |
| RAM | 64GB DDR5 | 大きいモデルでCPUオフロード時に有利 |
| SSD | 2TB NVMe SSD | 複数モデルの併存に必須 |
| 電源 | 850W 80PLUS Gold | 余裕構成 |
| 想定用途 | 本格チャット、コード補完、エージェント | 13B Q5_K_Mで45〜60 t/s前後 |
ハイエンド構成: 70B以上のフラッグシップモデル
| パーツ | 推奨 | 備考 |
|---|---|---|
| CPU | Threadripper 7960X以上 | 大量メモリ帯域 |
| GPU | RTX 5090(32GB) ×2 または RTX 6000 Ada | テンソル並列で70Bフルオフロード |
| RAM | 128GB DDR5 ECC | Mixtral 8x22Bの一部CPU実行用 |
| SSD | 4TB NVMe SSD(Gen5) | 大量GGUF格納 |
| 電源 | 1600W 80PLUS Platinum | 2GPU構成想定 |
| 想定用途 | 本格的な業務利用、研究、エージェント運用 | 70B Q4_K_Mで30〜40 t/s前後 |
なお、Apple Siliconの場合はM2/M3/M4 Max(64GB〜128GBユニファイドメモリ)がコストパフォーマンスに優れます。70B Q4_K_Mが20〜30 t/sで動き、消費電力も低い点で本格構成にも耐えうる選択肢です。
まとめ
llama.cppは2023年の登場以来、ローカルLLMという領域そのものを牽引してきたツールです。2026年5月時点の最新版b9085では、Hexagon NPU、AMD CDNA4、テンソル並列、1ビット量子化など、数か月前には想像もできなかった機能が次々と本流に入ってきています。
本記事の要点を改めて整理します。
- llama.cppはMITライセンスのC/C++製ローカルLLM推論エンジン。Ollama、LM Studio、KoboldCpp、text-generation-webuiの多くも内部はllama.cpp
- 導入はプリビルドバイナリが最速、最新機能を使うならソースビルド(
cmake -B build -DGGML_CUDA=ON) - HuggingFaceから
-hfオプションでGGUFモデルを直接実行可能 - llama-serverはOpenAI互換APIをそのまま提供。既存SDKコードをURLだけ差し替えてローカル化
- 量子化はQ4_K_Mが万人向けの標準、品質重視ならQ5_K_M
- 2026年の新機能はテンソル並列、Hexagon NPU、Gemma 4 day-one対応、AMD CDNA4対応
- 本格運用にはVRAM 16GB以上、エッジ用途ならMacBook M2 Maxが現実解
こんな人にllama.cppはおすすめ
- OllamaやLM Studioでは満足できず、最新モデルや最先端機能を即座に試したい
- OpenAI互換APIをローカルに立てて自社サービスに組み込みたい
- Raspberry PiやSnapdragon、Apple Siliconなど多様なハードで動かしたい
- GBNF文法による構造化出力で、エージェント開発の信頼性を上げたい
- RAG / Continue / Aider / Difyのバックエンドをフルローカルで自前運用したい
逆に向かないケース
- とにかくGUI操作で完結させたい(LM Studioを推奨)
- 1コマンドでモデルを切り替えたい(Ollamaを推奨)
- 本番で数十並列の高スループットが必要(vLLMを検討)
llama.cppは公式ロードマップ上、今後も新ハードウェアへの対応(Apple M5、Intel Battlemage、Qualcomm次世代Hexagonなど)と推論最適化(Speculativeデコーディングの強化、KVキャッシュ最適化、より積極的な量子化形式)が中心となる見込みです。2026年に新しくローカルLLM環境を組むなら、まずllama.cppを直接触れるようになっておくことが、今後どのフロントエンドが流行っても潰しが効く最も賢い投資と言えます。
本記事をブックマークして、新リリースが出るたびに該当セクションを参照してください。公式リリースページと公式リポジトリを併せてウォッチしておくことをおすすめします。
📦 この記事で紹介した商品
- 大規模言語モデル入門 → Amazonで見る
- NVIDIA GeForce RTX 4070 Ti SUPER → Amazonで見る
- crucial 32GB Kit (2x16GB) DDR5-5600 SODIMM CL46(16Gbit) CT2K16G56C46S5 : Comp… → Amazonで見る
- AMD Ryzen 7 7700X Desktop Processor – アマゾン → Amazonで見る
- TB NVMe SSD → Amazonで見る
※ 上記リンクはAmazonアソシエイトリンクです。購入いただくと当サイトに紹介料が入ります。
