Ollamaの並列リクエスト処理方法

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

ジャンプリンク: OLLAMA_NUM_PARALLEL とは何か？ · クイック調整レシピ · キューイングの仕組み · トラブルシューティング · 関連記事: Ollama CLI コマンド チートシート

スループット、レイテンシ、VRAM、およびランタイムやハードウェアをまたぐベンチマークについてさらに詳しく知りたい場合は、LLM パフォーマンス: ベンチマーク、ボトルネックと最適化 を参照してください。

マルチステップエージェントは、サンプリングが不安定な場合にリトライが増幅されます。Qwen や Gemma クラスのモデルにおけるデフォルトの temperature、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 を上げてもレイテンシが安定しなくなり、キューが膨張し続ける場合、それは目的別に構築されたサービングエンジンへの移行を検討すべき、より明確なシグナルの一つです。 Ollama から vLLM へ: ローカル LLM サーバーをいつ移行すべきか では、vLLM が並列リクエスト同士の劣化を防ぐために使用するメカニズムである、継続的バッチング（continuous batching）や PagedAttention を含む、その意思決定プロセスを解説しています。

メモリ不足時の処理

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

リクエストキューイング

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

モデル管理

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

メモリ最適化

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

障害シナリオ

致命的なメモリ枯渇: キューに待機しているリクエストですら利用可能なリソースを超えた場合、Ollama は以下を行う可能性があります：

• ディスクへページング（パフォーマンスが著しく低下）
• “out of memory”（メモリ不足）エラーを返す
• 極端な場合、モデルインスタンスをクラッシュさせる

管理者は、メモリ使用量を監視し、ハードウェアの能力に基づいてこれらのパラメータを調整すべきです。大きなモデル（7B+ パラメータ）を動作させたり、複数の同時リクエストを処理したりする場合、メモリ不足の処理は非常に重要になります。

Ollama 最適化戦略

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

• RAM: 13B モデルには 32GB+、70B モデルには 64GB+
• ストレージ: モデルのロード/スワップを高速化するために NVMe SSD
• GPU: 大きなモデルには 16GB+ の VRAM を備えた NVIDIA RTX 3080/4090

運用戦略

• バッチリクエスト: メモリオーバーヘッドを分散させるために複数のクエリを同時に処理
• 自動モデルアンロード: 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 * OLLAMA_CONTEXT_LENGTH に比例して増加します：32K コンテキスト設定での 4 つの並列スロットは、リクエストが実際にそれを使用する前に、単一の 128K シーケンスがロードされたかのように KV キャッシュを確保します。16 GB のカードでは、この予算計算がキューイング動作よりも通常は重要となります - 完全な VRAM バジェットと、なぜ単一の長文コンテキストセッションには OLLAMA_NUM_PARALLEL=1 が通常は正しい開始点であるのかについては、16 GB GPU での KV キャッシュ を参照してください。

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 は、バッチングと並列実行の両方を利用することで、複数のリクエストを効率的に処理します。バッチングはリクエストを同時に処理するためにグループ化し、並列実行は複数のリクエスト（またはモデル）が同時に実行されることを可能にします。この2つのメカニズムは、システムのメモリに依存し、最適パフォーマンスのために設定可能です。

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

有用なリンク

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