Ollama环境变量配置详解：模型目录迁移、局域网共享与性能调优

很多朋友第一次接触本地大模型，第一反应都是先把模型拉下来再说，结果没几天系统盘就被塞满了，更困惑的是，改了环境变量之后，模型还是往老地方下载。我最早也是这样，折腾完各种依赖，最后发现，真正需要长期打交道的其实就是一个叫 Ollama 的工具，以及一套环境变量配置方法。这篇是这个系列的第三篇，前面聊过大模型的基础概念和本地运行思路，这一篇专门把 Ollama 是什么、环境变量怎么设，一次讲透。适合刚入门的同学，也适合已经跑起来几个模型、但还没搞明白模型目录、服务端口、并发参数为什么这么配的人。

1. Ollama 到底给你省了什么：先理解它的工作方式

1.1 没有 Ollama 时，本地跑模型要折腾多少步

直接跑大模型的传统流程，远比大多数新手想象得复杂：先装一套 Python 运行环境，再配显卡计算库，然后把权重文件下载下来，处理成推理框架能读的格式，接着还要写一段加载代码、处理分词器、控制输入输出格式。中间只要出现一个版本不匹配，就是一片红色的报错。就算这些全过了，模型加载之后显存不够、上下文设置不对、回答速度慢，又是另一轮调参。

普通学习者的需求其实很简单：把模型在本地跑起来，给一个命令行，或者给一个 HTTP 接口，能用就行。至于模型量化、显存分配、上下文窗口怎么处理，最好由工具自动完成。Ollama 正好踩在这条线上，这也是它能火起来的原因。

1.2 Ollama 的“镜像化”设计思路

Ollama 给我的第一感觉，很像把模型当作一个个封装好的“镜像”来管理。你不需要关心模型文件到底散落在哪里，也不用手动处理权重格式，只需要两条命令：

bash复制ollama pull <模型名>
ollama run <模型名> "你好，介绍一下你自己"

pull 负责从模型仓库拉到本地，run 负责加载并运行。模型跑起来后，Ollama 会在后台启动一个常驻服务进程，默认监听本机的某个端口。换句话说，你得到的不只是一个命令行玩具，而是一个可以直接用 HTTP 请求调用的本地推理服务。这对后续接开发工具、做测试脚本，都特别方便。

1.3 边界：什么地方该用它，什么地方不该硬上

Ollama 适合个人学习、研究实验、小团队内网部署，也适合对数据隐私要求高、不想把内容发给外部厂商的场景。它的优势是上手快、资源占用可控、接口足够简单。

但它不是万能的。如果要做几万并发、需要弹性扩容的生产级平台，Ollama 的运维能力和扩展性就比较吃力。规划设计的时候，把它定位成“本地可用的推理入口”，而不是“完整生产平台”，会少走很多弯路。

2. 安装 Ollama：三平台实操与装完必做的动作

2.1 Linux / macOS：一条命令装完

Linux 和 macOS 的官方安装方式都是执行一段安装脚本：

bash复制curl -fsSL https://ollama.com/install.sh | sh

Linux 装完后，后台服务一般由 systemd 托管，相当于系统会自动拉起一个常驻进程；macOS 装完会生成一个原生应用，服务和图形入口绑定在一起。

这里有个实际经验：如果当前网络访问不通或不稳定，脚本方式可能中途失败，这时候别反复重试，直接去手动下载对应平台的安装包更省事。脚本方式虽然方便，但依赖安装源连通性，一卡就是半天。

2.2 Windows：安装包和托盘程序

Windows 没有 Linux 那种一行命令的安装方式，常规做法是下载安装包，双击安装。装完后托盘区会出现一个图标，这个图标代表后台服务在运行，右键可以查看服务状态或退出。

需要注意，Windows 安装方式默认以后台服务模式运行，这决定了环境变量要写在系统层面，不是随便在某个终端里 export 一下就行。这一点我会在第 3 节详细展开，很多人改了半天发现不生效，就是栽在这里。

2.3 装完之后的验证三连

安装完不要急着拉大模型，先做三个验证。

第一步，确认命令行能用：

