为什么使用大模型的时候，同样的提示词，一次要花 3 毛钱，另一次只要 2 毛？为什么有的请求几乎秒回，有的却越来越慢？答案或许不在模型本身，而在一个很多人忽略的机制：提示词缓存！
在这期 Build Hour 里，OpenAI 和 Wrap 的两位技术专家系统地讲解了提示词缓存（Prompt Caching）的运行机制，以及在开发智能体系统时的使用技巧。
所谓提示词缓存，本质上就是 “算过的不再算”。当多个请求拥有相同的前缀（系统提示词、工具定义、已有对话历史、图片或音频等）内容时，模型不需要重复处理已经计算过的部分，只对新增内容继续推理。这样可以同时降低延迟和成本，而且不会影响模型的智能水平。输出不会变，只是少做了重复工作。
很多人以为缓存是 “存下文本”。其实不是。缓存存的是模型在注意力机制（Transformer）里计算出来的一堆中间向量，也就是所谓的 KV cache。只要前缀完全一致，顺序也一致，这部分计算就可以复用。
这里有几个关键点。
第一，缓存从 1024 个 Token 开始生效。不到这个长度，是不会触发缓存的。如果你的系统提示词是 900 个 Token，可能反而在浪费机会。实际测试表明，把提示词扩展到超过 1024 个 Token，一旦开始命中缓存，整体成本可能反而下降。
第二，前缀必须完全一致。哪怕多一个空格、多一个时间戳、换个顺序，都会让缓存失效。有的用户只是因为在提示词里加入动态时间信息，缓存命中率直接变成 0%。很多缓存问题，都是工程细节造成的。
第三，缓存是自动触发的，不需要额外代码。但如果你的请求量很大，可能会被分发到不同机器，影响命中率。这时可以使用 “提示词缓存键” 这个参数，把相关请求有意识地路由到同一组引擎。实测案例里，有团队把命中率从 60% 提升到 87%，带来大幅的成本下降。
缓存带来的收益到底有多大？
在 GPT-4o 上，缓存 Token 有 50% 折扣，在 GPT-4.1 上是 75%，在 GPT-5 系列上高达 90%。实时语音场景下，音频缓存的折扣接近 99%。对于长对话或长上下文应用，这不是小数目。
更重要的是延迟。随着输入变长，未缓存请求的首 Token 时间会明显上升，而缓存请求基本保持平稳。换句话说，缓存让延迟更接近 “输出长度” 而不是 “整个对话长度”。
不过，真正难的不是 “打开缓存”，而是如何设计提示词。
一个常见场景是智能客服或编程助手。系统提示词和工具定义是固定的，但用户问题是动态的。最佳做法是把静态内容尽量放在前面，把动态内容放在后面，避免修改已经被模型 “见过” 的部分。如果需要改变任务方向，与其修改最早的用户消息，不如在对话末尾追加一条新指令，这样可以保住之前的缓存。
长时间运行的智能体还会遇到另一个问题，就是上下文越来越大。这里就出现了一个取舍。你是选择频繁截断历史、保持上下文精简，还是尽量保留历史以提高缓存命中率？一个比较靠谱的建议是，不要只看缓存命中率，要同时看输入 Token 总量。频繁压缩虽然会降低命中率，但可能总体更便宜。
还有一个容易被忽略的细节，如果使用推理模型，建议用 Responses API 而不是 Chat Completions。因为推理模型内部有隐藏的思维链 Token，只有 Responses API 会完整保留它们，否则缓存命中率会下降。
再比如工具调用。工具定义本身属于前缀的一部分，如果你动态增删工具，会直接影响缓存。可以使用 allowed_tools 参数在不改变前缀的前提下限制可用工具，避免不必要的失效。
对于批量任务，还有弹性处理（flex service tier）和 24 小时扩展缓存等选项。通过适当配置，可以在异步场景下进一步提高命中率。
最后，一个常见疑问，缓存有没有副作用？会不会影响模型效果？
答案是没有。只要前缀一致，缓存和重新计算得到的结果是一样的。所谓的 “权衡” 更多发生在你为了提高命中率而调整上下文策略时，而不是缓存机制本身。
简单说，提示词缓存不是一个锦上添花的优化，而是构建成熟 AI 应用时必须考虑的基础能力。很多成本差距，不是模型能力差距，而是工程细节差距。
如果你在做智能客服、编程助手、图像批处理、长对话智能体，或者任何长上下文场景，提示词缓存值得单独花时间设计一遍。省下的不是几分钱，而是整个系统的效率。
