ollama pullとrunの違い、モデルの保存先と移動方法

ollama pull と ollama run の違い

ollama pull はモデルをダウンロードして終了します。ollama run はモデルがない場合にだけダウンロードし、その後モデルをメモリに読み込んで対話型チャットを開始します。ダウンロードの動作は同じで、ファイルの保存先も同じです。その後も処理を継続するのは run だけです。

この違いによって、スクリプトで使うべきコマンドと、キーボードから実行するべきコマンドが決まります。

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

1 行目はモデルを取得して終了するため、プロビジョニングや systemd の unit で安全に使用できます。2 行目はチャットセッションを開始します。終了するには /bye と入力するか、Ctrl+D を押します。3 行目は単一のプロンプトを送信し、回答を表示して終了します。セッションではなく回答が必要なスクリプトでは、この形式を使用します。この 3 つ目の形式でも、回答の長さはモデルに委ねられます。そのため、1 行の質問に対して 3 段落の回答が返ることがあります。num_predict で回答を制限することで、スクリプトの run を呼び出し側が実際に扱えるサイズに収められます。モデル名は頻繁に変わるため、ここでの gemma4 はプレースホルダーとして扱ってください。これは 2026 年 8 月時点で公式 Ollama ドキュメントが使用している例であり、library のどの tag でも動作は同じです。実際のサーバーで必要なリソース量が検証済みのモデルに置き換える場合は、VPS で Nemotron 3.5 Lightning を実行するで、pull に使う正確な tag と必要なメモリを確認できます。

初回の ollama run がフリーズしたように見える理由

新しい VPS で最初の run を実行すると、数分間出力が表示されないことがあります。異常ではありません。モデルをディスクに保存してメモリへ読み込むまで、チャットプロンプトは表示されません。つまり、run は表示できるものが何もない状態で、数 GB のダウンロードを実行しています。

この処理が見えにくくなる理由は2つあります。Ollama は出力先が端末の場合にだけ進捗バーを表示します。そのため、シェルスクリプト、cron ジョブ、CI ステップ、または通常の ssh host ollama run ... 内で実行した run は、ダウンロード中に何も出力しません。さらに、データの保存が完了しても、最初のトークンを生成する前にファイルをディスクから RAM へ読み込む必要があります。小規模な VPS では、この読み込みに時間がかかります。モデルを保持するメモリが不足している場合、カーネルが swap を使い始めるため、待ち時間はさらに長くなります。

推測せず、別のセッションから状況を確認します。

df -h /
watch -n5 df -h /

空き容量が段階的に減っている場合、ダウンロードはまだ進行中です。コマンドが実行中なのに空き容量の減少が止まった場合、ダウンロードが完了し、メモリへの読み込みが始まっています。

これは、事前に pull しておくべき理由です。ollama run と入力する人が、ダウンロードの待ち時間を負担することになってはいけません。

要求される前にモデルを取得する

人以外の対象にも同じことが当てはまります。Ollama エンドポイントを指定したコーディングエージェントは通常、数 GB のダウンロードが完了するまで待たず、最初のリクエストで処理を諦めます。新しいサーバーでは、サーバーをインストールするスクリプトと同じスクリプトでモデルも取得します。

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

初めてサーバーを構築する場合は、VPS への Ollama の完全なインストール手順で、サービス自体と接続を許可する対象を確認できます。その後に設定する価値があるのは、端末を終了しても継続するモデル取得です。ダウンロードが途中で終了すると、モデルストアが不完全な状態になるためです。

tmux 内で実行するか、boot 時に 1 回だけ実行する unit として systemd に渡します。/etc/systemd/system/ollama-pull.service を記述します。

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

どちらのコマンドも、意図的に /bin/sh -c 経由で実行します。単独の ExecStart= には絶対パスが必要です。また、installer によって binary の配置先が異なる場合があるため、確実なのは実行環境で command -v ollama を確認することです。shell 経由で実行すると、ガイドからコピーしたパスではなく、service の PATH が使われます。最初の ExecStart も重要です。After=ollama.service は server unit が起動したことを示すだけで、利用可能になったことまでは示しません。そのため、pull を開始する前に loop で ollama list の応答を待ちます。

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

journal に、エラーなしで pull が完了したことが表示され、ollama list でモデルを確認できるはずです。変動する tag を最新状態に保つには、同じ pull を実行する systemd timer または週次の cron エントリを追加します。更新された tag を再取得すると、新しい layer がダウンロードされ、旧 layer は参照されなくなります。参照されなくなった layer は、次回 server の起動時に削除されます。

プルが中断された場合の動作

モデルの各レイヤーは、その内容から生成した固有のハッシュの下に保存されます。そのため、プルが中断されても作業は無駄になりません。同じ ollama pull を再度実行すると、完了済みのレイヤーは認識されてスキップされ、中断されたレイヤーからダウンロードが再開されます。

