この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。

3行でいうと

  • 既定では、1つのモデルが同時に処理する依頼は1件です（OLLAMA_NUM_PARALLEL=1）。
  • 並列数を増やすと、必要なメモリは「並列数×文脈の長さ」に比例して増えます。
  • 待ち行列の上限は既定で512件。あふれると503エラーです。
  • 複数のモデルを同時に載せられるのは、メモリに収まる場合だけです。

先に結論

Ollamaの同時処理は、2段階で考えると分かりやすいです。公式FAQは、2つのレベルがあると書いています。

  1. 複数のモデルを同時にメモリに置く（メモリに余裕があるとき）。
  2. 1つのモデルが複数の依頼を同時に処理する（読み込み時にメモリに余裕があるとき）。

見立てです。1人で使うだけなら、既定のままで困らないことが多いと思います。数人、または複数のアプリ（チャット、エディタ、自動処理）から同時に使うなら、並列数と文脈の長さをメモリに合わせて決める必要があります。

前提：言葉の整理

設定項目と既定値

OllamaのFAQと、ソースコード（envconfig/config.go）の両方で確かめた値です。

環境変数 意味 既定値
OLLAMA_NUM_PARALLEL 1つのモデルが同時に処理する依頼の数 1
OLLAMA_MAX_LOADED_MODELS 同時に読み込むモデルの数 GPUの数×3（CPUのみなら3）
OLLAMA_MAX_QUEUE 待ち行列に置ける依頼の数 512
OLLAMA_CONTEXT_LENGTH 文脈の長さの既定値 VRAMで変わる（下記）
OLLAMA_KEEP_ALIVE モデルをメモリに残す時間 5分
OLLAMA_FLASH_ATTENTION 注意計算の省メモリ方式 対応していれば自動
OLLAMA_KV_CACHE_TYPE KVキャッシュの精度 f16

FAQの注意書きも、重要です。WindowsでRadeon（AMDのGPU）を使う場合は、当面、同時に載せるモデルが1つまでが既定、とあります。この記事のMac向けの話には関係しませんが、機器によって既定が違う例です。

文脈の長さの既定値は、文書で食い違っています

僕らが読んだ範囲で、3通りの記述があります。

ソースコードの説明文（envconfig）は、「4k/32k/256kがVRAMで決まる」としています。つまり、最新の挙動は、Context lengthのページに近いと読めます。ただし、Macの統一メモリが、この「VRAM」にどう当てはまるのかは、文書に書かれていませんでした。実際の値は、ollama ps のCONTEXT列で確かめるのが確実です。

メモリの増え方

FAQは、並列処理が文脈を広げると説明しています。公式の例では、2Kの文脈を4つ並列にすると、8Kの文脈になり、メモリも追加で要ります。また、OLLAMA_NUM_PARALLEL で必要なRAMは、OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH に比例して増えると書かれています。

ソースコード（llm/llama_server.go）では、内部のサーバーを -c（文脈の長さ×並列数）と -np（並列数）で起動する処理があります。FAQの説明と一致します。

僕らの計算です。KVキャッシュの1トークンあたりの大きさは「2×層の数×KVヘッド数×ヘッド次元×1要素のバイト数」です。Qwen3-8Bの設定ファイルは、層36、KVヘッド8、ヘッド次元128なので、BF16（2バイト）で1トークン147,456バイト（144KiB）です。

文脈の長さ（1件分） 並列数 実際の文脈 KVキャッシュ
8,192 1 8,192 約1.13GiB
8,192 4 32,768 約4.5GiB
32,768 4 131,072 約18GiB

これは重みとは別の、追加の分です。並列数を4に上げると、同じ文脈の長さでも、KVキャッシュは4倍になります。なお、OllamaのKVキャッシュの既定はf16（2バイト）なので、上の前提と合います。OLLAMA_KV_CACHE_TYPE=q8_0 にすると約半分、q4_0 で約4分の1になる、とFAQにあります（Flash Attentionが有効なとき。精度は少し落ちる）。

並列数を増やせないモデルがある

ソースコード（server/sched.go）には、次の記述があります。

  • 埋め込み用のモデル（文章をベクトルに変えるモデル）は、常に並列数1で読み込む。
  • 一部のモデル系列は、並列数を1に固定する。コード中の一覧は、mllama、qwen3vl、qwen3vlmoe、qwen35、qwen35moe、qwen3next、lfm2、lfm2moe、nemotron_h、nemotron_h_moe、nemotron_h_omniです。このとき、「model architecture does not currently support parallel requests」という警告を出して、1に直します。

ソースのコメントは、理由を、GitHubのIssue #4165として挙げています。僕らは、そのIssueの中身は読んでいません。

つまり、OLLAMA_NUM_PARALLEL=4 と設定しても、モデルによっては効きません。一覧は、mainブランチを2026年10月8日に読んだ時点のもので、変わりえます。

混んだときに何が起きるか

FAQとソースコードから、流れをまとめます。

  1. モデルがすでに読み込まれていて、空きがある：依頼はすぐ処理されます。
  2. 読み込み済みだが、並列数いっぱい：ソースコードを読むと、内部のサーバーの前に「並列数」と同じ大きさの順番待ち（セマフォ）があり、空くまで待ちます。
  3. まだ読み込まれていないモデルへの依頼：待ち行列に入ります。
  4. メモリが足りず、新しいモデルを載せられない：FAQによると、既に載っているモデルが使い終わって降ろされるまで、新しい依頼は待たされます。待たされた依頼は、順番どおりに処理されます。GPUで動かす場合、新しいモデルは、VRAMに全部収まる必要があります。
  5. 待ち行列があふれる：OLLAMA_MAX_QUEUE（既定512）を超えると、503（過負荷）のエラーが返ります。ソースにも、「server busy, please try again. maximum pending requests exceeded」のメッセージがあります。

僕らの読み取りです。ソースの処理ループには「この依頼が動き出すまで、他の依頼を止める」というコメントがあり、モデルの入れ替えが必要な依頼が先頭にあると、後ろの依頼もそのあいだ待つと読めます。実際の待ち時間は測っていないので、推測です。

使い終わったモデルは5分残る

既定では、モデルは使い終わってから5分、メモリに残ります。keep_alive を使うと変えられます。

APIの keep_alive は、OLLAMA_KEEP_ALIVE より優先されます。コマンドでは ollama stop <モデル> で、すぐに降ろせます。

常時稼働では、残す時間が長いほど、次の依頼の最初の待ちが短くなります。ただし、メモリを占有し続けるので、他のモデルを載せたいときの邪魔になります。見立てです。常用するモデルを1〜2個に絞って -1 にし、それ以外は既定のままにする、が扱いやすいと思います。

状態を確かめる

設定のしかた（Macの場合）

FAQによると、Macのアプリ版で環境変数を設定するときは、launchctl setenv を使い、Ollamaのアプリを再起動します。公式FAQの書き方（OLLAMA_HOSTの例）を、並列数などに置き換えた例です。この記事では、実行していません。

launchctl setenv OLLAMA_NUM_PARALLEL 2
launchctl setenv OLLAMA_CONTEXT_LENGTH 8192
# そのあと、Ollamaアプリを再起動する

Linuxでsystemdを使う場合は systemctl edit ollama.service、Windowsではユーザーの環境変数に設定します。

目的別の見立て

見立てです。

つまずきやすい点

気をつけること

出典

更新履歴