Ollamaでディスクが埋まった時にやること──モデルの保存先変更と削除コマンド

ローカルLLMをOllamaで試していくと、モデルファイルはすぐに数十〜数百GB単位で溜まっていく。ディスクが埋まったときにやるべきことは大きく2つ——不要なモデルを消すことと、保存先自体を容量のあるドライブへ移すことだ。この記事はOllama公式ドキュメントの原文だけを根拠に、具体的なコマンドとOSごとの注意点を整理する。

3行まとめ

1. モデルの保存先はOSごとに固定パス（macOS: ~/.ollama/models、Linux: /usr/share/ollama/.ollama/models、Windows: C:\Users\%username%\.ollama\models）で、環境変数OLLAMA_MODELSを設定すれば変更できる
2. Windows公式ドキュメントには「OLLAMA_MODELSの保存先を変更していた場合、アンインストーラはダウンロード済みのモデルを削除しない」という注意書きがあり、通常のアンインストールだけでは容量が戻らないケースがあることが明記されている
3. Linux公式ドキュメントには、サービス・ライブラリ・バイナリ・モデルを個別にrmで消していく完全アンインストール手順が示されており、ollama rm <モデル名>より踏み込んで容量を全部取り戻したい場合はこちらが必要になる

モデルの保存先はOSごとに固定パス

Ollama公式FAQは、モデルの保存先を次のように明記している。

ディスクの空き容量を確認する際は、まずこのパスの使用量を見るのが最初の一手になる。

保存先を変更する：OLLAMA_MODELS

保存先を別のディレクトリ（容量の大きい外付けドライブなど）に変更したい場合、公式ドキュメントは環境変数OLLAMA_MODELSを使うよう案内している。設定手順自体はOSごとの「環境変数の設定方法」節（GUIでの設定やlaunchctl・systemctl経由の設定など）に委ねられており、変数名を指すだけの単純な仕組みだ。

Linux環境で注意が必要なのは所有者の設定だ。公式ドキュメントは次のように明記している。

On Linux using the standard installer, the ollama user needs read and write access to the specified directory. To assign the directory to the ollama user run sudo chown -R ollama:ollama <directory>.

標準インストーラでLinuxにインストールした場合、Ollamaは専用のollamaユーザーで動作しており、指定した保存先ディレクトリへの読み書き権限をこのユーザーに与えておかないと、パスを変更しても正しく動かない。

Dockerで動かす場合の保存先

Ollama公式ドキュメントのdocs.ollama.com/dockerページを今回curlで取得すると（.mdサフィックスを付けて生Markdown形式で取得した）、CPUのみで起動する最も基本的なコマンドは次のように案内されている。

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

-v ollama:/root/.ollamaという指定から分かる通り、Dockerコンテナ内部でのOllamaの保存先は/root/.ollamaであり、これはこの記事の冒頭で挙げたホストOS側の3パス（macOS/Linux/Windowsそれぞれの.ollamaディレクトリ）とは別の、コンテナ内部の固定パスになる。この例ではollamaという名前のDockerボリュームにマウントされているため、実際のデータはホスト側のDocker管理領域（docker volume inspect ollamaで確認できる場所）に保存される形になる。

GPUアクセラレーションについては、Linux・Windows（WSL2経由）ではNVIDIA Container Toolkitを導入した上で--gpus=allオプションを付けて起動する。一方、公式ドキュメントには「GPU acceleration is not available for Docker Desktop in macOS due to the lack of GPU passthrough and emulation（macOSのDocker DesktopではGPUパススルー・エミュレーションの両方が欠けているため、GPUアクセラレーションは利用できない）」と明記されている。macOSでOllamaを動かす場合、Dockerコンテナ経由ではなくネイティブアプリとして動かしたほうがGPU（Apple Silicon）を使える、という違いがある。

まず何が入っているかを確認する：ollama ls

削除する前に、そもそも何がディスクを圧迫しているのかを確認する必要がある。Ollama公式CLIリファレンスは、ダウンロード済みモデルの一覧を表示するコマンドとしてollama lsを挙げている。同じパラメータ数でも量子化形式（GGUFの量子化レベルなど）によってファイルサイズは大きく変わるため、一覧を見て「同じモデルの古いバージョンが複数残っていないか」「使っていない量子化版が残っていないか」を確認するのが、削除の前段階として有効だ。

不要なモデルを消す：ollama rm

Ollama公式のCLIリファレンスによると、モデルを削除するコマンドは次の通り。

ollama rm gemma4

モデル名を指定するだけのシンプルな削除コマンドで、指定したモデルファイルがローカルストレージから削除される。定期的に使わなくなった旧バージョンのモデルを整理する運用が、ディスク圧迫への一番手早い対処になる。

個別モデルの削除ではなく、丸ごとアンインストールしたい場合

ollama rmは個別のモデルを消すコマンドだが、Ollamaそのものを丸ごと消して容量を全部取り戻したい場合の手順も、OSごとの公式ドキュメント（docs.ollama.com/linux・docs.ollama.com/windows）に書かれている。

Linux版の公式手順は、サービス・ライブラリ・バイナリ・モデルをそれぞれ個別のコマンドで削除していく形だ。

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm /etc/systemd/system/ollama.service
sudo rm -r $(which ollama | tr 'bin' 'lib')
sudo rm $(which ollama)
sudo userdel ollama
sudo groupdel ollama
sudo rm -r /usr/share/ollama

