Llama-Server ルーターモード - リスタートなしでの動的モデル切り替え

再起動せずにLLMを配信・切り替え可能。

目次

長らく、llama.cpp には致命的な制限がありました。
それは、1プロセスにつき1つのモデルしか提供できず、モデルを切り替えるには再起動が必要だった点です。

その時代は終わったのです。

最近のアップデートにより、llama-server にルーターモードが導入されました。これにより、現代のローカル LLM ランタイムに対して人々が期待するものに近い機能を実現しています。

  • モデルの動的な読み込み
  • 必要に応じたアンロード（解放）
  • リクエストごとの切り替え
  • プロセスの再起動不要

llm router on the table

言い換えれば、Ollama のような挙動を、補助輪なしで実現しているということです。

ローカルランタイム、クラウド API、セルフホスト基盤のどれを選ぶべきか迷っている方は、 LLM ホスティング概要 が良い出発点になります。

前提条件

ルーターモードには、比較的新しい llama-server ビルド（2024年中期以降）が必要です。古いビルドには --models-preset や --models-dir フラグがありません。

インストールオプション（パッケージマネージャー、プレビルドされたバイナリ、または CUDA を含むソースからのフルビルド）については、 llama.cpp クイックスタート を参照してください。

llama-server が用意できたら、ビルドがルーターモードに対応していることを確認してください。

llama-server --help | grep -i models

--models-preset または --models-dir が表示されれば問題ありません。表示されない場合は、より新しいビルドに更新してください。

私の現在のモデル関連のヘルプ出力は以下の通りです。

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

ルーターモードが実際にやっていること

ルーターモードは、llama-server をモデルディスパッチャに変えます。

-m フラグで単一のモデルにバインドする代わりに、サーバーは以下のように動作します。

  • モデルをロードせずに起動する
  • モデル名を指定したリクエストを受け取る
  • メモリにまだない場合はそのモデルを読み込む
  • 推論（インファレンス）を実行する
  • レスポンス後にモデルをアンロードするか、次のリクエストのためにウォーム状態（温存）にするかを選択する

基本的な考え方

もはや以下のような実行はしなくなります。

./llama-server -m model.gguf

以下のように実行するようになります。

./llama-server --models-preset models.ini --port 8080

そして、クライアントが実際に何かをリクエストするかに基づき、サーバーが何を、いつ読み込むかを決定させます。

これは重要な意味を持ちます。なぜなら、1つの永続プロセスがモデル群全体をサーブし、クライアントがタスクに応じて適切なモデル（コーディング用、チャット用、要約用など）を選択できるからです。これにより、あなたの側での調整コストはゼロになります。

設定: モデルの定義

ここはまだ少し荒削りな部分です。

完全な安定した公式フォーマットはまだありませんが、現在のビルドでは設定ファイル経由で INI スタイルのモデル定義をサポートしています。

models.ini の例

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

各セクション名が、クライアントが API リクエストの "model" フィールドで使用するモデル識別子となります。

主要な設定パラメータ

パラメータ 制御する内容
model GGUF ファイルへの絶対パス
ctx-size トークン単位のコンテキストウィンドウサイズ。値を大きくすると VRAM 使用量が増加します。
ngl GPU にオフロードするレイヤー数。CPU のみを使用する場合は 0 に設定し、VRAM 限界に達するまで増加させます。
threads CPU に残るレイヤー用の CPU スレッド数。

適切な ngl 値の選択は、GPU の利用可能な VRAM に依存します — GPU の選択やハードウェアのコストパフォーマンスについては、コンピュートハードウェアガイド を参考にしてください。チューニング中にライブの VRAM 消費量を確認するには、Linux 用 GPU モニタリングツール をご覧ください。

設定ファイルでサーバーを起動

./llama-server --models-preset /opt/llama.cpp/models.ini --port 8080

サーバーが正常に起動したことを確認します。

curl http://localhost:8080/v1/models | jq '.data[].id'

models.ini の各セクション名がモデル ID としてリスト表示されるはずです。

安定性について

INI 設定インターフェースはまだ進化途中です。

  • コミット間でフラグが変更される可能性があります
  • 特定の実行構成でのみ認識されるパラメータがあります
  • ドキュメントが実装の進みに追いついていません

再起動間での再現性が必要な場合、llama.cpp の特定のコミットにピン留めすることをお勧めします。

API の使用方法: リクエストごとのモデル切り替え

サーバーが起動したら、モデルの切り替えは標準的な OpenAI 互換 API を通じて行われます。 simplemente "model" フィールドを設定するだけです。

