llama.cpp クイックスタート：CLIとサーバー

ローカル推論にllama.cppに何度も戻っています。Ollamaなどが抽象化している制御を直接手に入れられる上、動作も安定しています。GGUFモデルをllama-cliで対話的に実行したり、llama-serverでOpenAI互換のHTTP APIを公開したりするのが簡単です。

ローカル、セルフホスト、クラウドのアプローチの間でまだ迷っている場合は、まずこのピラガイドから始めることをお勧めします。 2026年のLLMホスティング：ローカル、セルフホスト、クラウドインフラの比較.

2026年にllama.cppが選ばれる理由

llama.cppは、以下の点に偏重した軽量な推論エンジンです。

• CPUおよび複数のGPUバックエンド間でのもたらす移植性
• 単一マシンにおける予測可能なレイテンシ
• ラップトップからオンプレミスノードまでの柔軟なデプロイ性

プライバシーとオフラインでの操作を重視する場合、実行フラグに対する決定的な制御が必要な場合、あるいはフルスタックなPython中心のスタックを実行せずに推論をより大きなシステムに組み込みたい場合に、その真価を発揮します。

また、後でスループットの高いサーバーランタイムを選択する場合でも、llama.cppの理解は有益です。例えば、GPUでの最大サービングスループットが目標である場合、以下のツールを使ってvLLMと比較することも検討したいでしょう。 vLLMクイックスタート：高性能LLMサービング そして、ツール選択をベンチマークするには以下を参照できます。 Ollama vs vLLM vs LM Studio: 2026年にLLMをローカルで実行する最良の方法は?.

特にOllamaをllama-serverとの代替案として比較検討している場合、2026年のllama.cppとOllama が、Ollamaを維持すべき時と直接llama.cppに移行すべき時の具体的なトリガーを伴う、専用のペアワイズ比較です。

Windows、macOS、Linuxでのllama.cppのインストール

利便性、移植性、最大のパフォーマンスのいずれを重視するかによって、実用的なインストール経路は3つあります。

パッケージマネージャーによるインストール

これが最も素早く「動作する状態にする」オプションです。

# macOSまたはLinux
brew install llama.cpp

# Windows
winget install llama.cpp

# macOS (MacPorts)
sudo port install llama.cpp

# macOSまたはLinux (Nix)
nix profile install nixpkgs#llama-cpp

ヒント：インストール後、ツールが存在することを確認してください：

llama-cli --version
llama-server --version

事前構築バイナリによるインストール

コンパイラなしでクリーンなインストールを行いたい場合は、llama.cppのGitHubリリースで公開されている公式の事前構築バイナリを使用してください。これらは通常、複数のOSターゲットと複数のバックエンド（CPUのみおよびGPU有効なバリアント）をカバーしています。

一般的なワークフロー：

# 1) OSとバックエンドに合ったアーカイブをダウンロード
# 2) 解凍する
# 3) 解凍したフォルダから実行

./llama-cli --help
./llama-server --help

正確なハードウェア用にソースからビルド

CPU/GPUバックエンドから最適なパフォーマンスを引き出したい場合は、CMakeを使ってソースからビルドしてください。

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# CPUビルド
cmake -B build
cmake --build build --config Release

ビルド後、バイナリは通常以下の場所に配置されます：

ls -la ./build/bin/

1コマンドでのGPUビルド

ハードウェアに合ったバックエンドを有効にします（例：CUDAとVulkan）：

# NVIDIA CUDA
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

# Vulkan
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release

Ubuntu 24.04 + NVIDIA GPU：完全なビルド手順

NVIDIA GPUを搭載したUbuntu 24.04では、ビルド前にCUDAツールキットとOpenSSLが必要です。以下にテスト済みのシーケンスを示します：

1. CUDAツールキット 13.1のインストール

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-ubuntu2404.pin
sudo mv cuda-ubuntu2404.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.1.1/local_installers/cuda-repo-ubuntu2404-13-1-local_13.1.1-590.48.01-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu2404-13-1-local_13.1.1-590.48.01-1_amd64.deb
sudo cp /var/cuda-repo-ubuntu2404-13-1-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-1

