Ollama模型存储路径迁移：修改OLLAMA_MODELS环境变量释放系统盘

1. 为什么非动不可：默认路径的痛点与适用场景

先聊聊背景。Ollama 这个工具，用过的都知道，本地跑大模型的体验做得相当干净：一条命令拉模型，一条命令进对话，API 也有，配合各种前端项目特别方便。但正因为太方便了，很多人装完就顺手开始 pull 模型，等反应过来的时候，几十个 G 已经填进去了，而且全留在系统盘里。我见过不少开发者，C 盘剩余空间从几十 G 一路掉到三五个 G，最后还是回来学怎么改路径。

先说清楚默认路径到底放哪。Ollama 装完后，模型默认存放在用户目录的.ollama/models文件夹下面。Windows 上是C:\Users\用户名\.ollama\models，macOS 上是~/.ollama/models，Linux 上如果是用安装脚本装的，通常在/usr/share/ollama/.ollama/models，如果用 Docker 跑，那模型是在容器里的/root/.ollama/models。这个默认行为本身没什么问题，但它隐含了三个坑。

第一个坑是空间。一个 7B 参数的量化模型，通常 4 到 5 个 G，13B 大概是 8 到 9 个 G，70B 量化后也能到 40G 以上。你要是同时下三五个模型，系统盘直接就顶不住了。很多人的系统盘是 256G 或 512G 的 SSD，本身装了系统和软件就已经占了大半，再塞几个模型进去，剩下的空间连编译项目都费劲。

第二个坑是重装系统。模型文件在 C 盘，重装系统时除非你刻意备份，否则就是全部丢失。而这些模型是慢慢下回来的，很多大模型的下载量是按 G 算的，重装一次系统，等于把积累全清零，重新下载的时间成本会让人很上头。

第三个坑是性能差异。模型加载完之后的推理过程，其实对磁盘的持续读取要求不算特高，算力主要还是在 GPU 和内存上，但首次加载模型时要把权重全部读入内存，这一步就是典型的顺序读操作。如果你的系统盘是 NVMe SSD，而数据盘是普通 SATA SSD 或者机械硬盘，加载耗时差距就会显现出来；反过来，如果系统盘空间紧张到只剩几个 G，虚拟内存和缓存都在挤牙膏，整个系统都跟着慢。

所以什么场景适合做迁移？我总结下来是这几类：系统盘空间不足的普通用户；有多块磁盘、想把模型专门放一块容量的数据盘上的玩家；需要把整套 Ollama 连同模型搬到另一台机器上的开发者；还有用 Docker / 服务器部署，希望模型目录独立于系统盘、方便统一管理和备份的团队。这篇文章里我会把完整操作拆开讲，Windows 为主，Linux 和 macOS 的关键差异也带上。

2. 弄清模型存储结构再动手：默认位置与路径规则

2.1 各平台默认存储位置

要迁移，先得知道东西存在哪。Ollama 的模型目录，官方叫法是模型存储目录，实际路径取决于平台和安装方式：

而 Ollama 程序本体，在 Windows 上默认装在C:\Program Files\Ollama，这个目录里是主程序、运行库这些。程序目录我一般建议别动，保持默认就好，真正要迁移的主要是模型目录，也就是.ollama整个文件夹。程序目录动起来牵扯到服务注册、安装路径、启动方式，容易出现乱七八糟的问题，模型目录则安全得多，本质上就是拷文件加指向改路径。

2.2 存储目录里的文件长什么样

在你动手之前，先打开.ollama\models看一眼。里面不是一堆散落的模型文件，而是两个核心子目录：manifests和blobs。

manifests存放的是模型的清单文件，每个模型对应一个 JSON 格式的描述，记录了这个模型由哪些层组成、每个层的哈希值、大小等信息。真正的大块头都在blobs目录下，里面是二进制数据文件，文件名是一串 sha256 哈希。为什么要这么设计？因为 Ollama 支持模型分层复用：如果两个模型共享同一个基础层，那这个层在磁盘上只存一份。比如某个中文模型和它的聊天变体，基础权重相同，blobs 里就能复用同一份大文件，节省不少空间。你迁移的时候，manifests和blobs是整套搬走的关系，缺一个都会导致模型识别不了或加载失败。

提示：有些初学者看到 blobs 里的哈希文件名以为文件损坏，其实那只是内容寻址存储的正常表现，不要手动改文件名。

2.3 真正控制路径的是环境变量而不是配置文件

