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-clillama-mtmd-clillama-serverllama-gguf-splitllama.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の特徴とバックエンド)がインストールされていることを確認してください。

参考文献