缓存 LLM 响应：不只是按 prompt 哈希

每个人给 LLM 应用加的第一个缓存，都是把 prompt 哈希映射到响应的键值存储。开发环境里命中率看起来还行，生产里令人失望，因为真实用户用十四种不同方式问同一个问题，而 SHA 哈希把它们当成不同请求处理。朴素缓存命中二十分之一。聪明的缓存命中三分之一。

命中率到底从哪里来

语义缓存——把 prompt 嵌入、按相似度查、相似度足够高就返回缓存响应——能挽回基于哈希的缓存丢掉的大部分。阈值很重要：太松你会发出错误答案，太严就退回到二十分之一。把精确匹配和语义匹配组合起来，能拿到前者的速度、后者的召回率，又不带任何一个的错误。把缓存分层：热门 prompt 放内存里，长尾穿透到向量库。

永远不该缓存什么

有副作用的工具的 function-calling 响应。任何响应依赖于时间、用户状态或缓存看不到的外部数据的内容。流式响应——除非你缓存整个序列再重新流式——半缓存半实时是最坏的组合。规矩和任何缓存一样：失效是难的部分，“以后再想办法”等于”凌晨 3 点被 page”。

真正能省钱的 LLM 缓存，不是教程里那个。它是你团队在 6 个月剖析之后写出来的那个。