llama.cpp の CLI とサーバーを使用したクイックスタート
「OpenCode のインストール、設定、および使用方法」
llama.cpp(https://www.glukhov.org/ja/llm-hosting/llama-cpp/ “llama.cpp”)はローカルでの推論に最適です。Ollamaや他のツールが抽象化しているコントロールを提供し、簡単に動作します。llama-cliを使用してGGUFモデルをインタラクティブに実行したり、llama-serverを使用してOpenAIと互換性のあるHTTP APIを公開したりするのが簡単です。
ローカル、セルフホスト、クラウドのアプローチの選択にまだ迷っている場合は、まず以下のガイドから始めましょう。 LLMホスティング2026:ローカル、セルフホスト、クラウドインフラの比較
2026年のllama.cppの理由
llama.cppは、以下の傾向があります:
- CPUと複数のGPUバックエンドをまたいでのポータビリティ,
- 単一のマシンで予測可能なレイテンシー,
- ラップトップからオンプレミスノードまで、デプロイの柔軟性。
プライバシーとオフライン操作が必要な場合、ランタイムフラグに対する決定的なコントロールが必要な場合、またはフルなPython中心のスタックを実行せずに、より大きなシステムに推論を組み込みたい場合にllama.cppが特に優れています。
また、後でより高いスループットのサーバー実行環境を選択したとしても、llama.cppを理解しておくことは役立ちます。たとえば、GPUでの最大のサービススループットが目的であれば、vLLMと比較するのも良いでしょう。
vLLMクイックスタート:高性能LLMサービス
そして、ツール選択のベンチマークについては以下を参照してください。
Ollama vs vLLM vs LM Studio:2026年にLLMをローカルで実行する最適な方法?

Windows、macOS、Linuxでllama.cppをインストール
便利さ、ポータビリティ、最大のパフォーマンスのいずれかを目的としているかによって、3つの実装パスがあります。
パッケージマネージャー経由でのインストール
これは、最も速く「実行する」オプションです。
# macOS or Linux
brew install llama.cpp
# Windows
winget install llama.cpp
# macOS (MacPorts)
sudo port install llama.cpp
# macOS or 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/
GPUビルドを1つのコマンドで
ご使用のハードウェアに合ったバックエンドを有効にしてください(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:完全なビルドウォークスルー
Ubuntu 24.04にNVIDIA GPUがある場合、ビルドする前に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
cp llama.cpp/build/bin/llama-* llama.cpp
これにより、llama-cli、llama-mtmd-cli、llama-server、llama-gguf-splitがllama.cppディレクトリに生成されます。
また、複数のバックエンドをコンパイルし、実行時にデバイスを選択することもできます。これは、異質なマシンに同じビルドをデプロイする際に役立ちます。
GGUFモデルと量子化を選択
推論を実行するには、GGUFモデルファイル(*.gguf)が必要です。GGUFは、llama.cppなどのエンジンが必要とする標準化されたメタデータを含む単一ファイル形式です。
モデルを取得する2つの方法
オプションA:ローカルのGGUFファイルを使用
GGUFを./models/にダウンロードまたはコピーします:
mkdir -p models
# models/my-model.ggufに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
モデルが特定のシーケンスを出力するときに生成を終了させたい場合は、リバースプロンプトを使用してください。これは、インタラクティブモードで特に役立ちます。
llama-cliの主要なフラグ
200個のフラグをすべて覚えるのではなく、正しさ、レイテンシー、メモリに影響を与えるものに集中してください。
モデルとダウンロード
| 目的 | フラグ | いつ使用するか |
|---|---|---|
| ローカルファイルをロード | -m, --model |
*.ggufをすでに持っている場合 |
| Hugging Faceからダウンロード | --hf-repo, --hf-file, --hf-token |
速い実験、自動キャッシュ |
| オフラインキャッシュを強制 | --offline |
オフラインまたは再現性のある実行が必要な場合 |
コンテキストとスループット
| 目的 | フラグ | 実用的なノート |
|---|---|---|
| コンテキストを増減 | -c, --ctx-size |
大きなコンテキストはRAMまたはVRAMをより多く使用します |
| プロンプト処理を改善 | -b, --batch-size および -ub, --ubatch-size |
バッチサイズは速度とメモリに影響します |
| CPU並列性を調整 | -t, --threads および -tb, --threads-batch |
CPUコアとメモリ帯域幅に合わせて調整してください |
GPUオフロードとハードウェア選択
| 目的 | フラグ | 実用的なノート |
|---|---|---|
| 使用可能なデバイスを一覧表示 | --list-devices |
複数のバックエンドがコンパイルされている場合に役立ちます |
| デバイスを選択 | --device |
CPUとGPUのハイブリッド選択を有効にします |
| レイヤーをオフロード | -ngl, --n-gpu-layers |
最も大きな速度のレバーの一つです |
| マルチGPU論理 | --split-mode, --tensor-split, --main-gpu |
マルチGPUホストまたは不均等なVRAMに役立ちます |
サンプリングと出力品質
| 目的 | フラグ | おすすめの初期値 |
|---|---|---|
| 創造性 | --temp |
0.2から0.9、タスクによって異なります |
| ナクレアスサンプリング | --top-p |
0.9から0.98が一般的です |
| トークンカットオフ | --top-k |
40が古典的な基準値です |
| 繰り返しを減らす | --repeat-penalty および --repeat-last-n |
小さなモデルに対して特に役立ちます |
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
サーバーのオプションだが重要なフラグ
| 目的 | フラグ | なぜ重要なのか |
|---|---|---|
| 並列性 | --parallel |
平行なリクエストのためのサーバースロットを制御します |
| 負荷下でのスループット改善 | --cont-batching |
連続バッチングを有効にします |
| アクセスを制限 | --api-key または --api-key-file |
APIリクエストの認証に使用されます |
| Prometheusメトリクスを有効にする | --metrics |
/metricsを公開するために必要です |
| プロンプトの再処理リスクを減らす | --cache-prompt |
レイテンシーのためのプロンプトキャッシュ動作 |
コンテナで実行している場合は、多くの設定は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)
埋め込み
/v1/embeddingsでOpenAI互換の埋め込みが公開されていますが、モデルが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/my-embedding-model.gguf \
--embeddings \
--host 127.0.0.1 \
--port 8080
パフォーマンス、監視、生産性の強化
「llama.cppのコマンドラインオプションの中で、速度とメモリに最も影響を与えるものはどれですか?」というFAQの質問は、推論をシステムとして扱うことで簡単に解決できます:
- メモリ上限は通常、最初の制約(CPUではRAM、GPUではVRAM)です。
- コンテキストサイズはメモリの主要な倍増要因です。
- GPUレイヤーのオフロードは、秒あたりのトークン数を向上させる最も速い方法です。
- バッチサイズとスレッド数はスループットを改善するかもしれませんが、メモリの圧力を増やす可能性もあります。
より深い、エンジニアリングファーストの視点については以下を参照してください: 2026年のLLMパフォーマンス:ベンチマーク、ボトルネック、最適化
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がローカルホスト以外にアクセス可能になった場合:
--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の特徴とバックエンド)がインストールされていることを確認してください。