ubuntu ollama models 路径

在 Ubuntu 上跑 Ollama，拉了几个模型之后系统盘就红了，想换个盘又怕删了重下。这篇从「模型到底存在哪」讲起，给一套查路径、改路径、迁移旧模型、验证生效的完整流程，顺带说清哪些情况不适合挪目录——比如你用的是容器或多用户共用一台机器。

在 Ubuntu 上跑 Ollama，最容易踩的坑不是装不上，而是拉了几个模型之后系统盘突然红了。这时候大家第一反应是「删了重下」，但模型权重动辄几个 G，重下既费流量又费时间。其实只要搞清楚 Ollama 把模型放哪、怎么改这个位置，把目录挪到大盘或挂载盘上就行，整个过程不用重拉一次。

这篇按「先查清楚 → 再挪 → 挪完验证 → 出问题能退回来」的顺序讲。中间会说到 systemd 服务和容器两种场景的差别，以及哪些情况下这件事不值得做。文中不写死任何数字和版本，需要看具体体积、价格这类会变的信息，到站内对应页面核对当时的数字。

Ollama 的模型默认放在哪

先说结论：Linux 上 Ollama 的模型根目录，默认是挂在当前运行 Ollama 的那个用户的家目录下面，而不是 /usr/share、/var/lib 这类系统目录。这一点很关键，因为它直接决定了三件事——你要有那个用户的家目录读写权限、备份的时候要想到它、以及换个用户跑服务可能就看不到原来的模型了。

目录内部不是「一个模型一个文件夹」的结构。它按 blobs 和 manifests 分开存：blobs 是真正的权重分片，manifests 是清单，记录某个模型名对应哪些分片。同一个基础模型被多个 tag 复用时，blob 只存一份。所以你不能靠数文件夹个数来判断装了几个模型，也不能随手删某个文件夹就当作卸载。

blobs

实际的权重分片文件，体积大头都在这，多个 tag 复用时共享同一份

manifests

清单文件，记录模型名、tag 和它引用了哪些 blob，体积很小

运行用户

启动 Ollama 进程的那个账号，决定了默认家目录落在哪

先查清你这台机器实际用的路径

改之前必须先确认这台机器实际生效的是哪个目录。别翻文档猜默认值，因为环境变量、服务配置都可能覆盖它。按下面的顺序排查，基本不会漏。

1. 确认进程是以哪个用户起的看当前跑 Ollama 的进程属于哪个账号，这个账号的家目录就是默认候选位置。多用户机器上尤其要先确认这一步。
2. 查该用户环境里有没有覆盖项环境变量里的模型目录设置如果存在，会盖掉默认值。在运行用户的 shell 里直接看这个变量，比翻配置文件快。
3. 看服务单元里的配置如果是 systemd 托管的，去服务单元的配置里找运行用户和目录相关的设置，非交互式启动不读登录 shell 的那些文件。
4. 用目录体积反推已经拉过模型的机器，看哪个候选目录体积最大、文件时间最新，真正在被读写的那个才是生效目录。
5. 记下三件事再动手运行用户、生效目录、所在挂载点。同时确认目标盘有足够空间，不然挪到一半空间不够更麻烦。

命令行里也可以直接问 Ollama 自己当前生效的模型目录，这比任何二手资料都可靠。查完把这几个值记在一张纸上或笔记里，后面回退要用。

把模型目录挪到大盘上的完整步骤

迁移的动作顺序是固定的，顺序错了轻则白搬一次，重则模型显示未下载。核心原则两条：先停服务，以及用复制而不是剪切。

1. 停掉服务先把正在跑的 Ollama 停干净，确认进程确实退出了。带着进程复制可能拿到写了一半的文件。
2. 复制而不是移动用保留权限和时间戳的方式整目录复制到新位置。复制完对比两边的文件数量和目录体积，确认完整。
3. 改配置指向新目录按你的启动方式改对应位置。手工在 shell 里跑改 shell 配置，systemd 托管就改服务单元，两套位置别搞混。
4. 启动并确认新目录在长体积重启服务，然后看新目录的体积有没有变化、有没有新文件写进去。这一步能直接证明配置生效了。
5. 确认稳定后再清理旧目录旧目录先留着，观察一段时间，确认重启后依然正常读写，再回收空间。