2. 環境にCUDAを追加（~/.bashrcに追記）：

# cuda toolkit
export PATH=/usr/local/cuda-13.1/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-13.1/lib64:$LD_LIBRARY_PATH

次にsource ~/.bashrcを実行するか、新しいターミナルを開きます。

3. OpenSSL開発ヘッダーのインストール（クリーンなビルドに必要）：

sudo apt update
sudo apt install libssl-dev

4. llama.cppのビルド（llama.cppクローンを含むディレクトリから、CUDAを有効にして）：

cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-mtmd-cli llama-server llama-gguf-split llama-embedding
cp llama.cpp/build/bin/llama-* llama.cpp

これにより、llama-cli、llama-mtmd-cli、llama-server、llama-embedding、およびllama-gguf-splitがllama.cppディレクトリに生成されます。

また、複数のバックエンドをコンパイルし、ランタイムでデバイスを選択することもできます。これは、同じビルドを heterogeneous なマシン群にデプロイする場合に便利です。

GGUFモデルと量子化の選択

推論を実行するには、GGUFモデルファイル（*.gguf）が必要です。GGUFは、モデルの重みとllama.cppなどのエンジンに必要な標準化されたメタデータがバンドルされた単一ファイル形式です。

モデルを取得する2つの方法

オプションA：ローカルGGUFファイルを使用

GGUFを./models/にダウンロードまたはコピーします：

mkdir -p models
# GGUFをmodels/my-model.ggufに配置

その後、パスで実行します：

llama-cli -m models/my-model.gguf -p "Hello! Explain what llama.cpp is." -n 128

オプションB：llama.cppがHugging Faceからダウンロード

モダンなllama.cppビルドは、Hugging Faceからダウンロードし、ファイルをローカルキャッシュに保持できます。これは、クイック実験には最も簡単なワークフローであることが多いです。

# モデルをHFからダウンロードしてプロンプトを実行
llama-cli \
  --hf-repo ggml-org/tiny-llamas \
  --hf-file stories15M-q4_0.gguf \
  -p "Once upon a time," \
  -n 200

また、リポジトリセレクタで量子化を指定し、ツールが対応するファイルを選択させることもできます：

llama-cli \
  --hf-repo unsloth/phi-4-GGUF:q4_k_m \
  -p "Summarize the concept of quantization in one paragraph." \
  -n 160

後に完全なオフラインワークフローが必要な場合、--offlineはキャッシュの使用を強制し、ネットワークアクセスを防ぎます。

ローカル推論のための量子化の選択

量子化は、「ローカル推論にどのGGUF量子化を選択すべきか」という問いに対する実用的な答えであり、品質、モデルサイズ、速度を直接的にトレードオフします。

実践的な出発点：

• CPUファーストのマシンではQ4またはQ5バリアントから始める
• RAMまたはVRAMに余裕がある場合、より高い精度（またはより激しくない量子化）に移行する
• モデルがタスクに対して「賢くない」ように感じるとき、修正策は多くの場合、より良いモデルまたはより激しくない量子化であり、サンプリング調整だけではありません。

また、コンテキストウィンドウの重要性を忘れないでください：GGUFファイル自体が収まっても、大きなコンテキストサイズはメモリ使用量（時には劇的に）を増やします。

llama-cliクイックスタートと主要パラメータ

llama-cliは、モデルがロードされること、バックエンドが動作すること、プロンプトが正しく動作することを検証する最速の方法です。

最小限の実行

llama-cli \
  -m models/my-model.gguf \
  -p "Write a short TCP vs UDP comparison." \
  -n 200

対話的なチャット実行

会話モードはチャットテンプレートのために設計されています。通常、対話的な動作を有効にし、モデルのテンプレートに従ってプロンプトをフォーマットします。

llama-cli \
  -m models/my-model.gguf \
  --conversation \
  --system-prompt "You are a concise systems engineering assistant." \
  --ctx-size 4096