bash复制ollama --version

能输出版本号，说明命令行工具已经就绪。

第二步，拉一个小体积模型试试水。比如先用一个 1.5B 或 2B 级别的测试模型，确认整个流程能走通，再考虑拉 7B、14B 甚至更大的模型。命令很直观：

bash复制ollama pull <小型聊天模型>
ollama list

ollama list 能列出本地已有的模型，看到自己刚拉的模型出现，就算成功。

第三步，确认后台端口在监听。Linux 下直接看：

bash复制ss -ltn | grep 11434

能看到 11434 端口处于监听状态，说明后台服务正常。macOS 和 Windows 可以用对应的网络工具或资源监视器确认。三步都过了，安装阶段才算真正结束。

3. 环境变量是给谁看的：Ollama 进程读取机制

3.1 最重要的一个认知：环境变量只在服务启动时读一次

这个认知值不值钱不好说，但绝对能帮你少踩 90% 的坑：Ollama 的环境变量不是改完立刻生效的，而是后台服务进程在启动时读取一次。你在终端里手动 export OLLAMA_MODELS=/new/path，再运行 ollama run，如果后台服务还是用旧配置起的，那它依然不会读你的新路径。

必须重启 Ollama 后台服务，让进程重新读取环境变量，改动才会真正生效。很多人改了半天，echo 看一下变量明明是对的，但模型还是下载到老地方，原因就在这里。

3.2 三种托管模式下，环境变量该写到哪里

不同平台、不同启动方式，环境变量的“写入位置”完全不同。我整理了一张对照表：

把这个表记住，就可以避免“在终端 export 了，但服务是 systemd 拉起来的”这种错位情况。终端环境变量和服务进程环境变量是两个东西，不要混为一谈。

3.3 核心环境变量速查表

平时用得最多的环境变量，我列成一张速查表：

这里提一句：Ollama 版本更新很快，默认值可能随版本变化，以你当前版本文档为准。上面这些变量里，最常用的是前三个，后几个属于性能调优向，后面会逐个讲到。

4. 模型迁移：把模型目录从系统盘挪走

4.1 默认目录为什么容易出问题

默认情况下，Ollama 会把模型文件放在用户目录的 .ollama 文件夹里。听起来没什么，但模型文件体积很可观：一个常见的 7B 模型动辄 4~5GB，70B 级别的大模型能到 40GB 甚至更多，而且模型之间可以同时存在好几个。

系统盘放一堆几十 GB 的模型文件，后果就是 C 盘或根分区很快告警，电脑越用越卡。更麻烦的是，以后想迁移目录、重装系统，都得连带处理这些大文件。所以动手拉模型之前，最好先把模型目录规划好。

4.2 Linux / macOS bash 环境两种改法

方法一：写入 shell 配置文件。修改 ~/.bashrc 或 ~/.zshrc：

bash复制export OLLAMA_MODELS=/data/ollama/models

保存后执行 source ~/.bashrc，然后重启 Ollama 服务。这种写法适合平时习惯在终端手动启动服务的人。

方法二：修改 systemd 服务配置。如果你用的是 systemd 托管的 Ollama，更推荐这种方式：

bash复制sudo systemctl edit ollama.service

在打开的覆盖文件里写入：

ini复制[Service]
Environment="OLLAMA_MODELS=/data/ollama/models"

然后执行：

bash复制sudo systemctl daemon-reload
sudo systemctl restart ollama

注意，覆盖文件里的配置优先级高于原始服务文件，我用下来没遇到过被其它配置覆盖的情况。如果你不确定当前服务用的什么配置，可以用：

bash复制sudo systemctl cat ollama

看一眼实际生效的启动参数和环境变量。

4.3 Windows 下的设置方式

Windows 下右键“此电脑”->“属性”->“高级系统设置”->“环境变量”，新建一个用户或系统变量，变量名 OLLAMA_MODELS，值指向新目录，比如 D:\ollama\models。

命令行里也能快速设置：

cmd复制setx OLLAMA_MODELS "D:\ollama\models"

