Ollama マルチモデル並列実行：Qwen、Llama、DeepSeek 設定実践

Ollama 0.2 以降、複数のモデルを同時に動かせるようになりました。ollama run deepseek-coder でコードに切り替え、次に ollama run qwen2.5 で翻訳に切り替え、そのたびに 10 数秒待ってロードし直す——そんな必要はもうありません。1 つのサービスで 3 つのモデルを必要に応じて呼び出せます。DeepSeek はコード処理、Qwen は中国語処理、Llama は汎用的な質問に対応します。

3 つの環境変数でマルチモデル並列実行を有効にできます。OLLAMA_MAX_LOADED_MODELS で同時ロード数を、OLLAMA_NUM_PARALLEL で 1 モデルあたりの並列数を、OLLAMA_KEEP_ALIVE で待機時間を制御します。この記事では、設定方法、3 つのモデルそれぞれの得意分野、そしてメモリ管理のコツ——よく使うモデルの事前ロード、たまにしか使わないモデルの必要時呼び出し、VRAM が足りないときのシステムメモリの活用——を詳しく解説します。

Ollama マルチモデル並列実行の基本設定

まずは良いニュースから。Ollama 0.2 以降、マルチモデル並列実行はネイティブにサポートされた機能です。追加のプラグインを入れる必要も、複雑な設定ファイルをいじる必要もありません。いくつかの環境変数だけで、複数のモデルをおとなしく待機させられます。

悪いニュースは、もし VRAM（ビデオメモリ）が足りなければ、これらのモデルがシステムメモリを食い尽くし、パソコンが牛車のように遅くなって、人生を疑うほどになる可能性があることです。

3 つの重要な環境変数

ターミナルを開いて、まずこの 3 つの変数を見てみましょう。

# 同時にロードするモデルの最大数
export OLLAMA_MAX_LOADED_MODELS=3

# 1 つのモデルが同時に処理できるリクエストの最大数
export OLLAMA_NUM_PARALLEL=2

# 待機キューの最大長（超えると新しいリクエストを拒否）
export OLLAMA_MAX_QUEUE=512

OLLAMA_MAX_LOADED_MODELS が要です。3 に設定すれば、Qwen、Llama、DeepSeek の 3 つを同時に動かせます。ただし、いきなり大きな値にしないでください——この値はハードウェアに制約されます。メモリ要件については後ほど詳しく説明します。

OLLAMA_NUM_PARALLEL が制御するのは、1 つのモデルの並列処理能力です。サービスが同時に複数のリクエストを受け取るなら、この値を高めに設定できます。とはいえ正直なところ、個人利用ならデフォルト値で十分です。

システムサービスの設定（Linux）

systemd で Ollama サービスを管理している場合（多くの Linux ディストリビューションのデフォルト方式）、設定はとても簡単です。

sudo systemctl edit ollama.service

開いたエディタに次を追加します。

[Service]
Environment="OLLAMA_MAX_LOADED_MODELS=3"
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_KEEP_ALIVE=30m"

保存して終了し、サービスを再起動します。

sudo systemctl restart ollama

OLLAMA_KEEP_ALIVE という変数はとても面白いものです。これはモデルがメモリ内で「待機」する時間を制御します。30m に設定すると、モデルはロード後 30 分間メモリ内に保持され、次に呼び出すときはロードし直さずに済みます。ずっと待機させたいなら -1 に設定できます。

メモリは足りる？ 判断する 1 つの方法

設定はできましたが、メモリは足りるでしょうか。

ざっくりした見積もりです。7B モデルはおよそ 4〜5GB の VRAM（FP16 量子化）、14B モデルは 8〜10GB が必要です。7B モデルを 3 つ同時にロードするなら、少なくとも 16GB の VRAM を積んだ GPU が必要です。

私の RTX 3060 は 12GB の VRAM しかありません。7B モデルを 2 つ動かすのはまだスムーズですが、3 つ目はシステムメモリを借りるしかなく——速度は大きく落ちます。Mac（Apple Silicon）を使っているなら、システムメモリと GPU メモリは共有なので、32GB の統合メモリがあれば 3 つのモデルを動かすのに余裕があります。

3 大モデルの特徴と選択戦略

さて、設定は終わりました。次はこの 3 つのモデルをどう選ぶかを話しましょう。正直なところ、私も最初はかなり迷いました——3 つともダウンロードしたものの、使うたびにどれを呼び出せばいいか分からなかったのです。しばらく試行錯誤して、ようやく少しコツがつかめてきました。