Ollama 控制模型路径的核心，是一个叫OLLAMA_MODELS的环境变量。版本更新到现在，官方始终没有提供一个直观的 GUI 设置项去改模型目录，配置方式就是设环境变量。为什么用环境变量而不是配置文件？因为 Ollama 在桌面端需要跟随用户登录启动、在服务器端需要跟随系统服务启动，环境变量在这两种场景下都能被服务进程读取到，而配置文件在不同平台上的位置和权限处理会更麻烦。官方把这个设计保持得很简单，我们也别去花心思找“配置文件”，直接把目光聚焦在环境变量上就行。

除了OLLAMA_MODELS，常见的有这么几个环境变量：

• OLLAMA_MODELS：模型存储路径，迁移的核心变量。
• OLLAMA_HOST：服务监听地址和端口，默认127.0.0.1:11434，改成0.0.0.0:11434可以允许局域网其他机器访问。
• OLLAMA_KEEP_ALIVE：模型在内存中停留的时间，默认 5 分钟，改成-1可以让模型一直驻留内存，适合需要频繁响应场景。
• OLLAMA_NUM_PARALLEL：并行处理请求数，默认 1，并发高时可以调大，但会占用更多显存。

后面几个变量和迁移关系不大，但知道了有这些货，你在排查问题的时候思路会宽很多。

3. 迁移全流程实操：数据备份、变量修改、模型搬移

3.1 迁移前的准备清单

我建议你按这个顺序来准备，不要上来就直接拷贝文件。

第一步，先搞清楚目标盘符和目录。比如你想把模型放到 D 盘的D:\AIModels\ollama，那这个目录最好单独建一个，不要和乱七八糟的软件装在一起。目录路径尽量用纯英文，不要带中文或空格，虽然 Ollama 对中文路径的兼容性比早期好了一些，但为了稳一点，还是用纯英文最保险。

第二步，检查磁盘剩余空间。新目录所在磁盘的剩余空间，至少要大于当前模型目录的总大小。怎么查当前模型目录多大？在命令行里到.ollama目录下跑一条命令就行：

Windows PowerShell 下：

Get-ChildItem -Path "C:\Users\用户名\.ollama" -Recurse | Measure-Object -Property Length -Sum

Linux 或 macOS 下：

du -sh ~/.ollama

我见过有人赶时间，没看空间就把模型往新盘拷，拷到一半空间满，然后两边各留一半残缺文件，反而更难收拾。这条别省。

第三步，确认当前正在运行的模型会话。先看看有没有模型还挂在内存里占着文件锁。运行ollama ps，如果列表为空，说明当前没有模型被加载；如果有模型还在跑，建议正常退出客户端，或者等推理任务结束后再操作。

3.2 第 1 步：停掉服务再动手

这是整个迁移里最容易翻车的环节。Ollama 在 Windows 上默认是通过系统托盘常驻的，服务进程是ollama app.exe，迁移期间如果这个进程还开着，它可能会持有模型文件句柄，导致拷贝失败，或者拷贝到一半进程重新写入数据，最后得到一份不一致的目录。所以必须先彻底退出。

Windows 上操作：

1. 右键点击托盘区域的 Ollama 图标，选 Quit 退出。
2. 打开任务管理器，在“详细信息”里找ollama app.exe和ollama.exe，确认都退干净了。
3. 如果还挂在后台，可以在管理员 PowerShell 里强制结束：

Stop-Process -Name "ollama" -Force

Linux 上操作要看服务管理器：

sudo systemctl stop ollama

macOS 上点菜单栏图标退出，或在终端里：

launchctl stop ollama

这一步如果停了，迁移的其余操作才算有保障。

3.3 第 2 步：设置 OLLAMA_MODELS

这一步的核心就是把新路径告诉 Ollama。Windows 里图形界面设置环境变量最直观，按 Win 键搜索“环境变量”，打开“编辑系统环境变量”，在“高级”选项卡里点“环境变量”，然后在系统变量列表里新建一个变量：

• 变量名：OLLAMA_MODELS
• 变量值：D:\AIModels\ollama

这里有一个细节容易被忽略：环境变量分用户变量和系统变量。Ollama 在 Windows 上是通过用户会话启动的，所以设置在用户变量里通常就够。但如果你希望这台机器上的所有用户共享同一份模型目录，那就设置在系统变量里。我个人建议放用户变量，减少系统级配置的权限问题。

Linux 上设置方式更直接，修改服务配置文件：

sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf <<'EOF' [Service] Environment="OLLAMA_MODELS=/data/ollama/models" EOF

然后重载服务：

sudo systemctl daemon-reload