登録されたモデルのリスト表示

curl http://localhost:8080/v1/models

補完リクエスト — 最初のモデル

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

別のモデルに切り替え — 同じエンドポイント、同じポート

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

サーバーはアンロード/ロードサイクルをシームレスに処理します。クライアントコードは変更する必要がなく、model フィールドのみを変更すればよいです。

Python の例

openai Python クライアントを使用している場合:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# Use the coding model
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Switch to the chat model — same client, different model name
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

内部で起きていること

qwen に対するリクエストが届き、現在 llama3 がロードされている場合:

  1. llama3 が VRAM からアンロードされる
  2. qwen のウェイトがディスクから読み取られ、VRAM にロードされる
  3. 推論が実行される
  4. 次のリクエストにより、qwen をロードしたままにするか、再度切り替えるかが決まる

これにより、よくある質問に直接答えられます。

ローカル LLM サーバーは再起動せずにモデルを切り替えられるのですか？

リクエストごとにモデルを動的にロードすることで、起動時にバインドすることなく切り替えを実現しているのです。

Systemd サービス: 本番環境向けのセットアップ

専用ユーザーとディレクトリの作成

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

バイナリとモデル設定を指定場所にコピーします。

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models-preset /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

有効化と起動

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

確認とログの検査

sudo systemctl status llama-server

journalctl -u llama-server -f

正常に起動すると、サーバーがリスニングしていることを示す行と、モデルレジストリがロードされたことを示す行が表示されます。簡単な健全性チェックとして:

curl -s http://localhost:8080/v1/models | jq '.data[].id'

これにより、自動再起動と中央集結型のモデル切り替えを備えた永続サービスが構築されました。手動のプロセス管理は不要です。他のバイナリにも同じパターンを適用したい場合は、Linux 上で任意の実行ファイルをサービスとしてホスティングする で一般的なアプローチを説明しています。

llama-server の --metrics フラグは、Prometheus 互換のエンドポイントを公開します。llama.cpp 専用のダッシュボード、PromQL クエリ、アラートルールについては、LLM インファレンス監視ガイド を参照してください。より広範なオブザーバビリティ（可観測性）セットアップについては、オブザーバビリティガイド がフルスタックをカバーしています。

理解すべき制限事項

ルーターモードは本当に有用ですが、本番環境で頼る前に明確にするべきトレードオフがあります。

メモリに常駐するのは常に1つのモデル

models.ini で複数のモデルが定義されていても、1ワーカーあたり VRAM に常駐するのは常に1つのモデルのみです。切り替えとは、完全なアンロードと再ロードのサイクルを意味します。

  • 切り替えとは再ロードを意味する
  • レイテンシのスパイクは避けられない
  • 典型的な Q5 圧縮の 7B モデルでは、ディスク速度や VRAM 帯域幅によりますが、再ロードに 3〜10 秒かかる場合があります

これにより、もう1つの重要な質問にも答えられます。

llama.cpp は同時に複数のモデルをサーブできますか？

厳密にはできません。複数の定義はサポートしていますが、同時常駐はサポートしていません。2つのモデルを本当に並列でロードする必要がある場合は、2つの別々の GPU に2つのプロセスを配置する必要があります。

モデルサイズごとの測定された VRAM 消費量や 1 秒あたりのトークン数については、LLM パフォーマンスベンチマーク が全体像をカバーしています。16 GB GPU での llama.cpp 固有の数値 — 複数コンテキストサイズでのデンスモデルと MoE モデル — については、16 GB VRAM GPU での llama.cpp ベンチマーク をご覧ください。

スマートキャッシュ機能がない

最近の使用頻度に基づいてモデルを追い出すウォームプールを維持する Ollama とは異なり:

  • 自動的なモデルエビクション（追い出し）戦略がない
  • バックグラウンドでのプリウォーミング（事前温存）がない
  • 頻繁に使用されるモデル用の優先キューがない

llama3 と mistral のリクエストを交互に送信すると、すべてのリクエストで再ロードが発生します。これは、ハードウェアに近い層で動作することの本質的なコストです。

混合ワークロードではレイテンシが予測しにくい

1つのモデルを常に使用する、動作の良いワークロードは高速です。複数のモデルを交互に使用するワークロードは遅くなります。クライアントのルーティングロジックは適切に計画してください — 可能な限りモデルごとにリクエストをグループ化してください。

設定は安定していない

INI サポートは存在し、最近のビルドでは概ね動作しますが、完全に標準化されていません。フラグやパラメータ名はバージョン間で変更されています。llama-server をアップグレードする場合、デプロイ前に新しいビルドに対して models.ini をテストしてください。

