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 退出。第三行发送单个提示词，输出回答后退出。这正是脚本需要的形式：获取回答，而不是保持会话。第三种形式仍然完全由模型决定回答长度，因此一行问题可能得到三段回答；使用 num_predict 限制回答长度，才能让脚本生成的 run 保持在调用方实际可用的大小范围内。模型名称变化很快，因此请将此处的 gemma4 视为占位符：截至 August 2026，这是 Ollama 官方文档使用的示例，库中的任何标签都以相同方式工作。如果您希望改用一个已经根据实际服务器规格确定资源需求的模型，在 VPS 上运行 Nemotron 3.5 Lightning 会提供确切的拉取标签和所需内存。

为什么第一次运行 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 的人不应承担下载所需的等待时间。

在有人请求前预先拉取模型

对于任何非交互式客户端，情况也一样：指向您的 Ollama 端点的编码代理通常会在首次请求时直接放弃，而不会等待数 GB 的下载完成。在新服务器上，应在安装服务器的同一脚本中执行拉取：

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

如果您是首次部署服务器，VPS 上完整安装 Ollama会介绍服务本身，以及允许访问该服务的对象。接下来值得配置的是一个不依赖终端会话的拉取任务，因为下载在中途被终止，通常会导致模型存储库只包含部分内容。

请在 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

journal 应显示拉取已完成且没有错误，随后 ollama list 应显示该模型。要让会移动的标签保持最新，请添加 systemd timer，或添加每周运行一次相同拉取命令的 cron 条目。重新拉取已移动的标签会下载新的层，并使旧层失去引用；这些旧层会在服务器下次启动时清理。

中断拉取会发生什么

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

有一个操作会破坏这一进度。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 配置，因此由您设置或内置于镜像中的 OLLAMA_MODELS 行都会显示在那里。如果没有这类配置，模型存储目录位于服务运行账户的 home 目录下；getent passwd 会在以冒号分隔的第六个字段中输出该 home 目录。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 所有。在无 root Podman 中，ID 会映射到您用户的 subuid 范围，因此主机上的所有权又会有所不同：在无 root Podman 下运行 Ollama介绍了这种映射。

清理时需要注意。docker volume prune 会删除所有未被任何容器引用的卷。如果删除或重新创建 ollama 容器时不保留其卷，之后运行 prune 会删除您下载的所有模型，除非重新下载，否则无法恢复。在对存储模型的服务器运行 prune 前，请先阅读 如何清理 VPS 上的 Docker 磁盘占用。

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

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm 会删除该标签对应的清单，然后删除所有不再被任何清单引用的层。文件解除链接后，空间会立即释放，因此 df 会马上反映变化。由于层可以共享，删除两个高度相关标签中的一个时，释放的空间可能远小于其旁边 ollama list 显示的大小。这是正常行为，并不表示删除失败。

手动删除文件会破坏两者之间的对应关系。使用 rm 删除 blob 后，清单仍会列出该 blob，因此 ollama list 仍会显示该模型；使用模型时，读取缺失的层会失败。手动删除清单后，其层仍会留在磁盘上，但没有任何引用指向这些层，因而会继续占用空间，而且 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 的脚本化形式。

为什么第一次运行 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 可直接定位 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 后，其 layer 仍会留在磁盘上，但没有任何引用它们。应使用 ollama rm <model>；该命令会删除 manifest，然后删除其他模型不再需要的 layer。如果文件已经被手动删除，请对相应 tag 运行 ollama rm 以清除条目，然后重启服务器。服务器会删除没有任何 manifest 引用的 layer。