最後のrm -r /usr/share/ollamaが、この記事の冒頭で挙げたモデル保存先（/usr/share/ollama/.ollama/models）を含むディレクトリごと削除する行にあたる。専用のollamaユーザー・グループも合わせて削除する点が、単なるアプリのアンインストールとは違う、Linuxならではの手順になっている。

Windows版は「Add or remove programs」からアンインストーラを実行する形だが、公式ドキュメントには次の注意書きがある。

"If you have changed the OLLAMA_MODELS location, the installer will not remove your downloaded models"

つまり、OLLAMA_MODELS環境変数でモデルの保存先をデフォルトから変更していた場合、Windowsの標準アンインストーラはそのモデルファイルを削除しない。保存先を変更した状態でOllamaをアンインストールしてもディスク容量が戻らない、というのはこの記事の冒頭で紹介した「保存先変更」の運用と表裏一体の注意点だ。

読み込み状況を確認する：ollama ps

「今どのモデルがメモリに乗っているか」を確認したい場合はollama psコマンドが案内されている。公式FAQは「GPUにモデルがロードされているかを確認するにはollama psコマンドを使う」と説明しており、ディスク容量そのものではなくメモリ（VRAM／RAM）の使用状況を見る際に使うコマンドだ。

モデルをメモリに残す・即座に解放する設定

ディスクの空き容量とは別に、実行中のメモリ（RAM／VRAM）消費が問題になる場合もある。Ollama公式FAQによると、モデルは既定で応答生成後5分間メモリに保持され、連続してリクエストする場合の応答速度を上げる仕組みになっている。すぐにメモリを解放したい場合はollama stop llama3.2のようにモデル名を指定して停止できる。

APIを使っている場合は、/api/generate・/api/chatエンドポイントのkeep_aliveパラメータで保持時間を制御できる。指定できる値は次の4種類。

• 時間の文字列（"10m"や"24h"など）
• 秒数の数値（3600など）
• 負の数（-1や"-1m"など）：メモリに保持し続ける
• 0：応答生成後すぐにアンロードする

サーバー起動時に環境変数OLLAMA_KEEP_ALIVEを設定すれば、全モデル共通の既定値を変更することもできる。ただし個別リクエストでkeep_aliveパラメータを指定した場合は、そちらがOLLAMA_KEEP_ALIVEの設定より優先される。

同時実行数が多すぎる場合の挙動

公式FAQは、リクエストが集中した場合の挙動も説明している。搭載メモリ（CPU推論ならシステムメモリ、GPU推論ならVRAM）に余裕があれば複数モデルを同時にロードでき、個々のモデルもメモリに余裕があれば並列リクエストを処理できるよう設定される。新しいモデルをロードするだけの空きメモリがない場合、新規リクエストはキューに入れられ、既存モデルがアイドルになり次第アンロードされて空きが作られる。あまりに多くのリクエストが送られた場合はサーバーが503エラーを返し、キューに積める件数はOLLAMA_MAX_QUEUE環境変数で調整できる。

ディスクではなくメモリ（RAM/VRAM）側の消費を抑えるための環境変数も、公式FAQに複数まとまっている。

OLLAMA_KV_CACHE_TYPEはモデルファイルそのものの容量ではなく、会話が長くなるほど増えていくコンテキストキャッシュのメモリ使用量に効く設定で、この記事のここまでの内容（ディスク上のモデルファイルの容量）とは別軸の最適化にあたる。公式ドキュメントはこの設定について「現状はグローバルオプションで、すべてのモデルが指定した量子化タイプで動く」と注記している。

なお、Windows環境でRadeon GPUを使う場合は「同時ロードできるモデル数は既定で1つまで」という別の制限があることも公式FAQに明記されている。これはROCm v5.7時点でのVRAM取得機能の制約によるもので、ROCm v6.2が利用可能になれば他OSと同じ既定値に従うようになる、と説明されている。

モデルごとのサイズ内訳は本記事では扱っていない

限界を先に書く。

個別モデルファイルの正確なサイズ内訳。 モデルごとのディスク使用量の具体的な数値は、モデルとパラメータ数によって大きく変わるため、本記事では触れていない。

Dockerボリュームの実体パス。 コンテナ内部の保存先が/root/.ollamaであることは公式ドキュメントの起動コマンド例から確認できたが、そのボリューム（ollamaという名前のnamed volume）がホストOS側のディスク上のどこに実体として置かれるかは、Docker自体の仕様（docker volume inspectで確認する必要がある）の話であり、Ollama公式ドキュメント単体では確認できなかった。

クラウドモデル利用時のローカルディスクへの影響。 Ollama公式FAQには「クラウドホスト型モデルを使う場合はプロンプト・応答を処理するが保存・ログはしない」という記載があるが、これはクラウドモデルの話であり、ローカルにダウンロードするモデルのディスク管理とは別の話である点に注意。

関連記事

• ローカルLLMとは何か──自分のPCでAIを動かす仕組み・利点・始め方を解説
• ローカルLLMおすすめモデル10選──無料で動かせるAI【2026年版】
• Llama 4のローカルセットアップと性能【2026年版】