prompt cache 怎么提高

最近在做一套 GA + LLM 的量化策略系统时，我踩到了一个很隐蔽的坑。
这个问题不影响功能。
但会持续增加调用成本。
一开始，我发现 prompt cache hit rate 只有 20% 左右。
我第一反应是模型不稳定。
也怀疑过 prompt 写法有问题。
甚至觉得可能是 GA 搜索过程太随机，导致每次请求差异太大。
但继续看数据后，我发现情况不太对。
很多 prompt 看起来几乎一样。
固定规则也基本没有变化。
可缓存就是无法命中。
后来我专门拆了一下 LLM 的缓存机制，才找到真正原因。
LLM 的 prompt cache，本质上是前缀级别的精确匹配。
也就是说，它不是判断两段 prompt 的内容是否相似。
而是要求从开头开始，token 必须连续一致。
只要前面某个位置发生变化，后面的固定内容再多，也很难被复用。
而我原来的 prompt 结构正好反了。
我把 GA 每次生成的动态 JSON 放在最前面。
角色定义、任务说明和输出规则这些固定内容，反而放在后面。
这就导致每次请求一开始就不同。
哪怕后面还有上千行完全一致的规则，也无法形成稳定的缓存前缀。
缓存自然一直失效。
找到原因之后，我重新调整了 prompt 的结构。
我把角色定义、任务说明、输出格式和固定约束全部放到最前面。
这些内容组成一个稳定的 locked prefix。
GA 生成的参数、实验变量和 JSON 输入，则统一放到最后。
同一类任务也尽量使用同一套 prompt header。
这样可以保证请求前半部分保持一致。
改完之后，cache hit rate 明显提升。
LLM 的调用成本也随之下降。
GA 的整体运行效率也更高了。
这次最大的经验是，优化 LLM 成本不能只盯着模型和 token 数量。
Prompt 的排列顺序同样重要。
固定内容尽量前置。
动态内容尽量后置。
对于需要大量重复调用 LLM 的系统来说，这种结构调整看起来很小，但最终节省的成本可能非常可观。