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"

最初の行はモデルを取得して終了するため、プロビジョニングや systemd unit で安全に使用できます。2 行目はチャットセッションを開始します。終了するには /bye と入力するか、Ctrl+D を押します。3 行目は単一のプロンプトを送信し、回答を出力して終了します。セッションではなく回答が必要なスクリプトでは、この形式を使用します。モデル名は頻繁に変わるため、ここでの gemma4 はプレースホルダーとして扱ってください。これは 2026 年 8 月時点で公式 Ollama ドキュメントが使用している例であり、library のどの tag でも同じように動作します。

最初の ollama run が停止したように見える理由

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

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

推測せず、別のセッションから進行状況を確認してください。

df -h /
watch -n5 df -h /

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

これは、事前に pull しておくべき理由です。ollama run と入力する人が、ダウンロードの完了を待つ必要はありません。

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

新しいサーバーでは、サーバーをインストールする同じスクリプトでモデルも取得します。

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

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

tmux 内で実行するか、ブート時に実行する one-shot 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= には絶対パスが必要です。また、インストーラーがバイナリを常に同じディレクトリへ配置するとは限らないため、command -v ollama で実際の環境を確認することが唯一確実な方法です。シェル経由で実行すれば、ガイドからコピーしたパスではなく、サービスの PATH が使用されます。最初の ExecStart も重要です。After=ollama.service はサーバー unit が起動したことを示すだけで、利用可能になったことを示すものではありません。そのため、pull を開始する前にループで ollama list の応答を待ちます。

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

journal には、エラーなしで pull が完了したことが表示されます。その後、ollama list でモデルを確認できます。移動するタグを最新に保つには、同じ pull を実行する systemd timer または週次の cron エントリを追加します。更新されたタグを再度 pull すると、新しいレイヤーがダウンロードされます。旧レイヤーを参照するものがなくなり、次回サーバーを起動したときに削除されます。

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

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

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

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

VPS で Ollama がモデルを保存する場所

このガイドを含め、どのガイドに書かれたパスもそのまま信頼せず、自分の環境で確認してください。場所はパッケージインストールかコンテナかによって異なり、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 行も表示されます。この行がない場合、保存先はサービスを実行するアカウントのホームディレクトリ配下にあります。getent passwd は、コロン区切りの6番目のフィールドにそのホームディレクトリを出力します。find は1つのファイルシステム内で blobs ディレクトリを検索します。レイヤーは実際にこのディレクトリへ書き込まれます。モデルが別のマウントにある可能性がある場合は、-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 で、新しいパスに関する権限エラーを確認します。一覧が正しいことを確認するまで、古いコピーは削除しないでください。移動に失敗した状態で元のコピーを削除すると、すべてを再ダウンロードする必要があります。

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

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 を実行する方法で説明しています。

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

ollama rm でモデルを削除し、rm は使用しないでください

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm はそのタグのマニフェストを削除し、その後、残っているマニフェストから参照されていないレイヤーを削除します。これらのファイルのリンクが解除されると、空き容量はすぐに戻るため、df は直ちに移動します。レイヤーは共有されるため、密接に関連する2つのタグのうち1つを削除しても、タグの横に ollama list が表示したサイズより空き容量が大幅に少ない場合があります。これは正しい動作であり、削除に失敗したわけではありません。

手動でファイルを削除すると、マニフェストとレイヤーの対応関係が壊れます。rm で blob を削除すると、マニフェストにはその blob が残るため、ollama list ではモデルが表示され続けます。また、欠落したレイヤーの読み込み時に、モデルの使用が失敗します。マニフェストを手動で削除すると、そのレイヤーは参照先がないままディスク上に残り、空き容量を消費します。この容量は、Ollama のコマンドでは報告されません。すでに手動削除を行った場合は、そのタグに対して ollama rm を実行すると残ったエントリを削除できます。サーバーを再起動すると、どこからも参照されていないレイヤーも削除されます。

最後に、混同されやすい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 を実行すると、処理中は何も表示されません。2 つ目のセッションを開き、watch -n5 df -h / を実行してください。空き容量が段階的に減っていれば、ダウンロードは進行中です。事前にモデルを pull しておけば、この待ち時間は発生しません。

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

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