← Retour aux guides

Prompt Caching 入门：原理、配置与省钱实战

Prompt Caching 是什么？

Prompt caching（提示词缓存）是一种降低大模型调用成本和延迟的技术。它的核心思路很简单：如果你的请求里有一大段长期不变的内容，例如系统提示词、产品文档、代码库说明、角色设定或工具规范，模型服务可以把这部分内容预处理后缓存起来。下次你发送相同前缀时，系统不需要重新完整计算这段内容，只需要复用缓存结果，再处理新增的用户问题。

对开发者来说，prompt caching 最适合用于“固定上下文很长、用户问题很短”的场景，比如客服知识库问答、Claude Code 代码分析、RAG 文档问答、Agent 工具说明、多轮对话中的固定系统规则等。它通常不能让输出免费，但能显著降低可缓存输入 token 的费用，并减少首 token 延迟。

它是如何工作的？

你可以把一次模型请求理解为三段：固定前缀、变化输入和模型输出。固定前缀包括 system prompt、开发者指令、长文档、工具定义等；变化输入通常是用户的新问题；输出则是模型生成的回答。Prompt caching 会对固定前缀生成可复用的内部表示，并用缓存键记录。当后续请求的前缀保持一致，且满足模型厂商的缓存规则时，就会产生缓存命中。

需要注意，缓存不是简单的字符串存储。模型通常缓存的是经过 token 化和预计算后的上下文状态。因此，哪怕你只改了固定前缀中的一个标点、空格、时间戳或动态 ID，也可能导致缓存失效。要想稳定命中缓存，关键是让可缓存部分尽量长、尽量靠前、尽量不变。

步骤一：找出你的“稳定上下文”

先审查你的请求结构，把内容分成“长期不变”和“每次变化”两类。长期不变内容可以包括品牌语气、回答格式、安全规则、API 文档、数据库字段解释、代码仓库结构、FAQ 知识库等。每次变化的内容则包括用户提问、当前页面状态、临时参数、最新日志等。

• 适合缓存：几千到几十万 token 的文档、代码、工具说明、固定 system prompt。
• 不适合缓存：时间戳、随机数、用户昵称、实时搜索结果、每次都会变化的短文本。

步骤二：重排消息，把稳定内容放在前面

缓存通常依赖请求前缀匹配，所以你应该把稳定内容放在最前面，把动态内容放在最后。例如先放 system 规则，再放知识库正文，再放工具规范，最后才放用户问题。不要在固定前缀中插入“当前时间是……”这类动态字段，否则每次请求都会变成新前缀。

一个实用模板是：第一段写角色与输出规范，第二段放长期知识库，第三段放工具调用规则，第四段再加入用户本次问题。这样即使用户问题不同，前面的大段内容仍然有机会命中缓存。

步骤三：在代码中保持前缀完全一致

很多缓存命中失败并不是模型问题，而是工程细节导致的。比如 JSON 序列化顺序变化、模板多了换行、文档每次重新拼接顺序不同、系统提示词自动加入版本号。建议把固定 prompt 存成版本化文件，例如 prompt_v3.txt；更新时明确升级版本，不要在运行时临时改写。

• 固定模板：避免每次生成不同空格、换行或排序。
• 固定文档顺序：知识库分块拼接时保持稳定排序。
• 隔离动态字段：把用户 ID、时间、会话状态放到后置消息中。

步骤四：通过 59API 接入 Claude 或 GPT

如果你想以更低成本测试 prompt caching，59API 是一个很实用的 AI API 中转选择。它提供按量付费访问 Claude（Opus、Sonnet、Haiku、Fable）和 GPT 模型，API base URL 为 https://api.59api.com，并兼容 Claude Code、Codex 以及常见 OpenAI SDK。对已有项目来说，通常只需要替换 base URL 和 API Key，就能把调用切到 59API。

59API 的优势在于价格低、接入简单、模型质量保持官方原生水准，不做降级替换。对于需要频繁发送长上下文的开发者，prompt caching 加上低价 API relay，能同时优化输入成本和整体预算。如果你正在做 Agent、代码助手或文档问答，可以考虑注册 59API 账号并用小流量先跑一轮成本对比。

步骤五：设计一次缓存命中测试

测试时准备两次几乎相同的请求。第一次请求包含长 system prompt 和长文档，再提出问题 A；第二次请求保持前面长内容完全一致，只把最后的用户问题改成问题 B。观察控制台或响应中的 token 计费字段，如果提供 cached tokens、cache read、cache creation 等指标，就可以判断是否命中。

如果没有看到缓存收益，按顺序检查三件事：第一，模型是否支持 prompt caching；第二，固定前缀长度是否达到缓存门槛；第三，两次请求的前缀是否真的一致。很多模型要求可缓存内容达到一定 token 数量，太短的 prompt 即使重复也未必触发明显收益。

步骤六：在生产环境中优化成本

上线后不要只看单次请求价格，而要看“每个有效回答的平均成本”。你可以记录总输入 token、缓存命中 token、输出 token、请求延迟和失败率。对于长文档应用，建议把大型稳定上下文做成少数几个版本，而不是为每个用户生成不同版本。这样缓存复用率更高，成本曲线更可控。

• 高频场景：客服机器人、代码库问答、内部知识助手收益最大。
• 低频场景：一次性长文本分析也有帮助，但缓存复用有限。
• 版本管理：文档更新后会产生新缓存，旧缓存命中率会下降。

常见误区

第一，prompt caching 不等于把回答缓存起来。它缓存的是输入上下文的计算结果，不会直接复用旧答案。第二，缓存命中不代表整次调用免费，变化输入和输出仍然会计费。第三，不要为了缓存牺牲安全性，敏感用户数据不应混入公共固定前缀。第四，缓存策略要和模型选择一起考虑：长推理任务可以选 Claude Sonnet 或 Opus，低成本高并发任务可评估 Haiku 或合适的 GPT 模型。

总结：什么时候应该使用 Prompt Caching？

当你的应用需要反复发送同一段长上下文，并且每次只改变少量用户输入时，就应该使用 prompt caching。它的关键实践是：稳定内容前置、动态内容后置、模板完全一致、监控缓存指标。结合 59API 这类低成本、兼容 OpenAI SDK 与 Claude Code 的 API relay，开发者可以在不牺牲模型质量的前提下，更便宜地构建长上下文 AI 应用。

Tarifs · Docs