llama-server の使い方｜ローカルLLMをAPI化【2026年版】

llama-serverとは何か：ローカルLLM推論サーバーの中核エンジン

llama-serverは、llama.cppプロジェクトが提供するHTTPベースの推論サーバーです。かつてはserverという名称で呼ばれていましたが、llama.cppのリファクタリングに伴い2024年以降はllama-serverとして独立したバイナリとして提供されています。OpenAI互換のREST APIエンドポイントを備えており、LlamaをはじめとするGGUF形式のモデルをローカル環境で動かしながら、既存のOpenAI SDKやツールチェーンをほぼそのまま流用できる点が最大の魅力です。

弊社（クリスタルメソッド）では各種LLMの検証・実務利用を継続的に行っており、llama-serverはオンプレミス環境でのプロトタイプ検証やバーチャルヒューマン向け推論基盤として実際に稼働させてきました。本記事ではそのノウハウをベースに、llama-serverの仕組み・セットアップ・主要オプション・実運用のポイントを詳しく解説します。

なお、Llama自体の概要については Llamaとは何か を、導入全体の流れは Llama 導入ガイド をあわせてご参照ください。

llama-serverのアーキテクチャと処理フロー

llama-serverがリクエストを受け取ってレスポンスを返すまでの流れを以下に示します。クライアントはOpenAI互換エンドポイントにHTTPリクエストを送るだけでよく、内部の推論処理はすべてllama.cppのC++ランタイムが担います。

KVキャッシュはコンテキスト長に応じてVRAMまたはRAMに確保されます。並列リクエストはスロット（slot）という単位で管理され、--parallelオプションで同時処理数を指定できます。スロット数を超えたリクエストはキューに積まれるため、サービング用途ではこの設計を理解した上でリソース計画を立てる必要があります。

インストールとビルド方法

llama-serverはllama.cppのビルドで同時に生成されます。以下に代表的な環境ごとの手順をまとめます。

macOS（Apple Silicon）

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DLLAMA_METAL=ON
cmake --build build --config Release -j$(sysctl -n hw.logicalcpu)
# バイナリ: build/bin/llama-server

Apple SiliconではMetalバックエンドが自動的に有効になり、GPUオフロードが効きます。弊社環境ではM2 Max搭載機でLlama 3.3-8B Q4_K_Mを動かした際、CPUのみと比較してトークン生成速度が約4〜5倍向上しました。

Linux（CUDA環境）

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)

CUDAビルドにはCUDA Toolkit 11.8以上が必要です。複数GPUがある場合は--tensor-splitオプションでモデルを分割配置できます。

Dockerを使う方法

# CPU版
docker run --rm -p 8080:8080 \
  -v /path/to/models:/models \
  ghcr.io/ggerganov/llama.cpp:server \
  -m /models/your-model.gguf --host 0.0.0.0 --port 8080

# CUDA版（GPUあり）
docker run --rm --gpus all -p 8080:8080 \
  -v /path/to/models:/models \
  ghcr.io/ggerganov/llama.cpp:server-cuda \
  -m /models/your-model.gguf --host 0.0.0.0 --port 8080 -ngl 99

Dockerイメージは公式のGitHub Container Registry（ghcr.io）で提供されています。ビルド環境を汚したくない場合や、CI/CDパイプラインに組み込む場合はこちらが手軽です。

基本的な起動コマンドとオプション

最小構成でサーバーを起動するコマンドは以下の通りです。ここでは現行の実用モデルであるLlama 3.3（70B）のGGUF量子化版を例に使用します。

./llama-server \
  -m ./models/Llama-3.3-70B-Instruct-Q4_K_M.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 80 \
  -c 4096

主要なオプションを表にまとめます。

オプション	意味	推奨値・備考
-m / --model	GGUFモデルファイルのパス	必須
-ngl / --n-gpu-layers	GPUにオフロードするレイヤー数	VRAMに収まる最大値。全層なら99や999でも可
-c / --ctx-size	コンテキストウィンドウのトークン数	大きいほどVRAM消費増。2048〜8192が現実的
--parallel / -np	同時処理スロット数	デフォルト1。API経由で複数リクエストを処理する場合は増やす
--host	バインドするIPアドレス	外部公開する場合は0.0.0.0。ローカルのみは127.0.0.1
--port	リッスンポート	デフォルト8080
--api-key	APIキー認証	外部公開時は必ず設定。Bearer認証に対応
-t / --threads	CPUスレッド数	物理コア数を上限の目安にする
--flash-attn / -fa	Flash Attention有効化	長コンテキスト時のVRAM削減・高速化に有効
--chat-template	チャットテンプレートの指定	GGUFメタデータから自動検出されることが多い

