ローカル LLM サーバーは、再起動なしにモデルを切り替えることができますか？

サーバーは、動的なモデルロード機能を実装し、要求に応じて現在のモデルをアンロードして新しいモデルをロードすることで、プロセスの再起動なしにシームレスな切り替えを可能にします。

llama.cpp は複数のモデルを同時に提供することをサポートしていますか？

Llama.cpp は複数のモデルを定義できますが、通常はワーカーごとにメモリに 1 つのモデルのみが読み込まれ、他のモデルは必要に応じて読み込まれます。

llama.cpp と Ollama はモデル管理においてどのように比較されますか？

Llama.cpp は低レベルの制御と動的読み込みを提供する一方、Ollama は内蔵キャッシュとライフサイクル管理を備えた、より洗練された体験を提供します。

llama.cpp における自動モデル切り替えツールにはどのようなものがありますか？

llama-swap などのツールは、モデルの自動読み込みとアンロードを外部からオーケストレーションする機能を提供し、生の llama.cpp よりも高レベルのインターフェースを実現します。

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

Q: llama.cpp サーバーにおける「ルーターモード」とは何か？

ルーターモードは、単一のサーバーインスタンスが、受信するリクエストに応じてモデルを動的にロード、アンロード、および切り替えられる機能です。

LLM を再起動せずに提供および切り替えを行います。

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

その時代は終わりました。

最近のアップデートで llama-server にルーターモードが導入され、現代のローカル LLM ランタイムとして期待される機能に近づきました。

モデルの動的ロード
必要に応じてのアンロード
リクエストごとの切り替え
プロセスの再起動なし

llm router on the table

言い換えれば、Ollama のような挙動が、初級者用の補助（トレーニングホイール）なしに手に入るということです。

現在、ローカルランタイム、クラウド API、セルフホスティングインフラの選択に迷っている場合は、 LLM ホスティングの概要が良い出発点になります。

前提条件

ルーターモードには、2024 年半ば以降の llama-server ビルドが必要です。古いビルドには --models フラグがありません。

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

llama-server を入手したら、ビルドがルーターモードをサポートしているか確認します。

llama-server --help | grep -i models

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

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

-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 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 /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 を通じて行われます。単に "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")

# コーディングモデルを使用
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# チャットモデルへ切り替え — 同じクライアント、異なるモデル名
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 がロードされている場合、以下が起こります。

llama3 が VRAM からアンロードされる
qwen の重みがディスクから読み込まれ、VRAM にロードされる
推論が実行される
次のリクエストが、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 /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 に複数のモデルが定義されていても、ワーカーごとに任意の時点で VRAM に存在するのは 1 つのモデルだけです。切り替えは、完全なアンロードと再ロードサイクルを意味します。

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

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

llama.cpp は同時に複数のモデルを提供できるのか？

実質的にはできません。複数の定義はサポートしていますが、同時駐留はサポートしていません。2 つのモデルを真に並行してロードする必要がある場合は、2 つの GPU に 2 つのプロセスが必要です。

モデルサイズごとの測定された VRAM 消費量とトークン/秒については、LLM パフォーマンスベンチマークで全体像を確認できます。16 GB GPU での llama.cpp に特化した数値（高密度モデルと MoE モデルの複数のコンテキストサイズ）については、16 GB VRAM GPU での llama.cpp ベンチマークを参照してください。

スマートキャッシュなし

Ollama がウォームプールを維持し、直近使用に基づいてモデルを排除するのとは異なり、llama.cpp ルーターモードでは以下がありません。

自動モデル排除戦略
バックグラウンドでの事前ウォーミング
頻繁に使用されるモデル用の優先キュー

llama3 と mistral へのリクエストを交互に送信すると、すべてのリクエストで再ロードがトリガーされます。これは、メタルに近い実装であることの根本的なコストです。

混合ワークロードではレイテンシが予測不可能

1 つのモデルを一貫して使用する振る舞いのあるワークロードは高速です。複数のモデルを交互に使用するワークロードは低速になります。クライアントのルーティングロジックをそれに応じて計画し、可能な限りモデルごとにリクエストをグループ化してください。

設定は安定していない

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

Llama.cpp と Ollama の正直な比較

機能	llama.cpp ルーター	Ollama
動的ロード	はい	はい
モデル切り替え	はい	はい
組み込みレジストリ	部分的 (INI)	はい (プルベース)
メモリ管理	基本的	高度
モデル排除なし	TTL ベース
UX の磨り上げ	低	高
OpenAI API 互換	はい	はい
制御性	最大	意見あり
設定の安定性	実験的	安定

個人的な見解

llama.cpp ルーターモードを選択するのは、以下を望む場合です。

モデルごとのランタイムパラメータへの最大制御
最小のプロセスオーバーヘッド
抽象化レイヤーなしでの llama.cpp フラグへの直接アクセス
カスタムツール用のハッカブルな基盤

Ollama を選択するのは、以下を望む場合です。

安定した、磨り上げられた体験
自動モデルダウンロードとバージョン管理
設定なしでのスマートなキープアライブと排除
初日からバッテリー込みの機能

どちらが間違っているわけではありません。選択は、自分で管理したい程度に依存します。

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

Llama.cpp と 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 サーバーにおけるルーターモードとは何か

それは、静的なバイナリを動的推論サービスに変える欠落したレイヤーです。モデルのカタログ全体のリクエストに応えられる単一のプロセスです。

しかし、まだ完成していません。

現在、それは以下です。

実ワークロードに十分な強さを持つ
より高度なルーティングの基盤として有望
設定と安定性の面で少し荒々しい

ワークロードが予測可能で、モデルごとにリクエストをグループ化できる場合は、ルーターモードは今日でもよく機能します。本番環境グレードの信頼性とモデルごとの分離が必要なら、ネイティブ実装が成熟するまで llama-swap を使用してください。

どちらにせよ、Ollama のような挙動が得られ、かつ仕組みを隠しません。