Ollamaのモデルをメモリに常駐させる方法

数分後に Ollama がモデルをアンロードするのはなぜですか？

Ollama は、最後のリクエストから 5 分間はモデルをメモリに読み込んだまま保持し、その後解放します。次のリクエストでは、ディスクから重みを読み込み、再び RAM または VRAM にマッピングする必要があるため、最初のトークンが返る前に待ち時間が発生します。そのため、チャット UI やコーディングエージェントは、最初は高速でも、しばらく操作しないと、次のメッセージで再び遅く感じられます。故障ではありません。アイドルタイマーの期限が切れただけです。

このタイマーは keep_alive と呼ばれます。モデルごとに設定され、リクエストが完了するたびに再開されます。現在リクエストに応答しているモデルがアンロードされることはありません。サーバーが期限切れにできるのは、アクティブなリクエストがないモデルだけだからです。2026 年 8 月時点のデフォルト値は 5 分で、このサーバーが読み込むすべてのモデルに適用されます。

keep_alive を設定する場所は、個別のリクエストとサーバーのデフォルト設定の 2 つです。systemd の drop-in を使用すると、サーバーのデフォルト設定を再起動後も維持できます。このガイドでは、Ollama がすでにサービスとして実行されていることを前提とします。実行されていない場合は、VPS への Ollama のインストール から始めてください。

現在常駐しているモデルと、有効期限を確認する方法

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

出力が空の場合、ロード済みのモデルはありません。そのため、次のリクエストでは完全なロードが必要です。PROCESSOR は重みの配置先を示します。100% GPU と 100% CPU は明確な状態です。25%/75% CPU/GPU のように分割されている場合、モデルが VRAM に収まらないため、一部がプロセッサー上で実行され、生成速度が低下します。

UNTIL は残り時間を示し、4 minutes from now のような相対時間を出力します。モデルが負の keep_alive でロードされた場合は Forever を出力します。サーバーがモデルをアンロードしている短い間は Stopping... を出力します。

リリースによって列の構成が変わっているため、スクリプトでフィールド数を数えるのではなく、ヘッダーを確認してください。自動化する場合は、API に問い合わせます。

curl -s http://localhost:11434/api/ps

各エントリには expires_at、2026-08-09T14:38:31.83753Z のような絶対タイムスタンプ、そして size_vram が含まれます。size_vram は、そのモデルのうち GPU メモリ上に配置されている部分を示します。size_vram が 0 の場合、モデルは CPU 上で実行されています。

実際の reload にかかるコスト

推測で判断しないでください。Ollama はすべてのレスポンスで、ロード時間を load_duration としてナノ秒単位で報告します。

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

最初の呼び出しではモデルをロードするため、load_duration は大きな値になります。1000000000 で割ると、秒単位で確認できます。2 回目の呼び出しはモデルをメモリに保持したまま実行されるため、報告される値は大幅に小さくなります。この 2 つの値の差が、タイマーの期限切れ後にすべてのユーザーが負担する待ち時間です。これが keep_alive を変更する主な理由です。この差の大部分はディスク読み取りによるものです。そのため、モデルディレクトリを 2 台目のボリュームへ移動した場合は、そのボリュームの速度がコールドロードごとの最短時間を決めます。この一時停止の前後における生成速度については、使用中のマシンで秒あたりのトークン数を測定する方法を参照してください。

1 回のリクエストで Ollama モデルをメモリに保持する

リクエストに keep_alive を指定します。リクエストの処理が完了した時点から、そのモデルに適用されます。

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

指定できる値は次の 4 形式です。

• 期間文字列: "30m"、"24h"、"90s"
• 秒数として解釈される単純な数値: 3600
• アイドルタイムアウトを無効にする負の値: -1 または "-1m"
• 0: このリクエストの処理完了直後にアンロード

リクエストで指定した値は、サーバーのデフォルト設定を両方向で上書きします。これは見た目以上に重要です。クライアントが独自の keep_alive を送信すると、サーバーで設定した値より優先されます。

生成処理を行わずにモデルをロードすることもできます。モデル名だけを送信します。サーバーはモデルをロードし、"done": true を含む空のレスポンスを返します。

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

これは、再起動後や新しいモデルの pull 後に実行するコマンドです。最初の実際のユーザーリクエストでロード時間が発生することを防げます。CLI でもフラグを使って同じ処理を実行できます。

ollama run --keepalive 30m qwen3:8b "hello"

OLLAMA_KEEP_ALIVE でデフォルト値を設定する

