Ollama マルチモデルデプロイ：Qwen、Llama、DeepSeek の並列実行

午前3時、ターミナルでスクロールするログを眺めながら、17回目のモデル切り替え。ollama run deepseek-coder でコードを処理し、ollama run qwen2.5 でドキュメントを翻訳し、ollama run llama3.2 で一般的な質問に答える。每次切り替えるたびに十数秒待つ必要があり、GPUファンが唸りを上げて、まるで私の悪戦苦闘に抗議しているようだ。

このような日々を半月以上続けて、ようやく気づいた：Ollama 0.2以降、複数のモデルを同時に実行できるのだ。切り替える必要はない。毎回リロードする必要もない。1つのサービスで3つのモデルを、必要に応じて呼び出す。

この記事では、1台のマシンでQwen、Llama、DeepSeekの3つのモデルをデプロイし、それぞれの役割を分担させつつ、GPUメモリを使い果たさない方法についてお話ししたい。具体的な設定方法、3つのモデルのそれぞれの強み、そして私が踏んだ落とし穴について共有する。

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

まず良いニュースから：Ollama 0.2以降、マルチモデル並列実行はネイティブサポートされている。追加プラグインは不要、複雑な設定ファイルをいじる必要もない。いくつかの環境変数を設定すれば、複数のモデルが待機してくれる。

悪いニュースは、GPUメモリ（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は単一モデルの並列処理能力を制御する。サービスが同時に複数のリクエストを受信する場合、この値を高く設定できる。正直なところ、個人使用ならデフォルト値で十分だ。

システムサービス設定（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に設定する。

メモリは足りる？簡単なチェック方法

設定は完了したが、メモリは十分か？

大まかな見積もり：7Bモデルは約4-5GB VRAM（FP16量子化）、14Bモデルは8-10GB必要。3つの7Bモデルを同時に読み込むには、少なくとも16GB VRAMのGPUが必要だ。

私のRTX 3060は12GB VRAMしかない。2つの7Bモデルを実行するのはスムーズだが、3つ目のモデルはシステムメモリを借用する必要がある——速度は大幅に低下する。Apple Silicon搭載のMacを使用している場合、システムメモリとGPUメモリは共有されるため、32GBの統合メモリがあれば3つのモデルを余裕で処理できる。

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

さて、設定は完了した。次に、この3つのモデルをどう選ぶかについて話そう。正直、最初はかなり迷っていた——3つのモデルをすべてダウンロードしたが、毎回どれを使うべきかわからなかった。いろいろ試して、いくつかのパターンをまとめた。

Qwen：中国語と多言語の王者

AlibabaのオープンソースQwenシリーズは、中国語能力が本当に強い。多くの中国語ドキュメントを書き、いくつかの英語の技術記事を翻訳したが、結果は良かった。公式データによると、Qwenは100以上の言語をサポート——中国語と英語だけでなく、日本語、韓国語、フランス語、スペイン語なども処理できる。

中国語コンテンツを頻繁に扱う場合や多言語翻訳を行う場合、Qwenが第一選択だ。qwen2.5:7bを使って5000語の技術文書を翻訳したが、多くのオンライン翻訳ツールより品質が良かった。特に技術用語の翻訳について——“API endpoint”を奇妙な”API 終点”のように翻訳することはない。

Llama：最もバランスの取れたオールラウンダー

MetaのLlamaシリーズは、オープンソースモデル界の「兄貴分」だ。タスクタイプがわからない場合は、Llamaを使えば間違ない。

大きな利点がある：商用ライセンスが非常に寛容だ。製品の月間アクティブユーザーが7億人未満であれば、商用利用が無料だ。これは多くの個人開発者和小規模チームにとって重要な考慮事項だ。

もう一つの利点は、大きなコンテキストウィンドウだ。Llama 3.2は128Kトークンまで処理できる——小説1冊分くらいだ。非常に長いドキュメントを処理する必要がある場合、この利点は明らかだ。

DeepSeek：コーディングと推論の強力ツール

DeepSeekは最近使い始めたばかりだが、すぐに気に入った。特にコーディングタスクでは、そのパフォーマンスに驚かされた——生成されるコードの品質が高く、コードロジックを積極的に説明してくれる。

Premaiの比較レポートによると、DeepSeekの推論コストは同類モデルより95%低い。多くの推論タスクを必要とする人にとって、これは実質的な利点だ。低コストは、限られたハードウェアでより多くのタスクを実行できることを意味する。

どれを選ぶ？クイックリファレンステーブル

タスクタイプ	推奨モデル	理由
中国語執筆、翻訳	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が空）を送信すると、モデルが読み込まれメモリに保持される。これはプリロードの良い方法だ——よく使うモデルを事前に読み込んでおけば、後の呼び出しで即座に応答する。

