前缀缓存：让同一份系统提示词不再反复付费

你每天往 LLM API 发几千个请求，每一次都带着同样的系统提示词、同样的 few-shot 示例。模型并不知道它们一样——除了前缀缓存这条路，每个部分都要重新算一遍。前缀缓存（prefix caching，各家产品里也叫 context caching）不改变模型，也不改变答案，它只做一件事：把请求开头那段重复计算的 K/V 中间结果留下来，下一个人接着用。

它到底缓存了什么

不是最终答案。是自回归生成时，提示词每个 token 在每层注意力里算出的 key/value 张量。算第一个 token 时，长提示词的主要开销就在这里。前缀缓存把这部分结果按 KV block 存住，下一个请求只要开头字节级一致，就直接引用，不再重算。

这也解释了它的硬性前提：匹配从第一个字节开始，一路比对。系统提示词里多一个空格、少一个换行，从那个位置起全部失效。

一条最重要的工程规则：固定在前，变化在后

缓存命中率几乎完全由 prompt 的结构决定：

- 系统提示词放在最前，且长期不动。改词可以，但把改动放最后，前面所有稳定内容继续命中。

- 用户输入、检索文档、当前时间戳这类每次不同的内容，一律放后面。时间戳放最末尾，而不是一开始「今天是 2026-08-28」。

- 检索场景下，把稳定 Few-shot 放在检索结果前面，同一段被多轮引用也能吃命中。

RAG 系统常见的错误是每次把「用户问题 + 检索片段」随机排序后拼进 prompt，前缀从第四个 token 起就全乱了，缓存形同虚设。

收益体现在哪三个数字

1. **首 token 延迟（TTFT）**：提示词阶段占去首次响应的大头。同样 4k token 前缀，命中缓存时 TTFT 常能缩到未命中的两三成以下，具体倍数看模型和并发。

2. **输入成本**：主流云厂商对缓存命中的输入 token 按约 10% 计费。系统提示词 2k token、日发万级请求，差额是按天累计的真金白银。

3. **派发效率**：多个同前缀请求会把 KV block 留在同一 GPU 显存里，引擎顺手把它们排进同批连续批处理，整体吞吐上升。

算一笔具体的账：一个客服机器人，系统提示词加人格设定共 1,500 token，日均 20,000 次请求，输入单价每百万 token 3 元。没有缓存时，这部分提示词每天花 1,500 × 20,000 ÷ 1,000,000 × 3 = 90 元；缓存命中 90% 后，只有 10% 按原价计费，每天 18 元，一年多出约 31,000 元的差额空间。如果你的系统提示词不足两百 token，那前缀缓存的主要价值就不在成本，而在 TTFT——几百毫秒的首字延迟对聊天产品的体感影响，比账单明显得多。

容易踩的三个坑

- **过期比你想得快**。KV block 空闲若干分钟就会被回收。流量是「十分钟五百个请求 + 三小时空窗」这种形态时，你会大量撞上不命中，而不是缓存坏了。

- **换模型 = 全量重算**。缓存是按模型权重组织的，A/B 切模型那一分钟，命中归零，TTFT 会有一阵毛刺，属正常现象。

- **别只看 usage 总价**。响应里的 `cached_tokens` 才是真实命中率。周均值掉到三四成，大概率是有人在提示词开头加了东西——把它当成一条告警指标挂上。

落地的三步

先把现有 prompt 从前往后过一遍，按「永不变 → 偶尔变 → 每次变」重排，这一步不花一分钱，通常立竿见影。再确认用的是原生支持的缓存端点而不是自己手搓 Redis（RAG 语义缓存是另一件事，命中的是整条答案，别混用）。最后把 `cached_tokens / prompt_tokens` 比率进监控，低于阈值就有人动了共享前缀。

前缀缓存不提升模型能力，它只是让你为说了八百遍的话，只付一次钱、等一次时间。