llama.cpp｜ローカルLLM

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：モデル形式（safetensorsとGGUF）　|　原理：推論の実務（機械学習）

要点（結論先出し）

llama.cpp＝C/C++製の基盤推論エンジン。GGUFを、CPU・GPU・Apple Silicon と幅広いハードで、最小構成で動かす（要最新確認）。
強みはGPUオフロード：モデルの層を「GPUに何層・残りCPU」と分けて載せられ、VRAMが足りなくても巨大モデルを動かせる。
Ollama や LM Studio の多くが内部でこれを使う。直接叩けると最も細かく制御できる。

概念 ── 「最小構成で何でも動かす」基盤

llama.cpp は依存を抑えたC/C++実装で、GPUが無くてもCPUだけで動きます。対応バックエンド（CUDA・Metal・Vulkan等・要最新確認）を選んでビルドすれば、その環境で最適化された推論ができます。ローカルLLMの「下回り」の事実上の標準です。

主なコマンド（名称は更新が速い・要最新確認）：

llama-cli … 1回の対話・生成
llama-server … OpenAI互換APIサーバとして常駐 → OpenAI互換API
llama-quantize … 量子化（→ 量子化方式（k-quantsとGPTQとAWQ））

動くコマンド（最小例）

# GGUFを指定して1回生成（GPUに35層オフロード）
llama-cli -m ./models/model-Q4_K_M.gguf \
  -p "ローカルLLMとは何かを3行で。" \
  -ngl 35 -c 4096

# OpenAI互換サーバとして常駐（既存ツールから叩ける）
llama-server -m ./models/model-Q4_K_M.gguf \
  -ngl 35 -c 8192 --host 127.0.0.1 --port 8080

-ngl（number of GPU layers）が肝。-c はコンテキスト長で、増やすほどKVキャッシュが太る → コンテキスト長とKVキャッシュ。詳細手順は対応lab。

仕組み ── GPUオフロード（層分割）

flowchart LR
  G["GGUFの全レイヤー"] --> SPLIT["-ngl で分割"]
  SPLIT --> GPU["前半N層をVRAMへ（速い）"]
  SPLIT --> CPU["残りをRAM＋CPUで（遅い）"]
  GPU --> OUT["生成"]
  CPU --> OUT

-ngl を大きくするほどGPUが担当し速くなりますが、VRAMを食います。VRAMに収まる最大の -ngl を探すのが基本チューニング。全層載ればCPUオフロードは不要です。

運用の勘所

-ngl を上げてVRAMが溢れる直前が最速点。OOMしたら1段戻す。
量子化（Q4_K_M）と -ngl の合わせ技で「載らないはずのモデル」を動かす → オフロードと量子化でメモリに収める
速度・対応バックエンドはビルド設定とバージョン依存。要最新確認。

なぜそうするか

llama.cpp が基盤として強いのは、ハードを選ばず、層単位でメモリと速度をトレードできるから。これにより「VRAMちょうどに収める」細かな調整ができ、家庭用ハードの限界を押し広げられます。Ollamaの手軽さの裏にあるのもこの柔軟性です。

⚠️ よくある落とし穴

-ngl を最大固定：VRAMを超えると遅くなるかOOM。実測で詰める。
コンテキスト長を盛りすぎ：-c を大きくするとKVでVRAMが急増。用途に合わせる。
CPUオンリーで巨大モデル：動くが遅い。量子化で軽くしてから。
コマンド名を暗記：main→llama-cli 等、名称は変わる。都度ドキュメント確認。

対応lab

local-llm-study/labs/llamacpp_quickstart.md … 入手・GGUF実行・サーバ常駐・-ngl調整。