Llama.cpp vs Ollama

ルーターモードは、Ollama 과의旧来のライフサイクルのギャップを縮めました — 動的な読み込みとリクエストごとの切り替えは llama-server でネイティブに利用可能になりました — しかし、完全に解消したわけではありません。メモリ管理は依然として基本的なものです（エビクションポリシーなし、ウォームプールなし）、設定の安定性は依然として実験段階であり、2つの異なるモデル間の切り替えは常に完全なアンロードと再ロードのコストを伴い、Ollama の TTL ベースのキープアライブ（保持）とは異なります。要約すると: ルーターモードは最大限の制御とハック可能な基盤を提供します。一方、Ollama は設定の手間が少ない、より磨き上げられた意図的な体験を提供します。

インストール、モデル管理、GPU 配置、KV キャッシュ制御、API、パフォーマンス、障害モード、および片方を選択または移行する具体的なトリガーを含む、完全な 2 者比較については、2026年の llama.cpp vs Ollama をご覧ください。これは本サイトにおける2つのランタイム間の正規の比較です。

Ollama を選択する場合、Ollama CLI チートシート が日常的なコマンドをカバーしています。vLLM、LM Studio、LocalAI も含めたより広範な比較については、2026年の異なるローカルランタイムの比較 を参照してください。

Llama.cpp vs llama-swap

llama-swap は、1つ以上の llama-server インスタンスの前に位置する外部オーケストレーターです。

  • リクエストをインターセプトし、model フィールドを検査する
  • そのモデルに対応する適切な llama-server プロセスを開始する
  • 設定可能なタイムアウト後にアイドルなインスタンスをシャットダウンする
  • モデルが準備できたら、リクエストをプロキシして通す

手元でのセットアップについては、llama-swap クイックスタート をご覧ください。

主な違い

観点 ルーターモード llama-swap
ビルトイン はい いいえ (別バイナリ)
成熟度 実験的 より安定
柔軟性 限定的 高
制御レイヤー 内部 外部プロキシー
モデルごとの設定 INI ファイル YAML ファイル
プロセスモデル 単一プロセス モデルごとに1プロセス

llama-swap を使うタイミング

llama-swap は、モデルごとのプロセスレベルの分離を提供します。これは、1つのモデルインスタンスでのクラッシュが他のインスタンスに影響しないことを意味します。また、各モデルが完全に独立した llama-server フラグで実行できるようにもなります。

以下の必要がある場合は使用してください:

  • より良いライフサイクル制御と分離
  • 設定可能なアイドルタイムアウトを備えたよりスマートな切り替えロジック
  • より予測可能なレイテンシ（各モデルは初回ロード後にウォームなプロセスを持つ）
  • 将来的な成熟を待たず、現在の本番環境安定性

ネイティブなルーターモードで十分な場合

以下を望む場合は、ビルトインのルーターを使用してください:

  • 外部依存関係ゼロ
  • 管理すべき単一プロセス
  • シンプルなデプロイ（1つのバイナリ、1つの設定ファイル）
  • 開発またはシングルユーザースセットアップのための最小限のスタック

所感

ルーターモードは、llama-server にとって大きな前進です。

長年続いている要求に答えました。

llama.cpp サーバーにおけるルーターモードとは何ですか？

これは、静的なバイナリを動的なインファレンスサービスに変える、欠けていたレイヤーです — 1つのプロセスが、モデルカタログ全体のリクエストに対応できるのです。

しかし、まだ完成ではありません。

現在は:

  • 実際のワークロードに対応できるほど強力
  • より洗練されたルーティングの基盤として有望
  • 設定と安定性の辺りは少し荒削り

ワークロードが予測可能であり、モデルごとにリクエストをグループ化できる場合は、ルーターモードは今日でも良好に機能します。本番環境グレードの信頼性とモデルごとの分離が必要であれば、ネイティブ実装が成熟するまで llama-swap を検討することをお勧めします。

再起動せずに VRAM を解放する必要がある場合 — ベンチマーク実行、メンテナンスウィンドウ、またはクリーンな開発リセットのために — スクリプト可能なアプローチは、ロードされたモデルを列挙し、それぞれに対してアンロードエンドポイントを呼び出すことです。完全な curl と jq のパターンは、再起動せずに llama.cpp ルーターモデルをすべてアンロードする に記載されています。

どちらにせよ、あなたはメカニズムを隠さずに、Ollama のような挙動を得ることになります。

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。