ただし、1 つの操作によってこの進捗が失われます。Ollama サーバーの起動時には、どのモデルマニフェストからも参照されていない保存済みレイヤーが削除されます。中断したプルによって残された不完全なレイヤーは、まさにこの対象です。そのため、再試行前にサービスを再起動すると、すでにダウンロードしたデータが破棄されます。先にプルを再試行し、再起動は後で行ってください。再起動後も不完全なダウンロードを確実に保持する必要がある場合は、サービスの環境変数に OLLAMA_NOPRUNE=1 を設定してください。ただし、その後は設定を削除してください。この起動時のクリーンアップが、孤立したレイヤーのディスク上への蓄積を防いでいるためです。

プルが no space left on device で失敗した場合は、再試行前に空き容量を確保してください。df がディスク容量不足を報告し、モデルディレクトリの du でその使用量を説明できない場合、容量は別の場所で使用されています。何かを削除する前に、df と du の結果が一致しない理由を確認してください。

Ollama は VPS 上のどこにモデルを保存しますか？

このガイドを含め、どのガイドのパスもそのまま信頼せず、自分の環境で確認してください。場所はパッケージインストールとコンテナで異なります。OLLAMA_MODELS が設定されている場合は、さらに変わります。

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat は、すべての drop-in を含む unit ファイルを表示します。そのため、自分で設定した OLLAMA_MODELS 行や、イメージに組み込まれた OLLAMA_MODELS 行も確認できます。この行がない場合、モデルの保存先はサービスを実行するアカウントのホームディレクトリ配下です。getent passwd は、そのホームディレクトリをコロン区切りの6番目のフィールドに表示します。find は、blobs ディレクトリを1つのファイルシステム内で検索します。実際のレイヤーはこのディレクトリに書き込まれます。モデルが別のマウントに存在する可能性がある場合は、-xdev を省略してください。

次に容量を測定し、自分の環境の結果を確認します。

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

保存先には2つの部分があります。manifests にはモデルタグごとに小さなファイルが1つ保存されます。このファイルには、そのタグを構成するレイヤーが記録されています。blobs にはレイヤー本体が保存されます。各レイヤーは内容のハッシュを名前として持ち、容量のほとんどはここで使用されます。レイヤーはタグ間で共有されるため、同じ重みに基づく2つのモデルは、ollama list ではそれぞれのサイズを報告しますが、ディスク上ではその容量を1回だけ使用します。そのため、表示されたサイズの合計が、du でディレクトリについて報告される容量を超えることがあります。

モデルファイルは、小容量の VPS の root ファイルシステムを、通常インストールする他のものより速く使い果たします。容量に最も大きく影響するのは重みの形式です。q4、q8、fp16 の選択は、モデル1つあたり数 GB の差につながります。

OLLAMA_MODELS でモデルをデータボリュームへ移動する

2 台目のディスクまたは容量の大きいデータボリュームを使用できる場合は、root ファイルシステムが一杯になる前にモデルの保存先を移動します。最初にサーバーを停止してください。書き込み中のファイルをコピーしないためです。

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit は drop-in ファイルをエディターで開きます。パッケージに含まれる unit は変更されないため、パッケージ更新で変更内容が上書きされません。次の 2 行を追加します。

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show で新しいパスが表示され、ollama list で移動前と同じモデルが表示されることを確認します。リストが空の場合、サーバーは新しいディレクトリを読み取れません。サービスは ollama ユーザーとして実行されるため、そのユーザーに移動先への読み取りおよび書き込み権限が必要です。上記の chown 行でこの権限を設定します。新しいパスに関する権限エラーがないか、journalctl -e -u ollama を確認します。リストが正しいことを確認してから、古いコピーを削除してください。移動に失敗した状態で元のコピーを削除すると、すべてを再ダウンロードする必要があります。

別の方法では、元のパスを維持し、そのパスにデータボリュームをマウントします。

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

findmnt でマウントが表示されれば、bind mount は有効です。bind mount は、同じサーバー上の別のソフトウェアがデフォルトの場所をすでに使用している場合に便利です。ただし、注意点があります。コピーしたファイルは、マウントポイント配下の root ディスク上に残っています。マウントによって隠れているだけなので、アンマウントして削除するまで容量は解放されません。次にログインする担当者へ説明しやすいのは、2 つの方法のうち環境変数を使う方法です。

コンテナがモデルを別の場所に保持する場合

公式イメージは、ollama ユーザーに属するホスト上のディレクトリではなく、マウントした場所にモデルを保存します。ドキュメントに記載されている実行コマンドは次のとおりです。

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

コロンの前にある ollama は名前付き Docker ボリュームで、/root/.ollama はコンテナ内でサーバーが書き込む場所です。そのため、前のセクションにあるパスに対して du を実行しても何も見つかりません。そこには何も保存されていないためです。実際の場所とサイズを表示します。

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

docker volume inspect から Mountpoint フィールドを読み取り、その値に対して sudo du -sh を実行します。モデルをデータボリュームに保存するには、名前付きボリュームをホストディレクトリ（-v /mnt/data/ollama:/root/.ollama）に置き換えて、コンテナを再作成します。コンテナは root として書き込むため、ホスト上のディレクトリの所有者は root になります。rootless Podman では、ID がユーザーの subuid 範囲にマッピングされるため、ホスト上の所有者表示はさらに異なります。このマッピングについては、rootless Podman で Ollama を実行する方法で説明しています。