setx 只影响后续新启动的进程，当前已经开着的终端不会更新，所以设完要新开一个终端，再重启 Ollama 服务。如果 Ollama 是以 Windows 服务方式在后台跑，改完系统环境变量后还要到服务管理里重启它，部分安装方式甚至需要重新登出再登入，才能让服务进程读到新的用户环境变量。

4.4 怎么确定迁移真的生效了

重启服务后，先运行 ollama list，如果你之前已经拉过模型，它们应该还在列表里。如果这时没有报错，说明新目录可以被正常读取。

更直接的办法是看正在运行的进程的环境变量。Linux 下可以这样查：

bash复制pgrep -a ollama
sudo cat /proc/$(pgrep -f 'ollama serve' | head -n1)/environ | tr '\0' '\n' | grep OLLAMA_MODELS

输出里如果显示的是你的新路径，说明环境变量确实被服务进程拿到了。如果一直是旧路径，基本可以断定：后台服务没有重启，或者变量写到了一个不会被读取的配置文件里。别猜，直接看进程，比什么验证都准。

5. 局域网共享：OLLAMA_HOST 与端口修改

5.1 默认只监听本机是有意为之

默认情况下，Ollama 只监听 127.0.0.1，也就是只有本机能访问。很多新手觉得这是小题大做，但仔细想想，一旦服务绑到所有网卡上，局域网里任何一台机器都可以往你本机发推理请求，如果又有权限控制问题，很容易变成给别人免费打工的算力节点。

所以没必要一上来就把服务改成 0.0.0.0，等确实需要局域网内其他电脑共用时再改。

5.2 开放局域网访问的具体操作

想开放局域网访问，最干净的做法还是走 systemd 覆盖配置。Linux 下：

bash复制sudo systemctl edit ollama.service

写入：