モデルが特定のシーケンスを出力したときに生成を終了するには、リバースパrompt（逆プロンプト）を使用します。これは特に対話モードで有用です。

重要なllama-cli的主要フラグ

200ものフラグを暗記するのではなく、正しさ、レイテンシ、メモリを支配するものに注目してください。

モデルとダウンロード

コンテキストとスループット

GPUオフロードとハードウェア選択

サンプリングと出力品質

llama-cliによる例示的なワークロード

プロンプトだけでなくファイルの要約

llama-cli \
  -m models/my-model.gguf \
  --system-prompt "You summarize technical documents. Output five bullets max." \
  --file ./docs/incident-report.txt \
  -n 300

結果の再現性を高める

プロンプトをデバッグする際は、シードを固定し、ランダム性を減らします：

llama-cli \
  -m models/my-model.gguf \
  -p "Extract key risks from this design note." \
  -n 200 \
  --seed 42 \
  --temp 0.2

OpenAI互換APIによるllama-serverクイックスタート

llama-serverは、以下を公開できる組み込みHTTPサーバーです：

• チャット、コンプリティオン、エンベディング、レスポンスのためのOpenAI互換エンドポイント
• 対話的テストのためのWeb UI
• 本番環境の可視化のための任意のモニタリングエンドポイント

ローカルモデルでサーバーの起動

llama-server \
  -m models/my-model.gguf \
  -c 4096

デフォルトでは、127.0.0.1:8080でリッスンします。

外部にバインドする場合は（例えばDocker内やLAN内）、ホストとポートを指定します：

llama-server \
  -m models/my-model.gguf \
  -c 4096 \
  --host 0.0.0.0 \
  --port 8080

任意だが重要なサーバーフラグ

コンテナ内で実行する場合、多くの設定はLLAMA_ARG_*環境変数を通じて制御できます。

API呼び出しの例

curlによるチャットコンプリティオン

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer no-key" \
  -d '{
    "model": "gpt-3.5-turbo",
    "messages": [
      { "role": "system", "content": "You are a helpful assistant." },
      { "role": "user", "content": "Give me a quick llama.cpp checklist." }
    ],
    "temperature": 0.7
  }'

本番デプロイのヒント：--api-keyを設定した場合、x-api-keyヘッダー経由で送信できます（または、ゲートウェイに応じてAuthorizationヘッダーを继续使用してもよい）。

llama-serverを対象とするOpenAI Pythonクライアント

OpenAI互換のサーバーでは、base_urlを変更するだけで多くのクライアントが動作します。

import openai

client = openai.OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="sk-no-key-required",
)

resp = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "Explain threads vs batch size in llama.cpp."},
    ],
)

print(resp.choices[0].message.content)

エンベディング

OpenAI互換エンベディングは/v1/embeddingsで公開されますが、モデルはnoneでないエンベディングプーリングモードをサポートする必要があります。

curl http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer no-key" \
  -d '{
    "input": ["hello", "world"],
    "model": "GPT-4",
    "encoding_format": "float"
  }'

専用のエンベディングモデルを実行する場合、エンベディング専用モードでサーバーを起動することを検討してください：

llama-server \
  -m models/Qwen3-Embedding-0.6B-Q8_0.gguf \
  --embeddings \
  --host 127.0.0.1 \
  --pooling last \
  --port 8080

または、CPUでllama-cppとエンベディングモデルを実行したい場合：

CUDA_VISIBLE_DEVICES="" llama-server \
  -m models/Qwen3-Embedding-0.6B-Q8_0.gguf \
  --embeddings \
  --host 127.0.0.1 \
  --pooling last \
  --port 8080

以下のように試してください：

CUDA_VISIBLE_DEVICES="" llama-embedding \
  -m /path/to/Qwen3-Embedding-0.6B-Q8_0.gguf \
  -p "your text here" \
  --pooling last \
  --verbose-prompt

1つのプロセスからの複数モデルのサービング