macOS 上设置 launchd 环境变量稍微绕一点，需要修改~/Library/LaunchAgents/com.ollama.app.plist加一个 EnvironmentVariables 字典，或者在启动命令前用launchctl setenv注入。图形界面下也可以通过“环境变量”面板修改，但 mac 的图形配置入口不如 Windows 直观，建议直接编辑 plist 或者用launchctl setenv OLLAMA_MODELS 路径再重启 Ollama。

注意：环境变量改完之后，如果 Ollama 进程已经启动，它不会自动读取新变量，必须重启进程才生效。这也是后面很多“改了不生效”问题的根源。

3.4 第 3 步：把旧模型搬到新位置

拷贝方式我推荐用系统自带命令，稳定可靠，不用额外装工具。Windows 下用 robocopy，这个是微软官方提供的文件复制工具，特别适合大量小文件和断点续传场景。

先把旧目录原样复制到新路径：

robocopy "C:\Users\用户名\.ollama" "D:\AIModels\ollama" /E /COPYALL /DCOPY:T

参数说明：

• /E：复制所有子目录，包括空目录。
• /COPYALL：复制所有文件信息，包括数据、属性、时间戳、安全信息。
• /DCOPY:T：复制目录时间戳。

我第一次迁移的时候没有加/COPYALL，结果复制的目录里文件时间戳全变了，虽然 Ollama 读模型靠的是哈希和清单，时间戳变了不影响使用，但后续排查问题、判断哪份文件是新的时很容易糊涂，所以建议一步到位加上。

复制完成后，做一次对比验证。robocopy 在复制结束后会输出统计信息，看“失败”列是否为 0。如果中间网络或磁盘波动导致有文件没复制成功，它会明明白白列出来。稳妥起见，再跑一次同样的 robocopy 命令，幂等会快速跳过已完成部分，最后输出一致就说明两边目录同步。

Linux 下直接用rsync更顺手：

sudo rsync -av --progress /usr/share/ollama/.ollama/ /data/ollama/models/

注意源目录结尾的斜杠，加斜杠表示复制目录内的全部内容，而不是复制目录本身。rsync 的-a是归档模式，保留权限、时间戳等属性。

3.5 第 4 步：重启服务并验证模型可用

重启 Ollama。Windows 上直接去开始菜单点 Ollama 图标启动。

启动后多做一步验证：打开命令行，运行：

ollama list

重点看一下输出的模型列表是否完整，然后随便选一个模型跑一句对话测试：

ollama run 某个已有的模型名 "你好，简单介绍一下你自己"

能正常输出，说明 Ollama 成功在旧路径找不到模型，然后在新路径的OLLAMA_MODELS下找到了模型文件。

我遇到过一种情况：ollama list正常，但ollama run报model not found。原因是环境变量指向的路径下，blobs 文件不完整，或者 manifests 与 blobs 之间没有对应上。这时候回到D:\AIModels\ollama目录，对比一下manifests和blobs的内容是否和旧目录一致就有答案了。robocopy / rsync 只要报成功，这类问题基本不会出现，但排查思路要清楚。

确认一切正常后，旧目录不要立即删。我习惯保留一段时间，等新目录稳定运行几天、确认每次加载都正常后，再把旧目录清掉。这个习惯能让你在遇到问题时随时可以回滚。

4. Ollama 常用命令速查与深度解读

4.1 基础命令：list、run、pull

这部分命令是天天要用的，但很多 人只是“能跑就行”，没深究过参数细节。

ollama list查看本地已有的模型列表。输出里有两列：模型名和大小。比如qwen2:7b、llama3.1:8b这种。注意模型名里的冒号前是模型家族名，冒号后是标签（tag），可能代表参数量、量化格式或版本。列模型的时候，如果某个模型是从某个 Modelfile 创建的，名字会有别的前缀，但这个后面再展开。

ollama pull <模型名>从远程仓库拉取模型。如果你知道要精确版本，尽量直接指定 tag。比如ollama pull qwen2:7b-instruct-q4_K_M和ollama pull qwen2拉下来的可能不是同一个文件，后者默认 tag 往往是官方推荐的最新版。做迁移或备份时，我建议先list一下看本地到底有哪些带 tag 的版本，别盲目认为ollama pull qwen2拉的就是你之前用的那个。

ollama run <模型名>启动一个交互式对话会话。进去之后可以正常聊天，输入/exit退出；输入/bye某些版本也支持但不太标准。run还有几个值得一提的参数组合：

ollama run llama3.1:8b --verbose

--verbose会在每次输出后打印详细的统计信息，包括 token 生成速度、评估耗时、显存占用等。调优或测速的时候非常有用。

ollama run qwen2:7b "用一句话解释什么是数据库索引"

