ローカルLLM 複数モデル運用ガイド 2026年版：llama-swap で VRAM を使い回し、Ollama 手動切り替えを卒業する

結論：チャット用・RAG用・コード補完用とローカルLLM を使い分けて VRAM が足りなくなるなら、llama-swap を導入してください。llama-swap は llama.cpp / vLLM など OpenAI 互換サーバの前段に立つ Go 製リバースプロキシで、① リクエストされたモデルを自動ロード/アンロード、② TTL ベースでアイドルモデルを VRAM から自動退避、③ モデルグループで複数モデルを同時常駐、を単一エンドポイントで実現します。Ollama / LM Studio が「ランタイム本体」なのに対し、llama-swap は「どのモデルをいつ載せるか」を捌くスイッチャー。手動で ollama stop / run を打つ運用を卒業できます。

ローカルLLM を本格的に使い始めると、ほぼ全員が同じ壁にぶつかります。「チャットには 70B、コード補完には軽量な 7B、RAG の埋め込みには専用モデル……と使い分けたいのに、全部同時に VRAM へ載せると溢れる」という問題です。

その都度 ollama stop / ollama run を手で打つのは現実的ではありません。本記事は、この複数モデル運用を llama-swap で自動化する実践ガイドです。テーマは「Ollama / LM Studio / llama.cpp / vLLM のどれを使うか」という選定の話ではなく、選んだランタイムの上で複数モデルをどう捌くか という運用の話に絞ります。

llama-swap の正体：ランタイムではなく「前段のスイッチャー」

最初に役割をはっきりさせます。llama-swap（GitHub: mostlygeek/llama-swap）は、モデルを動かすランタイム ではありません。

• llama.cpp / vLLM / TabbyAPI など：実際にモデルを VRAM へ載せて推論する OpenAI 互換サーバ（＝ランタイム本体）
• llama-swap：その前段に立ち、リクエストの model フィールドを見て、必要なランタイムを起動/終了し、単一エンドポイントへ集約する Go 製リバースプロキシ

クライアント（OpenWebUI、Continue、自作スクリプトなど）は llama-swap の単一エンドポイント（例：http://localhost:8080/v1）だけを知っていればよく、「今どのモデルが VRAM に載っているか」を意識する必要がなくなります。リクエストで model: "qwen2.5-coder-7b" を指定すれば、llama-swap が裏で該当ランタイムを起動し、応答を返します。

Ollama / LM Studio との関係を整理します。

ツール	役割	複数モデルの扱い
Ollama	自己完結型ランタイム（DL + 実行）	自動スワップはあるが制御が粗い。手動 stop/run になりがち
LM Studio	GUI 付きランタイム	GUI でモデル切り替え。自動化・ヘッドレス運用は不向き
llama.cpp（llama-server）	軽量・高速なランタイム	単体ではモデル切り替えの概念なし（1プロセス1モデル）
vLLM	高スループットなサーバ	同上。並列リクエスト向き
llama-swap	前段プロキシ（スイッチャー）	TTL / groups でモデルを自動管理。これが主役

つまり llama-swap は Ollama の代替ではなく 補完 です。llama.cpp / vLLM を裏に置いて llama-swap で捌くのが最も制御しやすい構成ですが、Ollama を裏に置く構成も可能です。各ランタイムの素の比較は「ローカルLLM実行ツール比較 2026年版：Ollama / LM Studio / llama.cpp / vLLM」を参照してください。

llama-swap の中心価値：3つの機能

llama-swap を入れる理由は、突き詰めると次の 3 機能です。

1. TTL ベースの自動アンロード（最重要）

各モデルに「アイドル何秒で VRAM から退避するか」を設定できます。コード補完用の 7B を呼んだ後、5 分使わなければ自動でアンロードされ、VRAM が空く。次にチャット用 70B を呼べば、空いた VRAM へ載る。こうした挙動が自動で回ります。

手動 stop/run の往復がなくなる のが最大の価値です。VRAM が限られる環境ほど効きます。

2. モデルグループ（同時起動）