モデルの手動アンロード

メモリが tight な場合、特定のモデルを手動でアンロードできる：

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量子化なら、1つの14Bと1つの7Bを同時に実行できるか、3つの7Bモデルを実行できる。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入門：ローカルでLLMを実行する最初の一歩」と「Ollama Modelfileパラメータ詳解：カスタムモデル作成の完全ガイド」。この記事はシリーズの続きで、マルチモデルデプロイという高度なトピックをカバーしている。

設定クイックリファレンス

変数	推奨値	目的
`OLLAMA_MAX_LOADED_MODELS`	2-3	同時に読み込むモデル数
`OLLAMA_NUM_PARALLEL`	2	モデルごとの同時リクエスト数
`OLLAMA_KEEP_ALIVE`	30m または -1	モデル待機時間
`OLLAMA_MAX_QUEUE`	512	キュー長

まとめ

長々と話したが、核心は3点に尽きる：

3つの環境変数を設定すれば、マルチモデル並列実行が可能。OLLAMA_MAX_LOADED_MODELSが数量を制御し、OLLAMA_KEEP_ALIVEが待機時間を制御する。
タスクに応じてモデルを選択。コードはDeepSeek、中国語はQwen、汎用はLlama。悩みすぎない——それぞれに強みがある。
メモリ管理が重要。高頻度モデルをプリロードし、低頻度モデルはオンデマンドで読み込む。GPUメモリが足りない？システムメモリを借りればいい——動けば十分。

16GB以上のVRAMを持つGPU、または32GB以上の統合メモリを持つMacをお持ちなら、3つのモデルの並列デプロイを試してみてください。最初は学習曲線があるかもしれないが、設定が完了すれば、単一モデルよりはるかに良い体験が得られる。頻繁な切り替え不要、ロード待ち不要——そのスムーズさはかなり満足感がある。

質問やハマった落とし穴があれば、コメントで教えてください。私も学習中なので、あなたが遭遇した問題の答えを持っているかもしれない。

6 min read · 公開日: 2026年4月6日 · 更新日: 2026年4月8日

default

AI・インテリジェンス

Ollama マルチモデルデプロイ：Qwen、Llama、DeepSeek の並列実行

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

3つの重要な環境変数

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

メモリは足りる？簡単なチェック方法

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

Qwen：中国語と多言語の王者

Llama：最もバランスの取れたオールラウンダー

DeepSeek：コーディングと推論の強力ツール

どれを選ぶ？クイックリファレンステーブル

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

切り替え遅延の原因は？

keep_alive：モデルを「常に待機」させる

モデルの手動アンロード

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

小さなヒント：高頻度モデルを優先

実践的な応用シナリオ

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

スマートカスタマーサービス：日英バイリンガル

ナレッジQ&A：推論 + チャット

完全な呼び出し例

設定クイックリファレンス

まとめ

コメント

Ollama Embedding 実践：ローカルベクトル検索と RAG 構築

Ollama Embedding 実践：ローカルベクトル検索と RAG 構築

LangChain + Ollama 統合ガイド：ローカル LLM アプリ開発完全マニュアル

LangChain + Ollama 統合ガイド：ローカル LLM アプリ開発完全マニュアル

Ollama Modelfile パラメータ詳解：カスタムモデル作成の完全ガイド

Ollama Modelfile パラメータ詳解：カスタムモデル作成の完全ガイド

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

3つの重要な環境変数

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

メモリは足りる？簡単なチェック方法

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

Qwen：中国語と多言語の王者

Llama：最もバランスの取れたオールラウンダー

DeepSeek：コーディングと推論の強力ツール

どれを選ぶ？クイックリファレンステーブル

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

切り替え遅延の原因は？

keep_alive：モデルを「常に待機」させる

モデルの手動アンロード

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

小さなヒント：高頻度モデルを優先

実践的な応用シナリオ

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

スマートカスタマーサービス：日英バイリンガル

ナレッジQ&A：推論 + チャット

完全な呼び出し例

設定クイックリファレンス

まとめ

コメント

関連記事

Ollama Embedding 実践：ローカルベクトル検索と RAG 構築

Ollama Embedding 実践：ローカルベクトル検索と RAG 構築

LangChain + Ollama 統合ガイド：ローカル LLM アプリ開発完全マニュアル

LangChain + Ollama 統合ガイド：ローカル LLM アプリ開発完全マニュアル

Ollama Modelfile パラメータ詳解：カスタムモデル作成の完全ガイド

Ollama Modelfile パラメータ詳解：カスタムモデル作成の完全ガイド