クリーンアップについて注意点があります。docker volume prune は、どのコンテナからも参照されていないすべてのボリュームを削除します。ボリュームを付けずに ollama コンテナを削除または再作成すると、後で prune を実行した際に、ダウンロード済みのすべてのモデルが削除されます。再度ダウンロードする以外に元へ戻す方法はありません。モデルをホストしているサーバーで prune を実行する前に、VPS の Docker ディスク使用量を整理する方法を確認してください。

ollama rm でモデルを削除する。rm は使用しない

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm は、そのタグの manifest を削除し、その後、参照する manifest がなくなった layer を削除します。これらのファイルの unlink が完了するとすぐに空き容量が戻るため、df は直ちに反映されます。layer は共有されるため、関連性の高い 2 つのタグのうち 1 つを削除しても、タグの横に ollama list が表示したサイズより、解放される容量が大幅に少ない場合があります。これは正しい動作であり、削除に失敗したわけではありません。

ファイルを手動で削除すると、対応関係が壊れます。rm で blob を削除しても manifest にはその blob が残るため、ollama list はモデルを表示し続けます。また、不足している layer の読み込み時に、そのモデルを使用しようとすると失敗します。manifest を手動で削除すると、その layer は参照先がないままディスクに残り、Ollama のコマンドからは報告されない容量を占有します。すでに手動削除を行った場合は、そのタグに対して ollama rm を実行すると残ったエントリが消去されます。サーバーを再起動すると、参照されていない layer も削除されます。

最後に、混同されやすい 2 つの違いを確認します。ollama rm はディスク容量に関する操作です。ollama stop gemma4 はモデルをメモリからアンロードしますが、ディスク容量はまったく解放しません。ダウンロード完了後にモデルを RAM に常駐させる時間は別の設定です。リクエストのたびに再読み込みせず、モデルをロードしたままにするで説明しています。

FAQ

ollama pull と ollama run の違いは何ですか

ollama pull はモデルをディスクにダウンロードして終了します。ollama run はモデルがすでにディスク上にあるか確認し、なければダウンロードしてメモリに読み込み、その後インタラクティブなチャットセッションを開きます。どちらも同じディレクトリに同じファイルを書き込みます。プロビジョニングやスクリプトでは pull を使い、キーボードから操作する場合は run を使います。ollama run <model> "your prompt" はプロンプトを1つ送信して終了します。これは run のスクリプト向けの形式です。

最初の ollama run がハングしたように見えるのはなぜですか

モデルをダウンロードしています。モデルをディスクに保存してメモリに読み込むまで、チャットのプロンプトは表示されません。モデルのサイズは数GBあります。Ollama は出力先が端末の場合にだけ進行状況バーを表示します。そのため、スクリプト、cron ジョブ、または ssh host ollama run ... 内で実行した run は、処理中に何も表示しません。別のセッションを開き、watch -n5 df -h / を実行してください。空き容量が段階的に減っていれば、ダウンロードが進行中です。事前にモデルを pull しておけば、待ち時間は発生しません。

Ollama はモデルをどこに保存しますか

保存場所はインストール方法によって異なるため、推測せずに表示してください。systemctl cat ollama.service を実行すると、unit または drop-in で OLLAMA_MODELS が設定されているか確認できます。設定されていない場合、保存先はサービスを実行するアカウントのホームディレクトリ配下にあります。その場所は getent passwd ollama で表示できます。sudo find / -xdev -type d -name blobs 2>/dev/null を使うと、レイヤーディレクトリを直接特定できます。コンテナーイメージでは、保存先はマウントされたボリューム内にあります。docker volume inspect ollama はそのホスト側の Mountpoint を表示します。

Ollama のモデルを別のディスクへ移動するにはどうすればよいですか

サービスを停止し、rsync -a で保存先を新しい場所へコピーします。sudo chown -R ollama:ollama <directory> でサービスアカウントにディレクトリの所有権を付与し、sudo systemctl edit ollama.service を実行して [Service] 行の下に Environment="OLLAMA_MODELS=<directory>" を追加します。sudo systemctl daemon-reload で再読み込みし、サービスを再起動します。systemctl show ollama --property=Environment と ollama list で確認します。リストが空の場合、ほとんどは ollama ユーザーが新しいディレクトリを読み取れないことが原因です。journalctl -e -u ollama で問題のパスを確認できます。

モデルファイルを削除すると空き容量は増えますか

ファイルを手動で削除すると容量は解放されますが、保存領域の整合性が失われます。blob を削除しても manifest にはモデルが記録されたままなので、ollama list には表示され続け、使用時に失敗します。manifest を削除すると、参照されなくなったレイヤーがディスク上に残ります。ollama rm <model> を使ってください。これは manifest を削除し、その後、他のモデルが必要としないレイヤーを削除します。すでにファイルを手動で削除した場合は、タグに対して ollama rm を実行してエントリを消去し、その後サーバーを再起動します。サーバーが、どの manifest からも参照されていないレイヤーを削除します。