サーバーは起動時に OLLAMA_KEEP_ALIVE を読み込み、独自の値を持たないすべてのモデルで使用します。リクエストのフィールドと同じ形式を指定できるため、30m、3600、-1 はすべて使用できます。

注意が必要なのは、変数をどの環境に設定するかです。SSH セッションで export OLLAMA_KEEP_ALIVE=30m を実行しても効果はありません。パッケージ版のインストールでは、サーバーは独自のユーザーと環境で systemd サービスとして実行されるためです。ログインシェルとそのサービスの環境は共有されません。設定が無視されたように見える原因として、これが最も一般的です。

systemd の drop-in で再起動後も設定を維持する

sudo systemctl edit ollama.service

エディターには、2 つのコメントマーカーが表示されます。その間に入力してください。2 つ目のマーカーより下に書いた内容は、systemd によって破棄されます。

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

保存すると /etc/systemd/system/ollama.service.d/override.conf が書き込まれます。これは配布された unit を直接編集するのではなく、drop-in として追加されます。そのため、ollama.service を置き換える Ollama パッケージのアップグレード後も、この設定は維持されます。drop-in と unit ファイルに慣れていない場合は、systemd の service と timer のガイドで仕組みを確認できます。

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

最後のコマンドは、サービスが実際に使用する環境変数を表示します。その行に OLLAMA_KEEP_ALIVE=30m がない場合、drop-in は適用されていません。原因のほとんどは、[Service] ヘッダーがないか、マーカーより下に行を入力したことです。再起動すると、読み込まれているモデルがすべて破棄されるため、次のリクエストではコールドロードが発生します。上記の preload 呼び出しで事前に読み込んでおいてください。

モデルを常駐させるコスト

ollama ps の SIZE 列は、リクエスト処理中だけでなく、アイドル時間全体にわたって確保されるメモリを示します。4-bit 量子化の 8B モデルでは、約 5 から 6 GB を使用します。27B モデルでは話が変わるため、常駐させる前に CPU のみの VPS で実行する場合のメモリ計算を確認してください。keep_alive を -1 に設定すると、サーバー上の他のすべてよりモデルを常に優先することになります。小規模な VPS では、データベース、Web アプリケーション、ビルドジョブに使えるメモリを直接削ることになります。

推定値を信頼せず、実際の数値を確認してください。モデルを読み込んだ状態で実行し、その後 ollama stop した状態でもう一度実行します。

free -h

available 列は、カーネルが新しいプロセスに割り当てられるメモリを示します。NVIDIA GPU を搭載したサーバーでは、nvidia-smi に VRAM の同じ状況が表示されます。メモリが不足すると、カーネルは回収のためにプロセスを終了します。

sudo dmesg -T | grep -i "out of memory"

ollama を示す行があれば、モデルサーバーが終了対象になったという意味です。データベースを示す行があれば、モデルが優先され、重要なプロセスが失われたという意味です。どちらも、余裕のないサーバーで keep-alive の時間を長く設定した結果です。

ここでは見落としやすいコストが 2 つあります。コンテキスト長を長くすると、より大きな KV cache（key value cache。モデルが生成中に保持する、トークン単位の attention 状態）が確保されます。このキャッシュも常駐サイズに含まれます。そのサイズは num_ctx から決まるため、コンテキストウィンドウを広げると、応答中だけでなくアイドル時間全体にわたって常駐モデルが保持するメモリも増加します。1 より大きい OLLAMA_NUM_PARALLEL では、並列スロットごとにこのキャッシュが 1 つ確保されます。1 つのモデルで複数のユーザーに応答する予定なら、重みだけでなくスロット数を含めてメモリを見積もってください。

妥当な初期値は、十分な余裕があるサーバーで 1 つのモデルに -1 を使用することです。共有サーバーでは、30m のようにリクエスト間の空き時間をカバーする値を設定してください。作業を停止した後にメモリを解放できるようになります。

モデルを即座にアンロードする

ollama stop qwen3:8b

出力なしで返り、モデルは ollama ps から消えます。ロードされていない名前を指定すると、couldn't find model "qwen3:8b" to stop が返ります。API では、プロンプトを指定せず、keep_alive に 0 を設定してリクエストします。

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

応答には "done_reason": "unload" が含まれます。サービスを再起動する代わりに、こちらを使用してください。systemctl restart ollama でもメモリを解放できますが、ロード済みの他のモデルをすべて削除し、実行中のリクエストも終了させます。

