ollama加载本地模型 如何做到始终驻留显存不退出

本地跑 Ollama 时经常遇到这种情况：第一次问答很快，隔一会儿再问又要等十几秒重新加载，模型像是被踢出了显存。如果你把 Ollama 当常驻服务给团队或自己的工具链用，这种反复加载很烦。这篇按「先看是不是保活没设对、再看是不是显存不够、最后看是不是被别的东西挤掉了」的顺序，把保活设置和验证动作讲一遍。

本地跑 Ollama 时经常遇到这种情况：第一次问答很快，隔一会儿再问又要等十几秒重新加载，模型像是被踢出了显存。如果你把 Ollama 当常驻服务给团队或自己的工具链用，这种反复加载很烦。它不只是「慢一点」的问题，还会让上游调用的超时设置、并发队列、缓存策略全部要跟着调整，等于把不稳定的成本转嫁给了调用方。

这篇按「先看是不是保活没设对、再看是不是显存不够、最后看是不是被别的东西挤掉了」的顺序，把保活设置和验证动作讲一遍。全程只给判断标准和可执行动作，具体占用数字和硬件差值到站内页面按你的卡核对。

先搞清模型为什么会被卸载

Ollama 默认按空闲时间回收，不设保活就会在闲置一段时间后把权重从显存挪走，下次请求重新加载。这个机制本身是合理的省显存设计，只是对常驻服务不友好。你要做的第一件事不是去改参数，而是确认「慢」到底是不是卸载造成的，否则容易改了半天没效果。

• 显存不够：新模型进来时旧模型必须让位，这是硬件容量问题，改保活参数解决不了
• 服务重启或进程被杀：容器重建、systemd 重拉、手动 kill 都会让显存里的模型消失
• 显卡驱动重置：掉驱动、休眠唤醒后显存状态被清空，体感上和卸载一模一样
• 区分办法：连着问两次，第二次仍要加载才说明是卸载；两次都慢就是别的原因

保活参数怎么设：从单次请求到全局默认

保活有两层：单次请求带时长参数，进程退出后失效；服务端环境变量设全局默认，重启服务生效。临时压测、演示用前者；独占显卡、给团队当常驻接口用后者。写死在启动脚本里比写进终端 export 靠谱，容器和 systemd 托管时要确认变量确实落在服务进程的环境里。

# 单次请求钉住一段时间的示意，具体参数名以你安装的版本为准；到站内文档核对当前支持的写法；服务端全局保活通常用环境变量设置，负数表示不主动卸载；改完必须重启服务进程，只改当前终端不生效

保活不是越久越好。模型一直占着显存，同卡上想临时跑个别的模型或做微调就没空间了。下面这张表帮你按场景选策略，不用一刀切。

显存够不够、有没有东西在抢

按参数量和量化档位粗算权重占用，再留出上下文缓存的空间。上下文开得越大，缓存占用越高，长对话场景尤其明显。具体留多少到站内部署测算页按你的卡和模型口径对一遍，别凭感觉估。

• 同时开两个客户端指向同一个 Ollama，是共用同一份已加载模型，不会各占一份，别按进程数估显存
• 桌面环境、浏览器硬件加速、其他常驻推理进程都会吃显存，保活前先把这些用量看清
• 多卡机器要确认模型是否被拆到多张卡上，拆分后单卡余量不足同样会触发卸载
• 上下文长度、并发数这类参数也会推高占用，调保活的同时顺手看一下它们

如果算下来这台机器根本没有余量长期占住，那就不是参数问题，而是容量问题。这时候与其硬扛，不如换个思路，比如换更小的量化档位，或者把常驻任务挪到一台专门的机器上。

怎么验证保活生效，以及不生效时的排查顺序

验证动作很直接：加载一次，等超过你设的空闲时长，再发一次请求，看响应时间是否没有回落。更可靠的办法是看服务日志里的加载与卸载记录，凭手感判断容易把网络抖动也算进去。

1. 确认服务没有重启看进程启动时间和日志开头，容器或 systemd 托管时尤其容易在你不注意时被重拉
2. 确认环境变量被读到在服务进程的实际环境里查，而不是在当前终端查；两边的环境不一定一样
3. 确认显存没被别的东西占满加载后立刻看显存占用，再等一段时间复看，占用掉下去就是被卸载了
4. 确认没有多客户端并发挤占多个工具同时打请求会推高瞬时占用，必要时先隔离测试，只留一条链路

保活解决的是「来回加载」，解决不了「显存本来就不够」。