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。第二行會開啟聊天工作階段；輸入 /bye 或按下 Ctrl+D 即可離開。第三行會傳送單一提示、輸出回答後結束。當指令碼需要回答而不是工作階段時，這就是適合的形式。第三種形式仍會讓回答長度完全由模型決定，因此單行問題可能得到 3 個段落的回答；使用 num_predict 限制回答長度，才能讓指令碼中的 run 維持在呼叫端實際可處理的大小內。模型名稱變動很快，因此請將此處的 gemma4 視為預留位置：截至 August 2026，這是官方 Ollama 文件使用的範例，library 中的任何 tag 都會以相同方式運作。如果你想改用已有人依據實際伺服器規模評估過的模型，在 VPS 上執行 Nemotron 3.5 Lightning 會提供確切的 pull tag，以及模型需要的記憶體容量。

為什麼第一次執行 ollama 看起來像是卡住

在全新的 VPS 上，第一次執行 run 可能會在幾分鐘內沒有任何輸出。這不是故障。模型必須先下載到磁碟並載入記憶體，聊天提示字元才會出現。因此，run 會先執行數 GB 的下載，之後才會顯示任何內容。

有兩個原因會讓這項工作不明顯。Ollama 只有在輸出連接到終端機時才會顯示進度列。因此，在 shell script、cron 工作、CI 步驟或純粹的 ssh host ollama run ... 中執行 run 時，下載期間完全不會輸出任何內容。下載完成後，還必須將檔案從磁碟讀入 RAM，才能產生第一個 token。在小型 VPS 上，這個讀取過程可能很慢。如果主機沒有足夠的記憶體容納模型，kernel 會開始使用 swap，等待時間就會大幅增加。

請從第二個工作階段監控執行狀態，不要自行猜測：

df -h /
watch -n5 df -h /

可用空間逐步減少，表示下載仍在進行。命令仍在忙碌，但可用空間不再減少，表示下載已完成，並開始將模型載入記憶體。

這就是應預先 pull 模型的原因。輸入 ollama run 的人不應該同時承擔下載所需的等待時間。

在有人提出請求前先下載模型

對任何非人工操作的用戶端也是如此：指向 Ollama endpoint 的程式碼代理通常會在第一次請求時直接放棄，而不是等待數 GB 的下載完成。在新主機上，請在安裝伺服器的同一個 script 中執行 pull：

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

如果這是第一次建立伺服器，完整的 VPS 上 Ollama 安裝指南會說明服務本身，以及允許哪些對象連線。接著應設定一個能在終端機關閉後繼續執行的 pull。下載若在中途被終止，模型儲存區就可能只完成一部分。

請在 tmux 內執行，或交由 systemd 作為開機時執行的一次性 unit。請寫入 /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= 時需要絕對路徑，而安裝程式不一定會將 binary 放在相同目錄，因此在本機執行 command -v ollama 才是唯一可靠的方式。透過 shell 執行時，會使用服務的 PATH，而不是直接複製指南中的路徑。第一個 ExecStart 也很重要：After=ollama.service 只表示伺服器 unit 已啟動，不代表服務已就緒。因此，迴圈會等待 ollama list 回應後，才開始 pull。

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

journal 應顯示 pull 已無錯誤完成，接著 ollama list 應能顯示該模型。若要讓會變動的 tag 保持最新，請加入 systemd timer 或每週執行一次相同 pull 的 cron 項目。重新 pull 已更新的 tag 時，會下載新的 layers；不再有任何內容指向的舊 layers，會在伺服器下次啟動時清理。

pull 中斷時會發生什麼事

模型的每個層都會以其內容的雜湊值儲存。因此，pull 中斷不代表先前的工作全部浪費。再次執行相同的 ollama pull 時，系統會辨識並略過已完成的層，繼續下載中斷的層。

但有一個操作會刪除這些進度。Ollama 伺服器啟動時，會移除沒有任何模型資訊清單參照的已儲存層，而中斷的 pull 所留下的部分層正是這種情況。因此，在重試前重新啟動服務，會丟失已下載的部分。請先重試 pull，稍後再重新啟動。如果部分下載內容確實必須在重新啟動後保留，請在服務環境中設定 OLLAMA_NOPRUNE=1，之後再移除該設定，因為啟動時的清理機制能避免孤立層持續累積並占用磁碟空間。

如果 pull 因 no space left on device 中斷，請先釋放空間再重試。如果 df 回報磁碟已滿，但模型目錄中的 du 無法解釋占用的空間，表示空間使用量發生在其他位置。此時在刪除任何內容前，建議先閱讀df 與 du 的結果為何不一致。

Ollama 會將模型儲存在哪裡？

請直接查詢自己的主機，不要盲目信任任何指南（包括本指南）提供的路徑。套件安裝與容器使用的儲存位置不同；如果有人設定了 OLLAMA_MODELS，位置也會再次變更。

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

systemctl cat會列出 unit file 及所有 drop-in，因此由你設定或內建於映像檔中的 OLLAMA_MODELS 行都會顯示在其中。如果沒有這一行，模型儲存區會位於服務執行帳號的 home directory 下，而 getent passwd會在以冒號分隔的第 6 個欄位中列出該 home directory。find會在單一檔案系統中搜尋 blobs directory；模型層實際就寫入該目錄。如果模型可能已位於獨立掛載點，請省略 -xdev。

