Ollamaが並列リクエストをどのように処理するか

このガイドでは、Ollamaが並行リクエストをどのように処理するか（並行性、キュー잉、リソース制限）と、OLLAMA_NUM_PARALLEL 環境変数（および関連する調整項目）を使用してそれをチューニングする方法について説明します。

ジャンプリnk: OLLAMA_NUM_PARALLEL とは? · クイックチューニングレシピ · キューの仕組み · トラブルシューティング · 関連: Ollama CLI コマンドチートシート

スループット、レイテンシ、VRAM、ランタイムやハードウェア間のベンチマークの詳細については、LLM パフォーマンス: ベンチマーク、ボトルネック & 最適化 を参照してください。

マルチステップエージェントは、サンプリングが不安定な場合にリトライを繰り返します。Qwen および Gemma クラスのモデルにおけるデフォルトの温度、top_p、ペナルティ設定については、Qwen と Gemma のエージェント推論パラメータ を参照してください。

並行リクエストの処理

• 並列処理: Ollama はリクエストの並行処理をサポートしています。システムに十分な空きメモリ（CPU 推論の場合は RAM、GPU 推論の場合は VRAM）がある場合、複数のモデルを同時にロードでき、各ロードされたモデルは複数のリクエストを並行して処理できます。これは環境変数 OLLAMA_NUM_PARALLEL によって制御され、各モデルが同時に処理できる並行リクエストの最大数を設定します。デフォルトでは 4 に設定されています（またはメモリ利用状況に応じて 1）が、調整可能です。

• バッチ処理: 同じモデルへの複数のリクエストが同時に到着した場合、Ollama はそれらをバッチ化してまとめて処理します。これは、両方のリクエストが並行して処理され、ユーザーは同時にストリーミングされたレスポンスを確認できることを意味します。サーバーはバッチを埋めるために意図的に待機しません。リクエストが利用可能になったらすぐに処理が開始されます。

キューと制限

• キューイング: 並行リクエスト数が設定された並列処理数（例：モデルに対する OLLAMA_NUM_PARALLEL を超えるリクエスト）を超えた場合、追加のリクエストはキューに追加されます。キューは先入れ先出し（FIFO）方式で動作します。

• キューの制限: キューに追加されるリクエストの最大数は OLLAMA_MAX_QUEUE によって制御されます（デフォルト: 512）。キューが満杯の場合、新しいリクエストはサーバーが過負荷であることを示す 503 エラーを受けます。

• モデルのロード: 同時にロードできる異なるモデルの数は OLLAMA_MAX_LOADED_MODELS によって制御されます。リクエストに新しいモデルのロードが必要でメモリが不足している場合、Ollama はアイドル状態のモデルをアンロードしてスペースを確保し、モデルがロードされるまでリクエストをキューに追加します。

シナリオの例

同じモデルへの 2 つのリクエストが同時に到着し、サーバーの並列処理が 2 以上設定されている場合、両方のリクエストはバッチでまとめて処理され、両方のユーザーは同時にレスポンスを受信します。並列処理が 1 に設定されている場合、1 つのリクエストは直ちに処理され、もう 1 つは最初の処理が完了するまでキューに追加されます。

リクエストが異なるモデル用であり、メモリに十分な容量がある場合、両方のモデルをロードしてリクエストを並行して処理できます。十分なメモリがない場合、1 つのモデルをアンロードする必要がある場合があり、リクエストはキューに追加されます。

まとめテーブル

要約すると、Ollama はサーバーが並行性用に構成され、十分なリソースがある場合に、複数の同時リクエストを効率的に処理するように設計されています。それ以外の場合、リクエストはキューに追加されて順番に処理されます。

OLLAMA_NUM_PARALLEL をraisingしてもレイテンシが安定せず、実際のトラフィック下でキューが持续增长する場合、それは専用サービングエンジンへの移行を検討するに値する明確な兆候の一つです。Ollama から vLLM へ: ローカル LLM サーバーを移行するタイミング では、vLLM が並行リクエストの相互劣化を防ぐために使用する継続的バッチ処理と PagedAttention などのメカニズムを含む、その決定プロセスについて解説しています。

