Ollamaの常駐運用とは、モデルをVRAMに保持して再ロードを省く設定のこと。16GB級のGPUでOllamaを常駐・並列で回すとき、運用時に触る頻度が高い設定は3つ。keep_alive（APIリクエストのパラメータ。サーバー全体ではOLLAMA_KEEP_ALIVE環境変数）、OLLAMA_NUM_PARALLEL（同時リクエスト数）、OLLAMA_MAX_LOADED_MODELS（同時ロード数の上限）。num_ctx・Flash Attention・KVキャッシュ型を固定したうえで、この3点がVRAMの占有量とスループットを動かします。当サイトの検証環境（RTX 5080単体・num_ctx 8192）で、旧世代のgemma3:12bと最新世代のgemma4:12bを各条件3回平均で計測しました。実測した範囲（並列1・2・4）では、並列4でGPU全体のVRAM使用量が13,748MiB（gemma3:12b、約13.4GiB）まで上がっています。具体的な数値で順に見ていきます。
Ollama常駐運用を左右する3つの設定
Ollamaの常駐・並列運用で運用時によく触るのは、keep_alive・OLLAMA_NUM_PARALLEL・OLLAMA_MAX_LOADED_MODELSの3つ。keep_aliveはAPIリクエストのパラメータ（サーバー全体の既定値はOLLAMA_KEEP_ALIVE環境変数で、リクエストでkeep_aliveを指定するとそちらが優先されます）で、残り2つはサーバー側の環境変数です。役割が重ならないため、まず各設定が何を制御するのかを切り分けておくと設定値の逆算が楽になります。なおnum_ctx・Flash Attention・KVキャッシュ型もVRAM量に効くため、本記事ではそれらを固定したうえでこの3点を見ます。
keep_alive は、生成後にモデルをVRAMへ残すか解放するかを決めます。即時解放（0）・時間指定保持（5mなど）・無期限保持（-1）を選べ、公式の既定は5分です。ただし-1は「時間経過によるアンロードを止める」設定であって、メモリ圧迫時の退避まで禁止するロックではありません。OLLAMA_NUM_PARALLEL は1モデルが同時に受け付けるリクエスト本数で、増やすと並行処理用のコンテキスト関連メモリ（KVキャッシュ等）がリクエスト分だけ確保されます。OLLAMA_MAX_LOADED_MODELS は同時にVRAMへ載せられるモデル数の上限（既定値はGPU数×3、単一GPUなら3）。自動で複数常駐させる設定ではなく、上限の範囲で実際にリクエストされ合計がVRAMに収まったモデルが保持されます。
3つの効きどころは別々です。keep_aliveは「応答の即時性」、OLLAMA_NUM_PARALLELは「スループット」、OLLAMA_MAX_LOADED_MODELSは「モデル切替の速さ」に対応します。求める運用像によって触る設定が変わる、という整理です。Ollamaは数あるローカルLLMランタイムの一つで、同種ツールの比較は姉妹サイトのTextGenに関するよくある疑問7選｜LM Studio代替の正体を全部まとめて解説でも扱っています。
検証環境と測定方法論｜他プロセスのVRAM混入を排除する
並列運用のVRAM計測では、複数のollama serveが同じGPUを使うと、別プロセスのモデルやCUDA関連のVRAM使用量が測定値に混入し、対象設定による増加分を切り分けにくくなります。これを避けるための前提条件を先に示します。
検証環境はRTX 5080（16GB）単体。blog専用Ollama（Ollama 0.30.7）の専用serve（port 11439）だけをCUDAバックエンドで起動し、5060 Ti（Oculink接続）はCUDA可視デバイスから外したうえで、2026-06-12に計測しました。単一GPU・単一プロセスに固定したのは、別プロセスのVRAM消費が測定値に混ざる状態を排除するためです。手順は、対象GPUで計測対象の1プロセス（11439）だけを起動し他のVRAM消費プロセスを止める／ollama psのPROCESSORで100% GPUを確認し、必要に応じてGET /api/psが返すsize_vramでVRAMへのロード量も確認する／nvidia-smiでGPU全体のmemory.used（MiB）を取得する、です。
ベースライン、つまりモデル未ロードのserve待機時のGPU全体VRAM使用量は約1,500MiB（gemma3計測時1,495MiB／gemma4計測時1,509MiB）でした。本文のVRAM値はいずれもnvidia-smiが返すGPU全体のmemory.used（MiB・ドライバ予約等を含む）で、モデル単体の占有はロード前後の差分（増分）として併記します。
各測定の条件は次の通りです。各水準はNRUN=3回計測し、平均値（一部は最小〜最大も）を載せています。プロンプトは「ローカルLLMの常駐運用と並列処理について、日本語で250字程度で説明してください。」、stream=false、num_predict=160（並列計測の事前ウォームアップのみ32）。serve起動時の実効設定はOLLAMA_FLASH_ATTENTION=1（有効）・OLLAMA_KV_CACHE_TYPE=f16。temperatureとseedは固定せず既定値です。tok/sはOllama APIが返すeval_count÷eval_duration、並列の集約スループットは同時リクエストのeval_count合計÷実時間（wall）。VRAMは常駐ロード後の安定時にnvidia-smiで取得（GPU0=RTX 5080・memory.total 16,303MiB）。
think=falseを指定して計測しています（think=falseでは可視回答約260字・done_reason=stopを確認）。参考として、gemma4:12bの既定（think有効）の常駐時VRAMは10,234MiB、ウォーム生成76.6 tok/sでしたが、これは推論トークンの生成速度で、可視回答の生成性能とは別物です。keep_alive実測｜常駐と都度解放のVRAMトレードオフ
keep_aliveは即時解放（0）・時間指定保持（5mなど）・無期限保持（-1）を選べる設定です。本節では両端の挙動を比べるため、生成後に即解放する0と、VRAMに残し続ける-1を計測しました。応答の即時性とVRAMの空きが裏返しになる関係が、秒単位とMiB単位ではっきり出ます。
keep_alive=-1でgemma3:12bを常駐させると、GPU全体のVRAM使用量は11,064MiB（ベースライン比＋9,569MiB、約9.3GiB）になります。3回平均で、VRAMへ未ロードの状態から実行した生成（VRAMコールド）は79.0 tok/s、このときAPIが返したload_durationは6.3秒。常駐後のウォーム生成は86.3 tok/s で、load_durationは0.3秒でした。なおこのload_durationはAPIが返す「モデルのロードに費やした時間」で、OSのファイルキャッシュは制御していないため、物理ストレージからの純粋な読み込み時間ではありません（stream=falseのため厳密なTTFTも別計測扱い）。
gemma4:12bをthink=false（gemma3と生成モードを揃える）で同条件で測ると、常駐時のGPU全体VRAMは10,167MiB（＋8,658MiB、約8.5GiB）と一回り小さく、VRAMコールド生成は74.3 tok/s、常駐後のウォーム生成は71.8 tok/s。load_durationはコールド時5.0秒・ウォーム時0.4秒で、可視回答は約260字でした。同じ12Bでも世代でVRAM footprintが変わります。
keep_alive=0（生成後に即解放）では、生成直後にGPU全体VRAMがベースライン近傍へ戻りました。VRAMは返ってくる代わりに、次のリクエストでは毎回ロードが乗ります。整理すると、常駐はウォーム時のload_duration（0.3〜0.4秒）を保つ代わりにGPU全体で約11GiB（gemma3:12b、増分約9.3GiB）を使い続けます。ただしkeep_alive=-1でも、別モデルのロードでVRAMが不足すればアイドル中のモデルは退避され得ます（後述のMAX_LOADED=1で実際にgemma3:12bが退避されています）。常駐は「期限切れしない」設定であって、メモリ圧迫時の保持まで保証するものではありません。
OLLAMA_NUM_PARALLEL実測｜並列度とVRAM・スループットの関係
OLLAMA_NUM_PARALLELは同時リクエスト数を決める設定で、値を上げるほど集約スループットは伸びる一方、並列分のコンテキスト関連メモリでVRAMが積み増されます。RTX 5080の16GBで1・2・4の3水準を各3回平均で計測しました（gemma4はthink=falseで生成モードを揃え）。
| NUM_PARALLEL | gemma3:12b VRAM（総/増分） | gemma3 集約tok/s（min〜max） | gemma4:12b（think=false）VRAM | gemma4 集約tok/s（min〜max） |
|---|---|---|---|---|
| 1 | 11,056MiB / +9,561 | 70.3（70.1〜70.5） | 10,209MiB / +8,700 | 64.3（63.1〜65.2） |
| 2 | 11,764MiB / +10,269 | 117.6（114.0〜119.9） | 10,977MiB / +9,468 | 108.5（101.3〜112.3） |
| 4 | 13,748MiB / +12,253 | 172.6（168.0〜179.3） | 12,513MiB / +11,004 | 170.4（169.7〜171.0） |
VRAMはGPU全体のnvidia-smi memory.used、増分はベースライン比です（GPU total 16,303MiB）。いずれもRTX 5080単体・num_ctx 8192・各水準3回平均、2026-06-12計測。gemma3:12bでは並列1→2→4で追加スロット1本あたり平均約897MiB（1→2が＋708MiB、2→4が1本あたり＋992MiB）増えました。並列化でコンテキスト関連メモリが増えるのは公式仕様と一致しますが、nvidia-smiの総使用量だけでは、増分をすべてKVキャッシュ単体として分離はできません。集約スループットは並列度に応じて両モデルとも伸び、今回の3回平均ではgemma3:12bが並列1の70.3 tok/sから並列4で172.6 tok/sへ約2.5倍でした。モデル間ではgemma4:12b（think=false）のほうがVRAMが小さい（並列4で12,513MiB＝gemma3より約1.2GiBの余裕）一方、集約スループットは並列4で170.4 tok/sとgemma3の172.6 tok/sにほぼ並びます。この差は各runのばらつき（gemma3並列4は168.0〜179.3）に収まる範囲で、どちらが速いと判定する目的の数値ではありません。
本記事で実測した最大の並列度は4です。gemma3:12bの並列4ではGPU全体VRAMが13,748MiBに達し、memory.total 16,303MiBとの差（空き）は2,555MiB（約2.5GiB）でした。単純差分上は並列5が収まる可能性も残りますが、確保単位や断片化で失敗することもあり、並列5以上の可否や容量超過点は未検証です。安全側の運用目安としては、この条件では並列4以下が候補になります。なおOllama公式FAQによれば、利用可能メモリが不足すると新規リクエストはキューイングされ、アイドルの既存モデルがアンロードされ、キュー上限を超えるとサーバーは503を返します。
モデルスワップ実測｜OLLAMA_MAX_LOADED_MODELS
OLLAMA_MAX_LOADED_MODELSは同時にVRAMへ載せられるモデル数の上限です（既定はGPU数×3、単一GPUなら3）。2を指定しても自動で2本ロードするわけではなく、上限の範囲で実際にリクエストされ合計がVRAMに収まったモデルが保持されます。挙動を上限1と2で比べました。
上限1の場合、gemma3:12bを常駐（GPU全体VRAM 11,057MiB）させた状態でphi4:14bを要求すると、Ollamaはまずgemma3:12bを退避（evict）してからphi4:14bをロードします。ロード後のGPU全体VRAMは11,985MiBで、常に単一モデル分しか使いません。切替の代償は要求モデルのload_durationで、phi4:14bでは3回平均4.9秒でした。keep_alive=-1で常駐させていても、上限到達やVRAM不足では先のモデルがこうして退避されます。
上限2にして両モデルを実際にロードしたところ、gemma3:4b（公式3.3GB）とphi4-mini:3.8b（公式2.5GB）が同時に常駐し、GPU全体VRAMは9,418MiBでした。小型どうしで合計が16GBに収まったため共存でき、切替のたびのロード待ちを消せます。大型モデルどうしは合計が利用可能VRAMを超えやすく、その場合は1本ずつの切替運用が現実的です。なお複数GPUへ分散させる構成は設定の系統が変わるため、デュアルGPUでの自動分散は別記事で扱っています。
まとめ
運用時に触る3つの設定（keep_alive＝APIパラメータ／OLLAMA_KEEP_ALIVE、OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS）は、それぞれ別の軸を握っています。keep_aliveは応答の即時性とVRAMの空きのトレードオフ、OLLAMA_NUM_PARALLELはスループットと容量のバランス、OLLAMA_MAX_LOADED_MODELSは同時ロード上限の制御です。RTX 5080（memory.total 16,303MiB）の3回平均では、gemma3:12b常駐でGPU全体11,064MiB、並列4で13,748MiB、小型2本共存で9,418MiB。生成モードを揃える（gemma4はthink=false）と、並列1・2はgemma3:12bの集約スループットが約8〜9%高く、並列4では両モデルがほぼ同等（gemma3の測定範囲内）でした。gemma4:12bは全水準でVRAM使用量が小さい結果です。
設定値は空きVRAMから逆算するのが実用的です。常駐させたいモデルのVRAM増分を押さえ、残量から並列数の上限を見積もり、用途が切替中心なら小型共存も検討する——この順で詰めれば、本記事の測定条件に近い範囲ならVRAMを溢れさせずに常駐・並列を回しやすくなります。ただしモデルや量子化・コンテキスト長・KVキャッシュ設定が変われば必要VRAMも変わるため、最終的には手元のnvidia-smiとollama psで確認するのが確実です。
よくある質問
Q. keep_alive=-1にするとVRAMはどれくらい使い、ずっと保持されますか？
RTX 5080単体・3回平均で、gemma3:12b常駐時のGPU全体VRAM使用量は11,064MiB（ベースライン比＋9,569MiB）でした。gemma4:12b（think=false）は10,167MiB（＋8,658MiB）。ただしkeep_alive=-1は「時間経過でアンロードしない」設定で、別モデルのロードでVRAMが不足すればアイドルモデルは退避されます。保持を確実にしたいなら、同時ロード数や合計VRAMにも余裕を持たせます。
Q. RTX 5080の16GBで並列リクエストはいくつまで動きますか？
本環境（gemma3:12b・num_ctx 8192）では並列1・2・4を測定し、並列4まで動作を確認しました。並列4でGPU全体VRAMは13,748MiB、memory.total 16,303MiBとの空きは2,555MiB（約2.5GiB）です。並列5以上の容量超過点は未検証。num_ctxを伸ばすと必要VRAMも増えるため、長文コンテキストを多用するなら並列を2に落とすとVRAMに余裕ができます。
Q. gemma3とgemma4でtok/sを比べてよいですか？
生成モードを揃える必要があります。gemma4:12bはthinking対応で、Ollama既定ではthinkingが有効です。既定のままだと推論にトークン枠が使われ可視回答が出ないことがあるため、本記事ではgemma4にthink=falseを指定して非thinking生成に揃えています。揃えた条件では、並列1・2はgemma3:12bの集約スループットが約8〜9%高く、並列4ではほぼ同等でした（差は各runのばらつきの範囲）。
Q. 並列計測でVRAMが急増したら設定の効果と考えてよいですか？
まず同じGPUで複数のollama serveや他プロセスが動いていないかを疑うべきです。別プロセスのモデルやCUDA関連のVRAM使用量が測定値に混入すると、対象設定による増加分と切り分けられません。対象1プロセスだけを起動し、ollama psとnvidia-smiで確認してから再計測してください。
参考資料
- Ollama公式ドキュメント: FAQ（keep_alive / 環境変数 / 同時実行）
- Ollama公式GitHubリポジトリ
- Ollama公式ドキュメント: API Reference（load_duration / eval_count / keep_alive / think）
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
