Ollamaによる並行リクエストの処理方法

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

スループット、レイテンシ、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 を高くしてもレイテンシが安定しなくなり、実際のトラフィック下でキューが増え続けると、それは目的別のサービングエンジンへの移行を検討するに値する明確なシグナルの一つです。Ollama から vLLM へ：ローカル LLM サーバーを移行するタイミング では、その決定について詳しく解説しており、vLLM が並行リクエストの相互劣化を防ぐために使用するメカニズムとしての継続的バッチングと 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 の最適化戦略

GPU アクセラレーションを有効にするには export OLLAMA_CUDA=1 を実行し、CPU スレッドは export OLLAMA_NUM_THREADS=84 で設定します。

ハードウェア強化

• 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 のシーケンス 1 つがロードされたかのように 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：リクエストのバッチングと並列実行

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 サーバーを移行するタイミング