OpenAI互換APIエンドポイント一覧

llama-serverが提供するエンドポイントはOpenAI APIの主要なものをカバーしており、既存のOpenAI SDKのベースURLを書き換えるだけで多くのアプリケーションが動作します。

エンドポイント	メソッド	機能
/v1/chat/completions	POST	チャット形式の推論。ストリーミング対応（SSE）
/v1/completions	POST	テキスト補完（レガシー形式）
/v1/embeddings	POST	テキスト埋め込みベクトルの生成
/v1/models	GET	ロード中のモデル情報一覧
/health	GET	サーバーの稼働状態・スロット状況確認
/metrics	GET	Prometheusフォーマットのメトリクス（要--metricsフラグ）
/slots	GET	スロット状態の詳細（KVキャッシュ使用率など）

Python SDKからの接続例

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="your-api-key-if-set"  # --api-keyを設定した場合
)

response = client.chat.completions.create(
    model="local-model",  # モデル名は何でもよい（サーバー側は無視）
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "量子コンピュータを一言で説明して"}
    ],
    stream=True
)

for chunk in response:
    print(chunk.choices[0].delta.content or "", end="", flush=True)

モデル選択とGGUFの量子化レベル

llama-serverで使用するモデルはGGUF形式が必要です。Hugging FaceのBartowski氏などのリポジトリから量子化済みファイルをダウンロードするのが一般的です。現行世代の主力モデルとして、テキスト用途にはLlama 3.3（70B / 8B）、マルチモーダル（画像＋テキスト）用途にはMoE構造を採用したLlama 4 Scout / MaverickのGGUFが利用できます。量子化レベルによって精度・速度・メモリ使用量のトレードオフが変わります。

量子化タイプ	bits/weight	8Bモデル目安サイズ	品質・用途感
Q2_K	約2.6	〜3 GB	品質劣化大。VRAMが極端に少ない場合のみ
Q4_K_M	約4.8	〜5 GB	バランス最良。実務用途の第一選択肢
Q5_K_M	約5.7	〜6 GB	Q4_K_Mより精度高。VRAM余裕があれば推奨
Q8_0	約8.5	〜9 GB	FP16に近い品質。VRAMが十分な検証環境向け
F16	16	〜16 GB	量子化なし。ベースライン測定・ファインチューン後推論など

弊社の検証では、日本語タスク（要約・QA）においてQ4_K_MとQ8_0の品質差はほとんどのケースで許容範囲内でした。限られたVRAMでより大きなコンテキストを扱いたい場合、Q4_K_Mを選んで--flash-attnを有効にする組み合わせが実用的です。

マルチモーダル対応：LLaVA系モデルおよびLlama 4の画像入力

llama-serverはビジョンモデル（LLaVAなどマルチモーダルモデル）に対応しています。画像入力を扱う場合は--mmprojオプションでマルチモーダルプロジェクションファイルを指定します。また、Llama 4世代（Scout / Maverick）はネイティブマルチモーダルとして設計されており、画像＋テキストの複合推論を単一モデルで行える点が特徴です。

./llama-server \
  -m ./models/llava-v1.6-mistral-7b.Q4_K_M.gguf \
  --mmproj ./models/llava-v1.6-mistral-7b-mmproj-f16.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -ngl 35

画像はBase64エンコードして/v1/chat/completionsのメッセージ内に埋め込みます。OpenAI Vision APIと同様の構造でリクエストを送れるため、既存のVision対応クライアントコードがほぼそのまま使えます。

本番運用のベストプラクティス

systemdによるサービス化

サーバーをOSの起動時に自動で立ち上げるには、systemdユニットファイルを作成します。

# /etc/systemd/system/llama-server.service
[Unit]
Description=llama-server LLM inference API
After=network.target

[Service]
Type=simple
User=llama
ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/models/Llama-3.3-8B-Instruct-Q4_K_M.gguf \
  --host 127.0.0.1 --port 8080 \
  -ngl 33 -c 4096 --parallel 4 \
  --api-key ${LLAMA_API_KEY}
EnvironmentFile=/etc/llama-server.env
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

nginx によるリバースプロキシとTLS終端

llama-server自体はHTTPのみを提供するため、HTTPS化にはリバースプロキシが必要です。nginxのシンプルな設定例を示します。