現在測量使用量，並解讀你自己的數值：

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

儲存區分成兩個部分。manifests為每個模型 tag 儲存一個小檔案，該檔案會列出組成此 tag 的各個層。blobs則儲存層本身，每個層都以其內容的 hash 命名，幾乎所有容量都集中在這裡。由於不同 tag 會共用層，因此兩個以相同權重建立的模型，在 ollama list中各自回報自己的大小，但在磁碟上只會佔用一次空間。這些列出的大小加總後，可能大於 du回報的 directory 大小。

模型檔案填滿小型 VPS 的 root filesystem 的速度，可能比你通常會安裝的其他軟體都快。影響模型容量的最大因素是權重格式。選擇 q4、q8 與 fp16，每個模型都可能節省數 GB。

使用 OLLAMA_MODELS 將模型移至資料磁碟區

如果規劃中包含第二顆磁碟或較大的資料磁碟區，請在根檔案系統用滿前移動模型儲存區。先停止伺服器，避免複製仍在寫入的檔案。

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，套件升級也不會覆寫你的變更。加入以下兩行：

[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 會很有用。但它有一個陷阱：你複製出去的檔案仍位於根磁碟上的掛載點下方，只是被掛載內容隱藏，因此必須卸載並刪除這些檔案後，空間才會釋放。對下一位登入者說明時，環境變數是兩種方法中較容易理解的選項。

容器實際儲存模型的位置

官方映像會將模型儲存在你掛載的位置，而不是任何屬於 ollama 使用者的主機目錄。文件中的執行指令如下：

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

冒號前的 ollama 是具名 Docker volume，/root/.ollama 則是伺服器在容器內寫入的位置。因此，對上一節提到的路徑執行 du 會找不到任何內容，因為模型並不在那裡。請列出實際位置與大小：

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

從 docker volume inspect 讀取 Mountpoint 欄位，然後對該路徑執行 sudo du -sh。若要將模型儲存在資料 volume，請將具名 volume 替換成主機目錄（-v /mnt/data/ollama:/root/.ollama），然後重新建立容器。容器會以 root 身分寫入，因此該主機目錄最後會由 root 擁有。在 rootless Podman 中，UID 會改為映射到你使用者的 subuid 範圍，因此主機上的擁有者看起來也會不同：在 rootless Podman 下執行 Ollama 說明了這項映射。

清理時請注意。docker volume prune 會移除所有沒有被任何容器參照的 volume。若移除或重新建立 ollama 容器時未保留其 volume，之後執行 prune 會刪除你下載的所有模型，除了重新下載之外沒有其他復原方式。在對存放模型的 VPS 執行 prune 前，請先閱讀 如何在 VPS 上清理 Docker 磁碟使用量。

使用 ollama rm 移除模型，不要使用 rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm 會刪除該標籤的 manifest，接著刪除沒有任何剩餘 manifest 參照的 layer。這些檔案解除連結後，空間會立即釋出，因此 df 也會馬上變動。由於 layer 可以共用，移除兩個高度相關標籤中的其中一個時，釋出的空間可能遠小於其旁邊 ollama list 顯示的大小。這是正常行為，不代表刪除失敗。

手動刪除檔案會破壞兩者的對應關係。使用 rm 移除 blob 後，manifest 仍會列出該 blob，因此 ollama list 仍會顯示該模型；使用模型時讀取缺少的 layer，操作就會失敗。手動移除 manifest 後，其 layer 仍會留在磁碟上，但已沒有任何項目指向它們，佔用的空間也不會由 Ollama 指令回報給你。如果你已經這麼做，對該標籤執行 ollama rm 可清除殘留項目；重新啟動伺服器則會清除沒有任何項目參照的 layer。

最後要區分一點，因為這兩者經常混淆。ollama rm 處理的是磁碟空間。ollama stop gemma4 會將模型從記憶體卸載，但完全不會釋放磁碟空間。模型下載完成後會在 RAM 中保留多久，是另一項設定；讓模型保持載入，而不是每次請求都重新載入會說明這項設定。

FAQ

ollama pull 與 ollama run 有何不同？

ollama pull 會將模型下載至磁碟後結束。ollama run 會檢查模型是否已存在於磁碟；若不存在，便下載模型、將其載入記憶體，然後開啟互動式聊天工作階段。兩者都會將相同檔案寫入相同目錄。在佈建與指令碼中使用 pull；有人操作終端機時使用 run。ollama run <model> "your prompt" 只會傳送一個提示並結束，是 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。若未設定，模型儲存區會位於服務執行帳號的 home directory 下；getent passwd ollama 可列出該帳號。sudo find / -xdev -type d -name blobs 2>/dev/null 可直接找出 layer directory。對於 container image，儲存區位於掛載的 volume 中，而 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 後，其 layer 仍會留在磁碟上，且沒有任何項目參照它們。請使用 ollama rm <model>；此命令會刪除 manifest，接著刪除其他模型不需要的 layer。若檔案已遭手動刪除，請對該 tag 執行 ollama rm 以清除項目，然後重新啟動伺服器；伺服器會移除沒有任何 manifest 參照的 layer。