在本地部署 Ollama 后，很多应用都会遇到同一种性能浪费：相同模型、相同提示词和相同参数被反复提交，服务端却每次都重新执行完整推理。对于知识问答、内容审核、固定模板生成和自动化测试等场景，重复请求往往没有必要再次消耗计算资源。引入一层设计合理的结果缓存，可以显著缩短重复请求的响应路径，同时降低 GPU 或 CPU 的推理压力。🚀
一、先明确缓存解决什么问题
推理结果缓存针对的是“请求内容等价且允许复用历史答案”的场景。缓存命中后，应用不再调用 Ollama，而是直接返回已经保存的结果。它与模型常驻内存并不是一回事：Ollama 的 keep_alive 参数用于控制模型在请求结束后继续驻留内存的时间，可减少模型重复加载开销；结果缓存则跳过实际生成过程。两者组合使用，才能同时优化首次请求和重复请求。相关参数可参考 Ollama API 文档。
并非所有请求都适合缓存。固定知识查询、分类、摘要、格式转换等任务通常具有较高复用价值；创意写作、实时数据问答、包含用户隐私的内容，以及要求每次输出不同结果的任务，则应谨慎处理或直接绕过缓存。
二、构造稳定且完整的缓存键
缓存设计最关键的环节不是存储，而是缓存键。只对提示词做哈希并不安全，因为模型、系统指令和采样参数发生变化时，即使用户问题相同，预期结果也可能不同。建议先把所有影响输出的字段规范化，再生成 SHA-256 等稳定摘要。
- 模型标识：保存完整模型名称与标签，避免不同模型共用结果。
- 消息内容：纳入 system、user、assistant 等完整会话消息及其顺序。
- 推理参数：包括 temperature、seed、top_p、num_predict、stop、format 等。
- 模板版本：业务提示词修改后，通过版本号主动隔离旧缓存。
- 知识版本：RAG 场景应加入知识库版本、检索结果摘要或文档更新时间。
- 租户信息：多用户系统需要加入租户或权限范围，防止越权复用。
推荐思路：缓存键 = 哈希（接口版本 + 模型标识 + 规范化消息 + 规范化参数 + 业务版本 + 数据版本）。
所谓规范化，是指固定字段顺序、统一空白字符、明确缺省值，并把 JSON 对象按确定顺序序列化。否则语义相同但字段排列不同的请求会生成不同缓存键，降低命中率。⚙️
三、选择缓存层与数据结构
单机工具可以使用进程内 LRU 缓存，优点是实现简单、访问速度快，缺点是应用重启后数据丢失，多个进程之间也无法共享。需要持久化时，可选择 SQLite；面向多实例服务时，Redis 更适合提供共享缓存、过期控制和容量淘汰能力。
缓存值不应只保存回答文本，还可以记录创建时间、模型名称、参数摘要、完成状态和响应格式。若业务依赖 Ollama 返回的耗时或 token 统计，应明确区分“原始推理指标”和“本次缓存读取指标”，避免命中缓存后仍把旧耗时当作当前性能数据。Ollama 的生成接口支持流式返回，并在最终响应中提供统计信息，具体结构可查看 生成接口说明。
四、处理流式输出与并发重复请求
流式响应不能在生成到一半时写入正式缓存，否则客户端可能读到不完整内容。稳妥流程是先累计完整响应，确认请求成功且结束原因有效，再原子写入缓存。命中缓存后，如果前端必须保持流式体验，可以把完整文本按小片段重新发送；如果协议允许，也可以直接返回非流式结果。
高并发下还要防止“缓存击穿”。当多个相同请求同时未命中时，它们可能一起进入 Ollama，造成重复计算。可按缓存键增加短期互斥锁：第一个请求负责推理，其余请求等待；缓存写入后，等待者直接读取结果。锁必须设置超时，并在异常时释放，避免某次推理失败导致后续请求长期阻塞。🔒
五、设置过期、失效与安全边界
缓存不能只写不管。稳定的分类或格式化结果可以设置较长 TTL；依赖实时知识的数据应采用较短 TTL，或者在数据变更时主动删除相关键。模型升级、Modelfile 修改、系统提示词调整时，最简单可靠的办法是提升缓存命名空间版本，而不是逐条扫描旧数据。
对于包含个人信息、访问令牌、内部文档或商业数据的请求，应默认不缓存，或至少采用加密存储、最小权限、日志脱敏和租户隔离。不要直接把原始提示词放进可读缓存键，也不要在命中日志中输出完整问答内容。缓存首先是性能组件，也必须遵守原有的数据安全边界。🛡️
六、用指标验证是否真正加速
上线后应持续记录缓存命中率、未命中率、读取延迟、推理延迟、写入失败数、淘汰数量和锁等待时间。测试时可准备三组请求：完全相同的请求、仅参数不同的请求，以及模型或模板版本不同的请求。第一组应该命中，后两组必须未命中，这能尽早发现缓存键遗漏字段的问题。
- 先统计业务中重复请求的比例，确认缓存是否值得建设。
- 从确定性较强、风险较低的接口开始接入。
- 同时对比冷启动、模型已加载、缓存命中三种响应路径。
- 逐步调整 TTL、最大容量和淘汰策略，不使用无法复现的固定性能结论。
- 发布新模型或新提示词时，验证旧缓存不会被错误复用。
总结
Ollama 重复请求加速的核心，不是简单地把回答存起来，而是建立可判定、可失效、可隔离的复用机制。一个可靠方案应覆盖完整缓存键、原子写入、并发合并、版本失效、TTL、安全控制和可观测指标。实践中可以先用进程内缓存验证收益，再根据部署规模迁移到 SQLite 或 Redis；同时利用 keep_alive 降低非命中请求的模型加载成本。只有把结果缓存与模型常驻、并发控制和业务数据版本结合起来，才能获得稳定且可维护的加速效果。✅
