Ollama 的模型文件位置由环境变量 OLLAMA_MODELS 决定，默认通常落在当前运行用户的 ~/.ollama/models（Linux/macOS）或 C:\Users\<用户名>\.ollama\models（Windows）。所以“修改模型存储路径”实际要做的是两件事：让 Ollama 进程看到新的 OLLAMA_MODELS，并保证新目录对运行 Ollama 的系统用户可读写。前者取决于你用哪种方式启动 Ollama（systemd 服务、前台 ollama serve、Docker 容器、Windows 桌面程序），改法不一样；后者经常被忽略，改完启动失败多半是权限问题，而不是路径写错。
把模型目录换到大磁盘，通用做法是：先停掉 Ollama，把原~/.ollama/models完整迁移到新位置，再按启动方式注入OLLAMA_MODELS（systemd 用 drop-in，容器用挂载，前台用 export），最后确认新目录属主与运行用户一致。判断是否成功的信号是ollama list结果与迁移前一致，且新目录下出现 blobs、manifests 内容。若目录权限或挂载点没准备好，建议先回退到默认路径再排查，不要在原路径和软链接之间反复折腾。
先确认当前场景和目标
动手前先确认三件事，否则容易改到不生效的位置。第一，Ollama 是怎么起来的：包管理器安装的系统服务、手动 ollama serve、Docker 容器，还是 Windows 桌面托盘程序。第二，当前模型到底存在哪、有多大，是不是真的需要搬迁，还是只是磁盘紧张需要扩容。第三，目标路径所在磁盘的剩余空间、文件系统类型，以及 Ollama 运行用户对该目录是否有写权限。
- 看服务定义：
systemctl cat ollama，重点看User=、Environment=和ExecStart=。 - 看当前占用：
du -sh ~/.ollama/models，同时确认ollama list里有几个模型。 - 看容器挂载：
docker inspect ollama --format '{{json .Mounts}}'。 - 看目标盘：
df -h /data，避免迁到空间不足或网络文件系统的挂载点。
如果 systemctl cat ollama 显示的 Environment= 已经写了别的 OLLAMA_MODELS，说明之前有人改过，先确认旧值是不是你想要的，再决定覆盖还是修改。Docker 部署则不要试图在容器内改路径，直接把宿主机目录挂到容器内的模型目录更稳妥。
按这个顺序处理
推荐顺序是：停服务 → 迁移数据 → 设置变量 → 修权限 → 启动。先设置变量再迁移容易在启动时把新目录写空；反过来先停服务再拷贝，能避免拷贝过程中文件被追写。
1. 停止 Ollama 并迁移已有模型
sudo systemctl stop ollama
sudo mkdir -p /data/ollama/models
sudo rsync -a --info=progress2 ~/.ollama/models/ /data/ollama/models//data/ollama/models 是可替换项，换成你自己的目标目录；如果 Ollama 服务以 ollama 用户运行，源目录应取该用户的家目录，例如 /usr/share/ollama/.ollama/models，可以用 systemctl cat ollama | grep -E 'User|Environment' 确认后再拷贝。
2. 按启动方式注入 OLLAMA_MODELS
systemd 场景建议用 drop-in，不改动包管理器自带的 unit 文件，升级时更不容易被覆盖：
sudo systemctl edit ollama
# 在打开的编辑器中写入：
[Service]
Environment="OLLAMA_MODELS=/data/ollama/models"前台运行的方式是在同一 shell 中导出变量，再启动进程：
export OLLAMA_MODELS=/data/ollama/models
ollama serve容器方式通过挂载解决，容器内的模型目录保持不变：
docker run -d --name ollama \
-v /data/ollama/models:/root/.ollama/models \
-p 11434:11434 ollama/ollamaWindows 桌面版可在“系统属性 → 环境变量”中新增用户变量 OLLAMA_MODELS，值指向目标目录，也可以执行 setx OLLAMA_MODELS "D:\ollama\models"，之后必须完全退出托盘中的 Ollama 再重新启动，只关窗口不会让新变量生效。
3. 修正目录属主后启动
sudo chown -R ollama:ollama /data/ollama/models
sudo systemctl daemon-reload
sudo systemctl start ollama
sudo systemctl show ollama -p Environment最后一条用于确认变量是否被服务真正读到。若输出里仍有旧的 OLLAMA_MODELS，检查是不是主 unit 和其他 drop-in 同时设置了同名变量，以服务实际加载的结果为准。
改完后怎么验证
验证分三层，缺一层都不算完成。第一层是变量生效：sudo systemctl show ollama -p Environment 显示的路径与目标一致，容器场景用 docker exec ollama printenv OLLAMA_MODELS 检查。第二层是旧模型可用：ollama list 的输出应与迁移前一致，ollama run 一个已有模型能正常加载，不会触发重新下载。第三层是新写入落到新目录：拉取或运行一个模型后，用 ls /data/ollama/models/blobs | head 和 ls /data/ollama/models/manifests 看是否出现内容，同时确认旧目录不再增长。
预期信号是：服务启动日志里没有 permission denied 或 no such file or directory；ollama list 与迁移前条目一致；新目录大小随拉取模型增长；旧目录大小保持不变。若 ollama list 变空，通常是服务读到了新目录但数据没迁全，或数据迁到了运行用户看不到的位置，先用 journalctl -u ollama -n 50 对照日志再决定是否重迁。
容易忽略的边界
目录权限是最常见的坑：root 手动创建并拷贝的目录，属主往往是 root，而服务以 ollama 用户运行，结果就是能启动但写不进模型。挂载点也要注意顺序，如果 /data 是独立磁盘且开机时挂载，Ollama 必须在挂载完成之后启动，否则会先在根分区写出同名目录，后续挂载把它遮住，表现为“模型好像丢了”。
带 SELinux 或 AppArmor 的发行版，换到非默认目录后可能需要补充安全上下文，否则同样报权限错误；NFS、SMB 这类网络文件系统一般不建议直接作为模型目录，锁和延迟都可能带来问题。Windows 上 setx 只影响之后新开的进程，托盘程序要彻底退出；用户变量和系统变量同时存在时，以用户变量优先，改错位置会看起来“不生效”。
回退路径要提前想好：删掉 drop-in 里的 Environment 行，执行 systemctl daemon-reload 并重启，即可回到默认路径；只要旧目录还没删除，模型不会丢。升级 Ollama 后建议再执行一次 systemctl show ollama -p Environment，确认自定义配置仍被加载，再决定是否需要重新处理。