1. 为什么非动不可默认路径的痛点与适用场景先聊聊背景。Ollama 这个工具用过的都知道本地跑大模型的体验做得相当干净一条命令拉模型一条命令进对话API 也有配合各种前端项目特别方便。但正因为太方便了很多人装完就顺手开始 pull 模型等反应过来的时候几十个 G 已经填进去了而且全留在系统盘里。我见过不少开发者C 盘剩余空间从几十 G 一路掉到三五个 G最后还是回来学怎么改路径。先说清楚默认路径到底放哪。Ollama 装完后模型默认存放在用户目录的.ollama/models文件夹下面。Windows 上是C:\Users\用户名\.ollama\modelsmacOS 上是~/.ollama/modelsLinux 上如果是用安装脚本装的通常在/usr/share/ollama/.ollama/models如果用 Docker 跑那模型是在容器里的/root/.ollama/models。这个默认行为本身没什么问题但它隐含了三个坑。第一个坑是空间。一个 7B 参数的量化模型通常 4 到 5 个 G13B 大概是 8 到 9 个 G70B 量化后也能到 40G 以上。你要是同时下三五个模型系统盘直接就顶不住了。很多人的系统盘是 256G 或 512G 的 SSD本身装了系统和软件就已经占了大半再塞几个模型进去剩下的空间连编译项目都费劲。第二个坑是重装系统。模型文件在 C 盘重装系统时除非你刻意备份否则就是全部丢失。而这些模型是慢慢下回来的很多大模型的下载量是按 G 算的重装一次系统等于把积累全清零重新下载的时间成本会让人很上头。第三个坑是性能差异。模型加载完之后的推理过程其实对磁盘的持续读取要求不算特高算力主要还是在 GPU 和内存上但首次加载模型时要把权重全部读入内存这一步就是典型的顺序读操作。如果你的系统盘是 NVMe SSD而数据盘是普通 SATA SSD 或者机械硬盘加载耗时差距就会显现出来反过来如果系统盘空间紧张到只剩几个 G虚拟内存和缓存都在挤牙膏整个系统都跟着慢。所以什么场景适合做迁移我总结下来是这几类系统盘空间不足的普通用户有多块磁盘、想把模型专门放一块容量的数据盘上的玩家需要把整套 Ollama 连同模型搬到另一台机器上的开发者还有用 Docker / 服务器部署希望模型目录独立于系统盘、方便统一管理和备份的团队。这篇文章里我会把完整操作拆开讲Windows 为主Linux 和 macOS 的关键差异也带上。2. 弄清模型存储结构再动手默认位置与路径规则2.1 各平台默认存储位置要迁移先得知道东西存在哪。Ollama 的模型目录官方叫法是模型存储目录实际路径取决于平台和安装方式平台安装方式默认模型路径Windows安装包安装C:\Users\用户名\.ollama\modelsWindows手动下载 zip 解压同样在用户目录.ollama\modelsmacOS安装包安装~/.ollama/modelsLinux官方安装脚本/usr/share/ollama/.ollama/modelsLinux手动解压二进制~/.ollama/modelsDocker容器运行容器内/root/.ollama/models而 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 -SumLinux 或 macOS 下du -sh ~/.ollama我见过有人赶时间没看空间就把模型往新盘拷拷到一半空间满然后两边各留一半残缺文件反而更难收拾。这条别省。第三步确认当前正在运行的模型会话。先看看有没有模型还挂在内存里占着文件锁。运行ollama ps如果列表为空说明当前没有模型被加载如果有模型还在跑建议正常退出客户端或者等推理任务结束后再操作。3.2 第 1 步停掉服务再动手这是整个迁移里最容易翻车的环节。Ollama 在 Windows 上默认是通过系统托盘常驻的服务进程是ollama app.exe迁移期间如果这个进程还开着它可能会持有模型文件句柄导致拷贝失败或者拷贝到一半进程重新写入数据最后得到一份不一致的目录。所以必须先彻底退出。Windows 上操作右键点击托盘区域的 Ollama 图标选 Quit 退出。打开任务管理器在“详细信息”里找ollama app.exe和ollama.exe确认都退干净了。如果还挂在后台可以在管理员 PowerShell 里强制结束Stop-Process -Name ollama -ForceLinux 上操作要看服务管理器sudo systemctl stop ollamamacOS 上点菜单栏图标退出或在终端里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] EnvironmentOLLAMA_MODELS/data/ollama/models EOF然后重载服务sudo systemctl daemon-reloadmacOS 上设置 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、cpollama 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/modelsWindows 上这类问题少一些但如果你把模型目录放在了 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 SymbolicLinkLinux 用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 的大模型一次备份长期受益。我自己的做法是迁移完成后立即用压缩工具把整个模型目录打一个包存放在另一块磁盘上后续重装系统再也不用从头拉模型了。