SSD Nodes Learn 🎉 VPS $5.50/月〜
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-13

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

Ollamaはデフォルトで5分間アイドル状態になるとモデルをアンロードします。keep_aliveの設定方法と、再起動後も維持するsystemdの手順を解説します。

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 上で実行されています。

実際に発生する再読み込みコスト

推測で判断しないでください。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 を変更する理由はこれです。この待機の前後における生成速度については、自分の環境で 1 秒あたりのトークン数を測定する方法を参照してください。

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"}'

これは、再起動後や新しいモデルを取得した後に実行するコマンドです。最初の実際のユーザーリクエストでロード時間が発生することを防げます。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 のサービスとタイマーのガイドで仕組みを確認できます。

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 状態）が予約されます。このキャッシュも常駐サイズに含まれます。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 個目の大きなモデルのロードが拒否されることがあります。

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

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

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 を実行します。出力に変数が含まれていない場合、サーバーはその変数を認識していません。シェルで export した変数は systemd サービスには渡らないためです。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 で確認すると、そのモデルは一覧に表示されなくなっているはずです。

#ollama#llm#self-hosted-ai#systemd#performance