本地跑 Ollama 的人迟早会撞上两种尴尬：刚问完一句话，下次调用模型又要重新加载，等半天；或者模型一直赖在显存里不走，想换个大模型就爆显存。这两种情况都跟 keep_alive 有关。这篇不解释大道理，只讲这个参数在哪设、设成什么样、设错了怎么查。
本地跑 Ollama 的人迟早会撞上两种尴尬：刚问完一句话，下次调用模型又要重新加载，等半天；或者模型一直赖在显存里不走，想换个大模型就爆显存。这两种情况都跟 keep_alive 有关。它不是什么高级功能，就是一个空闲回收的倒计时开关，设对了体验顺滑，设错了要么白等要么白占。
这篇不解释大道理，只讲这个参数在哪设、设成什么样、设错了怎么查。动手之前建议先到 /guides 把本地部署相关的基础页扫一遍，确认自己的调用链路是命令行、SDK、客户端还是 WebUI，后面所有设置都建立在这个判断上。
keep_alive 到底在控制什么
它管的是「模型加载后在内存/显存里待多久没人用就被卸载」。注意它不控制加载速度，也不控制推理质量，和量化档位完全是两回事。很多人把它和显存优化混为一谈，结果调了半天发现首字延迟没变，那不是参数没用，是你期望错了地方。
- 计时从最后一次请求结束开始算，期间再来一次请求就重新计时，所以它更像「空闲回收倒计时」而不是「会话时长」
- 默认行为取决于你的安装方式与版本，别凭记忆下判断，先按下面的步骤实测一次当前值
- 它只影响卸载时机，不影响单次请求的耗时，冷启动等待和推理等待要分开看
- 不适用的情况：如果你的卡显存本来就够同时压好几个模型，或者你压根不换模型，调这个参数的收益很小
三个可以下手的设置位置，按优先级排
同一个参数在三条链路上都能设，优先级和生效范围不一样，改错地方最常见的表现就是「改了没反应」。建议按下面的顺序确认自己该动哪一层，别一上来就改环境变量。
- 单次请求级
- 调用时带上这个参数，适合临时跑一个长任务，或者临时把一个占显存的大模型踢出去
- 服务级默认
- 通过环境变量给守护进程设全局默认值，适合整台机器就服务固定几个模型、不想每次调用都写一遍
- 客户端配置级
- 有些客户端界面里提供了「保持加载」开关，底层往往就是往这个参数填值，先在客户端里找再动环境变量
- 确认调用链路看你是命令行 curl、SDK、桌面客户端还是 WebUI，不同链路生效优先级不同，写下来再动手
- 从最外层改起如果客户端里已经有开关，先动它；改完重启客户端观察一次，不行再往服务层找
- 服务层改完必须重启环境变量的改动不重启守护进程不会生效，重启方式可参考 /guides 里关于重启服务的页面
- 记录层级把「改在哪一层 + 值 + 观察结果」记一行，避免下次在两三层里来回试
值怎么挑：不是越长越好
常见的值分三档思路：负值类表示常驻不卸载，零值类表示用完即走，正数类表示空闲多久后卸载。具体字面量以官方文档和你当前版本的文档为准，别照抄老帖子，版本之间对负值的处理有过变化。
| 使用场景 | 取值方向 | 代价 |
|---|---|---|
| 反复追问同一模型 | 常驻方向 | 这块显存长期占着 |
| 一天换好几个模型试效果 | 短空闲方向 | 每次冷启动要等 |
| 跑一次性批处理/评测 | 用完即走 | 跑完立刻让位，不影响下一轮 |
| 多人共用一台机器 | 常驻 + 限并发 | 不限并发容易把显存打满 |
多模型混跑、并发提问的场景，这个参数要跟并发数和显存一起算，单看它会误判。显存账可以到 /models/deploy 用部署测算对一遍，把模型大小、并发数和你卡的实际容量放一起看。不适用的情况也要说清：共享机器上多人抢卡时，把它设成常驻等于长期占座，容易被同事投诉。
改完怎么验证、没生效怎么查
验证不能只看命令输出，要盯显存占用曲线。一次完整的验证至少要包含「改设置、重启、跑一次、空闲等待、再跑一次看是否重新加载」这几个动作，少一步都可能得出错误结论。
- 改设置并重启环境变量改动必须重启守护进程，没重启就验证等于白测
- 跑一次请求用你最常用的那条调用方式发一次，记下耗时
- 空闲等待等待时间要长于你设的空闲阈值，否则测不出卸载行为
- 再跑一次如果这次明显变慢，说明被卸载了，参数生效；如果速度不变，说明模型还驻留，继续往下查
- 先看是不是改在了错误的层级，比如客户端里写死了值，服务层怎么改都没用
- 再看服务有没有真的重启，很多人改完环境变量直接测，结论必然错
- 再看调用时是不是每次都显式传了参数，把服务层默认值覆盖掉了
- 最后看显存是否已被别的东西占住导致加载失败，这种情况是加载不进去而非没卸载，别诊断错方向
- 速度异常的同伴问题可以对照 /guides 里关于本地推理慢的排查思路一起看
按场景抄一份配置清单
下面几类场景可以直接对照着设，但请先跑一次基线再调：先不改参数测一次冷启动耗时和常驻时的显存占用，有基线才知道调整有没有换来收益。延迟基线可以用 /tools/speed-test 量，别靠感觉。
| 场景 | 建议方向 | 前提 |
|---|---|---|
| 个人单机、反复追问同一模型 | 常驻 | 接受这块显存一直占着 |
| 个人单机、一天换好几个模型 | 短空闲 | 接受每次冷启动等待 |
| 小团队共用一台机器 | 常驻 + 控制并发 | 别让人无限并发打满显存 |
| 一次性批处理或评测脚本 | 用完即走 | 跑完就让位，避免脚本挂住不释放 |
如果你压根不换模型、显存也够，那这个参数调不调差别不大；如果你在共享卡上做实验，常驻策略要提前跟同事打招呼。判断标准就一句：你的机器是「一台机器服务少数固定模型」还是「频繁换模型试效果」，前者往常驻走，后者往短空闲走。
下一步想知道你当前这套配置在不同参数下的实际延迟差异，可以到站内的速度测试工具跑一组对照，把改动前后的数字都记下来再决定长期用哪个值。→常见问题
我改了参数但好像没生效，最快怎么定位？
先确认改在哪一层：客户端面板里的开关优先级通常高于你后来加的全局环境变量，改环境变量后没重启服务也不会生效，另外单次请求里显式传了参数会覆盖默认值。按「客户端 → 服务重启 → 单次参数」这个顺序逐个排除，比反复改值有效。
把模型设成常驻会不会拖慢机器？
它占的是内存或显存，不占 CPU 算力，空闲时不参与计算，所以不会持续吃性能。代价是这部分显存不能让给别的模型或别的任务，机器同时在跑训练、出图、另一个推理服务时更容易冲突。显存紧的话宁可让它短暂驻留，别硬设常驻。
这个参数和量化档位、上下文长度有什么关系？
三者管的事不同：量化决定模型本身多大，上下文长度决定单次请求要预留多少 KV 缓存，这个参数决定模型加载后待多久。它们会一起决定显存够不够，所以要一起看。想按模型和量化算一遍占用，可以去模型部署测算页对一下，别只调这一个参数。