「埋め込みモデル + リランカー + チャットモデルは常に 3 つ同時に立てたい」というケースでは、groups でまとめて常駐させます。VRAM に余裕がある（DGX Spark / Strix Halo / Mac Studio など大容量 unified memory）環境では、10 個以上のモデルをグループ運用する事例もあります。

3. 設定ホットリロード + Web ダッシュボード

YAML 設定を編集すると再起動なしで反映。Web ダッシュボードで「今どのモデルがロード中か」「各モデルの稼働状況」を一覧できます。常駐サービスとして運用するときの可視性が高い点も実用上の利点です。

具体シナリオ：VRAM 24GB で 70B チャット + 7B コード補完を共存させる

最も現実的なシナリオで構成例を示します。RTX 4090 / 5090（VRAM 24〜32GB）クラスで、

• 普段は チャット用に 70B 級（Q4 で 24GB ギリギリ、または 32B Q4 で余裕を持たせる）を載せておきたい
• エディタからの コード補完は 7B 級 を低レイテンシで使いたい
• 両方を同時に常駐させると VRAM が溢れる

この場合、llama-swap の TTL スワップで「使う方だけ載せる」運用にします。設定 YAML の骨子はこうです。

# llama-swap config.yaml（骨子）
models:
  "qwen2.5-72b-chat":
    cmd: >
      llama-server --model /models/qwen2.5-72b-q4.gguf
      --ctx-size 8192 --n-gpu-layers 99 --port 9001
    proxy: "http://localhost:9001"
    ttl: 600          # 10分アイドルで自動アンロード

  "qwen2.5-coder-7b":
    cmd: >
      llama-server --model /models/qwen2.5-coder-7b-q5.gguf
      --ctx-size 16384 --n-gpu-layers 99 --port 9002
    proxy: "http://localhost:9002"
    ttl: 300          # 5分アイドルで自動アンロード

# 同時常駐させたいモデル群はグループで定義
groups:
  "embeddings":
    - "bge-m3-embed"
    - "bge-reranker"

クライアントは http://localhost:8080/v1 へ model: "qwen2.5-72b-chat" または model: "qwen2.5-coder-7b" を投げるだけ。llama-swap が「コード補完が来たらチャットモデルを退避して 7B を載せ、アイドルが続けば自動で空ける」を捌きます。--ctx-size や --n-gpu-layers はそのままランタイム（llama.cpp）へ渡るので、モデルごとにコンテキスト長・GPU オフロード量を最適化できます。

VRAM がどのモデルでどれだけ消費されるか（量子化とコンテキスト長の影響）は「メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版」で扱っているので、TTL 設計の前に併読をおすすめします。

コーディング支援（Continue / Cline）から llama-swap を使う

複数モデル運用の動機として最も多いのが、「VS Code のコーディング支援（Continue / Cline など）でチャットと補完に別モデルを使いたい」というケースです。これらのクライアントは OpenAI 互換 API を話せるので、接続先を llama-swap の単一エンドポイントに向けるだけで上記の自動スワップがそのまま効きます。

Continue（VS Code拡張）の config.yaml なら、モデルごとに provider: openai と apiBase を指定します。

# Continue の config.yaml（モデル定義の骨子）
models:
  - name: Chat 72B (llama-swap)
    provider: openai
    model: qwen2.5-72b-chat        # llama-swap 側のモデル名と一致させる
    apiBase: http://localhost:8080/v1
    apiKey: dummy                  # ローカルでは認証不要なのでダミー文字列で可
    roles: [chat, edit]

  - name: Autocomplete 7B (llama-swap)
    provider: openai
    model: qwen2.5-coder-7b
    apiBase: http://localhost:8080/v1
    apiKey: dummy
    roles: [autocomplete]

ポイントは2つです。

• model 名を llama-swap の設定（前節の models: のキー）と一致させる。Continue がチャットを投げれば 72B が、補完を投げれば 7B が、llama-swap 側で自動的にロードされます
• llama-swap を挟まず Ollama を直接使う場合は provider: ollama（apiBase: http://localhost:11434）を指定します。ただしチャット用と補完用の載せ替えを自分で面倒見ることになるので、VRAM が限られる環境では llama-swap 経由に寄せるほうが運用が楽です

