ローカルLLMを動かす llama.cpp 入門

はじめに

ローカルでLLMを動かす方法を調べていると、Ollamaと並んで「llama.cpp」という名前をよく見かけます。

llama.cppは、手元のPCやサーバーでモデルを推論するためのC/C++製ソフトウェアです。CPUだけで動かすことも、GPUを使って速度を上げることもできます。端末から試すだけでなく、HTTP APIとして起動すれば、Webアプリや他のサービスから呼び出せます。

この記事では、llama.cppの役割、GGUFと量子化、GPUの使い方、Dockerでの起動方法を順に整理します。Ollamaとの違いも、使い分けの目安がわかる範囲で触れます。

llama.cppは「モデル」ではなく「実行エンジン」

llama.cppはLLMそのものではありません。モデルファイルを読み込み、文章を生成するための推論エンジンです。

名前にLlamaとありますが、MetaのLlama専用という意味ではありません。GGUF形式に変換され、llama.cppが対応しているモデルであれば、Llama以外のモデルも実行できます。対応するモデルの種類は増え続けているため、使いたいモデルの配布元に「llama.cpp対応」「GGUF」と書かれているか確認するのが確実です。

土台になっているggmlは、CPUやGPUなどでテンソル計算を行うライブラリです。llama.cppはその上に、モデルの読み込みやトークン処理、推論、CLI、APIサーバーなどを用意しています。

ggmlは、機械学習の計算を行うための低レベルライブラリです。テンソル演算などの基本処理を、CPUやGPUといった異なる環境で動かせるようにします。llama.cppは、このggmlを土台にしてLLMを実行します。
名前が似ていて混同しやすいですが、ggmlは計算ライブラリ、GGUFはモデルを保存するファイル形式です。現在のllama.cppでは、モデルは主に.ggufファイルで扱います。GGUFは、以前使われていたGGMLなどのモデル形式の後継として設計されました。
たとえるなら、ggmlが「計算を動かす仕組み」、GGUFが「モデル本体を入れたファイル」、llama.cppが「それらを使って文章を生成する実行ソフト」です。

GGUFとは

llama.cppで使うモデルは、基本的にGGUF形式です。GGUFはモデルのテンソルデータとメタデータを保存するためのファイル形式で、モデル構造やトークナイザー、チャット用テンプレートなどの情報を含められます。

モデル配布元がHugging Faceなどで提供するsafetensors形式のモデルを使う場合、通常は次のような流れになります。

1. 元モデルをGGUFへ変換する
2. 必要なら量子化する
3. llama.cppに読み込ませて推論する

最初からGGUFで配布されているモデルなら、変換作業は必要ありません。ただし「GGUFなら何でも動く」というわけではなく、モデル構造が使っているllama.cppのバージョンで対応されている必要があります。ダウンロード前にモデルカードや配布ファイルを確認しておくと、形式違いや未対応で止まりにくくなります。

量子化でモデルを小さくする

元のモデルは、重みを高い精度で保持するためファイルサイズが大きくなりがちです。量子化は、重みをより少ないビット数で表し、ファイルとメモリの使用量を抑える方法です。

よく見る表記には、Q8_0、Q6_K、Q5_K_M、Q4_K_M、Q3_K_M、IQ系などがあります。数字が小さい量子化ほど小さくなる傾向がありますが、出力品質への影響も大きくなりやすく、方式によって速度も変わります。

形式の例	おおまかな使いどころ
Q8_0	サイズより品質を優先したいとき
Q6_K、Q5_K_M	Q4より品質を重視したいとき
Q4_K_M	サイズと品質のバランスを取りたいとき
Q3系、IQ系	メモリをさらに節約したいとき。品質と速度を実際に確認する

「Q4」は、モデルの全パラメーターが一律にちょうど4ビットになるという意味ではありません。実際にはテンソルごとに異なる量子化が使われることがあります。llama.cppの量子化ドキュメントにあるLlama 3.1 8Bの例では、Q4_K_Mのモデルファイルは約4.9 GBです。モデルや量子化方式によってサイズは変わります。

また、モデルファイルのサイズが、そのまま実行時に必要なVRAM量になるわけではありません。モデル本体に加えて、コンテキストを保持するKVキャッシュや計算用の領域も必要です。入力が長くなるほど、また同時に処理する会話数が増えるほど、メモリ使用量は増えます。

CPU・GPUで動かす

llama.cppの特徴のひとつは、特定のGPUだけに依存しないことです。CPU向けのSIMD最適化に加え、NVIDIA CUDA、AMD HIP、Apple Metal、Vulkan、Intel SYCLなどのバックエンドが用意されています。どのバックエンドを利用できるかは、インストール方法やビルド設定によります。

GPUを使う場合、モデルのレイヤーをVRAMへどれだけ載せるかを調整します。GPUに収まる範囲を増やせば速くなる傾向がありますが、VRAMを使い切ると起動に失敗したり、他の処理が不安定になったりします。モデルの一部をGPUに載せ、残りをCPUで処理することもできます。

推論速度を比べる場合は、モデル名だけでなく、量子化方式、コンテキスト長、GPUに載せたレイヤー数、同時処理数も揃えてください。これらが違うと、llama.cppと別のランタイムの比較が難しくなります。

Dockerでllama-serverを起動する

llama.cppには、端末から推論するCLIのほかに、HTTP APIを提供するllama-serverがあります。サーバーはWeb UIも備えており、OpenAI互換のチャットやEmbeddingなどのAPIを利用できます。