Qwen：中国語と多言語の神

アリババがオープンソースで公開した Qwen シリーズは、中国語能力が本当に優れています。これで中国語ドキュメントをいくつも書いたり、英語の技術記事を数本翻訳したりしましたが、どれも良い出来でした。公式データによると、Qwen は 100 以上の言語をサポートしています——中国語と英語だけでなく、日本語、韓国語、フランス語、スペイン語も処理できます。

中国語のコンテンツをよく扱うなら、あるいは多言語の翻訳をするなら、Qwen が第一候補です。qwen2.5:7b で 5000 字の技術ドキュメントの翻訳をしたことがありますが、翻訳品質は多くのオンライン翻訳ツールよりかなり良かったです。特に技術用語の翻訳では、「API endpoint」を「API 終点」のような奇妙な言葉に訳すことはありません。

Llama：汎用能力が最もバランス良い

Meta の Llama シリーズは、オープンソースモデルの中の「大御所」です。タスクの種類がはっきりしないなら、Llama を使えば、たいていは外れません。

大きな強みが 1 つあります。商用ライセンスがとても緩いのです。製品の月間アクティブユーザーが 700 万人を超えなければ、無料で商用利用できます。これは多くの個人開発者や小規模チームにとって、かなり重要な検討材料になります。

もう 1 つの利点は、コンテキストウィンドウが大きいことです。Llama 3.2 のコンテキストは 128K トークンに達します——小説 1 冊をまるごと収められるほどです。長いドキュメントを扱う必要があるなら、この強みは大きいでしょう。

DeepSeek：コーディングと推論の切り札

DeepSeek は最近使い始めたばかりですが、すぐに気に入りました。特にコーディングのタスクでは、その出来栄えに少し驚かされました——生成されるコードの品質が高く、コードのロジックを自分から説明してくれるのです。

Premai の比較レポートによると、DeepSeek の推論コストは同種のモデルより 95% 低いとのことです。大量の推論タスクを必要とする人にとって、これは実に確かな強みです。コストが低いということは、限られたハードウェアでより多くのタスクをこなせるということです。

どう選ぶ？ 1 枚の表で解決

タスクの種類	おすすめモデル	理由
中国語の執筆、翻訳	Qwen	中国語能力が最強、100 以上の言語をサポート
多言語コンテンツ	Qwen	多言語処理能力でリード
コード生成、デバッグ	DeepSeek	コーディング能力が高く、説明が明快
技術的な推論、分析	DeepSeek	推論コストが最も低く、効率的
汎用 Q&A、雑談	Llama	バランスが良く、外れにくい
長文ドキュメント処理	Llama	128K のコンテキストウィンドウ
商用プロジェクト（<700M MAU）	Llama	商用ライセンスが最も緩い

私個人の習慣はこうです。コードを書くときは DeepSeek、中国語ドキュメントを書くときは Qwen、英語のコンテンツや判断に迷うタスクは Llama。3 つのモデルの役割分担が明確なので、どれを使うか悩むことはほとんどなくなりました。

モデル切り替えとメモリ管理

正直に言うと、マルチモデルを使い始めたころ、最大の悩みは切り替えが遅すぎることでした。違うモデルを呼び出すたびに、しばらく待たされる——モデルがロードし直され、GPU のファンがうなりを上げ、あの待ち時間は本当に気が滅入りました。あとから知ったのですが、この遅延は最適化できるのです。

切り替え遅延はどういう仕組み？

モデル切り替えの遅延は、だいたい 10〜30 秒です。具体的な時間は、モデルのサイズ、ディスクの読み書き速度、そしてメモリの状態によります。7B モデルをディスクから GPU にロードするのにおよそ 10〜15 秒、14B モデルなら 20〜30 秒かかることもあります。

この遅延は実際の利用ではかなり煩わしいものです。特にコードをデバッグしているとき、DeepSeek で関数を生成した直後に Qwen でコメントを翻訳したいのに、長々と待たされるのです。

keep_alive：モデルを「ずっと待機」させる

解決策は、前述の OLLAMA_KEEP_ALIVE です。

原理はシンプルです。モデルは一度ロードしたら、メモリ内でアンロードせずに保持します。次に同じモデルを呼び出すときは、ロードし直さずにそのまま使えます。

グローバルに設定できます。

