Ollamaが並列リクエストをどのように処理するか
Ollamaの並行処理、キューイングの仕組み、および安定した並列リクエストを実現するためのOLLAMA_NUM_PARALLELのチューニング方法について理解する。
このガイドでは、Ollamaが並列リクエストをどのように処理するか(並行処理、キューイング、リソース制限)および**OLLAMA_NUM_PARALLEL環境変数**(および関連する設定)を使用してチューニングする方法を説明します。
ジャンプラインク: OLLAMA_NUM_PARALLELとは? · クイックチューニングレシピ · キューイングの仕組み · トラブルシューティング · 関連: Ollama CLIコマンドチートシート
スループット、レイテンシ、VRAM、およびランタイムとハードウェア間のベンチマークについて詳しくは、LLMパフォーマンス: ベンチマーク、ボトルネック & 最適化をご参照ください。
マルチステップエージェントは、サンプリングが不安定な場合にリ試行を倍増させます。QwenおよびGemmaクラスのモデルにおけるデフォルトのtemperature、top_p、およびpenalty設定については、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つのモデルをアンロードする必要がある場合があり、リクエストはキューに追加されます。
まとめ表
| シナリオ | 結果 |
|---|---|
| 2つのリクエスト、同じモデル、十分な並列度 | 両方ともバッチ化されて並列に処理される |
| 2つのリクエスト、同じモデル、並列度=1 | 1つが処理され、2つ目は1つ目が完了するまでキューに追加される |
| 2つのリクエスト、異なるモデル、十分なメモリ | 両方のモデルがロードされ、リクエストが並行して処理される |
| 2つのリクエスト、異なるモデル、メモリ不足 | メリが利用可能になるか、モデルがアンロードされるまで1つがキューに追加される |
要約すると、Ollamaはサーバーが並行処理用に設定され、十分なリソースがある場合に、複数の同時リクエストを効率的に処理するように設計されています。それ以外の場合、リクエストはキューに追加され、順番に処理されます。
メモリ不足の処理
Ollamaがインバウンドリクエストを処理するのに十分なメモリに遭遇しない場合、安定性を維持するためにキューイングメカニズムとリソース管理戦略の組み合わせを採用します:
リクエストキューイング
- メモリを即座に割り当てられない場合、新しいリクエストはFIFO(先入先出)キューに配置されます。
- キューサイズは
OLLAMA_MAX_QUEUE(デフォルト: 512リクエスト)によって制御されます。 - キューが容量に達すると、新しいリクエストは503「サーバー過負荷」エラーを受けます。
モデル管理
- アクティブなモデルは、アイドル状態になるとメモリからアンロードされ、キューイングされたリクエストのためにリソースを解放します。
- 同時にロードされるモデルの数は
OLLAMA_MAX_LOADED_MODELS(デフォルト: GPU数×3またはCPUの場合は3)によって制限されます。
メモリ最適化
- 同じモデルのリクエストをバッチ処理して、メモリ効率を最大化しようとします。
- GPU推論の場合、モデルごとに完全なVRAM割り当てが必要です。部分的なロードはサポートされていません。
失敗シナリオ
致命的なメモリ枯渇: キューイングされたリクエストですら利用可能なリソースを超えた場合、Ollamaは以下を行う可能性があります:
- ディスクへのページング(パフォーマンスが大幅に低下)
- 「メモリ不足」エラーを返す
- 極端な場合にはモデルインスタンスがクラッシュする
| 設定コントロール設定 | 目的 | デフォルト値 |
|---|---|---|
| OLLAMA_MAX_QUEUE | 最大キューイングリクエスト数 | 512 |
| OLLAMA_NUM_PARALLEL | ロードされたモデルあたりの並列リクエスト数 | 4(制限がある場合は1) |
| OLLAMA_MAX_LOADED_MODELS | 同時にロードされる最大モデル数 | GPU数×3または3 |
管理者は、メモリ使用量を監視し、ハードウェア機能に基づいてこれらのパラメータを調整する必要があります。メモリ不足の処理は、大規模モデル(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が未活用
- キューイング遅延が総レスポンス時間の大部分を占める
ヒント: クライアントも制御できる場合は、ジッター付きリトライとコネクションキープアライブを追加します。多くの「Ollamaが遅い」問題は、実際にはキューイング+コネクションオーバーヘッドです。
Ollama: バッチリクエスト vs 並列実行
Ollamaにおけるバッチ処理とは、複数のインバウンドリクエストをグループ化して単位として処理する手法を指します。これにより、並列化された操作から恩恵を受けるハードウェア(GPUなど)上で実行する場合、計算リソースのより効率的な利用が可能になります。
同じモデルに対する複数のリクエストが同時に到着すると、メモリが許す限り、Ollamaはそれらをバッチとしてまとめて処理できます。これによりスループットが向上し、モデルがバッチに対して最適化された行列演算を活用できるため、各リクエストのレイテンシが削減される可能性があります。
バッチ処理は、リクエストのサイズと複雑さが類似している場合に特に効果的で、ハードウェアの活用を向上させることができます。
Ollamaにおける並列実行とは、利用可能なメモリおよび設定に応じて、同じモデルまたは異なるモデルに対する複数のリクエストを同時に処理することを意味します。
Ollamaは2つのレベルの並列性をサポートしています:
- 複数モデルのロード: 十分なメモリがある場合、複数のモデルをロードして同時にリクエストを処理できます。
- モデルあたりの並列リクエスト: 各ロードされたモデルは、
OLLAMA_NUM_PARALLEL設定(メモリに応じてデフォルトは1または4)によって制御される複数のリクエストを並列に処理できます。
リクエストが並列度制限を超えると、OLLAMA_MAX_QUEUEまでキュー(FIFO)に追加されます。
まとめ
Ollamaは、バッチ処理と並列実行の両方を利用して、複数のリクエストを効率的に処理します。バッチ処理はリクエストをグループ化して同時処理を可能にし、並列実行は複数のリクエスト(またはモデル)が並行して実行されることを可能にします。両方の方法はシステムメモリに依存し、最適なパフォーマンスのために構成可能です。
さらにベンチマーク、並行性チューニング、およびパフォーマンスガイドについては、LLMパフォーマンス: ベンチマーク、ボトルネック & 最適化ハブをご確認ください。