你在 Windows 上装了 Ollama，双击图标能跑，但一关掉那个黑窗口接口就断了，脚本、知识库、编辑器插件全部连不上；想用任务计划或者服务方式让它开机就跑，又不知道哪种靠谱、哪些坑会踩。这篇按使用场景给三条路线，附一份可直接照着做的配置清单和排查顺序，最后说明什么情况下不适合做后台常驻。
你在 Windows 上装了 Ollama，双击图标能跑，但一关掉那个黑窗口接口就断了，脚本、知识库、编辑器插件全部连不上。想用任务计划或者注册成服务让它开机就跑，又不知道哪种靠谱、哪些坑会踩。
这篇按使用场景给你三条路线，附一份能直接照着填的配置清单和起不来时的排查顺序。不同做法适合的机器差别很大，正文里会写清每种在什么情况下不适用。
先搞清为什么关了窗口服务就停
默认启动方式是把 ollama serve 挂在当前终端会话上，会话一结束进程就跟着退出。这不是 bug，是前台进程的正常行为。你要做的不是「修好它」，而是换一种让进程不依赖你打开的那个窗口的启动方式。
判断当前服务到底在不在跑：另开一个终端请求本地接口，能返回模型列表说明服务活着。顺手到 /tools/speed-test 量一下延迟基线，后面排查时有对照，不然你只能凭感觉说「好像变慢了」。
- 进程被杀：窗口一关、终端一退，进程就没了，任务管理器里找不到
- 端口被占：服务其实起来了，但抢不到端口，请求打过去直接失败
- 模型被卸载：服务还在，只是显存里没东西了，第一次请求会特别慢
三条后台常驻路线怎么选
选型其实就一个问题：这台机器是不是只给你一个人用，以及会不会长期开着。下面三条路线的门槛和稳定性是反着走的，按场景挑，别按「哪个高级」挑。
| 路线 | 适合场景 | 明显短板 |
|---|---|---|
| 托盘启动方式 | 个人桌面，登录后自己用 | 不登录就不启动，多人共用机器不适用 |
| 任务计划程序 | 要给局域网脚本或他人调用 | 触发条件配错会静默失败，得会看历史记录 |
| 注册成系统服务 | 无人值守、当小服务器长期开机 | 需要额外的服务包装手段，门槛最高 |
- 开机触发
- 不用登录就会执行，适合无人值守机器
- 登录触发
- 必须有人登录才跑，文件路径和权限跟你当前用户一致
- 工作目录
- 任务计划默认目录跟你想象的不一样，模型路径和日志路径尽量写绝对路径
- 第一步，明确调用方先确认到底是谁在连这个服务：只有你自己，还是局域网内的脚本和同事。这决定绑定地址要听本机还是对外。
- 第二步，固定监听地址与端口默认只听本机回环地址，要让局域网访问得改成对外绑定。改完去 /ai-dict/category/infra 对照一下网络术语，别把绑定地址和防火墙规则搞混，这两个是两件事。
- 第三步，把参数写进环境变量模型存放路径和显存常驻参数都写成环境变量，避免每次重启后模型重新加载、第一次请求特别慢。
- 第四步，验证重启机器后不手动开任何窗口，直接请求接口，能拿到模型列表才算配好。验证时留一次走完整流程，别只测一次。
配置清单：照这几项逐条对
下面这份清单是按「后台跑起来之后还能查、还能维护」来设计的。每一项都是踩过坑才补上的，照着对，比事后翻日志省事。
- 固定监听地址与端口，写死在任务或服务配置里，别依赖系统默认值
- 模型存放路径用绝对路径，不依赖当前用户的环境变量
- 显存常驻相关参数提前设好，决定模型是否一直留在显卡里
- 日志输出到固定文件，后台跑出问题时至少有个地方能看
- 配一个健康检查脚本，定时打一次接口，失败就重启任务
# 健康检查思路：定时执行，非零退出就重启任务
curl -s http://127.0.0.1:<你的端口>/api/tags > /dev/null || echo restart-needed健康检查的频率别太密，也没必要太稀。太密会干扰正常请求，太稀等于没有。具体间隔可以到 /tools/speed-test 看本机响应水平再定，数字层面的事以站内当时显示为准。
起不来时的排查顺序
后台服务起不来，最忌讳一上来就改配置。按下面四步走，多数问题在第一步或第二步就能定位。顺序别颠倒，先看有没有进程，再看它有没有抢到端口。
- 第一步，查进程任务管理器里有没有对应进程。没有，就是启动配置本身有问题，先看任务计划的历史记录，别去翻应用日志。
- 第二步，查端口另开一个实例常导致端口冲突。先确认端口有没有被占，再决定换端口还是先杀旧进程，别两个都做。
- 第三步，查环境变量后台任务读不到你用户环境里设的变量是很常见的事。把需要的变量显式写进任务配置里最保险。
- 第四步，查权限与路径以系统账户跑的任务，工作目录和模型目录可能不在你有权访问的位置。改成绝对路径再试一次，多半就有输出了。
这些情况别急着做常驻
常驻不是默认答案，它只是把「手动启动」换成「一直占着资源」。下面几种情况下，按需启动反而更划算，也更好排查。
- 笔记本且经常休眠：唤醒后服务容易半死，比手动启动更难查
- 显存本就紧张：常驻会把模型一直占着显卡，同机再跑别的推理任务就抢不到卡
- 只是偶尔调用：为省一次手动启动去配一套自启，维护成本高于收益
- 接口要暴露到公网：那是安全问题不是后台问题，先搞清楚边界
接口要不要对外、能对外到什么程度，是另一套判断标准。这块别自己拍脑袋，先去 /safety 看看边界在哪，再决定要不要让服务常驻监听对外地址。调用频率值不值得常驻，可以到 /price-watch 核对当时的资源占用和成本口径。
下一步配好之后别只测一次，把延迟基线和健康检查都留一份记录。想横向比不同部署方式的响应差异，可以去站内工具页对着当时的数字看。→常见问题
为什么双击桌面图标能跑，命令行启动就不行？
两者启动方式和环境不同。图标方式通常已经在后台登记过，命令行则继承你当前终端的路径和环境变量，模型目录或 PATH 没配对时就会报错。先把启动命令里的可执行文件写成绝对路径，再补上模型目录相关的环境变量，通常就能复现图标方式的效果。
做成后台常驻以后，模型每次还要重新加载吗？
这取决于显存常驻参数和你的显存余量。默认情况下服务空闲一段时间会卸载模型释放显存，下次请求重新加载，表现为第一次响应特别慢。把常驻时长调大、显存够用的话可以一直留着，代价是别的程序分不到这块显存；具体参数名和取值去 /ai-dict/category/tips 对照。
开机自启配好了，为什么登录进去要等一会才能用？
开机触发和登录触发是两回事。开机触发在系统引导阶段就跑，但那时显卡驱动和网络栈可能还没就绪；登录触发要等你进桌面。想让服务更快可用，选开机触发并加上重试延时，或者干脆配一个定时健康检查，探到接口通了再对外 announce。