export OLLAMA_KEEP_ALIVE=30m  # モデルをロード後 30 分間保持
# または
export OLLAMA_KEEP_ALIVE=-1   # 手動でアンロードするまで無期限に保持

個別のリクエストでこの設定を上書きすることもできます。

curl http://localhost:11434/api/generate \
  -d '{"model": "qwen2.5:7b", "prompt": "", "keep_alive": "60m"}'

空のリクエスト（prompt を空に）を送ると、モデルはロードされてメモリ内に保持されます。これは事前ロードの良い方法です——よく使うモデルをあらかじめロードしておけば、後の呼び出しは即座に応答します。

モデルを手動でアンロードする

メモリが逼迫しているなら、あるモデルを手動でアンロードできます。

curl http://localhost:11434/api/generate \
  -d '{"model": "qwen2.5:7b", "keep_alive": 0}'

keep_alive を 0 に設定すると、モデルはすぐにメモリからアンロードされます。この操作でモデルファイルが削除されることはなく、占有していたメモリが解放されるだけです。

モデルサイズ別のメモリ要件

この表はしばらくかけてまとめたもので、あくまで参考用です（データはコミュニティのフィードバックと私の実測によるものです）。

モデルサイズ	FP16 量子化	Q4 量子化	おすすめ GPU
7B	14〜16GB	4〜5GB	RTX 3060 (12GB) 以上
14B	28〜32GB	8〜10GB	RTX 4070 (12GB) 以上
32B	64〜70GB	18〜20GB	RTX 4090 (24GB) 以上

私の RTX 3060 は 12GB の VRAM があります。Q4 量子化を使えば、14B 1 つと 7B 1 つ、あるいは 7B モデルを 3 つ同時に動かせます。3 つ目のモデルはシステムメモリを借りるので速度はやや落ちますが、クラッシュはしません。

GPU の VRAM が足りなくても、システムメモリが十分大きければ（32GB 以上）、CPU 推論を使うこともできます。速度はかなり遅くなりますが、使えます。使えればそれで十分なこともあるのです。

ちょっとしたコツ：よく使うモデルを優先ロード

私にはこんな習慣があります。最もよく使うモデルを優先して GPU にロードし、ほかのモデルはシステムメモリを借りるようにするのです。

たとえば私のワークフローでは DeepSeek を最もよく使うので、これを GPU に置いてずっと待機させます。Qwen と Llama はあまり使わないので、呼び出すときにロードし、システムメモリを借りることもあります。

こう配置すると、頻度の高いタスクの応答が最も速くなり、頻度の低いタスクは少し遅くなりますが、全体的な体験は良くなります。自分の利用習慣に合わせてこの順序を調整できます。

実践的な活用シーン

理論をここまで語ってきましたが、実際にどう使うかを話しましょう。以下は私がよく使うシーンです。何かのヒントになれば幸いです。

コーディングアシスタント：コード + ドキュメント

これは私が最もよく使うシーンです。コードを書くとき、2 つのモデルを組み合わせて使います。

• DeepSeek でコードのロジック生成、コードの説明、バグのデバッグ
• Qwen でコードコメントの翻訳、中国語ドキュメントの生成

例を挙げましょう。ある API インターフェースを書くとき、まず DeepSeek でコードの骨格を生成します。

curl http://localhost:11434/api/generate \
  -d '{"model": "deepseek-coder:6.7b", "prompt": "ユーザー登録とログインを処理する Express.js の RESTful API を書いて"}'

コードを生成したら、次に Qwen でコメントを中国語に翻訳します。

curl http://localhost:11434/api/generate \
  -d '{"model": "qwen2.5:7b", "prompt": "このコードの英語コメントを中国語に翻訳して：\n[コードの内容]"}'

2 つのモデルで役割分担すると、1 つのモデルだけを使うよりかなり効率が上がります。DeepSeek が生成するコードの品質はかなり信頼でき、Qwen の翻訳も自然で流暢です。

スマートカスタマーサポート：中英バイリンガル

国際ユーザー向けのカスタマーサポートシステムを作るなら、こう配置できます。

• Llama で英語ユーザーの問い合わせに対応
• Qwen で中国語ユーザーの問い合わせに対応

実装もそれほど複雑ではありません。ユーザーの入力した言語を検出し、対応するモデルを呼び出します。

import requests

def get_response(user_input, language):
    model = "llama3.2:3b" if language == "en" else "qwen2.5:7b"

    response = requests.post(
        "http://localhost:11434/api/generate",
        json={"model": model, "prompt": user_input, "stream": False}
    )

    return response.json()["response"]

