ollama_models 变量

本地用 ollama 跑模型，硬盘吃紧或者想把权重放到数据盘、外接盘，第一反应就是改 ollama_models。但很多人改完发现新目录还是空的、模型依旧下到老地方，或者重启后又被改回去。这篇不聊概念，只按顺序告诉你：变量该在哪一层设、哪些进程要一起重启、怎么确认真的生效、以及什么时候这个变量压根不该用。

本地用 ollama 跑模型，硬盘吃紧或者想把权重放到数据盘、外接盘，第一反应就是改 ollama_models。但很多人改完发现新目录还是空的、模型依旧下到老地方，或者重启后又被改回去。这篇不聊概念，只按顺序告诉你：变量该在哪一层设、哪些进程要一起重启、怎么确认真的生效、以及什么时候这个变量压根不该用。

先说清一个前提：这篇文章只解决「模型文件放哪」，不解决「跑得多快、能跑多大」。如果你真正的痛点是显存不够、加载慢，那是另一个方向的问题，改这个变量帮不上忙。想先摸清自己机器上的实际情况，可以到 /tools/speed-test 做一次检测，再回来决定要不要搬目录。

先搞清这个变量管什么

这个变量管的只是模型权重的落盘位置，也就是那些大文件存在哪块硬盘上。它不改变推理时的显存占用，也不影响你能跑多大的模型，更不会让加载变快——除非你把它从慢盘挪到了快盘。很多人改完没感觉，就是因为预期本身放错了地方。

落盘位置

下载下来的权重文件最终写在哪块盘、哪个目录，这是它唯一决定的事

用户级

你当前登录的 shell 会话里设的，只对你这个终端窗口里手敲的命令生效

系统服务级

后台常驻的那个进程读到的配置，通常和你的终端环境是两套东西

顺序上有个原则：先确认当前实际生效的目录，再谈改。上来就编辑配置文件是最容易白忙的做法，因为你连现在跑的是哪套环境都没弄清。先让模型列表吐一次，看它认的目录在哪儿，拿这个结果当基准，后面每一步改动才有对照。

• 确认当前生效目录：跑一次模型列表，观察它读的是哪个位置
• 判断干活的是谁：是你在终端手敲的进程，还是后台常驻的那个
• 分清层级：你要改的是当前会话，还是让所有用户、所有终端都认
• 记下基准：改之前把现状记下来，改完才有东西可比

改的时候按这个顺序来

改目录这件事，顺序比内容重要。中途改、分批搬、只改一层，都是后面「不生效」的常见来源。下面这套顺序照着走，能避开大部分坑。

1. 先停实例把正在跑的进程停干净，别在下载或推理中途改目录。半截文件留在老目录里，下次启动可能报校验失败，你还得回头清。
2. 写入变量决定好放哪一层：只在当前终端临时用，就当前会话设；要让后台服务也认，就写进服务能读到的位置。只在当前终端设的话，换个窗口就丢了。
3. 重启服务改完必须让读这个变量的进程重新起来。只重启客户端、没重启后台服务，等于没改。判断标准是进程的启动时间比你的修改时间新。
4. 整盘搬迁把老目录的权重整个搬过去，别只搬一部分。混着放最容易出现「有的模型在新目录、有的还在老地方」。搬完先别删原目录，跑通一次再清。
5. 验证生效让它在受控条件下拉一次模型，看新目录有没有真的长出文件。别只看命令回显，要看文件系统里实际多了什么。

改完不生效，照这个顺序查

不生效的原因基本就四类，按下面顺序查，比乱翻配置快得多。每一类都有明确的判断动作，别跳步。

• 第一查作用域：你改的是当前 shell 的环境，真正干活的是后台服务，两者环境不一定共享
• 第二查进程：只重启了客户端没重启服务，新变量根本没被读进去，看启动时间就能判断
• 第三查覆盖：有的启动方式或图形化封装会写死路径，环境变量的优先级排在它后面
• 第四查权限：新目录属主不是运行服务的那个账号，写入会静默失败或悄悄退回默认位置

这四类里，作用域和进程问题占了大多数。一个简单的判断办法：临时把变量在当前终端设好，然后直接在同一个终端里前台启动一次服务，看它认不认。认了，说明变量本身没写错，问题出在后台那套环境；不认，再回头查写法本身。

什么情况下别折腾这个变量

这个变量不是万能的，有些场景下改了反而给自己添麻烦。下面几种情况，建议先想清楚再动手。

• 容器里跑的：通常更该挂载卷而不是设变量，改了也容易被镜像的默认值盖掉
• 多人共用的机器：改全局目录会影响别人已有的模型清单和缓存，容易引起互相踩脚
• 只想省空间：优先挑更低的量化档位或清掉不再用的模型，比搬目录的收益更直接
• 路径指向网络盘或移动盘：加载速度可能掉得比省下的空间更让人难受，尤其是频繁切换模型时

还有一类情况：你其实只是想让下载快一点。那和目录位置无关，去 /tools 看看有没有合适的加速或镜像方案，比搬目录对症。