以下は、LinuxまたはWSL2上でNVIDIA GPUを使う場合の例です。DockerからGPUを使える状態になっていることと、GGUFモデルをカレントディレクトリのmodelsフォルダーに配置していることを前提にしています。

docker run --rm --gpus all \
  -p 127.0.0.1:8080:8080 \
  -v "$PWD/models:/models:ro" \
  ghcr.io/ggml-org/llama.cpp:server-cuda \
  -m /models/your-model.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  --ctx-size 4096 \
  --n-gpu-layers auto

your-model.ggufは実際のファイル名に置き換えます。初回はコンテナイメージの取得に時間がかかることがあります。モデルファイルはホスト側のmodelsフォルダーにあるため、コンテナを終了しても残ります。

ホスト側のポートを127.0.0.1に限定しているので、この例では同じPCから http://127.0.0.1:8080 でアクセスします。コンテナ内では、Dockerのポート転送を受けるためにサーバーを0.0.0.0で待ち受けさせています。

まずは生成APIで応答を確認できます。

curl http://127.0.0.1:8080/completion \
  -H "Content-Type: application/json" \
  -d '{"prompt":"水循環について、短く説明してください。","n_predict":128}'

llama-serverにはOpenAI互換のチャットAPIもあります。OpenAI互換クライアントから接続するときは、サーバーURLを http://127.0.0.1:8080/v1 に設定します。チャットAPI、Responses API、Embedding APIなど、使える機能はサーバーのバージョンとモデルによって確認してください。

NVIDIA GPUではなくCPUだけで試す場合は、CUDA用イメージではなく通常のserverイメージを使います。GPUを使いたいのに起動ログでCPUしか認識されていない場合は、DockerのGPU設定、ホスト側のNVIDIAドライバー、利用しているコンテナイメージを順に確認します。

ソースからビルドする方法

配布済みの実行ファイルやDockerイメージを使わず、自分の環境向けにビルドすることもできます。CUDAを使う場合の基本形は次のとおりです。

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

ビルドにはCMakeやC++コンパイラーに加え、CUDAを使う場合は対応するCUDA開発環境が必要です。環境ごとのオプションや依存関係は公式のビルド手順を確認してください。まず動かしてみたい段階なら、Docker版の方が準備する項目を減らせます。

Ollamaとはどう違うのか

Ollamaとllama.cppは、まったく別の推論技術という関係ではありません。Ollamaはモデルの取得・実行・管理をまとめた環境で、対応バックエンドのひとつとしてllama.cppを挙げています。Ollama自身もREST APIを提供しています。

一方、llama.cppを直接使うと、モデルファイルや起動オプション、GPUへの割り当て、サーバー設定を自分で調整しやすくなります。

	llama.cppを直接使う	Ollamaを使う
主な役割	推論エンジンとサーバーを直接動かす	モデルの取得・実行・管理をまとめる
モデルの扱い	GGUFファイルや起動オプションを指定する	CLIやAPIからモデル名で操作する
調整の細かさ	実行パラメーターを細かく設定しやすい	日常的な切り替えや管理がしやすい
向いている場面	性能測定、サーバー構築、動作の細かな調整	まずローカルLLMを手軽に使いたいとき

どちらが速いかは、実際に使うモデル、量子化、GPU、コンテキスト長などで変わります。名前だけで決めず、同じGGUFモデルと近い設定で試すのがおすすめです。

試すときに見ておきたいこと

ローカルで動いたかどうかだけでなく、次の項目を記録しておくと、設定を変えたときに比べやすくなります。

• モデル名とGGUFファイル名
• 量子化方式とファイルサイズ
• コンテキスト長
• GPUに載せたレイヤー数
• プロンプト処理と生成の速度
• 生成中のVRAM・RAM使用量
• 長い入力や複数リクエストでの安定性
• チャットテンプレートやツール呼び出しの動作

チャットモデルでは、モデルに合ったチャットテンプレートも重要です。テンプレートが正しく使われないと、会話の区切りやロール指定が崩れ、出力の質やツール呼び出しに影響することがあります。配布元が指示しているテンプレートと、GGUFに含まれるメタデータを確認してください。

また、画像や音声を扱えるモデルであっても、テキスト用のGGUFだけで動くとは限りません。モデルによっては画像・音声用の追加ファイル（mmprojなど）や、専用の起動方法が必要です。マルチモーダル機能はモデルごとに確認してから組み合わせます。

まとめ

llama.cppは、GGUF形式のモデルをローカルで推論するための実行エンジンです。CPUだけでも動かせますし、対応するGPUバックエンドを使えば一部または全体をGPUで処理できます。CLIでの確認からHTTP APIサーバーの構築まで、同じ仕組みを使って進められます。

量子化を使うとモデルを扱いやすいサイズにできますが、実行時にはコンテキストやKVキャッシュの分もメモリが必要です。まずは手元のVRAMに合う量子化モデルを選び、短めのコンテキストで起動して、メモリと速度を見ながら調整すると進めやすいです。

モデルを手軽に管理したいときはOllama、推論の設定やAPIサーバーを細かく触りたいときはllama.cppを直接使う。自分の用途に合わせて選べます。

次のステップへ

llama.cppを使ってプロトタイプのシステムを作成してみましょう。

参考資料

• llama.cpp 公式リポジトリ
• llama.cpp: モデルの入手と量子化
• llama.cpp: ビルド手順
• llama.cpp: Dockerでの実行
• llama.cpp: llama-serverの説明
• llama.cpp: 量子化ツール
• ggml: GGUF形式の説明
• Ollama 公式リポジトリ

---