1. 为什么需要自定义Ollama模型存储路径
在Ubuntu系统上使用Ollama运行大语言模型时，默认的模型存储位置可能会带来几个实际问题。首先，系统分区通常空间有限，而像deepseek-r1这样的8B参数模型动辄需要几十GB存储空间。我就遇到过系统盘爆满导致服务崩溃的情况，当时正在运行的训练任务全部中断，损失了不少计算资源。
其次，很多开发者习惯将大容量数据存放在单独的硬盘或NAS上。比如我的工作站的/home分区只有256GB，但挂载了一个4TB的机械硬盘专门存放模型数据。如果不修改默认路径，每次下载新模型都要手动迁移文件，既麻烦又容易出错。
通过systemd的override机制修改Ollama模型存储位置，相比直接修改环境变量有几个明显优势。最关键是它能实现持久化配置，即使Ollama后续更新也不会丢失设置。我有次系统升级后发现模型路径恢复默认，排查半天才发现是.bashrc里设置的环境变量被覆盖了。而systemd的override.conf文件则完全不受影响，配置始终生效。
2. 理解systemd的override机制
systemd作为现代Linux系统的服务管理器，其override功能就像给服务配置打补丁。想象你有一套默认参数的工作服（原始服务配置），override就是在不拆改原服装的前提下，通过外搭马甲（override.conf）来调整样式。这种设计既保持了原始配置的完整性，又满足了定制需求。
具体到Ollama服务，原始配置文件通常存放在/lib/systemd/system/ollama.service。直接修改这个文件有两大风险：一是软件更新时会覆盖修改，二是可能引发服务依赖问题。我就曾手贱改过Nginx的service文件，结果导致自动更新后服务无法启动。
override.conf的优先级规则很有意思。它采用"后来居上"原则，当systemd加载配置时：
- 先读取原始服务文件
- 再加载/etc/systemd/system下的同名文件
- 最后加载service.d目录中的override配置 这种层级结构让管理更灵活，比如可以在不同环境使用不同的override配置。
3. 准备操作环境
在开始修改前，建议先做好这些准备工作。首先确认Ollama服务状态：
systemctl status ollama正常应该显示"active (running)"。如果服务未运行，需要先启动：
sudo systemctl start ollama检查现有模型存储路径也很重要：
ollama list这个命令会显示已下载模型及其存储位置。我建议先备份当前模型数据，特别是如果你已经下载了重要模型。可以用rsync快速备份：
rsync -avz ~/.ollama /path/to/backup创建目标存储目录时要注意权限问题。比如我习惯把模型放在/media目录下的外接硬盘：
sudo mkdir -p /media/models/ollama sudo chown -R $USER:$USER /media/models/ollama记得用df -h确认目标分区有足够空间，大型模型需要预留至少50GB空间。
4. 创建并配置override文件
实际操作override.conf有两种方式。新手推荐使用systemctl edit命令：
sudo systemctl edit ollama这个命令会自动创建正确的目录结构和文件，我用它从没出过错。手动创建的话需要注意：
sudo mkdir -p /etc/systemd/system/ollama.service.d sudo nano /etc/systemd/system/ollama.service.d/override.conf文件内容的核心是[Service]段下的Environment设置。这是我的生产环境配置示例：
[Service] Environment="OLLAMA_MODELS=/mnt/nas/ai_models" User=dev Group=dev这里有几个实用技巧：
- 路径最好用绝对路径，避免相对路径的歧义
- 可以同时设置多个环境变量，每行一个Environment=
- 如果修改运行用户，要确保该用户对模型目录有读写权限
有次我设置了网络存储路径但服务启动失败，后来发现是NFS挂载时机问题。解决方法是在override.conf添加：
After=network-online.target Wants=network-online.target5. 应用配置并验证效果
修改完成后，必须按顺序执行这些命令：
sudo systemctl daemon-reload sudo systemctl restart ollama第一个命令让systemd重新加载配置，第二个重启服务应用更改。我建议间隔5秒再运行第二条命令，确保完全加载。
验证配置是否生效有多种方法。最直接的是检查服务环境：
sudo systemctl show ollama --property=Environment应该能看到你设置的OLLAMA_MODELS路径。
更实际的测试是下载新模型：
ollama pull llama2然后用du命令查看文件实际存储位置：
du -sh /你设置的路径/.ollama/models如果遇到问题，可以查看服务日志：
journalctl -u ollama -f常见错误包括路径权限不足（用chmod/chown修复）、磁盘空间不足（清理或扩容）或语法错误（检查override.conf格式）。
6. 高级配置与优化建议
对于需要更复杂配置的场景，override.conf还能实现这些功能。比如限制服务资源使用：
[Service] MemoryHigh=16G CPUQuota=200%我管理的多用户服务器上，会为不同用户创建独立的override配置：
/etc/systemd/system/ollama.service.d/user1.conf /etc/systemd/system/ollama.service.d/user2.conf每个文件设置不同的模型路径和用户权限。
对于性能敏感的应用，可以调整服务启动参数：
ExecStart= ExecStart=/usr/local/bin/ollama serve --numa --verbose注意必须先清空原ExecStart（等号后面留空），这是systemd的特殊语法。
模型目录结构优化也很重要。我习惯这样组织：
/models ├── ollama_prod # 生产环境模型 ├── ollama_dev # 测试用模型 └── ollama_temp # 临时下载目录每个目录对应不同的override配置，通过软链接动态切换。
7. 常见问题解决方案
在配置过程中，这些问题我遇到得最多。首先是权限问题，典型表现是服务启动失败且日志显示"permission denied"。解决方法：
sudo chown -R ollama:ollama /your/model/path注意如果修改了运行用户，这里的ollama要替换成实际用户。
其次是配置未生效的情况。先检查override.conf文件位置是否正确，必须是：
/etc/systemd/system/ollama.service.d/override.conf而不是其他路径。然后确认执行了daemon-reload，这是个高频遗忘点。
对于空间不足的情况，除了换路径还可以用符号链接：
mv ~/.ollama /big_disk/ ln -s /big_disk/.ollama ~/.ollama这样既不用改配置，又能利用大容量存储。
网络存储的挂载时机问题也很棘手。我的解决方案是在override.conf添加：
[Unit] After=remote-fs.target Requires=remote-fs.target确保网络存储就绪后才启动Ollama服务。