ini复制[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

重启后，在局域网里另一台机器上验证：

bash复制curl http://192.168.1.100:11434/api/tags

能返回一个模型列表的 JSON，说明服务已经开放成功。这里有个细节：如果机器有多个网卡，不要直接绑 0.0.0.0，而是绑定到具体的内网 IP，比如 OLLAMA_HOST=192.168.1.100:11434。这样只有指定的那个网段能访问，外网和别的网卡都进不来，安全性会好很多。

5.3 端口冲突与防火墙的坑

OLLAMA_HOST 里已经写了端口，OLLAMA_PORT 就不需要再单独设置了。如果 11434 被别的程序占用，可以用 OLLAMA_HOST=127.0.0.1:11435 这种方式直接换端口。

局域网访问不通时，先别怀疑配置，先查防火墙。Linux 的 firewalld 或 ufw 规则要放行对应端口，Windows 的入站规则也要手动加放行。我曾经在同一台机器上 curl 本机能通，但局域网机器就是连不上，排查到最后是防火墙把入站给拦了，跟 Ollama 本身一点关系都没有。

6. 性能调优：并发、显存、内存相关的环境变量

6.1 OLLAMA_KEEP_ALIVE：模型在内存里留多久

OLLAMA_KEEP_ALIVE 控制的是模型在内存或显存里的驻留时间。默认值是 5m，意思是 5 分钟内没有新请求，模型就会被卸载释放资源；5 分钟内又有请求进来，就继续保留。

如果服务被高频调用，建议把驻留时间调长，甚至设为 -1 永久驻留：

bash复制export OLLAMA_KEEP_ALIVE=-1

这里的代价是显存或内存一直被占用，哪怕暂时没有请求，资源也拿不回来。我的建议是：如果只是偶尔试一下，保持默认就行；如果反复调试对话场景，设置成 -1 能明显减少每次请求前的加载等待。

6.2 OLLAMA_NUM_PARALLEL 和 OLLAMA_MAX_LOADED_MODELS

OLLAMA_NUM_PARALLEL 控制同一个模型接受多少个并发请求，OLLAMA_MAX_LOADED_MODELS 控制允许同时驻留几个不同的模型。这两个值都受显存和内存上限约束。

举个例子：一个 7B 量化模型占用的显存不大，设成 2~4 并发一般比较稳；但如果是 70B 级别甚至是更大模型，单个请求都可能让显存吃紧，再把并发调大，很容易直接 OOM，进程被系统杀掉。

实操建议是分两步走：先以默认配置跑一个请求，用系统监视工具观察显存和内存占用，再结合平时的调用频率，小心地调整并行数。别一上来就拉满，资源占用和响应速度之间要有一个平衡。

6.3 OLLAMA_CONTEXT_LENGTH：上下文越长越吃显存

上下文窗口长度直接影响 KV Cache 的占用，上下文翻倍，显存占用也会明显上升。很多人遇到“生成到一半卡死”的诡异问题，其实不是模型坏了，而是上下文设得太大，显存被撑爆。

设置原则很简单：按任务实际需要的 token 数量来，不要盲目拉满。写普通代码、问答，不需要几万上下文；处理超长文档，再考虑调大。把 OLLAMA_CONTEXT_LENGTH 看作一个显存和能力的交换开关，而不是越大越好。

7. 环境变量不生效的排查链路

7.1 三个自检问题

遇到“改了环境变量但没效果”，先按顺序问自己三件事：

1. 服务重启了吗？环境变量只在服务启动时读取，不重启等于没改。
2. 变量写对位置了吗？终端 export 和 systemd 配置是两套环境，别搞混。
3. 变量名大小写对了吗？OLLAMA_MODELS 少个下划线、多个字母，都会悄悄失效。

这三个问题基本能覆盖八成以上的“不生效”场景。

7.2 一个实际案例：模型还是下载到默认目录

我调试过一个很典型的场景：用户说明明在终端里 export OLLAMA_MODELS=/data/ollama/models，echo 也能看到新路径，但 ollama pull 下载的模型还是落到了 ~/.ollama/models。

排查链路是这样的：

第一步，确认当前 shell 环境变量：

bash复制echo $OLLAMA_MODELS

确实显示新路径，说明终端环境没问题。

第二步，查看后台服务进程：

bash复制pgrep -a ollama

发现服务是由 systemd 拉起的，根本不在当前终端的环境里跑。也就是说，手动 export 只改了终端自己的环境变量，后台服务完全不知道。

第三步，修改 systemd 配置：

bash复制sudo systemctl edit ollama.service

写入 Environment="OLLAMA_MODELS=/data/ollama/models"，然后：

bash复制sudo systemctl daemon-reload
sudo systemctl restart ollama

第四步，再检查进程实际环境变量，确认：

bash复制sudo cat /proc/$(pgrep -f 'ollama serve' | head -n1)/environ | tr '\0' '\n' | grep OLLAMA_MODELS

输出新路径，问题彻底解决。这个案例最大的价值在于：排查环境变量，不能只盯着终端看，要看服务进程拿到了什么。

7.3 权限和磁盘空间这些隐性因素

还有一类问题，环境变量配置完全正确，但行为依然怪异，原因在权限和磁盘空间。

如果把 OLLAMA_MODELS 指向一个新目录，但这个目录对当前用户没有写权限，Ollama 的表现多种多样：有的直接启动报错，有的假装正常，但下载模型时一直卡住不动。解决办法很简单，给对应目录放开写权限：

bash复制sudo chown -R $USER:$USER /data/ollama

磁盘空间不足也容易被误判成环境变量问题。拉大模型时，如果目标分区剩余空间不充裕，看起来像是“进度条卡在 0%”，其实是临时文件写不进去。我的习惯是，模型目录所在分区至少预留一个模型体积的两倍空间，给下载和解压留出余地。多花两分钟确认这些基础条件，能省下后面一整晚的排查时间。

我自己现在的习惯，是把模型目录放在一块独立的数据盘上，OLLAMA_KEEP_ALIVE 设成 -1，因为天天都在调；OLLAMA_HOST 平时保持只监听本机，需要和同事共用时再临时改成内网 IP，用完立刻改回来。新手最建议的路线是：先用一个最小模型把整个流程跑通，然后挨个验证环境变量是否被服务进程读到，最后再开始拉真正想用的大模型。这套顺序走完，你在 Ollama 上基本就告别“莫名其妙不生效”的坑了。