直接给 prompt 参数，不进入交互模式，适合在脚本里调用。

4.2 模型管理：rm、show、cp

ollama rm <模型名>删除模型。删除的是本地模型记录和对应的 blobs 层文件。这里有个细节：如果两个模型共享了 blobs 里的某些层，删除一个模型不会把共享层删掉，因为引用计数还没归零。这个机制是好事，但如果你删完之后想确认空间是否真的释放，别只看一个模型的大小，还要对比删除前后ollama list里总占用和磁盘剩余空间。

ollama show <模型名>输出模型的详细信息：

ollama show llama3.1:8b

通常能看到模型架构、参数大小、量化类型、上下文长度、可能还有 license 信息。这里面最有用的其实是确认你到底下载的是哪个变体，特别是刚从第三方仓库拉模型的时候。

ollama cp <源模型名> <新模型名>复制一份模型记录。注意这个复制不是物理复制文件，而是在 manifests 里为同一组 blobs 创建一个新引用。说白了，就是给同一组权重换了个名字。好处是你可以在此基础上改造 Modelfile 而不用重复下载权重，坏处是如果你不理解“新名字照样占着旧层”这回事，可能会误以为删掉一个名字就省了空间。

4.3 构建与导入：create、import 相关

ollama create <模型名> -f <Modelfile>根据 Modelfile 构建自定义模型。Modelfile 的语法类似 Dockerfile，但内容更精简，核心指令包括 FROM（基础模型）、SYSTEM（系统提示词）、PARAMETER（推理参数）、TEMPLATE（对话模板）等。

举个例子，你想创建一个带特定中文系统提示词的模型：

FROM qwen2:7b SYSTEM "你是资深运维专家，回答问题时先给出结论再展开细节" PARAMETER temperature 0.7 PARAMETER num_ctx 8192

然后执行：

ollama create my-ops-assistant -f ./Modelfile

跑完ollama list里就会多一个my-ops-assistant。这事和模型迁移的关系在于，很多人以为自定义模型是下载了新权重，其实它只是在你本地已有的基础模型之上套了个配置壳，权重文件都是复用旧模型的 blobs。你迁移模型目录时，这类自定义模型的清单也在 manifests 里，跟着迁走即可，不用担心丢了自定义 Modelfile 就丢模型。

4.4 服务与调试：serve、ps、环境变量

ollama serve是手动启动服务的命令。正常安装时服务是自动启动的，手动跑 serve 主要用于排查问题，因为前台启动时日志直接打印在终端上，报错信息比平时明显。比如你改完环境变量但服务起不来，跑一下ollama serve能看到它读的路径、有没有权限错误，这些都是排查的第一手线索。

ollama ps查看当前正在运行的模型会话。输出项包括模型名、进程 ID、运行时长、上下文窗口占用等信息。我个人习惯在清理显存之前先跑一下ollama ps，确认没有会话占用 GPU。如果有些模型你不确定是不是常驻内存，ps一看就知道。OLLAMA_KEEP_ALIVE设成-1时，模型会一直驻留，此时ps里就会一直挂着这条模型记录。想立刻释放的话，可以直接把OLLAMA_KEEP_ALIVE改回短一点的时间并重启服务。

还有一个调试命令容易被忽略：ollama --version。迁移环境变量后如果版本路径出了问题，有时版本信息和运行时行为会给你线索；另外在官方 GitHub 提 issue 时，贴版本号也是基本素养。

5. 常见问题与排查技巧实录

5.1 改了环境变量但 ollama list 仍然显示旧路径

这个是我看到最多的问题。改完变量后不看效果就重启？大概率是没重开命令行窗口。环境变量是进程启动时读取的，你现有的终端窗口是在修改之前打开的，它继承的是旧环境，即使 Ollama 进程重启了，它也是从旧环境里继承的新变量？不对，这里要理清楚：如果你在系统设置里改了环境变量，已经打开的终端不会自动获得新值，从那个终端里启动 Ollama，读到的依然是旧值。解决办法是重新打开一个终端窗口，或者干脆注销重新登录。

还有一种情况，Ollama 不是你自己手动启动的，而是开机自启动的托盘程序。托盘程序启动时读取的环境变量来自系统或用户配置；如果你改了变量但托盘程序是在登录时立刻启动的，它可能先于某些配置刷新而读到旧值。最稳妥的做法是先在任务管理器里确认 Ollama 进程已结束，再重启 Ollama，而不是简单地靠修改开机启动项。

Linux 上如果用的是 systemd 服务，设置环境变量后必须daemon-reload再systemctl restart ollama，否则服务进程拿到的还是旧配置。