server {
    listen 443 ssl;
    server_name your.domain.com;

    ssl_certificate     /etc/letsencrypt/live/your.domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your.domain.com/privkey.pem;

    location /v1/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_read_timeout 300s;
        proxy_buffering off;  # SSEストリーミングに必須
        proxy_set_header Connection '';
        proxy_http_version 1.1;
    }
}

ストリーミング応答（SSE）を正常に受け取るにはproxy_buffering offが必須です。これを設定し忘れると、クライアント側でトークンがまとめて届いてしまい、リアルタイム表示が機能しません。弊社でも当初この設定を見落としてデバッグに時間を要した経験があります。

パフォーマンスチューニングの指針

セキュリティ上の注意点

• 外部公開する場合は必ず--api-keyを設定する。未設定のまま0.0.0.0でバインドすると誰でもモデルにアクセスできる状態になります。
• ファイアウォールでllama-serverのポートを直接外部に晒さず、nginxなどを経由させる。
• プロンプトインジェクション対策はアプリケーション層で別途実装が必要です（llama-server自体はサニタイズを行いません）。
• モデルファイルのダウンロード元は公式リポジトリ（llama.com・Hugging Face公式）または信頼できるソースに限定してください。悪意のあるGGUFファイルが存在する可能性が指摘されています。

組み込みWebUIの活用

llama-serverにはビルトインのWebUIが含まれており、デフォルトではhttp://localhost:8080にアクセスするとチャットインターフェースが表示されます。このUIはReactベースで実装されており、ストリーミング応答・モデルパラメータ（temperature、top-p等）のリアルタイム調整・セッション履歴管理などが可能です。APIの動作確認やプロンプト実験には積極的に活用できます。

WebUIを無効化してAPIのみ提供したい場合は--no-webuiフラグを付けます。本番環境では不要なエンドポイントを塞ぐ意味でも指定を検討してください。

他のローカルLLMサーバーとの位置づけ

ローカルLLMの推論サーバーにはOllama・vLLM・LM Studioなど複数の選択肢があります。llama-serverの立ち位置を整理します。

ツール	強み	向いているケース
llama-server	軽量・依存少・細かい制御が可能	サーバー組み込み・カスタム構成・ローリソース環境
Ollama	セットアップが極めて簡単・モデル管理が容易	開発者の個人環境・素早いプロトタイプ
vLLM	PagedAttentionで高スループット	GPU多数のデータセンター・高並列サービング
LM Studio	GUIで操作可能・非エンジニアにも優しい	ビジネスユーザーの試用・デモ

Ollamaは内部でllama.cppを使っているため、低レベルのオプションを自分でコントロールしたい・組み込みWebUIや/metricsエンドポイントを直接使いたいといった要件には、llama-serverを直接使う方が適しています。モデルの比較選定については Llama 比較記事 も参考にしてください。料金感については Llama 料金ガイド をご覧ください。

トラブルシューティング：よくあるエラーと対処法

症状	原因	対処法
CUDA out of memory	VRAMが足りない	-nglを減らす・-cを小さくする・より低量子化のモデルを選ぶ
応答が文字化け・おかしな記号	チャットテンプレートの不一致	--chat-templateで明示的に指定（llama3, chatml, mistralなど）
ストリームが一括で届く	プロキシのバッファリング	nginx設定にproxy_buffering off;を追加
モデル読み込みが極端に遅い	mmapが無効 or ストレージがHDD	SSDに移動・--no-mmapを外す
401 Unauthorized	APIキー不一致	リクエストヘッダにAuthorization: Bearer <key>を付与
生成が途中で止まる	コンテキスト長超過	-cを増やす。または--ctx-size 0でモデルのmax値を自動設定

まとめ

llama-serverは、llama.cppエコシステムの中核をなす軽量・高性能なローカルLLM推論サーバーです。OpenAI互換APIにより既存ツールとの親和性が高く、macOS・Linux・Dockerを問わず導入できます。主なポイントを振り返ります。

• GGUFモデルをHTTP経由で提供するシンプルなアーキテクチャで、依存関係が最小限
• -ngl・-c・--parallel・--flash-attnの組み合わせでリソースとパフォーマンスを細かく制御できる
• 本番運用ではsystemd化・nginxリバースプロキシ
  

  参考文献

  このフィールドは空白のままにしてください

  AIブログ購読

  　
  クリスタルメソッドがお届けする
  AIブログの更新通知を受け取る

  受信ボックスか迷惑メールフォルダを確認して購読手続きを完了してください。