1. 为什么你的 LLM 账单里输入 Token 总是最贵的那一项如果你正在用大模型做长文档问答、代码补全或者 Agent 工作流大概率会遇到一个很反直觉的现象明明用户只问了一句话账单里却扣了几万 Token。原因很简单每次请求你都要把系统提示词、知识库片段、历史对话、工具定义全部重新塞进去模型每次都要从头算一遍。这些内容在多次请求之间高度重复但计费系统不会因为你重复发送就给你打折。Prompt Caching 就是来解决这个问题的。它让服务端把请求前缀里已经算过的中间状态缓存下来下一次遇到相同前缀时直接复用不再重复计算。对使用者来说最直接的好处是缓存命中的输入 Token 单价大幅下降同时首 Token 延迟也会明显缩短。Anthropic 官方给出的数据是长提示词延迟最多降低 85%缓存输入单价约为常规输入的十分之一OpenAI 也提供自动缓存命中部分同样有折扣。但这里有个前提你得有一个稳定的统一入口来观察缓存到底有没有命中。如果今天用这个通道、明天换那个通道缓存前缀对不上命中率会掉得很难看。这也是我这次用 TaoToken 统一 Key 来做实测的原因——一个 Key 走所有模型请求头、前缀、计费口径都能对齐方便对比。这篇文章会拆三件事第一缓存命中和未命中的 Token 计费到底差在哪第二给你一份可以直接复制的请求头与前缀配置第三用脚本跑出不同前缀长度下的命中率和成本变化帮你判断自己的业务值不值得开缓存。适合正在做 RAG、长上下文 Agent、批量文档处理的开发者也适合单纯想把 API 账单压下来的团队。需要先说明一点缓存不是万能的。它只对“前缀稳定”的请求有效。如果你的提示词每次开头都在变缓存基本不会命中开了也白开。所以下面的实测重点就是帮你找到那个“前缀该多长、该多稳定”的平衡点。2. TaoToken 统一 Key 接入把缓存命中率变成可观测指标在讲配置之前先解决一个工程问题你怎么知道缓存命中了大多数模型的响应 usage 字段里会区分cache_creation_input_tokens、cache_read_input_tokens和普通input_tokens。如果你用的是多个通道、多个 Key这些字段的口径可能不一致统计起来很痛苦。用 TaoToken 的统一 Key所有请求走同一个 API 入口usage 结构一致命中率就能直接算出来。TaoToken 的定位是一个统一的模型调用通道官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。它的价值在于你不需要为每个模型单独维护一套鉴权和计费逻辑一个 Key 就能覆盖对话、编码、Agent 等场景。对于缓存实测来说这意味着你可以用同一套脚本、同一套统计口径去对比不同模型、不同前缀长度下的命中表现。接入步骤不复杂但有几个细节容易踩坑。第一步是拿到 Key进入控制台的 API Keys 页面创建地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。创建后立刻复制保存页面刷新后就不再完整显示。第二步是确认你要调用的模型 ID不同模型的缓存策略不一样Anthropic 系需要显式标记缓存断点OpenAI 系则是自动缓存。第三步是把 Base URL 指向 TaoToken 的 API 地址而不是各家官方地址。这里要强调一个概念缓存是“前缀缓存”不是“结果缓存”。服务端缓存的是注意力机制里的 K 和 V 矩阵也就是前缀经过 Transformer 计算后的中间状态。它不会缓存最终回答所以你发同样的提示词两次回答内容仍然可能不同但第二次的输入 Token 会便宜很多。理解这一点很关键否则你会误以为缓存能保证输出一致。对于做 RAG 的同学这意味着你的提示词结构要重新设计。把最稳定、最长的部分放在最前面比如系统角色定义、工具说明、固定的知识库头部把变化的部分放在后面比如用户当前问题、检索到的动态片段。前缀越稳定、越长缓存收益越大。反过来如果你把用户问题放在最前面后面再跟一大堆固定内容缓存几乎不可能命中。TaoToken 在这里的另一个好处是它让你可以在同一个 Key 下切换模型做对比。比如你可以先用 Claude 系模型测显式缓存再用 GPT 系模型测自动缓存统计脚本不用改。对于要写进生产环境的团队这种一致性比省几块钱更重要因为它决定了你的成本模型是否可预测。3. 可复制的请求头与缓存前缀配置清单这一节是全文最核心的部分直接给你能跑的配置。先讲 Anthropic 系的显式缓存因为它的控制粒度最细也最能体现缓存机制。Anthropic 要求你在请求体里用cache_control标记缓存断点通常放在系统提示词或长文档块的末尾。断点之前的内容会被缓存默认存活 5 分钟也可以设置更长的 TTL。下面是一个最小可用的请求体结构注意cache_control的位置{ model: claude-sonnet-4-20250514, max_tokens: 1024, system: [ { type: text, text: 你是一个严谨的技术文档助手回答必须基于给定资料不得编造。以下是产品手册全文...(此处省略数千字固定内容)..., cache_control: { type: ephemeral } } ], messages: [ { role: user, content: 请总结第三章的核心结论。 } ] }关键点cache_control放在system数组最后一个块的末尾表示“到这里为止的内容都缓存”。如果你有多个长文档块可以在每个块末尾都加断点Anthropic 最多支持 4 个断点。断点越多缓存粒度越细但管理成本也越高。实测下来对于单一长系统提示词的场景一个断点就够了。请求头方面走 TaoToken 统一入口时鉴权头用 Bearer 格式curl https://taotoken.net/api/v1/messages \ -H Content-Type: application/json \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -d request.json注意 Anthropic 原生接口用的是x-api-key而不是Authorization: Bearer这一点在切换通道时最容易出错。如果你用的是 OpenAI 兼容格式则用Authorization: Bearer $TAOTOKEN_API_KEY。两种格式 TaoToken 都支持但不要混用否则会返回 401。对于 OpenAI 系模型缓存是自动的你不需要加任何标记。但有一个隐含要求请求前缀要足够长通常超过 1024 Token 才会触发缓存。OpenAI 会在响应 usage 里返回prompt_tokens_details.cached_tokens你可以据此判断命中情况。配置上你只需要保证前缀稳定比如把系统提示词写成固定字符串不要在里面插入时间戳、随机 ID 或用户昵称。如果你用 Cline、Cursor 这类编码工具配置通常写在 settings 里。以 Cline 的 MCP 配置为例你需要填三件套Base URL、API Key、Model ID。Base URL 填https://taotoken.net/apiAPI Key 填你在控制台创建的 KeyModel ID 填具体模型名。三件套缺一不可尤其是 Model ID 写错会直接报模型不存在。Claude Code 的接入类似在配置文件里指定ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY指向 TaoToken 的地址即可。还有一个容易忽略的点缓存前缀里不要包含动态内容。我见过有人在系统提示词里写“当前时间是 {{now}}”结果每次请求前缀都变缓存命中率直接归零。正确做法是把动态内容放到 user 消息里系统提示词保持完全静态。4. 命中率验证脚本与不同前缀长度的成本对比配置写完接下来要验证。光看文档说“能省 10 倍”没用得自己跑数据。下面这个 Python 脚本会连续发送多次请求统计缓存命中和未命中的 Token 数并算出实际成本。你可以直接复制修改。import os import time import requests API_URL https://taotoken.net/api/v1/messages API_KEY os.environ[TAOTOKEN_API_KEY] # 构造不同长度的固定前缀用于对比 def build_prefix(repeat): base 以下是一段用于测试缓存命中率的固定技术文档内容请仔细阅读并记住。 return base * repeat def send_request(prefix_text, question): headers { Content-Type: application/json, x-api-key: API_KEY, anthropic-version: 2023-06-01, } body { model: claude-sonnet-4-20250514, max_tokens: 256, system: [ { type: text, text: prefix_text, cache_control: {type: ephemeral}, } ], messages: [{role: user, content: question}], } resp requests.post(API_URL, headersheaders, jsonbody, timeout60) resp.raise_for_status() return resp.json() def run_test(repeat, rounds5): prefix build_prefix(repeat) stats {cache_read: 0, cache_create: 0, normal_input: 0} for i in range(rounds): data send_request(prefix, f这是第 {i1} 次提问请回复 OK。) usage data.get(usage, {}) stats[cache_read] usage.get(cache_read_input_tokens, 0) stats[cache_create] usage.get(cache_creation_input_tokens, 0) stats[normal_input] usage.get(input_tokens, 0) time.sleep(1) return stats if __name__ __main__: for repeat in [10, 50, 100, 200]: result run_test(repeat) total result[cache_read] result[cache_create] result[normal_input] hit_rate result[cache_read] / total if total else 0 print(f前缀重复 {repeat} 次 | 总输入 {total} | 缓存读取 {result[cache_read]} | 命中率 {hit_rate:.2%})跑这个脚本时第一轮请求会看到cache_creation_input_tokens很大cache_read_input_tokens为 0因为缓存刚建立。从第二轮开始cache_read会显著上升。如果第二轮命中率还是 0说明前缀没对上检查是不是有动态内容混进去了。实测数据大致是这样的前缀重复 10 次约几百 Token时命中率不稳定因为前缀太短可能没达到缓存阈值重复 50 次时命中率开始明显上升重复 100 次以上时后续请求的缓存读取占比能稳定在 80% 以上。成本上假设常规输入单价是 3 美元/百万 Token缓存读取是 0.3 美元/百万 Token那么命中率 80% 意味着你的输入成本大约降到原来的 36% 左右。前缀越长、调用越频繁这个比例越划算。但要注意一个反直觉的点缓存写入本身是有成本的。Anthropic 的缓存写入单价通常比常规输入还贵大约是 1.25 倍。所以如果你的前缀只用一次就再也不用了开缓存反而更贵。缓存只有在“同一前缀被反复使用”时才有正收益。这也是为什么我建议你先用脚本跑一周的真实流量统计前缀复用率再决定要不要在生产环境开启。对于 OpenAI 系模型验证方式类似只是字段名不同看prompt_tokens_details.cached_tokens。你可以把上面的脚本改成 OpenAI 兼容格式Base URL 同样指向 TaoToken统计逻辑不变。5. 缓存不生效时的常见报错与排查路径缓存这块的报错往往不直观因为请求本身是成功的只是没省钱。下面是我踩过的几个典型问题按排查顺序列出来。第一个是 401 鉴权失败。如果你从 Anthropic 原生切到 TaoToken最容易犯的错是请求头没改。原生用x-api-keyOpenAI 兼容格式用Authorization: Bearer。混用会直接 401。排查方法先用 curl 发一个最小请求确认鉴权通过再上业务逻辑。如果报invalid x-api-key检查 Key 是否复制完整有没有多余空格。第二个是local proxy failed或连接超时。这类报错通常不是缓存问题而是网络出口或 Base URL 写错。确认你的 Base URL 是https://taotoken.net/api不要多加/v1或少写路径。有些工具的配置项叫base_url有些叫api_base填错位置也会导致请求发不出去。第三个是reading choices相关的解析错误。这通常出现在 OpenAI 兼容格式下响应结构和你预期的字段对不上。比如你按 Anthropic 的content[0].text去解析但实际返回的是 OpenAI 的choices[0].message.content。解决办法是打印完整响应体看清结构再写解析逻辑。缓存字段也一样Anthropic 在usage.cache_read_input_tokensOpenAI 在usage.prompt_tokens_details.cached_tokens别搞混。第四个是 OAuth 或 token 过期。如果你用的是某些客户端的 OAuth 流程token 有效期可能很短过期后请求会失败。这类问题在 Claude Code 接入时比较常见。建议直接用 API Key 方式避免 OAuth 的复杂性。配置时把 Base URL、Key、Model ID 三件套写全缺一个都会报错。第五个也是最隐蔽的请求成功、usage 正常但cache_read_input_tokens始终为 0。这几乎可以肯定是前缀不稳定。排查方法是把每次请求的 system 内容打印出来做 diff看有没有细微差异比如空格、换行、时间戳、随机 ID。我遇到过因为 JSON 序列化顺序不同导致前缀哈希变化的情况解决办法是固定序列化方式或者把动态字段移到 user 消息里。还有一个坑是缓存 TTL。Anthropic 默认缓存 5 分钟如果你的请求间隔超过 5 分钟缓存就失效了下一轮又要重新写入。对于低频调用的业务缓存收益会大打折扣。如果你的场景是每隔半小时跑一次批处理那缓存基本帮不上忙。这种情况下与其纠结缓存不如优化提示词长度把不必要的上下文砍掉。排查完这些如果命中率还是不理想建议用第 4 节的脚本做一次受控实验固定前缀、固定问题、连续发 10 次看命中率曲线。如果前几次命中率低、后面高说明缓存机制正常只是需要预热。如果始终为 0那就是配置或前缀结构的问题。6. 把缓存接进你的工作流从验证到长期编码场景跑通验证之后下一步是决定怎么用。这里分两种场景给建议。如果你的业务是长文档问答、合同审查、知识库检索这类“固定大前缀 动态小问题”的模式缓存几乎是必开的。做法是把系统提示词、工具定义、知识库头部全部静态化放在最前面并标记缓存断点用户问题放最后。这样每次请求只有问题部分是“新”的其余全部命中缓存。实测下来这类场景的输入成本能压到原来的三到四成首 Token 延迟也能明显改善。如果你的业务是长期编码、Agent 工作流缓存的价值更大因为这类场景的上下文会越滚越长。每一次工具调用、每一轮对话都会追加内容如果不做缓存Token 消耗是线性增长的。这时候建议用 Coding Plan 这类长期方案来管理调用地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。它的思路是把编码场景的调用集中管理配合缓存前缀策略让长会话的成本可控。对于想先验证模型效果再决定接入的同学可以先用模型对话页面做小规模测试地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。在里面手动构造长前缀观察响应速度和回答质量确认没问题再写进代码。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言的完整示例包括请求头、参数、错误码说明。最后给一个实用建议不要一上来就在生产环境全量开缓存。先用第 4 节的脚本跑一周真实流量的采样统计前缀复用率和命中率算出实际节省比例。如果节省比例低于 20%说明你的前缀结构需要调整或者业务本身不适合缓存。如果高于 50%那就放心开同时把缓存命中率加进监控面板一旦掉下来就告警。缓存不是一次性配置而是一个需要持续观察的运行时指标。把它当成你 LLM 成本优化里的一个常规项而不是一个开关。