5.2 服务启动失败或模型加载报错

常见错误是permission denied或failed to open。迁移后新目录的权限不对，尤其在 Linux 上，Ollama 服务默认以ollama用户运行，你拷贝过来的目录可能属于 root，服务没有读取权限。修复方式：

chown -R ollama:ollama /data/ollama/models chmod -R 0755 /data/ollama/models

Windows 上这类问题少一些，但如果你把模型目录放在了 NTFS 权限受限的文件夹下（比如别的用户创建的项目目录），也可能出现读取失败。这时右键文件夹 → 属性 → 安全，确认当前用户有完整控制权限即可。

还有一个常见报错：model requires more memory than is available。这个和迁移路径无关，纯资源问题。模型权重占用的内存加上推理时的 KV cache 超出了可用内存，要么换更小的量化模型，要么调低num_ctx上下文长度，要么给机器加内存。

5.3 迁移后发现空间没释放

迁移完成后，旧目录如果还在，空间当然没释放。但有一种更隐蔽的情况：你以为模型都迁走了，却忘了 Docker 容器里的模型目录。如果你平时用 Docker 跑 Ollama，挂载的 volume 和宿主机的目录映射关系你得自己理清。比如docker exec进容器看到/root/.ollama/models，这可能是某个 volume 挂载点，真正的数据还在宿主机某个路径下。只改了宿主机上的OLLAMA_MODELS，容器里的服务路径没变，模型还是会写到旧 volume 里。

另外提醒一句，删除旧目录时务必用官方方式删除或直接确认目录下没有正在运行的进程占用。Windows 下如果遇到“文件正在被另一个进程使用，无法删除”，多半是 Ollama 服务又自启了，任务管理器里清干净再删。

5.4 路径软链接方案到底行不行

有一些教程会建议不修改OLLAMA_MODELS，而是在原路径上做一个符号链接，指向新路径。Windows 下用mklink /D或 PowerShell 的New-Item -ItemType SymbolicLink，Linux 用ln -s。

软链接方案的好处是：不需要改动环境变量，Ollama 按默认路径找模型目录，实际访问的是链接目标。坏处是：系统盘上仍然存在一个目录入口，部分工具在统计磁盘占用时会把它算进系统盘；权限或路径失效时排查会多一层；如果你后续重装系统，链接关系还要重建。我的看法是，能用环境变量解决的场景，别用软链接。软链接适合的情况是：你确实不想动系统变量，但需要让 Ollama 在完全默认的路径配置下工作，比如某些自动化脚本硬编码了默认路径。

5.5 如何快速验证新路径确实生效

光看模型能跑还不够，最好能确认模型确实是从新目录加载的。Windows 上用资源监视器或者 PowerToys 的文件活动监控工具，可以查看ollama app.exe在启动时访问了哪个路径的文件。Linux 上有更直接的命令：

sudo lsof -p $(pgrep -f "ollama serve" | head -1) | grep models

输出里会列出当前进程打开的模型文件路径，这个路径就是实际生效的模型目录。如果输出路径仍指向旧位置，说明环境变量没有正确传入进程。

6. 写在最后的经验之谈

迁移这事情，本身不复杂，但它的价值在于帮你建立对工具运行机制的理解。我见过不少朋友从“跑通模型”到“管理模型”的转变，就是始于一次磁盘空间告急后的迁移。你会开始关注模型文件结构、环境变量、服务生命周期，后面再做备份、做多用户共享、做自动部署就顺理成章了。

而且这个操作的风险其实很低，比 Docker 迁移、数据库迁移之类要温和得多，最大的代价也就是复制几十 G 文件的等待时间。只要流程是“备份 → 停服 → 改变量 → 复制 → 验证 → 清理旧目录”，基本很难翻车。非要选一个最容易出错的环节，我会说是验证。很多人复制完文件，服务一启动看到模型列表就心满意足了，等到真正跑推理时才发现某个层缺失。所以我再啰嗦一句：迁移后的ollama run测试，千万别跳过。

最后再分享一个小经验。如果你有多台机器，或者经常重装系统，模型目录是可以整体打包成压缩文件存在外部硬盘上的。.ollama目录结构没有任何机器绑定信息，解压到新机器的任意路径，再设置好OLLAMA_MODELS，就能直接复现整批模型。这比逐个模型重新下载要省太多时间，尤其是那些几个 G 到几十个 G 的大模型，一次备份长期受益。我自己的做法是迁移完成后立即用压缩工具把整个模型目录打一个包，存放在另一块磁盘上，后续重装系统再也不用从头拉模型了。