linux ollama serve 后台运行

很多人是先在终端敲一句 ollama serve 跑通，然后一关窗口模型就没了；换成 nohup 挂后台，重启机器又得手动拉起来，环境变量也没生效。这篇按顺序走一遍：先确认服务单元在不在，再决定改配置还是自己写一个，最后教你怎么验证监听地址、日志和开机自启真的生效。

很多人第一次跑本地模型，都是先在终端敲一句 ollama serve，看着日志滚起来、请求能通，就以为搞定了。结果一关窗口进程没了；换 nohup 挂后台，重启机器又得手动拉一次；真正想让它在后台稳稳常驻，还得交给 systemd 这类服务管理器。这篇按顺序走一遍：先确认机器上有没有现成的服务单元，再决定是改配置还是自己写一个，最后验证监听、日志和开机自启是不是真的生效。

判断标准很简单：关掉所有终端、断开 SSH、再重启一次机器，模型服务还能接请求，才算「后台运行」达标。下面每一步都给可执行的命令和验证动作，不涉及的场景会明确说清楚，方便你按自己的安装方式对号入座。

先看机器上到底有没有 ollama 服务

动手之前先摸底，别急着新建第二个进程。用官方安装脚本装出来的环境，通常已经自带一个 ollama.service；手动解压二进制、或者用容器跑的情况，往往没有。先查清楚属于哪种，后面才知道是「改」还是「写」。

1. 查服务单元状态执行 systemctl status ollama 看有没有这个单元；再用 systemctl is-enabled ollama 看是不是开机自启。两个命令都报 not found，说明系统里根本没注册过。
2. 看端口有没有被占用 ss -lntp 看默认端口上是谁在监听。如果是你自己前台跑的进程，先 Ctrl+C 停掉再往下走，避免后面服务起来却抢不到端口。
3. 确认安装方式用 which ollama 看二进制落在哪，用 dpkg -l 或 rpm -q 看是不是包管理器装的。包管理器装的优先复用官方单元，手动装的直接跳到自己写 service 那一节。

环境变量放哪：别写进 shell 的 rc 文件

这是最常见的坑：把模型存储路径、监听地址写进 .bashrc 或 .zshrc，自己终端里测试一切正常，服务一开机启动就读不到。原因是服务进程不经过交互式登录，根本不会加载这些 rc 文件。给服务用的变量，必须写进 unit 本身或者独立的 override 片段。

推荐用 override 而不是直接改官方单元文件，这样包升级时你的改动不会被覆盖。执行 systemctl edit ollama 会生成一个覆盖片段，在里面用 Environment= 逐行声明变量即可，改完记得 daemon-reload 再 restart。

• 模型存储路径：决定模型文件落在哪个盘，机器上有多块盘时尤其要显式指定。
• 监听地址与端口：默认只监听本机，想给局域网其他设备用就得改成对外可访问。
• GPU 可见性：多卡机器上用设备编号控制给服务进程用哪几张卡。
• 运行用户相关变量：如果模型目录属主不是服务用户，光改路径没用，会直接报权限错误。

把监听地址改成对外可访问之前，先想清楚暴露面。公网直连一个不做鉴权的本地推理服务风险不小，这类取舍和加固方式可以到 /guides 里对一遍再决定。另外提醒一句：只执行 restart 不执行 daemon-reload，改过的配置不会生效，你会以为改了没用，其实是白改。

自己写一个 service：最小可用模板

手动装的环境没有现成单元，就自己写一个。结构按 Unit、Service、Install 三段来，字段不用多，够用就行。下面这份模板里的路径、用户、组都要换成你自己查出来的值，别照抄。

[Unit]\nDescription=Ollama Service\nAfter=network-online.target\n\n[Service]\nType=simple\nUser=你的用户名\nGroup=你的用户组\nEnvironment=OLLAMA_MODELS=/你的/模型目录\nEnvironment=OLLAMA_HOST=127.0.0.1:你的端口\nExecStart=/你的/二进制路径 serve\nRestart=always\nRestartSec=3\n\n[Install]\nWantedBy=multi-user.target

• ExecStart 结尾的 serve 子命令不能少，只写二进制路径它会打印帮助然后退出。
• User 和 Group 要跟模型目录的属主一致，否则加载模型时会报读写被拒。
• Restart=always 配合 RestartSec 是让服务崩了自动拉起的核心，缺了它就不能算常驻托管。
• WantedBy=multi-user.target 是开机自启的开关，缺了它 enable 也没意义。
• 文件存到 /etc/systemd/system/ 下，命名以 .service 结尾。

写完先执行 daemon-reload 让系统读到新单元，再 enable --now 同时完成开机自启和立即启动，最后立刻 status 看一眼。如果状态是 failed 或者反复 activating，先别急着改参数，去日志里找第一段报错。查路径和用户用 which、id 两条命令，比肉眼猜靠谱。

验证清单：怎么确认它真的在后台干活

进程在，不代表服务能用。三样东西都要看：service 状态是 active、端口在监听、日志里没有循环报错。三缺一就继续排查，别提前宣布完成。

这里有个容易忽略的细节：进程明明活着，但请求报错或者响应特别慢，常见原因是 GPU 没被服务进程实际用上——驱动或权限没在服务环境下生效。这种情况用一次真实推理请求就能暴露，光看进程列表发现不了。

最后一定要重启机器验证一次。很多配置只在当前会话里看起来正常，重启之后暴露的是用户权限、挂载顺序、自启开关的真实状态。重启后三项检查全部通过，才算这件事做完了。

起不来的常见排查顺序

服务起不来时，先看 journal 里时间最早的那条报错，多数问题在第一屏就能看出来。下面这套顺序按概率排，从最常见的往下排，照着走通常几分钟就能定位。

1. 看日志首段报错journalctl -u ollama -n 100 从头往下读。端口被占、模型目录无权限、二进制路径写错，这三类占了大多数。
2. 区分「起不来」和「起得来但连不上」status 是 failed 属于启动失败，查上面三类；status 是 active 但请求不通，多半是监听地址只绑了本机，或者防火墙拦了端口。
3. 处理反复重启先 systemctl stop 停掉，把 Restart 临时改成 no，再手动跑一次二进制看完整报错。拿到报错后回填配置，改回 always 再用。
4. 确认不是配置没生效改完配置没 daemon-reload 就 restart，等于没改。排查时顺手执行一次 daemon-reload，能排除掉一类假故障。

想让这套配置在更多机器上复用、或者想比较不同托管方式的差别，站内 /sites 收录了各种工具与托管方案的导航，可以按自己的场景挑一个；如果更关心本地推理的实际速度表现，/tools/speed-test 里有对应的测试入口。判断某个方案是否适合你，最终还是回到自己的机器配置和用途上，别人跑得通不代表你这边没有权限或依赖差异。