Prompt 缓存为什么没命中？用三次请求验证

Prompt 缓存复用的是先前请求已经处理过、且符合条件的输入前缀，不是复用上一次回答。模型仍要处理新问题并生成新内容。账单和响应时间是否改善，先取决于后续请求能否按该提供商的规则读到足够长、完全匹配的前缀。因此，第一步不是套用一个“节省百分比”，而是查看接口究竟记录了多少缓存写入与读取。

本课产物是一份三请求试验记录。单次命中不代表典型命中率，一次响应较快也不能证明延迟已经改善。

先准备合格且安全的稳定前缀

整次试验只选一家提供商、一个 API、一个模型版本和一个区域。用公开或虚构的参考资料模拟真正会反复使用的内容，把不变的指令和资料记作 P，把每次不同的问题放在 P 后面。不要把时间、请求编号、用户姓名或实时检索结果放在 P 前面。工具定义、输出格式和会影响前缀的生成设置也保持一致。

用所选提供商的计数方式确认 P 的 token 数。各模型的最低可缓存长度不同，有些还受请求配置影响。不要为“凑够门槛”加入无用长文；多出的输入可能抵消缓存收益。还要确认资料值得复用、没有超过上下文限制。示范时使用非敏感资料，真正处理业务文档前核对提供商的保留与数据要求。

提供商与接口	先核对启用方式和门槛	从哪里读到结果
OpenAI	当前文档对 GPT-5.6 及更新模型给出 1,024 个可见输入 token 的最低长度，并提供隐式或显式断点；旧模型规则不同。若模型支持显式断点，可标在 P 末尾；否则检查隐式断点能否覆盖 P。	usage.input_tokens_details.cached_tokens，以及有返回时的 cache_write_tokens
Anthropic	使用顶层自动或内容块级 cache_control，最低长度按模型确定。后缀常变化时，把显式断点放在最后一个稳定块。默认保留五分钟，可选一小时，但价格不同。	usage.cache_creation_input_tokens、cache_read_input_tokens、input_tokens
Google Gemini	Gemini 2.5 及更新模型默认支持隐式缓存，但不保证命中。Interactions API 只有隐式模式；generateContent 还提供测试版显式缓存对象，并按存储时长计费。须核对具体模型门槛。	Interactions 的 usage.total_cached_tokens；generateContent 的 usage_metadata
DeepSeek	默认开启磁盘上下文缓存，但读取必须完整匹配已持久化的前缀单元。共同前缀可能经过额外一次请求才成为单独的单元。	usage.prompt_cache_hit_tokens 与 prompt_cache_miss_tokens

这些字段的含义和计费口径并不完全相同，不应把原始数值拼成一个跨平台“命中率”。换算金额时，另查具体模型、日期和缓存模式适用的价格表。

按顺序发送三次请求

1. **请求 1，观察写入机会：**发送 P 加问题 A。保存完整的实际请求、响应中的用量字段、开始时间、可获取时的首 token 时间、总耗时、回答与验收结果。如果没有写入记录，可能是 P 不够长、断点不合格，或所选接口不提供该字段。
2. **请求 2，复用相同前缀：**等第一次响应开始后，在文档规定的缓存有效期内，发送完全相同的 P 加另一个简短问题 B。模型、工具、格式和其他影响前缀的设置保持不变。再次保存同样字段。有读取记录才能证实这次确实复用；没读到时应继续诊断，不能马上断定提供商不支持缓存。
3. **请求 3，改动前段作为对照：**只把 P 开头一处不影响任务含义的措辞改成 P′，仍提问 B，仍按相同标准验收。比较请求 2 与请求 3 的读取量。读取下降支持“前缀匹配被破坏”的解释；如果更早的系统内容或工具定义仍匹配，数字不一定降到零。

三次请求应顺序执行。Anthropic 文档说明，首次写入的条目要到首次响应开始后才可供后续读取，因此同时发出前两次请求不能可靠检验复用。其他平台的路由、保留时间或尽力而为机制，也可能让表面相同的文本没有命中。以原始响应字段为准，不用速度猜命中。

案例一：两次提问共用公开服务指南

客服团队用同一份公开产品指南回答取消预订和改期问题。P 放经确认的指南正文与回答格式。请求 1 问“预订后还能取消吗？”，请求 2 问“能否更改日期？”，只替换末尾的问题。如果所选接口在指南末尾有合格断点，第二次请求就能检验是否读取指南前缀，同时正常处理新问题。

复核者逐条检查答案是否符合指南，包括例外条件和引用条款。即使第二次有缓存读取，答错也不能算作工作流成功。把两次调用与复核的费用一起记录。指南长度和问题属于试验输入，任何 token 数都应以实际接口响应为准，不能凭示意案例编造。

案例二：时间戳放错位置造成预期落空

一个 Agent 先写“报告生成于 09:14”，再附上长期不变的参考指南。下次请求改成“09:15”，在进入指南前，前缀就已发生变化。虽然指南本身没变，请求 2 仍可能几乎读不到指南缓存。把时间戳和当前问题移到稳定指南之后；支持显式断点时，将断点标在最后一个稳定块，而不是会变化的块上。

只改这一处后重跑三请求试验。某些平台仍可能读取更早的系统或工具内容；DeepSeek 也可能在后续请求中把新发现的共同前缀持久化。应按照该平台的断点与用量字段解释结果，不要要求每次对照的读取量恰好为零。

用合格任务成本决定是否采用

每次至少保留提供商、API、模型、时间、P 的 token 数、缓存模式或断点、保留设置、输入输出用量、读取与写入字段、价格版本、延迟和验收状态。若显式缓存有存储费用，也要加入账单。先按该接口实际价格算出一批任务的模型、存储、工具和复核总成本，再除以通过相同验收标准的任务数；如果没有任务通过，就标明这一批没有可交付的单位成本。

用相同任务构成和质量门槛，对少量重复批次比较改造前后结果，同时展示缓存 token、完整成本、完成时间与被拒收的答案。缓存读取得更多，但答案质量下降或复核变重时，整体工作流未必受益。

不适用边界

这份试验只诊断输入前缀能否复用，不能代表全部流量，也不能证明将来的价格、保留政策或延迟收益。若请求很少共享合格前缀、共享内容经常变化，或隐私与存储要求不允许该缓存路径，就不适合把缓存当作主要优化手段。模型、接口、Prompt 结构或价格变化后，应重新核对官方文档与响应字段。