コーディングエージェント側のモデル選定やハード要件は「ローカルLLMでコーディングエージェントを動かすPCガイド 2026年版」にまとめています。

大容量 unified memory なら「グループ常駐」へ寄せる

VRAM が潤沢な環境では、戦略が逆になります。DGX Spark（128GB 級）や Strix Halo（VRAM 96GB 割当）、Mac Studio M3 Ultra（最大 512GB）のような大容量 unified memory 機では、TTL でスワップするより 複数モデルをグループで載せっぱなしにする ほうが応答が速くなります。

環境	VRAM / Unified	推奨戦略
RTX 4090（24GB）	24GB	TTL 逐次スワップ（載せ替え主体）
RTX 5090（32GB）	32GB	TTL スワップ + 小型モデルは常駐
Strix Halo（96GB 割当）	96GB	グループ常駐主体（70B + 複数小型を同居）
DGX Spark / Mac Studio M3 Ultra	128〜512GB	10+ モデルのグループ常駐

スワップにはモデルロードの待ち時間（数秒〜十数秒）が伴うため、VRAM に余裕があるなら「常駐させてロード待ちを消す」ほうが体感が良くなります。VRAM が制約なら TTL、潤沢ならグループ という使い分けが基本方針です。大容量機の選び方は「ミニPC / SFF（小型）PC 選び方ガイド 2026年版」が詳しいです。

導入の最短ルート

1. ランタイムを用意：まず llama.cpp（llama-server）または vLLM を単体で動かせる状態にする
2. llama-swap を入手：GitHub mostlygeek/llama-swap からバイナリを取得（Go 製単一バイナリ、Docker イメージもあり）
3. config.yaml を書く：上記の骨子をベースに、モデル定義 + ttl + groups を記述
4. 起動してダッシュボード確認：Web ダッシュボードで各モデルのロード状況を見ながら TTL を詰める
5. クライアントを単一エンドポイントへ向ける：OpenWebUI / Continue / 自作スクリプトの接続先を llama-swap のポートに統一

ポイントは ランタイム選定と運用設計を分けて考える ことです。「Ollama か llama.cpp か」はランタイムの話、「複数モデルをどう捌くか」は llama-swap の話。両者を切り分けると、自分の構成で何を変えればいいかが明確になります。

まとめ：llama-swap は「VRAM を時間軸で使い回す」ための装置

llama-swap の本質を 1 行で言うと 「限られた VRAM を、時間軸でモデル間に割り当てるスイッチャー」 です。Ollama / LM Studio がモデルを動かす「ランタイム本体」なのに対し、llama-swap は「どのモデルをいつ載せ、いつ空けるか」を自動で捌く前段プロキシ。役割が違うので競合せず、むしろ組み合わせて使います。

VRAM 24〜32GB で複数モデルを使い分けるなら TTL 自動アンロード、Strix Halo / DGX Spark / Mac Studio のような大容量機なら groups での同時常駐。手動 stop/run の往復に疲れているなら、導入の費用対効果は高いはずです。

入手先・関連商品

当サイトは Amazon.co.jp アソシエイト・プログラムに参加予定です。下記リンク経由で購入された場合、紹介料を受け取ることがあります。読者の負担は増えません。リンクは記事評価とは独立しており、編集判断には影響しません。

llama-swap はオープンソース（GitHub: mostlygeek/llama-swap）で無料です。複数モデル運用を快適にするのは結局 VRAM / unified memory 容量なので、ハードウェア側の選択肢を挙げます。

VRAM スワップ向け（24〜32GB クラス）

• GeForce RTX 5090 を Amazon.co.jp で見る

グループ常駐向け（大容量 unified memory）

• Ryzen AI MAX+ 395 ミニPC を Amazon.co.jp で見る
• Mac Studio M3 Ultra を Amazon.co.jp で見る

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• Ollama と llama.cpp の違い 2026年版：中身は同じ llama.cpp なのに何が違うのか
• ローカルLLM実行ツール比較 2026年版：Ollama / LM Studio / llama.cpp / vLLM
• メモリ帯域幅(GB/s)がローカルLLMの tok/sec を決める仕組み 2026年版