こうすれば、それぞれのユーザーが対応する言語の自然な返信を受け取れ、単一言語のモデルよりずっと良い体験になります。

ナレッジ Q&A：推論 + 雑談

ユーザーの質問の種類が違えば、異なる処理方法が必要になることがあります。

• DeepSeek で推論が必要な質問（「なぜ」「どうやって」など）に対応
• Llama でオープンな Q&A（「どう思う」「どう見る」など）に対応

推論を要する質問には論理的な分析が必要で、DeepSeek の推論能力は比較的高く、答えにより筋道が通っています。オープンな Q&A には厳密な推論は不要で、Llama の回答のほうが自然で、おしゃべりに近い感じになります。

質問のキーワードで種類を判断できます。たとえば質問に「なぜ」「原因」「原理」が含まれていれば DeepSeek を、「どう思う」「どう見る」「ちょっと話して」が含まれていれば Llama を使います。

完全な呼び出しの例

以下は、タスクの種類に応じて自動でモデルを選ぶシンプルな Python スクリプトです。

import requests

def call_ollama(task_type, prompt):
    """タスクの種類に応じて適切なモデルを選ぶ"""

    model_map = {
        "code": "deepseek-coder:6.7b",
        "chinese": "qwen2.5:7b",
        "english": "llama3.2:3b",
        "reasoning": "deepseek-coder:6.7b",
        "general": "llama3.2:3b"
    }

    model = model_map.get(task_type, "llama3.2:3b")

    # モデルの事前ロード（任意）
    requests.post(
        "http://localhost:11434/api/generate",
        json={"model": model, "prompt": "", "keep_alive": "30m"}
    )

    # 実際の呼び出し
    response = requests.post(
        "http://localhost/11434/api/generate",
        json={"model": model, "prompt": prompt, "stream": False}
    )

    return response.json()["response"]

# 呼び出しの例
result = call_ollama("code", "フィボナッチ数列の第 N 項を計算する Python 関数を書いて")
print(result)

このスクリプトはとてもシンプルですが、すでに基本的なマルチモデルのスケジューリングを実現できています。必要に応じて拡張できます。たとえばタスクの種類を増やしたり、より複雑な選択ロジックを加えたり、3 つのモデルの回答を統合したりできます。

そうそう、Ollama の基本的な使い方をもっと深く知りたいなら、シリーズの最初の 2 本の記事を読んでみてください。『Ollama 入門：ローカルで大規模言語モデルを動かす第一歩』と『Ollama Modelfile パラメータ詳解』です。この記事はその続きにあたり、マルチモデルデプロイという発展的なテーマを補うものです。

設定早見表

変数	推奨値	役割
OLLAMA_MAX_LOADED_MODELS	2〜3	同時にロードするモデルの数
OLLAMA_NUM_PARALLEL	2	1 モデルあたりの並列リクエスト数
OLLAMA_KEEP_ALIVE	30m または -1	モデルの待機時間
OLLAMA_MAX_QUEUE	512	待機キューの長さ

まとめ

長々と語ってきましたが、要は次の 3 点です。

1. 3 つの環境変数を設定するだけで、マルチモデルを並列で動かせます。OLLAMA_MAX_LOADED_MODELS で数を、OLLAMA_KEEP_ALIVE で待機時間を制御します。

2. タスクに応じてモデルを選ぶ。コードは DeepSeek、中国語は Qwen、汎用は Llama。悩まなくて大丈夫、それぞれに得意分野があります。

3. メモリ管理が重要です。よく使うモデルは事前ロード、たまにしか使わないモデルは必要時に呼び出し。VRAM が足りなければシステムメモリを借りる、使えればそれでよし。

16GB 以上の VRAM を積んだ GPU、あるいは 32GB 以上の統合メモリを積んだ Mac があるなら、3 つのモデルの並列デプロイをぜひ試してみてください。最初はしばらく試行錯誤が必要かもしれませんが、設定が決まれば、単一モデルよりずっと良い体験になります。頻繁に切り替える必要も、ロードを待つ必要もなく、あの快適さはなかなか気持ちのいいものです。

何か問題があったり、どこかでつまずいたりしたら、コメントで気軽に交流しましょう。私もまだ学んでいる最中です。あなたが出くわした問題に、たまたま私が答えを持っているかもしれません。