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 单元。第二行会打开聊天会话；输入 /bye 或按 Ctrl+D 退出。第三行发送单个提示词，输出回答后退出；脚本需要获取回答而不是保持会话时，应使用这种形式。模型名称变化很快，因此应将此处的 gemma4 视为占位符：截至 August 2026，这是 Ollama 官方文档使用的示例，库中的任何标签都具有相同的行为。

为什么第一次运行 ollama 看起来像卡住了

在全新的 VPS 上，第一次执行 run 后可能几分钟没有任何输出。这不是故障。只有模型下载到磁盘并加载到内存后，聊天提示符才会出现，因此 run 会先下载数 GB 的数据，不会立即显示提示符。

有两个原因会隐藏这一过程。Ollama 只有在输出目标是终端时才会显示进度条，因此在 shell 脚本、cron 任务、CI 步骤或普通 ssh host ollama run ... 中运行 run 时，下载期间不会输出任何内容。数据写入磁盘后，还必须从磁盘读取到 RAM，之后才会生成第一个 token；在配置较小的 VPS 上，这个读取过程可能很慢。如果服务器没有足够的内存容纳模型，内核会开始使用 swap，等待时间会进一步延长。

不要猜测，改用另一个会话查看进度：

df -h /
watch -n5 df -h /

可用空间分阶段减少，表示下载仍在进行。命令仍处于忙碌状态，但可用空间不再减少，表示下载已完成，模型正在加载到内存。

因此应提前拉取模型。输入 ollama run 的人不应同时承担下载所需的等待时间。

在有人请求前拉取模型

在新服务器上，使用安装服务器的同一个脚本拉取模型：

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

如果这是首次部署服务器，请参阅完整的 Ollama VPS 安装指南。其中介绍了服务本身，以及允许访问服务的对象。完成这些配置后，应设置一个不会因终端退出而中断的拉取任务。下载中途被终止，模型存储就可能只完成部分写入。

在 tmux 中运行该任务，或者将其交给 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 才是唯一可靠的做法。通过 shell 运行时，会使用服务的 PATH，而不是照搬指南中的路径。第一个 ExecStart 同样很重要：After=ollama.service 只表示服务器单元已启动，不表示服务已经就绪。因此，循环会等待 ollama list 返回后再开始拉取。

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

日志中应显示拉取已完成且没有错误，随后 ollama list 应显示该模型。若要让会变化的标签保持最新，可添加 systemd timer 或每周运行一次的 cron 条目，执行相同的拉取命令。重新拉取已发生变化的标签时，系统会下载新的层；旧层不再被任何内容引用，并会在服务器下次启动时清理。

中断 pull 后会发生什么

模型的每一层都按自身内容的哈希值存储。因此，中断 pull 不会浪费已完成的工作：再次运行相同的 ollama pull 时，系统会识别并跳过已经完成的层，然后从中断的那一层继续下载。

有一个操作会破坏这部分进度。Ollama 服务器启动时，会删除没有被任何模型清单引用的已存储层。中断 pull 留下的部分层正属于此类。因此，在重试前重启服务，会丢弃已经下载的内容。应先重试 pull，之后再重启。如果确实需要让部分下载在重启后保留，请在服务环境中设置 OLLAMA_NOPRUNE=1，然后再移除该设置，因为正是启动时的清理机制防止孤立层持续占用磁盘空间。

如果 pull 因 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 配置，因此您设置的或镜像中预置的 OLLAMA_MODELS 行都会显示在其中。如果没有这类配置，模型存储目录位于运行服务的账户的主目录下；getent passwd 会在以冒号分隔的第六个字段中输出该主目录。find 会在一个文件系统中搜索 blobs 目录，模型层实际就写入该目录。如果模型可能已经位于单独的挂载点上，请删除 -xdev。

现在测量实际占用量，并以您自己的结果为准：

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

模型存储由两部分组成。manifests 为每个模型标签保存一个小文件，其中列出了该标签使用的模型层。blobs 保存模型层本身，每个层都以其内容的哈希命名；几乎所有空间都占用在这里。由于不同标签之间会共享模型层，两个基于相同权重构建的模型在 ollama list 中会分别报告自己的大小，但这些层在磁盘上只占用一份空间。因此，列出的大小之和可能大于 du 报告的目录大小。

模型文件填满小型 VPS 的根文件系统的速度，通常比您可能安装的其他内容都快。影响模型大小的最重要因素是权重格式。在 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 文件的编辑器，因此不会修改软件包提供的单元文件，软件包升级也不会覆盖您的更改。添加以下两行：

[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输出挂载信息表示绑定挂载已生效。如果系统上的其他程序已经依赖默认位置，绑定挂载会更合适。此方法有一个问题：复制出去的文件仍位于根磁盘上的挂载点下，只是被挂载内容隐藏，因此必须先卸载并删除这些文件，空间才会释放。对于下一位登录系统的人员来说，环境变量更容易解释。

容器实际存储模型的位置

官方镜像会将模型存储在您挂载的位置，而不是任何属于 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 引用的层。取消文件链接后，空间会立即释放，因此 df也会马上移动。由于层可以共享，删除两个关系密切的标签中的一个时，释放的空间可能远小于其旁边 ollama list显示的大小。这属于正常行为，不是删除失败。

手动删除文件会破坏两者之间的对应关系。使用 rm删除 blob 后，manifest 仍会列出它，因此 ollama list仍会显示该模型；尝试使用模型时，读取缺失层会失败。手动删除 manifest 后，其层仍会留在磁盘上，但已没有任何引用它们的内容，因此会占用磁盘空间，而 Ollama 的任何命令都不会报告这些空间。如果已经这样操作，请对该标签执行 ollama rm，以清除残留条目；重启服务器后，未被任何内容引用的层也会被清除。

最后说明一个经常混淆的区别。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 /：如果可用空间逐步减少，说明下载正在进行。提前拉取模型即可避免等待。

Ollama 将模型存储在哪里？

存储位置取决于安装方式，因此应打印位置，不要直接假定。运行 systemctl cat ollama.service，查看单元或 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，然后删除其他模型不需要的层。如果文件已经被手动删除，请对该 tag 运行 ollama rm 以清除条目，然后重启服务器；服务器会删除没有任何 manifest 引用的层。