目标盘的选择有讲究。本地块设备或者稳定挂载的盘最稳；U 盘、临时挂载点、会被系统自动卸载的路径都不适合放模型。判断标准很简单：机器重启后这个路径还在不在，不在就别放。

• 复制时保留权限和时间戳，避免 manifest 与 blob 权限不一致导致已拉取的模型显示未下载
• 环境变量写法要跟启动方式匹配，改错地方的表现就是「改了但没生效」
• 新盘优先本地块设备或稳定挂载盘，别用容易被卸载的路径
• 停服务要停干净，别只看命令返回不报错就当没事

systemd 服务与容器场景的差别

同一件事，服务方式和容器方式的改法完全不同，改错位置是最常见的「改了没生效」。服务方式下，环境变量要写进服务单元，因为非交互式启动不读登录 shell 的配置；写在 shell 配置里对服务没影响。

容器里跑 Ollama，模型目录通常靠卷挂到宿主机，这样容器重建后模型不会丢。这时候你要改的是挂载关系，不是环境变量。挂载点和宿主机的目录要对应清楚，容器里看到的路径和宿主机上的实际路径是两回事。

改完怎么验证，出问题怎么退回去

迁移做完不要只看服务起没起来，要按三步验证。第一步，列出已装模型，看能不能正常显示；第二步，随便跑一次推理，确认不报找不到文件；第三步，触发一次新的拉取动作，看文件是不是写进了新目录。三步都过，才算真的成了。

• 列出已装模型正常显示，说明 manifest 和 blob 都能读到
• 跑一次推理不报找不到文件，说明读取链路通了
• 新拉取动作写进新目录，说明写入方向也对
• 重启一次服务再看一遍，确认不是这次会话的临时状态

空间核对建议用目录体积对比，而不是看剩余空间去估算，因为旧目录没清干净的话很容易误判。旧目录保留一段时间再删是稳妥做法，确认新路径重启后仍生效、读写稳定，再回收。

回退其实很简单，就是把配置改回原值然后重启服务。所以动手前一定先把原始配置和原目录位置记下来。有这张记录，最坏情况也就几分钟恢复。

目录越来越大时怎么管

体积涨得快，先分清是权重本身占大头，还是同一个模型的多个 tag 在重复占位。这两种情况的处理方式不一样：前者考虑是不是有必要装这么多模型，后者删除不用的 tag 通常比删整个模型更划算，因为共享的 blob 不会被连带删掉。

清理前先用列出模型和体积的方式定位大头，别凭印象删。凭印象删的结果往往是把常用的删了、没用的留着。另外拉取和推理是两种不同的读写模式，模型目录放在读写性能较好的本地盘上体验更稳，纯冷备的模型可以另算。

磁盘剩余空间要留出余量。拉取新模型时需要临时空间解包，盘快满的时候拉取容易中途失败，而且失败后留下的临时文件还得手动清。至于各模型具体占多少、当前有哪些可选模型，这类会变的数字到站内模型资料库核对。

什么情况下不建议动这个目录

不是所有情况都适合挪目录。下面这几类要么别动，要么换个做法，硬上反而给自己找麻烦。

• 生产服务正在跑还有并发请求：要么挑低峰窗口，要么干脆用新机器重建环境再切流量
• 用配置管理工具统一部署的集群：手改单机会造成配置漂移，应该改模板而不是改机器
• 有合规或审计要求数据落在固定分区：先确认新路径在不在允许范围内，再动手
• 不熟悉 systemd 和权限操作：先在测试机走一遍全流程，成本远低于直接改生产机
• 目标盘是临时挂载或网络不稳的存储：重启后路径可能不在，模型就找不到了

还有一类是「其实不需要挪」。如果只是偶尔用几个模型，加块盘做别的用途、把模型留在原地可能更省事。判断标准看你的使用频率和模型数量，而不是看剩多少空间。

先查清生效路径，再复制不剪切，改完按三步验证，旧目录留一阵再删——这四句话记住了，迁移基本不会翻车。