在本地部署大模型时，很多人会发现一个现象：同一个模型第一次请求明显较慢，后续请求却快了不少。🚀 这通常不是网络问题，而是模型经历了从磁盘读取、内存映射、显存分配到推理引擎初始化的“冷启动”过程。要降低用户感知延迟，关键并非盲目升级硬件，而是区分加载耗时与生成耗时，再通过预热、驻留和资源控制建立稳定的热加载机制。
一、先分清冷启动与热加载
冷启动是指模型当前不在可用内存或显存中，请求到达后才开始加载。模型文件越大、磁盘越慢、可用内存越紧张，等待通常越明显。若显存不足，部分计算还可能转移到 CPU，进一步影响首字响应时间。
热加载则表示模型已经驻留在内存或显存中，后续请求可以直接进入提示词处理和令牌生成阶段。热加载并不等于永久占用资源，而是通过合理的保活时间，在响应速度与资源利用率之间取得平衡。🔥
二、不要只看接口总耗时
Ollama 的生成接口会返回多项性能指标，其中 total_duration 表示请求总耗时，load_duration 表示模型加载耗时，prompt_eval_duration 表示输入处理耗时，eval_duration 表示输出生成耗时，时间单位均为纳秒。流式响应的这些指标位于 done 为 true 的最后一个数据块中，具体字段可查看API 用量说明。
排查时建议使用相同模型、相同提示词连续请求两次。如果第一次的 load_duration 较高，而第二次显著降低，就能确认主要瓶颈来自冷启动；如果两次加载耗时都不高，但生成仍然缓慢，则应继续检查上下文长度、CPU 与 GPU 分配、输出长度和并发排队。
建议记录的核心指标
- 首次请求的总耗时与模型加载耗时；
- 连续请求的首字时间和完成时间；
- 输入、输出令牌数量及对应处理耗时；
- 模型是否完全进入 GPU，以及可用显存变化；
- 空闲一段时间后再次访问是否重新触发加载。
三、用 keep_alive 控制模型驻留
Ollama 的 keep_alive 参数可以控制请求结束后模型继续驻留多长时间。例如设置为 15m，表示模型在请求完成后继续保留一段时间；设置为 0，则会在请求结束后立即卸载。参数定义可参考生成接口文档。
curl 来源链接 -d '{"model":"你的模型名","prompt":"你好","stream":false,"keep_alive":"15m"}'
实际配置不要一味追求“永不卸载”。单模型、持续访问的服务可以适当延长驻留时间；多模型共享一张显卡时，应优先保障高频模型，低频模型使用较短的保活周期。否则多个大模型相互挤占显存，可能造成频繁卸载与重新加载，形成典型的资源抖动。⚠️
四、在流量到来前主动预热
对于每天固定时段使用的知识库、代码助手或内部客服，可以在 Ollama 服务启动后发送一次轻量请求，让模型提前完成加载。预热提示词应尽量短，输出数量也应受控，因为预热目标是初始化模型，而不是执行真实业务。
- 先启动 Ollama 服务，并确认目标模型已下载完成；
- 发送简短的非流式生成请求，同时设置合适的 keep_alive；
- 检查响应中的 load_duration，确认加载过程已完成；
- 运行 ollama ps，核对模型所在处理器和剩余驻留时间；
- 再将业务网关或应用实例切换为可接收流量状态。
在 Linux 环境中，可以把预热脚本放在 systemd 服务启动后的执行步骤中；容器化部署则可以在 readiness 检查前完成预热。这样能够避免实例虽然“端口可访问”，实际上模型仍未准备好接收请求的问题。✅
五、优先保证模型完整进入 GPU
执行 ollama ps 可以查看当前已加载模型、处理器分配和驻留截止时间。PROCESSOR 显示 100% GPU，代表模型完整加载到 GPU；如果显示 CPU/GPU 混合比例，则说明存在部分卸载。相关判断方式见Ollama FAQ。
若模型无法完整进入显存，可从三个方向处理：选择参数规模更小或量化程度更高的模型；减少同时驻留的模型数量；降低不必要的上下文长度。尤其需要注意，上下文窗口越大，运行时所需内存通常越多，因此“模型权重能放进显存”并不代表当前上下文配置也一定合适。
六、上下文长度要按业务配置
过大的上下文窗口不仅增加内存压力，还可能延长提示词处理时间。普通问答没有必要照搬长文档分析或智能体任务的配置，应根据真实输入长度预留合理余量。Ollama 的上下文长度说明也明确指出，增加上下文长度会提高模型运行所需的内存。
优化时应先统计线上输入分布，而不是直接选择模型支持的最大值。普通聊天、文档摘要和代码仓库分析可以使用不同的模型实例或配置，避免所有请求都承担最大上下文带来的资源成本。💡
七、建立可重复的压测流程
一次测试不能代表真实效果。建议分别执行纯冷启动、连续热请求和空闲后重访三组测试，每组保持模型、提示词、生成参数和机器负载一致。冷启动测试前主动卸载目标模型，热请求测试连续执行多次，空闲测试则等待超过保活周期后再次发起请求。
- 冷启动组：用于评估磁盘、内存与显存加载链路；
- 热请求组：用于评估提示词处理速度和令牌生成速度；
- 空闲重访组：用于验证 keep_alive 是否符合实际访问间隔；
- 混合模型组：用于观察多模型切换时是否发生显存争抢。
最终应关注 P50、P95 等延迟分布，而不是只记录最快的一次结果。同时把模型名称、量化版本、上下文设置、硬件状态和 Ollama 版本写入测试记录，避免配置变化后进行无效对比。
总结
Ollama 冷启动优化的核心路径可以概括为：先利用 load_duration 定位加载瓶颈，再通过短请求预热模型，使用 keep_alive 控制驻留周期，并借助 ollama ps 检查 GPU 分配；如果资源仍然紧张，就缩小模型、控制上下文和减少同时驻留数量。真正稳定的低延迟方案，不是让所有模型永久在线，而是让高频模型保持热状态、低频模型有序卸载，并用持续监控验证每一次调整。🎯
