什么是本地LLM的提示词缓存？

缓存究竟如何加快速度

处理一段提示词，意味着模型要在开始生成回复之前，为每一个输入token计算出键值（KV）表示。这一步——提示词处理——发生在生成开始之前，其成本随提示词长度增加而增加。如果没有缓存，一段2000个token的系统提示词会在每一次请求中被完整地重新处理，即使它每次都是逐字节相同的内容。

缓存会保存针对某个前缀计算出的KV表示，并将其与确切的token序列绑定。当新请求以相同的token开头时，缓存的KV值会被直接复用，只有提示词中新增的、未缓存的部分才需要处理。实际效果是：对于命中缓存的情况，首个token出现所需的时间会显著缩短，因为大部分输入不再需要重新计算。

这也是多轮对话几乎自动受益的原因：对话的第3轮会将第1轮和第2轮作为其前缀，因此支持缓存的服务部署只需要处理最新一轮，而不必重新处理整个对话历史。

如何构建提示词才能真正受益

• ▸**把共享、不变的内容放在最前面。** 在不同请求间保持一致的系统提示词、指令和参考文档，应该放在会随请求变化的内容之前——缓存只对完全匹配的前缀生效，所以第一处出现差异之前的所有内容才是可以被复用的部分。
• ▸**让请求之间的共享前缀保持逐字节一致。** 系统提示词中哪怕只有一个字符的差异（比如时间戳、随机ID）都会打破前缀匹配，从而触发完整的重新处理——把每次请求特有的可变内容放到提示词末尾，放在可复用内容之后。
• ▸**不要指望缓存能帮到互不相关的单次请求。** 如果你的工作负载主要是没有共享设置的一次性提问，那么缓存就没有可以复用的内容——这项技术的价值，取决于你有多少流量真正共享着同一个前缀。
• ▸**长时间持续的对话最能从缓存保留设置中受益。** 检查你所用的服务部署会把缓存的前缀保留多久才驱逐——如果驱逐过于激进，对于轮次之间存在间隔的对话就起不到帮助。