メモリ不足の処理

Ollama が受信リクエストを処理するのに十分なメモリに遭遇しない場合、安定性を維持するためにキューイングメカニズムとリソース管理戦略の組み合わせを採用します：

リクエストキューイング

• メモリが直ちに割り当てられない場合、新しいリクエストは FIFO（先入れ先出し）キューに配置されます。
• キューのサイズは OLLAMA_MAX_QUEUE（デフォルト: 512 リクエスト）によって制御されます。
• キューが容量に達した場合、新しいリクエストは 503「サーバー過負荷」エラーを受けます。

モデル管理

• アクティブなモデルは、アイドル状態になったときにリソースを解放するためにメモリからアンロードされる場合があります。
• 同時にロードされるモデルの数は OLLAMA_MAX_LOADED_MODELS（デフォルト: GPU 数×3 または CPU の場合は 3）によって制限されます。

メモリ最適化

• 同じモデルのリクエストをバッチ処理して、メモリ効率を最大化しようとします。
• GPU 推論の場合、モデルごとに VRAM の完全な割り当てが必要です。部分的なロードはサポートされていません。

失敗シナリオ

深刻なメモリ枯渇: キューされたリクエストですら利用可能なリソースを超えた場合、Ollama は次のようになります：

• ディスクへのページング（パフォーマンスが著しく劣化）
• 「メモリ不足」エラーの返却
• 極端な場合、モデルインスタンスのクラッシュ

管理者は、ハードウェアの機能に基づいてメモリ使用量を監視し、これらのパラメータを調整する必要があります。メモリ不足の処理は、大規模モデル（7B 以上パラメータ）を実行する場合や、複数の並行リクエストを処理する場合に重要になります。

Ollama の最適化戦略

export OLLAMA_CUDA=1 で GPU アクセラレーションを有効にし、export OLLAMA_NUM_THREADS=84 で CPU スレッドを設定します。 ハードウェアの強化

• RAM: 13B モデルには 32GB 以上、70B モデルには 64GB 以上
• ストレージ: より高速なモデルのロード/スワップのための NVMe SSD
• GPU: 大規模モデル向けの NVIDIA RTX 3080/4090（16GB 以上の VRAM）

運用戦略

• バッチリクエスト: メモリオーバーヘッドを分散させるために複数のクエリを同時に処理
• 自動モデルアンロード: Ollama がアイドル状態のモデルをメモリから削除する
• 頻繁に使用するモデルのキャッシュ: 一般的なモデルをメモリに保持

モニタリング & トラブルシューティング

• nvidia-smi（GPU）と htop（CPU/RAM）を使用してボトルネックを特定
• メモリエラーの場合:
• 量子化モデルにアップグレード
• 並行リクエストを削減
• スワップスペースを増加

最適化ワークフローの例:

### GPU アクセラレーション付き量子化モデルを使用
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048

### ロードされたモデルと並行リクエストを制限
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4

これらの調整により、メモリ使用量を 30-60% 削減でき、レスポンス品質を維持できます。特に複数のモデルを実行する場合や、大量のリクエストを処理する場合に有益です。

OLLAMA_NUM_PARALLEL 環境変数

OLLAMA_NUM_PARALLEL は、Ollama が並行して実行するリクエストの数を制御します。 同じ Ollama サーバーに複数のリクエストを送信する場合、この設定はそれらが並行して実行されるか、キューに追加されるかを大きく決定します。

• 高い値は、十分な CPU/GPU/VRAM を持っている場合、スループットを向上させる可能性がありますが、レイテンシとメモリ圧力を増加させる可能性があります。
• 低い値は競合を減らし、安定性を向上させる可能性がありますが、リクエストがより頻繁にキューに追加されます。

OLLAMA_NUM_PARALLEL の設定方法

Linux / macOS (systemd サービスまたはシェル):

export OLLAMA_NUM_PARALLEL=2
ollama serve

一回限りの実行（このコマンドのプレフィックスのみ）:

OLLAMA_NUM_PARALLEL=2 ollama serve

Docker（例）:

docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama

値の選択方法

単一の GPU / 制限された VRAM に対して 1–2 で始め、次に徐々に増やしながら以下を監視します:

• GPU VRAM 使用量（OOM / 退避）
• CPU 使用率と負荷平均
• 通常のリクエストの p95 レイテンシ
• エラー率 / タイムアウト

CLI の使用のために特定のページを最適化している場合は、チートシートの Ollama CLI セクションと、ollama serve、ollama ps、ollama run のコマンド例を参照してください。

クイックチューニングレシピ

安定性ファースト

• OLLAMA_NUM_PARALLEL=1
• より小さい / 量子化モデルを使用
• より短いコンテキストサイズを優先

スループットファースト

• OLLAMA_NUM_PARALLEL=2（余裕がある場合はそれ以上）
• クライアント層でのリクエストバッチ処理を検討
• 十分な VRAM と CPU スレッドを確保

「2 つのリクエストが到着すると VRAM が不足する」

• OLLAMA_NUM_PARALLEL を削減
• より積極的な量子化モデルを使用
• コンテキスト長 / 最大トークン数を削減

トラブルシューティング

OLLAMA_NUM_PARALLEL が高すぎる兆候

• 負荷下でリクエストが断続的に失敗する
• GPU OOM / モデルアンロードが頻繁に発生する
• 2 つ目のリクエストが到着するとレイテンシが急上昇する

OLLAMA_NUM_PARALLEL が低すぎる兆候

• CPU/GPU が未活用
• キューイング遅延が合計レスポンス時間の大部分を占める

ヒント: クライアントも制御できる場合、ジッター付きリトライと Keep-alive 接続を追加してください。多くの「Ollama が遅い」問題は、実際にはキューイング + 接続オーバーヘッドです。

Ollama: バッチリクエスト vs 並列実行

Ollama におけるバッチ処理は、複数の受信リクエストをグループ化してユニットとして処理する慣行を指します。これにより、並列化された操作（GPU などのハードウェア）から利益を得る場合に、計算リソースをより効率的に使用できます。

同じモデルへの複数のリクエストが同時に到着する場合、メモリが許す限り、Ollama はそれらをバッチでまとめて処理できます。これによりスループットが向上し、モデルがバッチに対して最適化された行列演算を活用できるため、各リクエストのレイテンシが削減される可能性があります。

バッチ処理は、リクエストのサイズと複雑さが類似している場合に特に効果的で、これによりハードウェアの活用が向上します。

Ollama における並列実行は、利用可能なメモリと構成に応じて、同じモデルまたは異なるモデルに対して複数のリクエストを同時に処理することを意味します。

Ollama は 2 つのレベルの並列性をサポートしています:

• 複数モデルのロード: 十分なメモリがある場合、複数のモデルをロードして同時にリクエストを処理できます。
• モデルあたりの並行リクエスト: 各ロードされたモデルは、OLLAMA_NUM_PARALLEL 設定（デフォルトはメモリに応じて 1 または 4）によって制御され、複数のリクエストを並行して処理できます。

リクエストが並列制限を超えた場合、それらは OLLAMA_MAX_QUEUE までキュー（FIFO）に追加されます。

まとめ

Ollama は、バッチ処理と並列実行の両方を利用して、複数のリクエストを効率的に処理します。バッチ処理はリクエストをグループ化して同時処理を行い、並列実行は複数のリクエスト（またはモデル）を並行して実行することを可能にします。両方とも システムメモリ に依存し、最適なパフォーマンスのために構成可能です。

さらにベンチマーク、並行性チューニング、パフォーマンスガイダンスについては、LLM パフォーマンス: ベンチマーク、ボトルネック & 最適化 ハブをチェックしてください。

有用なリンク

• Ollama コマンドチートシート
• LLM パフォーマンス比較 - 16GB VRAM GPU 上の Ollama
• Ollama モデルを別のドライブまたはフォルダに移動
• Ollama が Intel CPU のパフォーマンスコアと効率的なコアをどのように使用しているか
• Ollama から vLLM へ: ローカル LLM サーバーを移行するタイミング