在本地部署 Ollama 后，最常见的性能困惑不是模型生成速度，而是“第一次请求为什么特别慢”。这段等待通常包含模型文件读取、权重装入内存或显存、运行环境初始化等过程，也就是冷启动延迟。🚀 对交互式助手、知识库问答和内部 API 服务来说，合理预加载模型并控制驻留时间，往往比盲目升级硬件更直接。
先分清冷启动与推理延迟
优化前应拆分请求耗时。冷启动主要反映在模型加载阶段；提示词处理和逐字生成则属于推理阶段。Ollama API 返回的 load_duration、prompt_eval_duration、eval_duration 和 total_duration 可以帮助定位瓶颈，时间单位为纳秒。流式响应的统计字段位于 done 为 true 的最后一个数据块中，具体定义可参考 API 用量指标说明。
- load_duration 较高：重点处理模型预加载、磁盘读取和内存驻留。
- prompt_eval_duration 较高：检查上下文长度、历史消息和提示词规模。
- eval_duration 较高：关注模型大小、量化版本、GPU 加速及输出长度。
方法一：发送空请求完成预加载
Ollama 支持通过不携带提示词的请求加载模型。应用启动后先执行一次预热，请求真正到来时就能跳过大部分权重加载过程。官方说明显示，/api/generate 和 /api/chat 均可采用这种方式，CLI 也可以传入空字符串，参见 预加载说明。
curl 来源链接 -d '{"model":"llama3.2","keep_alive":"30m"}'
ollama run llama3.2 ""
生产环境中，建议把预热动作放在服务启动脚本、容器启动后的生命周期钩子或健康检查之前。只有预热成功，才把实例加入负载均衡。这样可避免重启、扩容或故障迁移后，首位用户承担冷启动等待。✅
方法二：合理设置 keep_alive
模型加载后并不会永久驻留。Ollama 默认会将模型保留在内存中一段时间，官方当前说明为默认五分钟；API 的 keep_alive 可以传入“10m”“24h”等时长、秒数、负数或 0。负数表示持续驻留，0 表示响应后立即卸载。请求参数还会覆盖全局的 OLLAMA_KEEP_ALIVE 设置，详见 内存驻留文档。
curl 来源链接 -d '{"model":"llama3.2","keep_alive":-1}'
curl 来源链接 -d '{"model":"llama3.2","keep_alive":0}'
不要把所有模型都设为永久驻留。单模型专用服务可考虑 -1；访问有明显间隔的业务可设置 15m、30m 或 1h；低频大模型则应缩短时间，避免长期占用显存。多模型服务最好按照调用频率分级：核心模型长驻，次要模型定时保活，临时模型用完释放。🧠
方法三：用真实业务提示词做二次预热
空请求解决的是“模型是否已装入内存”，但首个真实请求还可能触发提示词模板处理、上下文分配或相关运行路径初始化。因此可以在空请求之后，再发送一条短小、固定且无敏感信息的业务提示词，并限制输出长度。预热请求应与线上使用同一模型、同一接口和相近参数，但不要塞入完整长上下文，否则只会制造额外负载。
硬件与参数层面的实用优化
- 模型要匹配资源：优先选择能够稳定放入显存或内存的量化版本。频繁在 CPU、GPU 或磁盘之间调度，可能抵消预加载收益。
- 控制上下文：上下文越长，通常需要的运行内存越多。不要仅为“预留能力”把 num_ctx 设置得远高于实际需求。
- 避免模型来回切换：显存不足时，多模型轮流调用容易反复装载。可以拆分实例，让不同实例分别服务高频模型。
- 检查加载位置：执行 ollama ps，查看模型当前是否在 CPU、GPU 或两者之间分配；字段解释见 官方 FAQ。
- 优先使用本地高速存储：模型目录放在机械硬盘、慢速网络盘或繁忙磁盘上，都会放大首次读取时间。
建立可重复的测试流程
优化效果不能只凭体感判断。建议重启 Ollama 后记录第一次请求，再立即发送相同请求记录热启动结果；随后等待超过驻留时间，测试模型卸载后的表现。每组测试至少保持模型、提示词、上下文参数和输出上限一致，并分别保存 load_duration 与 total_duration。📊 如果加载耗时明显下降但总耗时变化有限，说明瓶颈已经转移到提示词处理或生成阶段，不应继续只调 keep_alive。
常见误区
- 预加载不会让模型本身生成得更快，它主要减少首次请求的加载等待。
- 永久驻留不是通用最优解，内存或显存不足可能导致其他模型排队或频繁换入换出。
- 仅做一次命令行测试不代表线上效果，还要覆盖服务重启、并发访问和模型切换场景。
- 不要用超长提示词进行健康检查，否则健康检查本身可能占用推理资源。
总结
Ollama 冷启动优化可以概括为四步：先用 API 指标确认加载耗时，再以空请求预加载模型，随后通过 keep_alive 制定驻留策略，最后使用固定场景反复验证。高频单模型适合长驻，低频或多模型环境更需要精细控制内存。把预热纳入部署流程，并持续观察加载位置、资源余量与真实请求延迟，才能在响应速度和资源占用之间取得稳定平衡。⚡