1 台のサーバーで複数のモデルを実行する

OLLAMA_MAX_LOADED_MODELS は、同時にロードしておけるモデル数を制限します。2026 年 8 月現在、デフォルトは GPU 1 台あたり 3 モデルで、CPU のみのマシンでも 3 モデルです。この上限が数えるのはモデル数ですが、実際の制限要因はメモリです。そのため、3 モデルに達する前に、2 つ目の大きなモデルをロードできなくなる場合があります。

新しいモデルが要求され、ロードに必要なメモリが不足している場合、scheduler は常駐モデルの 1 つをアンロードして空きを作ります。scheduler はアクティブなリクエストがないモデルを優先します。また、タイマーが期限切れになっていないモデルも排出します。-1 でロードしたモデルも対象です。したがって、負の keep_alive はアイドルタイムアウトがないことを意味します。別のモデルのリクエストに備えて、モデルの重みを固定する設定ではありません。

この判断は debug レベルでログに記録されます。同じ drop-in に Environment="OLLAMA_DEBUG=1" の行をもう 1 つ追加して restart し、次を監視します。

sudo journalctl -u ollama -f

空きを作るために runner をアンロードしたという行が、その処理を引き起こしたリクエストの近くに記録されていれば、これら 2 つのモデルはこのマシン上で同時に収まりません。対処方法は、このマシンで実行するモデルを減らすことです。または、迅速な応答が必要なモデルには長い待機時間を設定し、まれに呼び出すモデルには 0 を設定します。

次のリリース後も使える指針

Ollama は頻繁にリリースされ、デフォルト値も変わるため、数値を暗記するのではなく、目の前のビルドを確認してください。

ollama --version
ollama serve --help

ollama serve --helpには、そのビルドが実際に読み取る環境変数が一覧されています。OLLAMA_KEEP_ALIVEもその中に含まれます。リリースをまたいで変わらず、安心して前提にできるルールが 2 つあります。リクエストで指定した値はサーバーのデフォルト値より優先されます。また、設定ファイルに読み込まれるはずの内容が記載されていても、実際に読み込まれた内容を示すのは ollama ps です。

エディターやエージェントがサーバーを操作する場合は、サーバーを疑う前に、そのクライアントが何を送信しているかを確認してください。自分の Ollama サーバーをコーディングエージェントの接続先にするでは、これらのリクエスト設定の場所を説明しています。

FAQ

Ollama が 5 分後にモデルをアンロードするのはなぜですか？

5 分はデフォルトの keep_alive です。これは、リクエストの完了時に Ollama が開始するアイドルタイマーです。タイマーが切れるとサーバーは重みを解放するため、次のリクエストでディスクから再読み込みします。この再読み込みが、体感する一時停止の原因です。1 回のリクエストだけ保持時間を延ばすには、JSON body に "keep_alive": "30m" を指定します。サーバー全体で変更するには、OLLAMA_KEEP_ALIVE 環境変数を使用します。

Ollama のモデルをメモリに永続的に保持するにはどうすればよいですか？

負の値を使用します。リクエストでは "keep_alive": -1、サーバーでは OLLAMA_KEEP_ALIVE=-1 を指定します。ollama ps を実行すると、UNTIL 列に Forever が表示されます。これはアイドルタイマーだけを無効にします。それ以外の動作は変わりません。別のモデルが要求されてメモリが不足した場合、スケジューラーは空き容量を確保するため、このモデルもアンロードします。

OLLAMA_KEEP_ALIVE が無視されるのはなぜですか？

設定した場所を確認してください。systemctl show ollama --property=Environment を実行し、その出力に変数が含まれていない場合、サーバーはその変数を認識していません。shell で export した変数は systemd service には引き継がれないためです。sudo systemctl edit ollama.service で設定し、その後 sudo systemctl daemon-reload と sudo systemctl restart ollama を実行します。もう 1 つの原因は、リクエストで独自の keep_alive を送信するクライアントです。この値がサーバーのデフォルト設定を上書きします。

Ollama を再起動せずにメモリを解放するにはどうすればよいですか？

ollama stop qwen3:8b を実行すると、そのモデルだけを直ちにアンロードできます。サーバーと、その他の読み込み済みモデルは動作を続けます。API 経由では、prompt を指定せずに "keep_alive": 0 を含むリクエストを送信します。レスポンスには "done_reason": "unload" が返ります。ollama ps で確認すると、対象モデルは一覧に表示されなくなっているはずです。