上記の例では、llama-serverは起動時に単一のモデルにバインドされます。プロセスを再起動せずにリクエストごとにモデルを切り替えたい場合、それがラーターモードの用途です。 llama-serverラーターモード：再起動なしでの動的モデル切替 を参照してください。 ルーターを再起動せずにVRAMを解放するスクリプト可能なアンロード全フローについては、llama.cppルーターモデルを再起動なしで全アンロード を参照してください。

パフォーマンス、モニタリング、本番環境の強化

「llama.cppのコマンドラインオプションで速度とメモリにとって最も重要なのはどれか」というFAQの質問は、推論をシステムとして扱うことで、はるかに簡単になります：

• メモリ上限は通常、最初の制約です（CPUではRAM、GPUではVRAM）。
• コンテキストサイズは主要なメモリ乗数です。
• GPUレイヤオフロードは、より高いトークン/秒への最速経路であることが多いです。
• バッチサイズとスレッドはスループットを改善できますが、メモリ圧力も増加させる可能性があります。

より深く、エンジニアリングファーストの視点については、以下を参照してください： 2026年のLLMパフォーマンス：ベンチマーク、ボトルネックと最適化.

16 GBクラスGPUでのllama-cliスタイルの測定された結果（トークン/秒、VRAM、および密なGGUFとMoE GGUFでコンテキスト（19K / 32K / 64K）をスイープしながらのGPU負荷）が欲しい場合は、16 GB VRAM LLMベンチマーク with llama.cpp (速度とコンテキスト) を参照してください。

特にQwen 3.6について、llama.cppは現在、生成スループットを大幅に向上させることができる組み込みマルチトークン予測（MTP）投機的デコードをサポートしています。llama.cppのすべての投機的デコード方法を含む包括的なガイドについては、投機的デコード を参照してください。Qwen 3.6 MTP固有のベンチマークについては、16GB GPUでのQwen 3.6 MTP vs Standard を参照してください。

PrometheusとGrafanaによるllama-serverのモニタリング

llama-serverは、--metricsが有効な場合、/metricsでPrometheus互換メトリクスを公開できます。これは、Prometheus スクレープ設定およびGrafanaダッシュボードと自然に組み合わせられます。

llama.cpp（およびvLLM、TGI）固有のダッシュボードとアラートについては：LLM推論を本番環境で監視 (2026)：vLLM、TGI、llama.cppのためのPrometheus & Grafana。 より広いガイド：可視化：監視、メトリクス、Prometheus & Grafanaガイド および LLMシステムのための可視化.

基本的な強化チェックリスト

llama-serverがlocalhostを超えて到達可能になる場合：

• --api-key（または--api-key-file）を使用してリクエストを認証する
• 必要でない限り0.0.0.0へのバインドを避ける
• サーバーのSSLフラグによるTLS、またはリバースプロキシでのTLSターミネーションを検討する
• 負荷下でのレイテンシを保護するために--parallelで並行性を制限する

トラブルシューティングクイックウィン

モデルはロードされるがチャットでの回答がおかしい

チャットエンドポイントは、モデルがサポートされているチャットテンプレートを持っている場合に最適です。出力が構造化されていないように見える場合、以下を試してください：

• llama-cli --conversationと明示的な--system-promptの使用
• モデルが指示またはチャットチューニング済みのバリアントであることを確認
• アプリに組み込む前にサーバーのWeb UIでテスト

メモリ不足が発生した

コンテキストを減らすか、より小さい量子化を選択します：

• --ctx-sizeを下げる
• VRAMが問題の場合、--n-gpu-layersを減らす
• より小さいモデルまたはより圧縮された量子化に切り替える

CPU上で遅い

以下から始めてください：

• 物理コア数と等しい--threads
• 適度なバッチサイズ
• マシンに合ったビルド（CPU機能とバックエンド）をインストールしたことを検証

参考資料

• 公式llama.cppリポジトリとドキュメント
• 公式CLIフラグドキュメント
• 公式llama-serverドキュメントとAPI詳細