你在 Linux 上装完 Ollama，想让它开机自启、换个模型存储目录、或者让局域网里别的机器能连上，结果发现文档里说要改 ollama.service，但改哪个字段、放什么位置、要不要重载服务，全没说清。这篇就按「先定位文件、再挑配置项、最后验证生效」的顺序，把改配置这条路径走一遍，顺便给你改坏之后的回退办法。
你在 Linux 上装完 Ollama，想让它开机自启、换个模型存储目录、或者让局域网里别的机器能连上，结果发现文档里轻飘飘一句「改 ollama.service」，改哪个字段、放什么位置、改完要不要重载，全没说。这篇按「先定位文件、再挑配置项、最后验证生效」的顺序，把这条路径完整走一遍，顺便把改坏之后的回退办法也交代清楚。
提前说一句：下面所有涉及具体数值的地方（端口号、路径长度、并发上限）都建议以你自己机器上 systemctl 读到的实际值为准，别照搬别人的示例。站内也整理了各家模型的接入方式和运行侧参数，需要对照时到 /tools/speed-test 或 /sites 看当时的状态，别把别人博客里的老配置直接抄过去。
先找到文件，再看清当前状态
改配置最容易踩的坑是「文件找对了没有」。同一台机器上可能同时存在用户级和系统级的 unit 文件，你改了其中一份，服务实际读的却是另一份，表现出来就是「改了完全没反应」。所以第一步不是编辑，而是先问 systemctl：这个服务现在到底在不在、用的是哪份文件。
- 确认服务状态先看服务是否处于运行中、有没有反复重启。状态列里如果是失败或不断 auto-restart，先别改配置，把失败原因解决掉再谈调参。
- 打印生效的 unit 文件用 systemctl 自带的查看子命令把当前真正生效的 unit 内容打印出来，重点看文件顶部注释里的路径来源，那才是你该改的那一份。
- 备份原始内容把打印出来的内容整体存成一份带日期的备份文件，同时把当前监听地址、端口、模型目录这些值记在一边，后面用来对比改动是否真的落地。
- 确认安装方式想清楚这套 Ollama 是系统包装的、脚本装的，还是跑在容器里。容器方式下宿主机这份 unit 可能根本不参与，改了等于白改。
常改的几个字段分别管什么
一个典型的服务文件大致分成三段：服务本身的行为、执行环境、安装关系。三段里真正高频要动的东西不多，先把它们归类，改的时候就不会东一榔头西一棒子。
| 所在段 | 典型字段管什么 | 什么时候需要动 |
|---|---|---|
| 服务段 | 启动命令、运行用户、工作目录、重启策略 | 换账号跑、进程崩了自动拉起、切换工作根目录 |
| 环境段 | 监听地址、端口、模型存放路径、运行侧开关 | 局域网访问、目录搬家、显存与并发相关调整 |
| 安装段 | 依赖关系、启动先后顺序 | 希望等网络或某个挂载就绪后再启动服务 |
环境变量段是最常被改坏的地方：变量名写错一个字母不会报错，只是静默不生效；路径末尾多一个斜杠，可能解析成另一个目录，然后你看到的是「模型全没了」，其实只是指到了空目录。
- 运行用户决定它对模型目录有没有读写权限，权限不够时表现为启动即失败，而不是连不上；
- 监听地址写成仅本机时，本机自测永远通，换台机器立刻就断，所以验证必须换机器；
- 模型存储路径改动前先把已有文件迁过去，否则服务会按新路径建空目录；
- 重启策略决定进程意外退出后会不会被拉回来，调试阶段可以调得保守一点；
- 日志相关设置决定出问题时你手上有没有线索，比事后到处猜要省事。
如果你只是想让某几个变量生效，而不是重写整份文件，优先用 drop-in 覆盖目录追加一个片段文件。这样原始文件保持干净，升级包管理器重新安装时也不会把你的改动冲掉。
改的流程与生效验证
改配置的动作顺序是固定的，不能跳步：改文件 → 重载服务定义 → 重启服务 → 查状态 → 实际发一个请求。很多人只做了「改文件 + 重启」，跳过了重载，结果 systemd 还在用内存里的旧定义，自然看不到变化。
- 改文件只改这一轮要验证的字段，一次改一项。多项同时改，出问题时你会分不清是哪一处导致的。
- 重载服务定义让 systemd 重新读取 unit 内容。注意重载定义不等于重启进程，前者是刷新配置，后者才让新配置真正生效，两个都要做。
- 重启并查状态重启后看状态是否是运行中、有没有立即退出、最近几条日志里有没有报错。状态不是运行中就别往下走。
- 发一次真实请求改的是监听地址，就换一台机器去连；改的是模型目录，就确认原来那些模型文件还能被列出来。本机连本机这条验证在做网络类改动时没有意义。
- 确认开机自启自启相关设置只有在真正重启机器后才算验证过。改完当晚不重启，第二天开机发现没起来，排查成本比现在多做一步高得多。
每改完一项就把观察到的现象记一行：改了什么、预期现象、实际现象。这个记录在你回退的时候就是唯一的线索来源，比凭记忆回想要可靠。
改坏了怎么退，什么情况别硬改
回退的顺序是确定的：先用备份文件覆盖回去，再重载定义加重启，还不行就检查是不是文件放错了目录、或者服务其实读的是 drop-in 覆盖那份而不是你手改的原始文件。绝大多数「回退也起不来」的情况，都是文件位置问题而不是内容问题。
| 现象 | 先查哪一处 | 常见原因 |
|---|---|---|
| 改完毫无变化 | 是否重载并重启、是否改错了文件位置 | systemd 还用旧定义，或存在 drop-in 覆盖 |
| 启动即失败 | 运行用户对模型目录的权限 | 目录权限或所属用户不匹配 |
| 本机通、外部不通 | 监听地址是否为本机、对外端口是否放行 | 监听范围受限或端口未开放 |
| 模型「消失」 | 模型存储路径指向的目录 | 路径写错或文件没迁移 |
哪些情况下别硬改？如果你的 Ollama 是容器化部署或者托管在别人维护的环境里，宿主机这份 unit 可能压根不参与启动流程，你改半天属于无效操作，应该去看容器或平台侧的配置入口。生产机器上更要谨慎：动手前必须确认除了当前这台之外还有其他入口能连上，否则一次改错就把自己关在门外了。
改配置的原则不是「一次改对」，而是「每改一步都能退回去」。
另外，如果你改配置的目的是做接入前的连通性验证或者对比不同运行侧的延迟表现，别把精力全花在 service 文件上。服务起来只是第一关，后面的响应速度和稳定性差异要看实际测量。站内 /tools/speed-test 提供了自己的测试入口，各家中转和官方渠道的当前情况到 /rankings 和 /price-watch 核对你当时的数字，再决定要不要长期挂着哪一套。
下一步配置改通之后，真正影响体验的是通道本身稳不稳、不同渠道的当前状态如何。去站内导航页把可选渠道过一遍，再对照价格追踪页确认当时的行情，别只看配置能不能跑起来。→常见问题
改完 ollama.service 重启了，为什么还是老样子？
多半是三件事：文件放的位置不是当前生效那份、只改了文件没重载服务配置、或者服务根本没被重启起来。按「确认生效文件 → 重载 → 重启 → 查状态 → 发请求」的顺序逐条验，别跳步。
能不能不改服务文件，只用环境变量控制行为？
临时验证可以，长期用不建议。临时变量的作用范围取决于你怎么启动进程，服务被系统拉起时读不到。要长期生效，还是落到服务配置里更稳，用覆盖文件的形式改也能少动原始内容。
改完连不上了，第一步做什么？
先别继续改。恢复备份文件、重载、重启，确认服务能正常起来、日志里没有明显报错；再去看你新加的字段是不是写法有问题。确认能连上之后，一次只加一项再试。
